Перенос модификаций из слоя в слой с идентификаторами

[Anais]

Я пытаюсь переносить модификации из слоя usp в слой cus с сохранением Id (чтобы данные, которые уже есть в пром.базе не "порвать"). По большей части потому что экспорт/импорт делать долго, да и не везде возможно.

Вопрос такой: в этой операции нет подвохов? В "методичке" по переносу написано про перенос с Id: "Возможность переноса кода в другой слой".

Ну хорошо. Возможность - это хорошо. А потом глючить не будет? Корректно будет работать с новыми объектами, создаваемыми/изменяемыми на обновленном usp слое? А то знаем мы эти "возможности" в Axapta...

Какой опыт у уважаемой общественности?

[Андре]

А разве диапазоны идентификаторов не сопоставляются с слоями? Мне казалось, что такой перенос в принципе не возможен.
Кстати, мы про id объектов говорим, а не записей?

[Anais]

Об Id объектов! И я уже поставила эксперимент с полем в таблице - работает!!! И даже после синхронизации ничего не слетело! И даже на слое usp потом присваивает Id с учетом Id на cus (на cus одно поле 50001, на usp добавилось поле 50002)
Надо бы еще с целой таблицей поэксперименитровать.

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

[db]

работает замечательно и глюков не будет. переносили со значениями идентификаторов целые слои.

Только одно "НО". Значения идентификаторов всех объектов, которые вы импортируете должны быть свободны. При конфликте цифирек объект не импортируется. Так что если вам выдалось сообщение, что такой то идентфикатор занят, то придется разбираться с этими объектами вручную

Ну а чтобы "не потерять по глупости" сделайте копию свой прм базы и ставьте опыты там

[Anais]

db, спасибо огромное за ответ!

Только не понятно, как могут совпасть Id, если (а) слои, созданные ранее в cus имеют _принципиально_ другие Id. (б) Axapta, вроде бы, корректно работает с объектами с Id'шниками из одного слоя на разных слоях.
Только если из приложения в приложение перебрасывать.

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

[kvan]

Обратите внимание на последний пост от BOAL
тут

[Anais]

kvan, спасибо большое!
Прочитала, прониклась. Буду думать...

[db]

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

У вас скорее всего приложение одно и живет своей жизнью, так что вряд-ли вы будете засовывать в него чужой cus-слой. Да, ид-шники перепутаются, но если "забыли" начать эксплуатировать сразу на cus, то импорт-экспорт со значениями идентификаторов будет приемлемым решением

[kvan]

ну не знаю ...
я сталкивался с проблемой после такого переноса с id'шниками когда возникали сложности с данными (из-за которых собсно и затевался такой перенос)

2db:
Так может попросите г-на BOAL сказать свое слово по этому поводу?

[Anais]

db, спасибо.
Да нет, не забыли. Просто дотестировали/_доводили до ума_/вносили начальные остатки/учились работать одновременно. Поэтому теперь нужно бы перелить то, что _довели до ума_ в cus и при этом не потерять данные, которые навводили.

А вот это прокоментируйте, плз:
"потом .аод файлик никуда не подсунуть."

[sukhanchik]

В приложении есть .aod файлики - в которых собсно все и хранится... 1 файлик - 1 слой. Соотв, после разработки в CUS-слое (когда один программит в CUS, другой в USR) - все творения программеров оказываются в файликах axcus.aod и axusr.aod. Далее, если ID-шники не перепутаны , можно взять эти 2 файлика и скопировать в одну папку - таки образом получим "склеенное" приложение. По такому принципу работает сервис-пак (по крайней мере первый) - он просто кладет файлик axsyp.aod (к примеру) в каталог приложения. Далее, Аксапта при запуске перестраивает индекс (axapd.aoi) и счастье наступает. В ситуации, когда ID-шники USR-слоя лежат в CUS-слое, при таком склеивании приложения могут возникнуть 2 элемента с одинаковыми ID-шниками - что приведет к не очень хорошим последствиям. Например вместо метода одного класса вызовется метод другого класса. Причем компилятор не всегда обратит внимание на дубликат ID-шников

[George Nordic]

Цитата:

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

Респект, Аня!

А теперь моя ложка дегтя: У нас из-за смеси cus и usr слоя при переносе модификации слетают права. Не все, выборочно. Насколько я понял, все-таки тяжело системе смотреть на идентификатор 500ХХ на cus-слое.

Подробнее здесь:http://www.axforum.info/forums/showt...&threadid=9480

Так что, если хотите 2 слоя - пусть это будут usr и usp.
У нас дело идет к тому, что мы выгружаем все проекты со все слоев, и импортируем на чистую базу на usr слой без идентификаторов. + ПОЛНАЯ настройка всех прав зоного

С Уважением,
Георгий.

[Anais]

sukhanchik, спасибо.
Это понятный глюк. Там написано "никуда" не подсунешь. Никуда - это очень-очень общее слово.

George Nordic, тож муррси.
Ну, я так и знала!

В общем, сливаю все на usr, бо лучше так и без боли, чем на cus и без зубов. Большое спасибо всем откликнувшимся!