Выравнивание Num влево последствия...

[36AC]

Проблема. У EDT Num поменяли выравнивание, в результате чего. У наследников Num выравнивание поменялось, а на полях таблиц где EDT наследники Num (в свойствах) выравнивание осталось вправо. Но при этом вновь введенные данные в эти поля, выравниваются как завещал NUm, те влево, а те данные которые были в таблицах, добавили перед значимой информацией кучу пробелов (те например вместо "SalesId", получили в результате наших монипуляций " SalesId").
Вопросы:
1. Как не перебирая свойства всех таблиц изменить корректное отображение в свойствах оных выравнивания.
2. Как избавиться от появишихся пробелов

[glibs]

Опять поставить выравнивание вправо, а потом влево. По-моему, мне так помогало.

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

[36AC]

Спсб, вечерком попробуем...

[36AC]

Цитата:

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

Опять поставить выравнивание вправо, а потом влево. По-моему, мне так помогало.

Не стал ждать до вечера на тестовой базе провел эксперимент. Выровнил вправо влево все стало ОК, так как доктор прописал!

[mazzy]

Цитата:

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

Опять поставить выравнивание вправо, а потом влево.

Совет опасный, поскольку после выравнивания уже введены новые записи с выравниванием.

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

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

Опять же, если вопрос от той компании с которой мы общались вчера,
то для вас сейчас важна надежность решения: После процедуры исправления ВСЕ данные должны быть корректными. К сожалению, выравнивание в обратную сторону не даст надежности, поскольку у вас уже введены новые данные с новым выравниванием.

Я предложил следующий вариант:
1. SQL скриптом перебрать все таблицы и все строковые поля.
2. убрать левые пробелы
3. записать измененную запись (только в том случае, если что-то изменилось)

этот вариант предполагает, что у вас нет данных со значимыми левыми пробелами (если это та компания, о которой я думаю, то похоже это предположение истинно).

В общем, раз уж произошла такая фигня, то
нужно искать вариант, который на 100% надежно решит проблему.
Будет чертовски неприятно, если какие-то таблицы останутся несвязанными.

[36AC]

Никаких если) вопрос от той компании с которой Вы разговаривали вчера! Просто тот с кем Вы разговаривали приходит на работу несколько позже других, правда и уходит соответственно! ;-) так вот появилось время спросить, я и спросил, получив ответ glibs изложил его, тому с кем вчера Вы имели беседу, получил ответ ИЗЛОЖЕННЫЙ ВЫШЕ) Но решили поэксперементировать с тестовыми данными, на первый взгляд все ок, прочитав ответ mazzy углублюсь в проверку связей)

[glibs]

Цитата:

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

...
Совет опасный, поскольку после выравнивания уже введены новые записи с выравниванием.
...

Это как?

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

[mazzy]

Цитата:

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

И ссылочная целостность уже нарушена.

В том то и дело.

[mazzy]

Цитата:

Сообщение от 36AC

углублюсь в проверку связей

Да.

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

Поэтому, по-моему, проще просто создать исправительный скрипт и прогнать его.
Результат получится гарантированным.

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

[glibs]

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

[AndyD]

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

[Vadik]

Ручное изменение Adjustment надежнее скрипта (человеческий фактор, так сказать)

[glibs]

Если это одна и та же сущность, то исправимо. Через Проверка/Синхронизация.

Хотя согласен, неприятно.

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

В общем, не исключено... но не должно по-хорошему.

[mazzy]

Цитата:

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

Ручное изменение Adjustment надежнее скрипта (человеческий фактор, так сказать)

После того, как:
1. выравняли влево некорректно (остались записи с левыми пробелами),
2. создали несколько записей с кодами, выровнянными влево

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

[mazzy]

Цитата:

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

Если это одна и та же сущность, то исправимо.

А с чего ты взял, что одна и та же?

Например, InvenDim выравнялся влево, а InventTrans, SalesLine и т.п. - нет.

Есть ли способ проверить для разных сущностей?

Я понимаю, что, скорее всего, произошло следующее.
Изменили выравнивание влево,
Аксапта начала синхронизацию, администратор сказал "ой" (по разным причинам) и прибил транзакцию.
В результате база выравняна одним способом, а в AOT указан другой способ.
Потом начали забивать новые данные.
Скорее всего пользовались lookup'ом и левые пробелы в Foreign Key попадали, а в Primary Key - нет (т.е. новый номер заказа левых пробелов не содержит, а ссылка на номенклатуру - содержит)

Я понимаю, что, скорее всего, Primary Key и Foreign Key выравняны одинаково.
Но нужна 100% уверенность.
Как раз 100% уверенности, лично у меня, нет.
Особенно для технических таблиц (*Settletent, *Posting, InventDim и т.п.)

Самым надежным и пока самым простым способом пока считаю SQL-скрипт, который перебирает все текстовые поля во всех таблицах и убирает левые пробелы.

[glibs]

Цитата:

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

...
после этого выравнивание вправо везде добавит левые пробелы?
...

Должны. Нужно делать в однопользовательском режиме.

Цитата:

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

...
Не останется ли смешанного варианты выравнивания?
...

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

Цитата:

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

...
Есть ли способ проверить, что во всех полях во всей базе выравнивание одинаковое?
...

Штатный — по-моему нет.

[AndyD]

Цитата:

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

Самым надежным и пока самым простым способом пока считаю SQL-скрипт, который перебирает все текстовые поля во всех таблицах и убирает левые пробелы.

Что бы не трогать все таблицы и поля можно сначала из Axapta'ы пробежаться по AOT'у и выбрать таблицы, в которых есть поля с EDT num или его наследниками.
Сохранить найденные таблицы и поля в промежуточную таблицу и уже по ней вносить исправления в б/д.

[glibs]

Цитата:

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

...
А с чего ты взял, что одна и та же?
...

Я имел в виду, что если речь идет о технической ошибке.

Т.е. если под "123" и " 123" пользователь понимает одно и то же, то хорошо.

Но если он под "123" уже понимает одно, а под " 123" — другое, то вот это проблема. И обрезанием пробелов она не вылечится.

[Vadik]

Цитата:

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

После того, как:
1. выравняли влево некорректно (остались записи с левыми пробелами),
2. создали несколько записей с кодами, выровнянными влево

ты же не хочешь написать универсальный скрипт, который проанализирует и исправит все-все ошибки во всех-всех таблицах? это мы уже проходили (тема о дефрагментации RecId)

Цитата:

после этого выравнивание вправо везде добавит левые пробелы?

да

Цитата:

Не останется ли смешанного варианты выравнивания?

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

Цитата:

Есть ли способ проверить, что во всех полях во всей базе выравнивание одинаковое?

DictType.extend()
SQLDICTIONARY.RIGHTJUSTIFY
DictType.setStringRight()

[Vadik]

Цитата:

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

Но если он под "123" уже понимает одно, а под " 123" — другое, то вот это проблема. И обрезанием пробелов она не вылечится.

эта проблема - в головах юзеров

Цитата:

просьба увеличить кредитный лимит по клиенту " Вася_Пупкин" (по тому, который с двумя пробелами в коде слева, клиента "Вася_Пупкин" не трогать)

отчеты после этого тоже весьма забавные будут печататься