Два RecId у одной записи таблицы

[EVGL]

Вот уже жертвы рекламы пошли. Используйте штатную процедуру проверки RecId. Сидит совершенно бесплатно в форме SQL Administration и исправно работает.

[sparur]

Цитата:

Сообщение от EVGL

Вот уже жертвы рекламы пошли. Используйте штатную процедуру проверки RecId. Сидит совершенно бесплатно в форме SQL Administration и исправно работает.

у меня таблица MarkupTrans, где TransRecId имеет EDT RecId, а не RefRecId.

Запуск данной процедуры не убьет ли мне ВСЕ ссылки в принципе?

[mazzy]

Цитата:

Сообщение от sparur

Запуск данной процедуры не убьет ли мне ВСЕ ссылки в принципе?

ВСЕ - не убьет.
Убьет только те ссылки, которые находятся в полях с типом, не унаследованнsм от recRefId.

[sparur]

Цитата:

Сообщение от mazzy

ВСЕ - не убьет.
Убьет только те ссылки, которые находятся в полях с типом, не унаследованнsм от recRefId.

под словом ВСЕ я это и подразумевал хорошо что непоспешили и не запустили эту процедуру

[sparur]

Возвращаясь к теме об отрицательных RecId, дефрагментации этого самого RecId, его разрядности и пр....

Меня вот интересует такой вопрос:

допустим гипотетическую ситуацию, когда у нас имеется идеальное состояние, т.е. нет никакой дефрагментации, все ок, дырок нет в принципе (хоть это и невозможно) что будет когда значение recId превысит волшщебную цифру в 2^32 (~4млрд).

Что в этом случае делать?? ведь данная цифра хоть и велика, но все же recId распределяется по ВСЕМ таблицам в пределах отдельной компании. А это значит если контора крупная с большим ежедневным оборотом, то год-два и как не крути, а проблема встанет!!!

Какой выход из ситуации?

[mazzy]

Цитата:

Сообщение от EVGL

Вот уже жертвы рекламы пошли. Используйте штатную процедуру проверки RecId. Сидит совершенно бесплатно в форме SQL Administration и исправно работает.

Вот они - спокойные пользователи международного функционала.
Где тип полей со ссылками на recId унаследованы от типа refRecId...