Как выполнять дефрагментирование RecID

[Yaroslav Batozskiy]

Цитата:

Что смутило меня: Скрипт находит такие поля, которые могут являться ссылами по recid. Делает это он довольно достоверно.

Фаза 2, шаг 8—сканер, который пытается найти соотвествующую таблицу к каждому целому полю в системе, и считает такие параметры, как процент попаданий и релевантность.
Потом отбрасывает то, что является случайным. В результате имеем около десятка полей (с сотней вариантов), который _с точки зрения сканера_ могут быть ссылками по RecId. Но на самом деле они могут таковыми и не являться. Обычно, просто по названию полей и по имени таблицы, на которую, как предположил сканер, ссылается поле видно, может такое быть, или не может. Поэтому результат работы сканера можно просмотреть _только_ вручную, руководствуясь процентом попаданий и еще тремя параметрами. Формализовать это сложно, может, потом сделаю
Ограничением алгоритма является то, что чем меньше строк таблице, тем меньше точность прогнозирования. И если в таблице есть только одна строка со ссылкой, которая другими путями найдена не была, то сканер её тоже не найдет. Отсюда слово «довольно» в фразе «ищет довольно достоверно». Но если в БД в таблице, например, VendSettlement поле TransRecId как ни-будь переименовать или сдублировать, то сканер это точно обнаружит, и покажет достоверность более 90%. Сканер—это уже новая доработка скрипта.

Цитата:

Нам ли оперировать такими терминами, как "иногда некорректно работать"? Ошибка или есть или ее нет.

Если Вы можете привести описание шагов, с помощью которого можно воспроизвести именно _ошибку_, и MBS это признает именно _ошибкой_, тогда почему Вы еще не зарегистрировали это в Сервисной системе MBS. Я пока вижу неправильную работу только при нарушении логической целостности данных.

Цитата:

Если есть ссылка, а запись, на которую она ссылается, отсутствует, и таких ссылок несколько

Ошибочные ссылки по Recid обнуляются и строки пишутся в таблицу FixRecidLostedRefs (тот самый лог) c указанием причины, значения ссылки, старого и нового RecId битой строки. Что с ними делать--я думаю можете догадаться сами--что то удалить, что то исправить (по tablename видно, особеноо если это *Settlement)

Цитата:

и есть несколько записей, на которые нет ссылок, как это будет автоматически разгребаться?

Именно это, по моему, разгребаться не должно. Скрипт все таки только дефрагментирует базу и избавляет её от ошибок логической целостности, а не лечит все ошибки пользователей, еще и с анализом первички

[Yaroslav Batozskiy]

Правильно сравнить положительные и отрицательные RecId просто--я к отрицательным прибавляю 4 миллиарда (2^32). После этого и сравнивает правильно, и расстояния считает верно

[Yaroslav Batozskiy]

Цитата:

Кстати, был в какой-то ветке вопрос (в какой, уже не помню), какие таблицы не переживут дефрагментацию RecId. smmTransLog

А почему собственно ???

[Vadik]

Цитата:

Изначально опубликовано Yaroslav Batozskiy
Если Вы можете привести описание шагов, с помощью которого можно воспроизвести именно _ошибку_, и MBS это признает именно _ошибкой_, тогда почему Вы еще не зарегистрировали это в Сервисной системе MBS. Я пока вижу неправильную работу только при нарушении логической целостности данных.

я жаловался на ошибки? не помню

Цитата:

Я имел ввиду, что сопоставление, IMHO, перестанет "иногда некорректно работать", если в этой таблице не будет строк с неправильными ссылками

- это же не мои слова.. и почерк не мой..

но не будем цепляться к словам

я никак не хотел поставить под сомнение целебные свойства Вашего скрипта, просто спросил то, что показалось непонятным

а за описание спасибо, думаю, многим это будет интересно, почитаем обязательно, будем думать

[Vadik]

Цитата:

Изначально опубликовано mazzy
Ух. Какая полезная ветка.
Перенесу, пожалуй, в проекты.

а может, в новости партнеров? проект ведь публиковаться не будет

[Vadik]

Сегодня ночью думал

Что надумал:

Задача бьется на две части:

- Собственно перенумерация RecId. Скрипт (составление списка используемых RecId, списка неиспользуемых, перенумерация) пишется средней руки программистом на T-SQL (PL/SQL) за несколько часов)

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

