Ошибки синхронизации при upgrade

[Qaz Qwerty]

Случилось делать upgrade с DAX4 на DAX5, возникли ошибки синхронизации. То есть выдает сообщение "не удалось синхронизировать 8 таблиц", списка таблиц нет. Удалось победить следующим образом:
1. Выйти из мастера upgrade и войти в Аксапту (надо было хоть посмотреть что там еще не сделано, в этом мастере).
2. Список таблиц, которые не синхронизировались, совпал со списком таблиц, где были warnings, которые все были типа "New unique index named 'I_1938BALCOLIDX may cause unique index violations'."
3. Открываем administrative tool/event viewer/ windows logs / applications. Смотрим там сообщение об ошибке от Dynamics Server. Там есть список полей, которые должны быть уникальны. Почему то мне удалось это увидеть ни в аксапте, ни в MSSQL, название индекса мне ничего не говорит.
4. Открываем SQL management studio, и пишем там кверю типа SELECT count(dataareaid), COUNT(balancesheet), count(COLUMN_), dataareaid, balancesheet, COLUMN_ from LedgerBalColumnsDim GROUP BY dataareaid, balancesheet, COLUMN_
HAVING count(*) > 1 order by dataareaid, balancesheet, column_
Скажу честно в кверях я разбираюсь как свинья в апельсинах, так что может и получше способы есть.

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

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

[Vadik]

Цитата:

Сообщение от Qaz Qwerty

Потому что длина поля с названием отчета стала короче, был сделан truncate и возникли дубли. То есть пень я пнем, наверное это сообщение было в предупреждениях на момент update, но так как их там много было, а времени всегда мало, то были они проигнорированы

Времени было мало, говорите.. Программисты должны быть смелыми, говорите

Цитата:

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

Nurse Tate: I'll get the lubricant...
Dr. Paulson: No time for lubricant!
Harry Block: There's ALWAYS time for lubricant!

Цитата:

А ручками вычищать чего то не соображу как

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

Цитата:

Может получше способы есть

Конечно есть - восстанавливать БД из бэкапа на момент "до начала апгрейда", анализировать почему обрезались поля и исправлять
P.S. Искренне надеюсь, Вы этот экзерсис не на рабочей БД провели.. Ну или что лубриканты в наличии и срок годности не истек

[Qaz Qwerty]

Не, ну это конечно же копия.

Ну а что надо было делать? Оно же не выдает сообщение где будут дубликаты и где их не будет, то есть не выдает это сообщение перед truncate. Говорит, что обрежу, и говорит это чуть ли не на каждой второй таблице, ну может не на каждой второй, но все равно больше сотни. У меня вообще кастомизаций нет, длина полей стандартная, какого извините , то есть какой был великий смысл в новой версии системы делать ключевые поля короче? Или я что то не понимаю?

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

Например, никто не знает почему при переходе виртуальные компании слетели (вернее коллекции таблиц)?

[gl00mie]

Цитата:

Сообщение от Qaz Qwerty

Открываем SQL management studio, и пишем там кверю типа SELECT count(dataareaid), COUNT(balancesheet), count(COLUMN_), dataareaid, balancesheet, COLUMN_ from LedgerBalColumnsDim GROUP BY dataareaid, balancesheet, COLUMN_ HAVING count(*) > 1 order by dataareaid, balancesheet, column_

В Аксапте есть штатная возможность найти дубликаты в индексах - в контекстном меню индекса Add-ins/Дубликаты.

[Vadik]

Цитата:

Сообщение от Qaz Qwerty

Например, никто не знает почему при переходе виртуальные компании слетели (вернее коллекции таблиц)?

У меня не проходит странное ощущение что Вы переход на следующую версию воспринимаете как запуск setup.exe какого-нибудь сервиспака. Как Вы вообще с версии на версию переходили?

[Vadik]

Цитата:

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

В Аксапте есть штатная возможность найти дубликаты в индексах - в контекстном меню индекса Add-ins/Дубликаты.

Она покореженные данные не восстанавливает, к сожалению. Так что только восстанавливаться из бэкапа

[Qaz Qwerty]

Vadik, брррр, я чего то не понимаю вопроса. Конечно, сетуп - sql и перенос базы данных на новый сервер, аксапты, сервис паков и запуск мастера upgrade. Что-то не так в этой процедуре?
Какой кстати смысл восстанавливать их бекап, все равно это проблему с разной длиной полей не решит, так ведь? Или вы мне предлагаете в качестве подготовки к upgrade в новой базе данных перекодировать все таблицы, где эти проблемы возникли, чтобы при truncate поля оставались уникальными? Вариант конечно, в общем примерно так и пришлось сделать, только не по всем таблицам.
Можно было еще отказаться от синхронизации и увеличить длину полей в тех таблицах, которые аксапта собирается обрезать, но я же говорю - сообщений о таких полях система выдала под сотню, а реально проблема возникла только в 8 таблицах, из них 5 удалось ручками поправить быстро, и только 3 реально нуждались в перекодировании, ну так руками пришлось сделать, несколько часов мороки.
А как это обойти?

[gl00mie]

Цитата:

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

Она покореженные данные не восстанавливает

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

Цитата:

Сообщение от Qaz Qwerty

Какой кстати смысл восстанавливать их бекап, все равно это проблему с разной длиной полей не решит, так ведь? Или вы мне предлагаете в качестве подготовки к upgrade в новой базе данных перекодировать все таблицы, где эти проблемы возникли, чтобы при truncate поля оставались уникальными? Можно было еще отказаться от синхронизации и увеличить длину полей в тех таблицах, которые аксапта собирается обрезать

В замечательной книге Программист-прагматик есть подглавка "Рассказ о резиновом утенке", в которой пишется о пользе объяснения кому-либо возникшей проблемы: подчас по ходу рассказа о ней решение находится само собой Еще более образно этот прием описан у Джона Робинсона в не менее замечательной книге Отладка приложений для Microsoft .NET:

Цитата:

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

Цитата:

Сообщение от Qaz Qwerty

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

С 4-ки на 2009-ю не переходил, врать не буду, но при переходе с 3-ки также вылезали "проблемные места", связанные с усечением полей, в количестве 160 штук:

• 78% касалась типа Filename и производных от него, которые с 260-и символов были обрезаны до 259 (видимо, разработчики вспомнили, что виндовая константа MAX_PATH подразумевает включение в 260 символов пути и завершающего нулевого символа, в то время как в БД Аксапты строковые данные - и пути к файлам в том числе - хранятся без завершающих нулей);
• 6% - укорачивания EDT BankChequeNum с 30 до 20 символов;
• 3% - укорачивания EDT BankRegNum с 14 до 12 символов;
• часть была связана с "пропажей" некоторых EDT, из-за чего длина полей уменьшилась до своего значения по умолчанию - 10 символов.

Всего различных случаев уменьшения длины строковых полей, не связанных с пропажей EDT, было 9 штук, т.е. вполне себе вменяемое число для рассмотрения каждого случая по отдельности. Если таблицы реально важные, то почему бы и не увеличить длину EDT ради сохранности данных?