01.03.2007, 18:14 | #1 |
Участник
|
Подскажите, пожалуйста, ссылку на обсуждение проблемы с задвоенными RecId
Со вчерашнего дня юзеры не могут зависти ни одного договора, система утверждает что запись уже существует. В свойствах таблицы договоров нахожу CreateRecIdIndex стоит Yes Меняю свойство на No, записи стали создаваться, однако RecId упорно с каждой новой записью повторяет RecId ранее созданных в этой таблицы записей. Не знание того, чем это может быть чревато в дальнейшем (я имею ввиду дубли и то что индекс перестанет существовать), напрягает. Может кто-либо дать рецепт лечения? |
|
01.03.2007, 21:44 | #2 |
Участник
|
|
|
02.03.2007, 06:26 | #3 |
Участник
|
Спасибо, Сергей!
Можно вопрос, как определить есть ли в моем приложении ссылки по RecId не наследованные от RecIdRef, глобально по всему AOT? |
|
02.03.2007, 09:51 | #4 |
Участник
|
Цитата:
RecId - это обычное целое число. Я не знаю, как униварсальным алгоритмом гарантировано распознать, что целое число является не числом, а RecID. |
|
02.03.2007, 10:11 | #5 |
Участник
|
Однако засада
Спасибо. |
|
02.03.2007, 11:00 | #6 |
Участник
|
Можно попробовать поискать не по реквизитам полей таблицы, а по способу их наполнения.
Если поле содержит в себе ссылку на RecId, то где-то должен быть явно прописан код такого присвоения. Нечто вроде MyTab.MyRef = Tab.RecId MyTab.update() Т.е. сначала находишь все поля, которые наследованы от RecIdRef, а потом по AOT ищешь где в коде напрямую используется каждое из этих полей, а также собственно RecId. Потом повторяешь операцию для найденных полей, поскольку возможны "ссылки на ссылку" Разумеется, работенка "та еще". Но, по крайней мере, это нечто, что может быть хотя бы частично автоматизировано. |
|
02.03.2007, 22:43 | #7 |
Участник
|
но это тоже не дает 100% гарантии.
к сожалению. |
|
05.03.2007, 06:51 | #8 |
Участник
|
Думаю идея здравая, не смотря на то что придется глаза поломать изрядно, просматривая найденный код.
|
|