Структура строится один раз для каждого сервиспака/хотфикса и один раз дополняется у клиента.

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

Т.е. мы с Вами расходимся только в том, нужно ли наделять скрипт модулем искуственного разума

У нас (у наших клиентов), насколько мне известно, проблем с переполнением RecId сейчас нет и в ближайшем будущем не предвидится (все-таки клиентская база поменьше и работать мы начинали в разное время ). Но если бы задача такая была поставлена, я бы делал именно так, как написал

P.S. к сожалению, первый раз Ваше описание алгоритма читал невнимательно (не было времени) и не догадался сохранить, а ближе к ночи Вы его немного подсократили. Надеюсь, я не спровоцировал Вас выдать какое-нибудь ноу-хау компании

[mazzy]

Цитата:

Изначально опубликовано Vadik
а может, в новости партнеров? проект ведь публиковаться не будет

даже только из-за кода, который положил ALES, по-моему, эту ветку уже можно положить в проекты.
http://www.axforum.info/forums/showt...0934#post40934

ALES, мои глубочайшие респекты. Спасибо.


Теперь по существу вопроса.
Я все ждал, когда кто-нибудь расскажет про Проверку кодов записей.
Главное меню \ Администрирование \ Периодические операции \ SQL Администрирование \ кнопка Проверка кодов записей.
Класс SysRecIdRepair.

Расскажите что это такое. Я думал, что это и есть дефрагментация RecId.

[Yaroslav Batozskiy]

Цитата:

Я все ждал, когда кто-нибудь расскажет про Проверку кодов записей.

А я все ждал, когда кто ни-будь туда заглянет... Там же все довольно просто, всего один класс, но я все же решил его не использовать. Полагаю, мнения всех "заглянуших" в него должны совпасть и между собой и с моим.

[mazzy]

пока ждали, тут такая дискуссия развернулась
а почему собственно, не стал использовать?
какие причины?

[glibs]

Цитата:

Изначально опубликовано Yaroslav Batozskiy
...
Там же все довольно просто, всего один класс, но я все же решил его не использовать. Полагаю, мнения всех "заглянуших" в него должны совпасть и между собой и с моим.
...

Ув. Yaroslav Batozskiy, так вы все-таки обвиняете процедуру проверки кодов записей в неработоспособности или наличии в ее алгоритме ошибок, или просто у вас к ней неприязнь личного плана?

Для того, чтобы сократить количество возможных "если", предположим, что перед ее запуском мы поправим табличку smmTransLog и запустим T-SQL скрипт, который убедит нас в том, что в рамках компании нет записей с RecID=0 и в рамках комппании не встречаются записи с одинаковым RecID.

Сугубо практический интерес. А то вопрос злободневный...

[Maxim Gorbunov]

2ALES

Цитата:

...опыт нескольких успешных проектов по подъему данных, позволяет мне...

Это что, персональный намек на мою некомпетентность что ли? Из разряда, "мы в отечественную так делали..."?

ALES, зачем Вы вводите людей в заблуждение. Изначально вопрос, на который Вы, по Вашему заявлению, дали исчерпывающий ответ, звучал так:

Цитата:

какие таблицы не переживут дефрагментацию RecId.

Ваш скрипт совершенно не отвечает на этот вопрос. Если честно, вообще не понятно, какая практическая ценность результатов его работы. Все, что он выдаст - поля, EDT которых наследует RecId, но не наследует RefRecId. И что? Дефрагментации и импорту данных совершенно все равно, наследует ли тип от RefRecId или нет. Обрабатываются поля, которые наследуют от RecId.

2Yaroslav Batozskiy

Цитата:

А почему собственно ???

Потому что, в smmTransLog есть поле, EDT которого не наследует от RecId, но при этом в нем сохраняются ссылки на RecId других таблиц (можно увидеть в Relation). Скрипт ALES такие поля, разумеется, не находит.

2mazzy
Наличие этой ветки в проектах у меня тоже сомнения вызвает, если честно. Пока ни одного "проекта, готового для использования" я здесь не вижу. Реклама вот точно была.

