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. Сделал так. Потом увидел, что поля в "табличку" тоже нужно найти, и у каждого клиента они свои, версии разные, поля могут быть и свои, правила тоже могут отличаться, пришлось написать сканер и еще несколько вещей, потом исправление ошибок, потом оказалось, что и табличка то не нужна, и скрипт стал универсальным.