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

[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 ради сохранности данных?