P.S.: ALES, если бы Вы в процессе накопления огромного опыта по подъему данных уделяли хоть немного внимания опыту, накопленному другими программистами, Вы бы наверняка прочли Development Best Practices Handbook. А именно параграф The Global Class в разделе Where to place the code (Dev_BPHB.chm::/Application_Design/Design_Principles/WhereToPutTheCode.htm):

Цитата:

Don't prefix calls to global methods with "Global::".

[Maxim Gorbunov]

Цитата:

Изначально опубликовано Yaroslav Batozskiy
А я все ждал, когда кто ни-будь туда заглянет... Там же все довольно просто, всего один класс, но я все же решил его не использовать. Полагаю, мнения всех "заглянуших" в него должны совпасть и между собой и с моим.

Да нет, не совпадают. Класс простой, решает ровно ту задачу, которая была поставлена перед его разработчиками. Не интеллектуальный вот только...

--- Добавлено ---
Да, еще, Ярослав, давно хотел Вам ответить, да забывал постоянно. Правда, ответ по поводу сообщения из другой ветки, ну да ничего:

Цитата:

Изначально опубликовано Yaroslav Batozskiy (http://www.axforum.info/forums/showt...0348#post40348)
Я довольно часто сталкивался со случаями неправильно расставленных EDT. Например при дефрагментировании RecId я обнаружил, что есть поля со ссылками по Recid, тип которых не наследуется от RecId (в результате чего при экспорте-импорте эти ссылки пересчитаны не будут, т.е. данные в таблице будут повреждены).

Совершенно правильно!

Цитата:

Изначально опубликовано Yaroslav Batozskiy
Пример—поле RTSLSessionTransId в таблице LedgerTrans (номер сессии трансляции, которая породила проводку).

А вот и нет. LedgerTrans.RTSLSessionTransId == RTSLSessionTrans.SessionTransId. Это вовсе не ссылка на RecId.

[ALES]

Цитата:

Изначально опубликовано Maxim Gorbunov
2ALES
Это что, персональный намек на мою некомпетентность что ли? Из разряда, "мы в отечественную так делали..."?]

2Maxim Gorbunov В исходном сообщении никаких намеков не было. На Вас никто не нападает, а Вы вдруг защищаетесь..

Цитата:

Изначально опубликовано Maxim Gorbunov
ALES, зачем Вы вводите людей в заблуждение. Изначально вопрос, на который Вы, по Вашему заявлению, дали исчерпывающий ответ...

Ответ начинался фразой Поиск "проблемных" полей, созданных на основе EDT RecId., дефрагментировать никто не обещал. При импорте подмножества таблиц, система Вам не сообщит, что связанной таблицы в файле нет и ссылки "поплывут"

Цитата:

Изначально опубликовано Maxim Gorbunov
Потому что, в smmTransLog есть поле, EDT которого не наследует от RecId, но при этом в нем сохраняются ссылки на RecId других таблиц (можно увидеть в Relation). Скрипт ALES такие поля, разумеется, не находит.

Где я обещал находить такие поля?

Цитата:

Изначально опубликовано Maxim Gorbunov
P.S.: ALES, если бы Вы в процессе накопления огромного опыта по подъему данных уделяли хоть немного внимания опыту, накопленному другими программистами, Вы бы наверняка прочли Development Best Practices Handbook. А именно параграф The Global Class в разделе Where to place the code (Dev_BPHB.chm::/Application_Design/Design_Principles/WhereToPutTheCode.htm): [/B]

Бинго! Один внимательный форумчанин есть
ps: Нашедшему в клиентском коде ALESа GLOBAL::метод... ставлю пиво и Вам Maxim, за каждый найденный такой фрагмент.
pps: Поскольку Вас Maxim Gorbunov это ТАК задело.. прошу понимать Исчерпывающий ответ как Исчерпывающий ответ по поиску в таблицах полей, созданных на основе EDT RecId.

[glibs]

Цитата:

Изначально опубликовано ALES
...
При импорте подмножества таблиц, система Вам не сообщит, что связанной таблицы в файле нет и ссылки "поплывут"
...

Извините, что вмешиваюсь в драку, но я считаю, что это вполне нормально, что система не сообщит вам о том, что в импортируемых данных есть ссылки на RecID записей, которых в импортируемых данных нет, и что такие ссылки не будут преобразованы (если я корректно понял ваш аргумент, конечно). Думать головой перед тем, как делать импорт данных, никто не отменял. А ссылки не обязательно "поплывут" при импорте. Есть случаи, когда от системы при импорте требуется именно такое поведение, как вы описали. Например, когда нужно "убрать" из виртуальной компании табличку, которая сылается по RecID на другие таблички не в рамках виртуальной компании. Так что не стоит так категорично...

