|
![]() |
#1 |
Участник
|
Спасибо за ответ.
Переименовывать первичный ключ не получится, так как там есть и объединение аналитик и перенос из одной в другую - поэтому приходится перебором всех таблиц. "Сам процедура должна создать/изменить соответствующие строки таблиц." Подскажите, пожалуйста, какие таблиц стоит проверить? Я попробовала проделать процедуру на тестовом приложении просто по всем таблицам, содержащим анаитику - ошибок неуникального ключа не было, значит ли это, что все в порядке? :-) |
|
![]() |
#2 |
Участник
|
Цитата:
Цитата:
Вам надо смотреть на индексы со свойством AllowDuplicate = No в которые включены поля Dimension. Если подобный индекс указан как Primary-индекс таблицы, то это первое "подозрение" на то, что это и есть одна из "суммирующих" таблиц. ============================================ И еще один момент. Дело в том, что кроме собственно поля Dimension фин.аналитики могут быть представлены парой полей: DimensionCode + Num. Причем не только в таблице Dimensions. Как правило, в подобных случаях формализовать (запрограммировать) переименование фин.аналитик - невозможно. Эти справочники придется менять вручную. Например, таблица LedgerControlDimension PS: Надеюсь, Вы анализировали не только EDT с именем Dimension, но и все EDT созданные на его основе? В стандарте таких нет, но мало ли, что сделано конкретно у Вас.
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
![]() |
#3 |
Участник
|
Владимир, если говорить про v3, то могли бы уточнить в каких еще таблицах нужно проверить/изменить аналитику?
|
|
![]() |
#5 |
Мрачный тип
|
Полная лажа по ссылке...
Правильный алгоритм:
__________________
Мы летаем, кружимся, нагоняем ужасы ... |
|
![]() |
#6 |
Участник
|
Цитата:
X++: // Сканирую список таблиц, имеющих ЯВНУЮ ссылку на таблицу Dimensions while select TableName from xRefTableRelation group by TableName where xRefTableRelation.RelatedTableName == "Dimensions" { tableId = tableName2Id(xRefTableRelation.TableName); dictTable = new DictTable(tableId); (...) } Ну, и про таблицы с полями на базе DimensionCode + Num не стоит забывать. Это таблицы вроде InventJournalReportTable_RU LedgerControlDimension LedgerRRGDimensionInterval_RU Кроме того, следует иметь в виду, что не у всех таблиц можно просто заменить одно значение на другое. Возможно, потребуется сложение/удаление строк. Возможно, автоматизировать процесс замены в некоторых таблицах вообще нельзя. А есть еще таблицы очень большого размера без индекса по фин.аналитикам. Например, InventSettlement. Для таких таблиц модификацию лучше выполнять прямыми SQL-запросами. В противном случае, время выполнения катастрофически увелививается. Другими словами, часть таблиц Вы сможете найти и обновить автоматически, но часть придется исать и обновлять вручную.
__________________
- Может, я как-то неправильно живу?! - Отчего же? Правильно. Только зря... |
|
|
За это сообщение автора поблагодарили: AX3 (1). |