Миф об уникальности RecId?

[Vadik]

Цитата:

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

Получается, что уникальность RecId - это миф?

Миф - это идея о том, что в системе есть функциональность, которая будет искать свободные "дырки" в диапазонах выделенных значений RecId
А уникальность RecId в таблице при наличии уникального индекса по этому полю - не миф
см. Как выполнять дефрагментирование RecID

[Alenka]

Дефрагментация стандартными способами на нашей базе невозможна из-за ее размера (около 500Гб) и потере целостности (стандартный метод не правит те ссылки на RecId, которые хранятся в таблицах).
Как же уникальность не миф, когда я получила по крайней мере 2 записи с одинаковыми RecId?

[Vadik]

Цитата:

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

Дефрагментация стандартными способами на нашей базе невозможна из-за ее размера (около 500Гб) и потере целостности (стандартный метод не правит те ссылки на RecId, которые хранятся в таблицах)

Поразительно, как быстро Вы прочли всю ветку по ссылке из первого моего сообщения
Стандартный метод корректно правит ссылки в пределах одной компании там, где они оформлены корректно (с использованием правильных EDT)
Делает он это неторопливо, но даже в Вашем случае за сутки отработать должен может

[Alenka]

2 Vadik : Просто я ее уже читала раньше.
2 oip: Все правильно, я неверно понимала понятие уникальности. Ошибка при вставке и сообщение о существующей записи появляются при создании записи с существующим RecId в этой же таблице. При этом запись все-таки создается со следующим RecId.

Спасибо за помощь и наставления .

[Vadik]

Цитата:

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

2 Vadik : Просто я ее уже читала раньше

Значит невнимательно читали, потому что Ваши выводы и аргументация ошибочны

Цитата:

Дефрагментация стандартными способами на нашей базе невозможна из-за ее размера (около 500Гб) и потере целостности (стандартный метод не правит те ссылки на RecId, которые хранятся в таблицах)

[Alenka]

Согласна, целостность может и не потеряется (нельзя ручаться за правильность EDT всех полей, использующих RecId), но время, требующееся для дефрагментации такой базы, по-моему вы указали сомнительное. Хотя продолжать дискуссию на эту тему - дело неблагодарное, т.к. проверить время выполнения дефрагментации на нашей базе не представляется возможным. Но в той же ветке, что вы указали есть примеры, когда 40Гб база дефрагментировалась несколько дней. Оптимизма это не прибавляет.

[Vadik]

Цитата:

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

Согласна, целостность может и не потеряется (нельзя ручаться за правильность EDT всех полей, использующих RecId)

И проверить корректность EDT в своих кастомизациях тоже не представляется возможным, и вспомогательных джобов для этого на форуме не постили

Цитата:

.. но время, требующееся для дефрагментации такой базы, по-моему вы указали сомнительное

Ну, Вы сомневаться-то сомневайтесь, но грязных намеков делать не надо - время самое что ни на есть реальное. Всего-то чуть менее полугода в отладчике и Query analizer-е

Цитата:

Хотя продолжать дискуссию на эту тему - дело неблагодарное, т.к. проверить время выполнения дефрагментации на нашей базе не представляется возможным

Ну как обычно - ни проверить, ни попробовать, ни исправить ошибки не представляется возможным, остается сидеть на попе и горевать о несовершенстве мира подобно Марвину. Ну нельзя же так - позитивнее как-то надо

Цитата:

Но в той же ветке, что вы указали есть примеры, когда 40Гб база дефрагментировалась несколько дней. Оптимизма это не прибавляет.

Да чего там - мы все умрем, Гольфстрим остановился (Маззи писал уже)

[egorych]

Цитата:

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

Дефрагментация стандартными способами на нашей базе невозможна из-за ее размера (около 500Гб) и потере целостности (стандартный метод не правит те ссылки на RecId, которые хранятся в таблицах).

Надо просто найти поля где хранятся ссылки на RecID и исправить EDT поля на RefRecId - тогда обновляться все будет корректно.