[Maxim Gorbunov]

ALES, прошу прощения. Что-то я действительно какой-то злой вчера с утра в форум залез. Ничего личного. Инцидент исчерпан.

Согласен с glibs. Думать надо чаще. Американцы вот, как писал Ремарк, даже перед туалетом таблички с надписью "Think!" вывешивали.

Ну и напоследок: ссылки в smmTransLog испортятся независимо от набора импортируемых/экспортируемых данных; остальные ссылки можно контролировать.

[Yaroslav Batozskiy]

Hi, All !

2MG

Цитата:

Да нет, не совпадают. Класс простой, решает ровно ту задачу, которая была поставлена перед его разработчиками

Аксиома, которую я вывел для себя:
в общем случае, частота вопросов от пользователей и сообщений об ошибках прямо пропорциональна количеству ошибок логической целостности данных (ОЛЦД) плюс некая константа, зависящая от квалификации, используемых модулей etc.
Опытным путем установлено, что при отсутствии ОЛЦД, частота вопросов определяется именно константой.
Анализ алгоритма "Проверки кодов записей" показал, что при любых эксплуатационных условиях он не исправляет никаких ОЛЦД, а может добавлять свои.
Из этого следует, что, во первых, я сам не буду его использовать, во вторых, постараюсь донести свое мнение до коллег, чтоб они не наступали на те же грабли.
Алгоритм достаточно простой, просто посмотрите, как себя он себя поведет, если есть дубликаты recid в разных таблицах, как будет работать с виртуальными компаниями, если есть ссылки, которые ссылаются на несуществуюшие строки, и наконец типы, которые не наследуются от recid.

Коллеги ! Давайте не будет тратить время на обсуждение этой аксиомы ! Вы можете либо принять её, либо не принимать !
В общем, если не принимаете, то, как говорил Задорнов, "спите осторожнее"

2glibs

Цитата:

так вы все-таки обвиняете процедуру проверки кодов записей в неработоспособности или наличии в ее алгоритме ошибок, или просто у вас к ней неприязнь личного плана?

На основании вышеперечисленного у меня появилась неприязнь личного плана
Одной из задач любого программиста и консультанта должна быть наиболее удобная работа с системой для персонала. Я же прозрачно намекнул, где копать и чем грозит.
Ув. glibs. Я просто дал совет. Хотите-разберитесь, хотите-проигнорируйте.

2MG

Цитата:

вот и нет. LedgerTrans.RTSLSessionTransId == RTSLSessionTrans.SessionTransId. Это вовсе не ссылка на RecId.

При relation ссылка не пересчитается при exp-imp и прочих оп. Да Бог с ней, с трансляцией, таких полей в системе туча, и много их в тех модулях, которые используются редко.
Максим, искать и приводить здесь не буду

Цитата:

Изначально вопрос ... Какие таблицы не переживут дефрагментацию ... smmtranslog

Максим, если речь идет о моем скрипте, то неужели Вы думаете, что я бы стал с этим заводиться, если б не мог такую тривиальную ситуацию разрулить ? Все там классно дефрагментируется, и что нужно исправится. Наши сейлзы даже не заметили, что я их CRM дефрагментировал.

2All
Коллеги ! Не хотелось бы, чтоб этот топик превращался в обсуждение моего скрипта. Написал я об этом просто, чтоб знали, что если у кого то возникнет критическая ситуация с этой проблемой, то мы можем помочь её решить. Я сам на эти грабли наступил (зациклилось), поэтому и пишу. Если у Вас, или Ваших клиентов такой ситуации не может быть в обозримом будущем, просто игнорируйте информацию о скрипте, учитывайте только то, что говорилось непосредственно о RecId.
Максим тут говорил о рекламе Нет, Максим... Я просто увлекся ответами на вопросы... Это вещь, которая в рекламе не нуждается. Если она кому-то не нужна, то реклама здесь не поможет, если нужна, то и без рекламы...

