Вопрос по ссылочной целостности

[chel]

Интересно, почему разработчики Axapta не возложили контроль ссылочной целостности на СУБД? В итоге система контролирует ссылочную целостность не везде. Наример, если настроить счет кассы на счет ГК, а потом удалить этот счет из плана счетов, то строки журнала кассы будут разнесены на несуществующий счет ГК. Или я что-то где-то не включил?

[mazzy]

потому что они принципиально решили ничего не возлагать на СУБД.

Почему НИЧЕГО не возлагается на СУБД? Изначально предполагалось, что СУБД могут использоваться разные. Даже те, кто не поддерживает развитые механизмы. Даже mySQL По маркетинговым соображениям остались только МС СКЛ и Оракл.

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

Включение/выключение контроля делается программистом. См. таблицы, свойства DeleteActions.

Теперь совершенно отдельный вопрос по Кассам. По идее российские программисты должны были бы включить. Почему они не везде включили... хм... это отдельный вопрос.

Спасает то, что переключать deleteAction можно самому.

[chel]

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

[Oleg Krutikov]

К таблице LedgerTable добавьте DeleteAction "Restricted" для таблицы RCashLedgerAccount. После этого счёт указанный в профиле разноски кассы удаляться из плана счетов не будет.

[TravellerInTime]

Quote:

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

Нет, не правильно! Такой бардак в Аксапте встречается повсеместно!

[mazzy]

Quote:

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

да, ошибка.

[imir]

Quote:

Originally Posted by mazzy

да, ошибка.

Начал ковыряться в 2012-й и как бэ.. хм.. учитывая, что теперь много ссылок recid, проблема встает в полный рост. Банально можно удалить структуру аналитик, узнать об этом через неделю и .. куча битых recid, невозможность разнести операции, построить отчеты.. все давай досвидания база.

Зарегил даже в коннект пост на эту тему,

https://connect.microsoft.com/dynami...-table#details

Там приложен файлик - 13000 "битых" delete action по таблицам "Group" и "Main".

Мне кажется, хотя бы для "Group" и "Main" можно сделать автоматическую проверку целостности, или нет?

[Logger]

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

В общем, я бы не стал перекладывать на ядро баги X++ программистов.
Лучше уж тогда настроить логирование на удаление по всем справочникам в системе, можно будет легко восстанавливать записи при возникновении подобных проблем, а также находить по битой ссылке что за запись была.

[imir]

Quote:

Originally Posted by Logger

Да не сильно она вам поможет.

Откуда такой вывод?

Quote:

Originally Posted by Logger

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

И я о том же. Но (!) еще в довесок -даже зная код - нельзя штатными средствами завести обратно запись с таким же Recid

Quote:

Originally Posted by Logger

В общем, я бы не стал перекладывать на ядро баги X++ программистов.

Эту обязанность на программистов возложили, в 1С допустим никто про это слыхом не слыхивал - все контролирует система, значит это возможно. Опять же - 13 000 (тринадцать тысяч) багов, это тенденция знаете - я не зря вначале процитировал Маззи

Quote:

Originally Posted by Logger

Лучше уж тогда настроить логирование на удаление по всем справочникам в системе, можно будет легко восстанавливать записи при возникновении подобных проблем, а также находить по битой ссылке что за запись была.

Журнал базы данных на удаление по всем таблицам, кроме транзакционных мы и раньше делали, но вот вопрос - как искать по журналу БД запись по Recid, или вообще опираясь на ошибку "не найдена запись с кодом (пусто) в таблице ..."