15.01.2019, 12:11 | #1 |
Участник
|
ievgensaxblog: MSDyn365FO. AX 2012 data upgrade with virtual companies.
Источник: https://ievgensaxblog.wordpress.com/...ual-companies/
============== In Dynamics 365 for Finance and Operations virtual companies are deprecated and could not be upgraded according to the documentation that just state this fact without proposing a solution. If we cannot upgrade, then we need to get rid of them. Here are the high level steps how you can de-virtualize a table. Let’s say that we have virtual company V with two companies: A and B. V has only one table collection with one table for simplicity, let’s call it Table1. <ol>Delete a data from Table1 that belongs to the companies A and B. When you create a virtual company, you may already have some data in the tables you want to share. That data may be orphaned, so we want to delete it to avoid duplicates. Can be done via simple T-SQL script:DELETE FROM Table1WHERE DATAAREAID = 'A' or DATAAREAID = ‘B’ Go to System administration > Setup > Virtual company accounts and delete the virtual company. Restart AX client. Insert data from the virtual company to de-virtualized companies via X++ job:static void deVirtualizeTables(Args _args){ DataAreaId virtualDataAreaId = 'V'; container oldCompaniesCon = ['A', 'B']; VirtualDataAreaList virtualDataAreaList; void deVirtualizeTable(TableId _tableId) { int i; DataAreaId dataAreaId; SysDictTable dictTable = new SysDictTable(_tableId); Common buffer = dictTable.makeRecord(); Common newBuffer; while select crossCompany buffer where buffer.dataAreaId == virtualDataAreaId { for (i = 1; i
__________________
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору. |
|
16.01.2019, 06:23 | #2 |
Мрачный тип
|
Круто, чо уж там ...
А если дело касается завиртуаленной таблицы, являющейся источником для определенного сегмента DefaultDimension или LedgerDimension ?
__________________
Мы летаем, кружимся, нагоняем ужасы ... |
|
|
За это сообщение автора поблагодарили: trud (5). |
16.01.2019, 09:12 | #3 |
Участник
|
Это не подходит для таблиц со связью по recId. Там придётся после вставки записей назад в старые компании пройтись и перебить все ссылки на новые recId. Для аналитик должно тоже сработать, но я не пробовал.
|
|
16.01.2019, 10:46 | #4 |
Участник
|
Кстати хорошее замечание от TasmanianDevil - т.е. лучше использовать немного другой алгоритм - перебить значение виртуальной компании на реальную в SQL, и дальше это уже размножить. В этом случае корректная ссылка по RecId останется хотя бы в одной компании
|
|
16.01.2019, 11:30 | #5 |
Мрачный тип
|
В остальных компаниях - будут интеллектуальные трэш, угар и содомия в одном флаконе по части копирования туда таблицы-источника, генерации новых комбинаций аналитики по новым значениям таблицы-источника и обновления имеющихся ссылок на новые ссылки по новым комбинациям. При наличии более одной такой таблицы - степень "радости" возрастает в геометрической прогрессии.
Кому они, виртуальные компании, <censored>, мешали?
__________________
Мы летаем, кружимся, нагоняем ужасы ... |
|
16.01.2019, 12:21 | #6 |
Участник
|
А зачем новые комбинации генерить? Аналитики и так были не company specific.
Цитата:
The primary table that is to be used as a source of financial dimension data MUST have a unique natural key value of 30 characters or less, and that value MUST resolve to a single RECID within that table.
|
|
|
За это сообщение автора поблагодарили: EVGL (3). |
16.01.2019, 13:13 | #7 |
Участник
|
Цитата:
|
|
17.01.2019, 05:47 | #8 |
Мрачный тип
|
Согласен, про комбинации погорячился (больше года не работал уже с этой "прелестной" поганью, подзабыл ужо чутка структуру) - только записи в DimensionAttributeValue , ссылающиеся на записи в виртуализированном справочнике, покорежить придется в остальных компаниях, что в принципе снижает степень проблемы.
__________________
Мы летаем, кружимся, нагоняем ужасы ... |
|
19.01.2019, 07:30 | #9 |
Участник
|
Прежде чем присоединись к критике, хочу сказать что автор сделал больше чем МС в этом направлении.
Можно (Insert + Delete) свести к одному Update. Я бы весь скрипт написал в T-SQL - проще, быстрее, можно повторить во всех средах (dev/qa/prod). У нас теже проблемы с использование Partition. У нас их 6 и апгрейд не подерживается МС. Проблему решил SQL скриптами - копируем все данные в новую базу и менять копируемый partition на initial (плюс 200 табличек у которых нет partition).
__________________
AxAssist 2012 - Productivity Tool for Dynamics AX 2012/2009/4.0/3.0 |
|
20.01.2019, 03:40 | #10 |
Участник
|
|
|
20.01.2019, 04:01 | #11 |
Участник
|
Цитата:
https://sumitsaxfactor.wordpress.com...in-sql-server/ Не то что это сильно проще |
|
20.01.2019, 04:05 | #12 |
Участник
|
Чисто из вредности спрошу, чем 2 SQL скрипта и 1 x++ джоб проигрывают в повторяемости во всех средах ? Да. там больше ручных действий, но если идти по списку то какая принципиальная разница?
|
|
20.01.2019, 14:18 | #13 |
Участник
|
Кстати вот эта конструкция перезапишет значения в полях CreatedDateTime, а оно иногда нужно. Т.е. нужно усложнять
X++: buf2buf(buffer, newBuffer); newBuffer.doInsert(); |
|
20.01.2019, 21:14 | #14 |
Участник
|
|
|
21.01.2019, 06:11 | #15 |
Участник
|
Ну довольно часто нужно, эту информацию часто показывают пользователям - дата и время создания, кто создал. Встречал также что кто-то даже отчеты строит по этим полям
|
|
21.01.2019, 10:05 | #16 |
Участник
|
|
|
22.01.2019, 03:08 | #17 |
Участник
|
Цитата:
Код: declare @newDataAreaId as nvarchar(4) = 'BBBB' declare @virtualDataAreaId as nvarchar(4) = 'V' insert into [Table1] ( [RECID] , [DATAAREAID] ...list of fields... ) SELECT [RECID] = row_number() over (order by (select NULL)) + (select isnull(max(RECID), 0) from [Table1] ) , [DATAAREAID] = @newDataAreaId , ...list of fields... FROM [Table1] as [sourceTable] WHERE [sourceTable].DATAAREAID = @virtualDataAreaId Data upgrade создаст все SQL sequence для RecId автоматически (см. DataUpgradePackage\AOSService\Scripts\AutoMajorDataUpgradePreReqs.ps и AdjustSQLSequences.sql). Скрипт делает select max(RecId) по всем таблицам, так что опять, что там в SYSTEMSEQUENCES неважно. Цитата:
Скрипт на T-SQL иногда быстрее и проще в разы, но в D365 MS не дает доступа на ПРОД базу SQL.
Цитата:
Плюс, а сколько там других шагов будет которые тоже вручную делать? По мне так на go-live день чем меньше шагов, тем лучше - Потушил AOSы (вручную), Запустил скрипт - DB back up, подготовка дынных (например virtual companies), скрипты от МС для подготовки bacpac, сам bacpac, залив bacpac в блоб, restore в sandpit, создание сервисных аккаунтов. Как скрипт отработал - запуск D365 upgrade. А сколько раз вы эти шаги будете делать перед реальным go-live? Тоже чисто из вредности спрошу, а вы код релизите через xpo вручную?
__________________
AxAssist 2012 - Productivity Tool for Dynamics AX 2012/2009/4.0/3.0 |
|
|
За это сообщение автора поблагодарили: trud (3). |
22.01.2019, 06:35 | #18 |
Участник
|
Неа, что должно смущать?
Цитата:
Цитата:
Сообщение от Alex_KD
Плюс, а сколько там других шагов будет которые тоже вручную делать?
По мне так на go-live день чем меньше шагов, тем лучше - Потушил AOSы (вручную), Запустил скрипт - DB back up, подготовка дынных (например virtual companies), скрипты от МС для подготовки bacpac, сам bacpac, залив bacpac в блоб, restore в sandpit, создание сервисных аккаунтов. Как скрипт отработал - запуск D365 upgrade. А сколько раз вы эти шаги будете делать перед реальным go-live? Хорошо когда можно через model store, но не всегда это возможно. Какое это отношение вообще имеет к теме дискусии? |
|
|
|