Если у кого-то будут _реальные_ _клиентские_ вопросы или проблемы--мою электропочту Вы знаете, мобильник сейчас в профиль напишу. Переводить 90 KB скрипта на с T-SQL на русский я не буду.

Кстати, я увидел в этом топике _инженерный_ подход к решению проблемы, у "Vadik". Но то, что он написал, это все же ближе к постановке задачи, а не к решению. Я тоже думал, что этим можно ограничиться. Однако потом убедился в правоте принципа 10-90. Сделал так. Потом увидел, что поля в "табличку" тоже нужно найти, и у каждого клиента они свои, версии разные, поля могут быть и свои, правила тоже могут отличаться, пришлось написать сканер и еще несколько вещей, потом исправление ошибок, потом оказалось, что и табличка то не нужна, и скрипт стал универсальным.

[glibs]

Yaroslav, благодарю вас за ответ. Теперь мне все ясно.

[komar]

Цитата:

Изначально опубликовано Yaroslav Batozskiy
Hi, All !

2MG

Аксиома, которую я вывел для себя:
в общем случае, частота вопросов от пользователей и сообщений об ошибках прямо пропорциональна количеству ошибок логической целостности данных (ОЛЦД) плюс некая константа, зависящая от квалификации, используемых модулей etc.
Опытным путем установлено, что при отсутствии ОЛЦД, частота вопросов определяется именно константой.
...........
Коллеги ! Давайте не будет тратить время на обсуждение этой аксиомы ! Вы можете либо принять её, либо не принимать !
В общем, если не принимаете, то, как говорил Задорнов, "спите осторожнее"

..............
Хотите-разберитесь, хотите-проигнорируйте.
............

Если у кого-то будут _реальные_ _клиентские_ вопросы или проблемы--мою электропочту Вы знаете, мобильник сейчас в профиль напишу.
..............

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

[Maxim Gorbunov]

Цитата:

Изначально опубликовано Yaroslav Batozskiy
Анализ алгоритма "Проверки кодов записей" показал, что при любых эксплуатационных условиях он не исправляет никаких ОЛЦД,

Да он, собственно, для этого и не предназначен.

Цитата:

Изначально опубликовано Yaroslav Batozskiy
а может добавлять свои.

Вот об этом и речь. Пока в обсуждении не было ни одного сообщения, подтверждающего создания новых ошибок процедурой проверки кодов записи. Почему у Вас нет личной неприязни, к примеру, к процедуре обработки накладной по заказу? А чем существенно отличается процедура проверки кодов записей?

Цитата:

Изначально опубликовано Yaroslav Batozskiy
Алгоритм достаточно простой, просто посмотрите, как себя он себя поведет, если есть дубликаты recid в разных таблицах, как будет работать с виртуальными компаниями, если есть ссылки, которые ссылаются на несуществуюшие строки, и наконец типы, которые не наследуются от recid.

По пунктам:
(1) Виртуальные компании
Если в таблицах, которые разделяются между компаниями, входящими в виртуальную, есть ссылки на RecId между собой, ситуация будет обработана корректно. Если есть ссылки из разделяемых таблиц на не разделяемые или наоборот - это уже ошибка целостности данных. Таким образом, процедура проверки кодов записей новых ошибок в этом случае не добавляет, а лишь повторяет старые.
(2) Ссылки на несуществующие строки
Проверка кодов записей сообщит о таких строках в infolog. Исправлены они не будут.
(3) Типы, которые не наследуются от RecId
Поля с такими типами, разумеется, не будут обработаны. Однако это, по сути, ошибка программистов. Кроме того, таблиц с такими полями, я что-то немного нашел (1 в 3.0 и 3 в 2.5).

Таким образом, проверка кодов записей практически (кроме (3)) во всех указанных случаях не добавляет ошибок целостности данных. Правда, не исправляет имеющихся, но этого никто и не обещал. Для таких процедур есть стандартная функциональность "Проверка целостности данных"

Цитата:

Изначально опубликовано Yaroslav Batozskiy
Я просто дал совет. Хотите-разберитесь, хотите-проигнорируйте.

Можно я тоже дам совет на случай, если вдруг кто-то из начинающих пользователей Axapta будет читать эту ветку. Прежде, чем разработать что-то свое, обязательно разберитесь со стандартным функционалом, решающим похожие задачи. В случае, если стандартный функционал позволяет решать Вашу задачу при условии внесения некоторых модификаций, отдавайте предпочтение изменению стандартного функционала, не создавайте собственное решение по любому случаю.

Цитата:

Изначально опубликовано Yaroslav Batozskiy
При relation ссылка не пересчитается при exp-imp и прочих оп.

А она, знаете ли, и не должна пересчитываться. Это ID проводки. Он импортируется вместе с проводкой из файла импорта. Это не RecId, который становится новым при импорте для каждой записи.

Цитата:

Изначально опубликовано Yaroslav Batozskiy
Да Бог с ней, с трансляцией, таких полей в системе туча, и много их в тех модулях, которые используются редко.
Максим, искать и приводить здесь не буду

Да, аргументация у Вас... Просто виновна, а почему не скажу... Далеко Вы так уйти можете.

В общем, я таких мест нашел не много (см. выше: всего одно).

Цитата:

Изначально опубликовано Yaroslav Batozskiy
Максим, если речь идет о моем скрипте

Нет, речь о стандартной процедуре дефрагментации. Вашего скрипта я не видел.

Цитата:

Изначально опубликовано Yaroslav Batozskiy
Не хотелось бы, чтоб этот топик превращался в обсуждение моего скрипта. Написал я об этом просто, чтоб знали, что если у кого то возникнет критическая ситуация с этой проблемой, то мы можем помочь её решить.

Во-первых, вряд ли мы начнем обсуждать Ваш скрипт, так как никто его кроме Вас не видел.
Рекламы в этой ветке, действительно не было. Она была в ветке, на основании которой родилась эта. Правда, с Вашим последним сообщением, намек на нее появился и здесь. Впрочем, ничего страшного в этом нет. Я вовсе не против рекламы в этом топике. Просто мне кажется достаточно странным его наличие в форуме Проекты.

[Yaroslav Batozskiy]

2MG

Цитата:

Почему у Вас нет личной неприязни, к примеру, к процедуре обработки накладной по заказу? А чем существенно отличается процедура проверки кодов записей?

Из за её глобальности и латентности результатов её работы. Когда мы проводим накладную заказа--результат видим и проверяем сразу. Результаты работы "Проверки.." охватить взглядом затруднительно, ош. могут проявиться позже

Цитата:

По пунктам:

1. Условно согласен. В "перекрестном" случае это не всегда ОЛЦД. Как вариант, _можем_ выделить, например, для компаний разные диапазоны recId, например DAT-первый миллиард, холдинг--второй миллиард, и по одному на две аффилированные структуры
2. ????? Ни разу не видел ! Обновления производятся командой UPDATE (строка 139, AX3SP1), поэтому такой случай SQL просто пропустит, т.к. он при обновлении исключится фразой WHERE в коррелированном запросе. По моему, не может такого быть. Или я что-то проглядел ?
3. Да. А поиск производился по каким модулям ? Я имел ввиду все модули, какая часть из них находится в наиболее часто используемых--не смотрел

Цитата:

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

Полностью согласен. Это и предполагалось...

Цитата:

А она, знаете ли, и не должна пересчитываться. Это ID проводки. Он импортируется вместе с проводкой из файла импорта.

Боюсь, что нет. В таблице LedgerTrans есть поле RTSLSessionTransId, которое ссылается на Recid таблицы RTSLSessionTrans--сессии трансляции--номер сессии, которая породлила проводку. В форме на этой табличке есть кнопка "Отменить"--откатывает трансляцию с удалением проводок.
После Exp-Imp или "Проверке..." в сессиях recid поменяется, а в проводках нет, поэтому сессию удалить можно будет только руками. Явный баг. Регистрирую в MBS.

Цитата:

Просто виновна, а почему не скажу... Далеко Вы так уйти можете.

Максим, просто при голосовом разговоре мы бы пришли к общему знаменателю за 5 минут. Я просто не хотел рекурсивно погружаться в этот вопрос. Т.к. для этого пришлось бы отдельный топик завести.

Мы тут коснулись "Проверки целостности данных"... Замечу, что функция проверяет не все таблицы, а только те, которые в ней прописаны в строках

PHP код:

    this.kernelCheckTable(tableNum(custInvoiceJour)); 


Если Вы добавляете таблицы, то имет смысл включить их в процедуру.