AXForum  
Вернуться   AXForum > Microsoft Dynamics AX > DAX: Программирование
All
Забыли пароль?
Зарегистрироваться Правила Справка Пользователи Сообщения за день Поиск Все разделы прочитаны

 
 
Опции темы Поиск в этой теме Опции просмотра
Старый 12.10.2010, 10:40   #1  
Murlin is offline
Murlin
Возьми свет!!!
Аватар для Murlin
Самостоятельные клиенты AX
Злыдни
 
291 / 32 (2) +++
Регистрация: 22.09.2008
Адрес: Тюмень, Рашан Федерашан
Разработка на usp слое
Доброго времени суток.

Дело в том что я решил включить разработку на usp слое для наших местных доработок, но второй программист почему то очень против.
Разрешите наш спор!
На сегодняшний день мы имеем готовый функционал на usr слое, который периодически должен будет обновляться, но заноситься он сравнением.
Работая на usr слое мы переписываем написанный функционал и затираем его, кроме того имеем очень много функционала который нам пока не нужен или вообще не нужен.
Не имея лучшего я предложил делать наши местные доработки на usp слое.
Возник спор. Мне не объяснили фактически какие минусы мы будем иметь кроме того что делать этого не нужно.
Вот собственно сообщение:
Цитата:
Для начала, зачем вообще нужны слои: они позволяют разделить разработку, ведущуюся разными организациями и/или для разных рынков/клиентов. т.е., скажем, вынести базовый (общий для всех) функционал на слой sys, какие-то региональные доработки – на слой gls, доработки отдельных внедренцев - на слои var/bus, доработки под конкретного клиента, а то, что сам клиент для себя лично дорабатывает, – на слой usr. Слои позволяют четко разнести модификации, сделанные разными компаниями или сторонами (внедренцем и заказчиком), кроме того, поскольку в Аксапте очень много завязок на внутренние идентификаторы объектов приложения (таблиц, полей, типов, классов, etc), для слоев выделяются непересекающиеся диапазоны идентификаторов, например, для sys - 1..16000, для usr - 50001-65000 (примерно, последние несско сотен используются объектами и типами ядра).

За счет этого, если одновременно создавать новые объекты на разных слоях и затем свести эти слои в рамках одного приложения, такие объекты гарантированно не пересекутся по идентификаторам (остается вариант пересечения по именам, но это контролировать проще, скажем, за счет использования префиксов/суффиксов). Это позволяет системе «не путаться» в них и рассматривать как различные объекты, а не как модификации одного и того же объекта. При модификации же объекта из нижележащего слоя он «поднимается» на слой, на котором ведется текущая разработка, с сохранением исходного идентификатора, и система при выполнении приложения использует копию объекта из самого верхнего слоя.

Таким образом, разведение функционала на слои и использование непересекающихся диапазонов идентификаторов позволяет четко отделить базовые разработки от собственных и, кроме того, позволяет относительно легко переносить собственные модификации при изменении приложения в "нижележащих" слоях: выпустили новый SP - слои с ним можно подложить в приложение вместо существующих, создать проект сравнения слоев на базе модификаций на том же usr-слое и быстренько эти модификации обновить для соответствия тому, что появилось в SP. Это удобно, когда изменения в "нижележащих" слоях происходят относительно часто, скажем, раз в полгода-год. К слову, для облегчения выпуска обновлений кроме «обычных» существуют и так называемые patch-слои; их имена соответствую именам «обычных» слоев, только заканчиваются на “p”: sys – syp, gls – glp, cus – cup, usr – usp. Ядро считает patch-слои расположенными «выше» соответствующих «обычных» слоев, т.е. при определении того, какую копию модифицированного объекта использовать, копия с patch-слоя имеет приоритет над копией из соотв. «обычного» слоя. Так вот, patch-слои не предназначены для «обычной» разработки, поскольку они используют тот же диапазон идентификаторов, что и соответствующий «обычный» слой; назначение patch-слоев – удобная форма выпуска исправлений для того или иного «основного» слоя: такие исправления, собранные в виде слоя, в отличие от исправлений в виде файлов экспорта (XPO), позволяют клиентам легко и быстро их накатывать. Если же вести разработку одновременно и в обычным, и в patch-слое, то объекты приложения в них почти наверняка пересекутся по идентификаторам, что может привести к непредсказуемым последствиям.

Например, в копии приложения без patch-слоя (приложение А) в «обычном» слое (usr) создается новый числовой тип данных IntType1, в таблицах создаются поля на базе этого типа. В это же время в другой копии исходного приложения с patch-слоем (приложение В) на этом слое создается строковый тип данных StrType2 с идентификатором, совпадающим с IntType1 из приложения А. В этом случае, если потом в приложение В подложить измененный usr-слой из приложения А, система подумает, что IntType1 и StrType2 – это один и тот же объект, а его копия на usp-слое – всего лишь модификация исходного объекта, а не отдельный не связанный с исходным тип.

При очередной синхронизации словаря данных будут созданы поля не целочисленного типа IntType1, с строгого типа StrType2, формы и код приложения начнут работать некорректно, полезут ошибки, но исправить их будет сложно, потому что нельзя будет просто удалить тип StrType2 с usr-слоя: возможно, на него уже ссылаются другие табличные поля или элементы управления на формах/отчетах. Аналогичные «сюрпризы» могут произойти при пересечении идентификаторов классов. В приложении методы классов ссылаются на класс, к которому они относятся, по идентификатору.

Если на слое usr в приложении А есть класс Class1 с определенным идентификатором и методом run(), выполняющим основную логику класса, в приложении В на usp-слое есть класс Class2 с таким же идентификатором и «своим» методом run(), то при подкладывании в приложение В usr-слоя из приложения А класс Class1 перестанет работать корректно, потому что система посчитает, что эти два класса – копии одного и того же (исходная и модифицированная), и будет для класса Class1 вызывать метод run() из Class2…

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

Если же в приведенных примерах не заменять периодически слой usr приложения В слоем из приложения А, то тогда вообще непонятно, зачем в приложении В вести разработку на отдельном слое.
Разве таже проблема с дублированием идентификаторов не будет возникать без usp слоя?
__________________
Axapta 3.0 sp 5 Oracle
Диплом Интернет-Университета Информационных Технологий: Основы бухгалтерского учета
Я могу взорвать вам мозг!!!
Старый 12.10.2010, 11:39   #2  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Murlin Посмотреть сообщение
Не имея лучшего я предложил делать наши местные доработки на usp слое.
Пробовал так. Это было давно. Сталкивался с глюком, когда работа нового объекта на usp-слое приводила к краху системы.

Для себя "придумал объяснение", что usP - это патч-слой. И разработчики предполагали, что в этом слое будут изменения уже существующих объектов. Поэтому появление новых объектов на этом слое не предусматривали, не тестировали.

С тех пор на usp-слое не программирую новых объектов.
Возможно, с тех давних пор что-то и изменилось.
__________________
полезное на axForum, github, vk, coub.
Старый 12.10.2010, 11:42   #3  
S.Kuskov is offline
S.Kuskov
Участник
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,439 / 1775 (66) ++++++++
Регистрация: 28.04.2007
Адрес: Калуга
Цитата:
Сообщение от Murlin Посмотреть сообщение
... Если же вести разработку одновременно и в обычным, и в patch-слое, то объекты приложения в них почти наверняка пересекутся по идентификаторам, что может привести к непредсказуемым последствиям. ...
Идентификаторы объектов могут пересекаться только если вести разработку в разных приложениях. И в этом случае абсолютно не важно patch-слой это или тот же самый.

Если вы хотите вести разработку в нескольких приложениях, то переход на patch-слой вам не поможет - нужно переходить на слои из разных диапазонов идентификаторов. Например на одном приложении разрабатывать в слое usr, а на другом - в слое var. Но это ли вам надо?

Ещё хочу напомнить о такой возможности, как каталог OLD в папке приложения. В который можно безболезненно подложить хоть patch-слой хоть тот же самый.
Старый 12.10.2010, 11:43   #4  
mazzy is offline
mazzy
Участник
Аватар для mazzy
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
29,472 / 4494 (208) ++++++++++
Регистрация: 29.11.2001
Адрес: Москва
Записей в блоге: 10
Цитата:
Сообщение от Murlin Посмотреть сообщение
Так вот, patch-слои не предназначены для «обычной» разработки, поскольку они используют тот же диапазон идентификаторов...
ну, с идентификаторами - вопрос решаемый.
Особенно, если вы "для себя" прогаете, а не на продажу.

Гемор, конечно, но вполне решаемо административными мерами.

Цитата:
Сообщение от Murlin Посмотреть сообщение
patch-слои предназначены только для выпуска обновлений и исправлений для уже созданных объектов приложения
А вот с этим - согласен.
__________________
полезное на axForum, github, vk, coub.
Старый 12.10.2010, 11:46   #5  
kornix is offline
kornix
MCP
MCBMSS
Злыдни
Ex AND Project
 
414 / 146 (5) +++++
Регистрация: 24.02.2009
Адрес: Санкт-Петербург
Похожий вопрос задавался тут и еще можете почитать здесь. О! И еще тут и кое что здесь, может это разрешит ваш спор

Последний раз редактировалось kornix; 12.10.2010 в 11:52.
За это сообщение автора поблагодарили: mazzy (2).
Старый 12.10.2010, 12:51   #6  
Murlin is offline
Murlin
Возьми свет!!!
Аватар для Murlin
Самостоятельные клиенты AX
Злыдни
 
291 / 32 (2) +++
Регистрация: 22.09.2008
Адрес: Тюмень, Рашан Федерашан
Цитата:
Сообщение от S.Kuskov Посмотреть сообщение
Идентификаторы объектов могут пересекаться только если вести разработку в разных приложениях. И в этом случае абсолютно не важно patch-слой это или тот же самый.

Если вы хотите вести разработку в нескольких приложениях, то переход на patch-слой вам не поможет - нужно переходить на слои из разных диапазонов идентификаторов. Например на одном приложении разрабатывать в слое usr, а на другом - в слое var. Но это ли вам надо?

Ещё хочу напомнить о такой возможности, как каталог OLD в папке приложения. В который можно безболезненно подложить хоть patch-слой хоть тот же самый.
Тут вся фишка в том что мы не просто подкладываем usr слой, а заносим изменения xpo файлом, значит проблема дублирования идентификаторов отпадает???
Вот мне и интересно какие кроме это последствия могут быть?
__________________
Axapta 3.0 sp 5 Oracle
Диплом Интернет-Университета Информационных Технологий: Основы бухгалтерского учета
Я могу взорвать вам мозг!!!
Старый 12.10.2010, 13:01   #7  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,312 / 3547 (125) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от Murlin Посмотреть сообщение
Тут вся фишка в том что мы не просто подкладываем usr слой, а заносим изменения xpo файлом, значит проблема дублирования идентификаторов отпадает???
За исключением того, что импорт в нижний слой объекта, измененного на верхнем слое может себя повести не так как ожидаете. Например объект может глючить. Или все изменения зальются сразу в usp. Т.е. xpo можно (гарантированно без последствий) заливать только в верхний слой (конечно только если объект лежит на нескольких слоях).

А так - конкретно usp-слой - я бы оставил "на всякий случай" как самый верхний слой. Иногда его не хватает.. Например - заливаешь большой xpo и смотришь все изменения (актуально при переходе на сервис-пак/ролап/большой хотфикс)
__________________
Возможно сделать все. Вопрос времени
За это сообщение автора поблагодарили: Murlin (1).
Старый 12.10.2010, 13:14   #8  
Murlin is offline
Murlin
Возьми свет!!!
Аватар для Murlin
Самостоятельные клиенты AX
Злыдни
 
291 / 32 (2) +++
Регистрация: 22.09.2008
Адрес: Тюмень, Рашан Федерашан
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
За исключением того, что импорт в нижний слой объекта, измененного на верхнем слое может себя повести не так как ожидаете. Например объект может глючить. Или все изменения зальются сразу в usp. Т.е. xpo можно (гарантированно без последствий) заливать только в верхний слой (конечно только если объект лежит на нескольких слоях).

А так - конкретно usp-слой - я бы оставил "на всякий случай" как самый верхний слой. Иногда его не хватает.. Например - заливаешь большой xpo и смотришь все изменения (актуально при переходе на сервис-пак/ролап/большой хотфикс)
То есть я понимаю что при таком способе никакого пересечения id не будет?
Таблица с usr слоя с другого приложения будет занесена с новым id которого нет ни на usr ни на usp?
только что попробовал сделать такое и в принципе все занеслось на usp слой, с нормальным id. Не пробовал пока только заносить в usr.
__________________
Axapta 3.0 sp 5 Oracle
Диплом Интернет-Университета Информационных Технологий: Основы бухгалтерского учета
Я могу взорвать вам мозг!!!
Старый 12.10.2010, 13:19   #9  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,312 / 3547 (125) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от Murlin Посмотреть сообщение
Таблица с usr слоя с другого приложения будет занесена с новым id которого нет ни на usr ни на usp?
Не будет. У usr-usp сквозная нумерация по id-шникам
__________________
Возможно сделать все. Вопрос времени
Старый 12.10.2010, 13:35   #10  
S.Kuskov is offline
S.Kuskov
Участник
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
 
3,439 / 1775 (66) ++++++++
Регистрация: 28.04.2007
Адрес: Калуга
Цитата:
Сообщение от sukhanchik Посмотреть сообщение
Не будет. У usr-usp сквозная нумерация по id-шникам
Не будет? Т.е. таблица не загрузится? Или не будет, в смысле пересечения id не будет?

Мой опыт говорит о том, что при загрузке нового объекта без сохранения id, этому объекту будет присвоен следующий свободный в загружаемом диапазоне идентификатор.
Старый 12.10.2010, 13:39   #11  
sukhanchik is offline
sukhanchik
Administrator
Аватар для sukhanchik
MCBMSS
Злыдни
Лучший по профессии 2015
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,312 / 3547 (125) ++++++++++
Регистрация: 13.06.2004
Адрес: Москва
Цитата:
Сообщение от S.Kuskov Посмотреть сообщение
Мой опыт говорит о том, что при загрузке нового объекта без сохранения id, этому объекту будет присвоен следующий свободный в загружаемом диапазоне идентификатор.
Именно так и будет. Не будет пересечений. А id при загрузке на usp присвоится из того же загружаемого диапазона что и usr
__________________
Возможно сделать все. Вопрос времени
Старый 12.10.2010, 13:40   #12  
Murlin is offline
Murlin
Возьми свет!!!
Аватар для Murlin
Самостоятельные клиенты AX
Злыдни
 
291 / 32 (2) +++
Регистрация: 22.09.2008
Адрес: Тюмень, Рашан Федерашан
Цитата:
Сообщение от S.Kuskov Посмотреть сообщение
Не будет? Т.е. таблица не загрузится? Или не будет, в смысле пересечения id не будет?

Мой опыт говорит о том, что при загрузке нового объекта без сохранения id, этому объекту будет присвоен следующий свободный в загружаемом диапазоне идентификатор.
Не понял ничего!
Будет пересечение id да или нет?
__________________
Axapta 3.0 sp 5 Oracle
Диплом Интернет-Университета Информационных Технологий: Основы бухгалтерского учета
Я могу взорвать вам мозг!!!
Старый 12.10.2010, 13:42   #13  
lev is offline
lev
Ищущий знания...
Аватар для lev
Oracle
MCBMSS
Axapta Retail User
 
1,723 / 491 (20) +++++++
Регистрация: 18.01.2005
Адрес: Москва
Цитата:
Сообщение от Murlin Посмотреть сообщение
Не понял ничего!
Будет пересечение id да или нет?
нет, пересечений не будет.
переносить надо будет без сохранения id.
__________________
"Страх перед возможностью ошибки не должен отвращать нас от поисков истины." (с)
С Уважением,
Елизаров Артем
За это сообщение автора поблагодарили: Murlin (1).
Старый 12.10.2010, 13:47   #14  
Murlin is offline
Murlin
Возьми свет!!!
Аватар для Murlin
Самостоятельные клиенты AX
Злыдни
 
291 / 32 (2) +++
Регистрация: 22.09.2008
Адрес: Тюмень, Рашан Федерашан
Цитата:
Сообщение от lev Посмотреть сообщение
нет, пересечений не будет.
переносить надо будет без сохранения id.
Спасибо всем большое.
__________________
Axapta 3.0 sp 5 Oracle
Диплом Интернет-Университета Информационных Технологий: Основы бухгалтерского учета
Я могу взорвать вам мозг!!!
Старый 12.10.2010, 18:46   #15  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5798 (201) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от Murlin Посмотреть сообщение
я решил включить разработку на usp слое для наших местных доработок
На сегодняшний день мы имеем готовый функционал на usr слое, который периодически должен будет обновляться, но заноситься он сравнением.
Работая на usr слое мы переписываем написанный функционал и затираем его, кроме того имеем очень много функционала который нам пока не нужен или вообще не нужен.
Не имея лучшего я предложил делать наши местные доработки на usp слое.
Цитата:
Сообщение от Murlin Посмотреть сообщение
Тут вся фишка в том что мы не просто подкладываем usr слой, а заносим изменения xpo файлом
Так зачем же все-таки вам вести разработку на usp-слое? Какие проблемы вы хотите решить таким образом? Что сейчас мешает вести собственные доработки "сбоку" на том же usr-слое, где находится "пока" и "вообще" не нужный функционал? Если вы просто хотите иметь возможность вернуться к тому коду, который вы переписываете и затираете, то храните его в old-каталоге и все. Зачем придумывать себе лишние трудности, которые самим же потом придется преодолевать? Или, может, вы думаете, что за счет разработки на другом слое при "занесении изменений" на usr вам меньше придется потом сравнивать объекты и сливать изменения? Если так, то это заблуждение...
Старый 12.10.2010, 19:34   #16  
BOAL is offline
BOAL
Участник
Аватар для BOAL
MCBMSS
Злыдни
1C
Лучший по профессии 2015
 
621 / 453 (17) +++++++
Регистрация: 28.04.2003
Адрес: Москва
Уже не раз обсуждали идеологию слоеных разработок.
С sukhanchik'ом имели опыт разных приложений с разными слоями, где шло обновление КАС слоя, как СП вниз под ЮСР с основным кодом.

Одного слоя мне лично мало, но и использовать слои с одним полем нумерации - это не оч. хорошо.
ЮСП занимать нельзя, он нужен для утилит (стираются слоем при нужде) и заливки ХРО сравнением без глюков (сравнение с ОЛД или при закачке не полноценное или глючит или нет удобный стрелочек).
Поэтому в вашем случае стоит опустить весь ЮСР в КАС, а разработку билда вести на ЮСР, опуская в КАС после кодревью на сборке обновления.
Но опять же, делать все это на рабочей базе тоже не хорошо, это удобно для Дев.
Обновление слоем или ХРО тоже обсуждали. Важно не попасть на стриание таблиц при синхронизации.
Старый 13.10.2010, 07:49   #17  
Murlin is offline
Murlin
Возьми свет!!!
Аватар для Murlin
Самостоятельные клиенты AX
Злыдни
 
291 / 32 (2) +++
Регистрация: 22.09.2008
Адрес: Тюмень, Рашан Федерашан
Цитата:
Сообщение от BOAL Посмотреть сообщение
Уже не раз обсуждали идеологию слоеных разработок.
С sukhanchik'ом имели опыт разных приложений с разными слоями, где шло обновление КАС слоя, как СП вниз под ЮСР с основным кодом.

Одного слоя мне лично мало, но и использовать слои с одним полем нумерации - это не оч. хорошо.
ЮСП занимать нельзя, он нужен для утилит (стираются слоем при нужде) и заливки ХРО сравнением без глюков (сравнение с ОЛД или при закачке не полноценное или глючит или нет удобный стрелочек).
Поэтому в вашем случае стоит опустить весь ЮСР в КАС, а разработку билда вести на ЮСР, опуская в КАС после кодревью на сборке обновления.
Но опять же, делать все это на рабочей базе тоже не хорошо, это удобно для Дев.
Обновление слоем или ХРО тоже обсуждали. Важно не попасть на стриание таблиц при синхронизации.
Просто потому что состояние сейчас катастрофическое, слияние двух проектов будет задачей нереальной. Кроме того второй программист занимается оптимизацией некоторых задач и я боюсь как бы не дооптимизироваться до того что все перестанет работать.
У нас нет ни кас ни вар никаких других кроме usr и usp. Притом при все что решение как бы на самом деле вертикальное, непонятно почему пожалели денег на слои.
__________________
Axapta 3.0 sp 5 Oracle
Диплом Интернет-Университета Информационных Технологий: Основы бухгалтерского учета
Я могу взорвать вам мозг!!!

Последний раз редактировалось Murlin; 13.10.2010 в 08:03.
Старый 13.10.2010, 07:59   #18  
Murlin is offline
Murlin
Возьми свет!!!
Аватар для Murlin
Самостоятельные клиенты AX
Злыдни
 
291 / 32 (2) +++
Регистрация: 22.09.2008
Адрес: Тюмень, Рашан Федерашан
Цитата:
Сообщение от gl00mie Посмотреть сообщение
Так зачем же все-таки вам вести разработку на usp-слое? Какие проблемы вы хотите решить таким образом? Что сейчас мешает вести собственные доработки "сбоку" на том же usr-слое, где находится "пока" и "вообще" не нужный функционал? Если вы просто хотите иметь возможность вернуться к тому коду, который вы переписываете и затираете, то храните его в old-каталоге и все. Зачем придумывать себе лишние трудности, которые самим же потом придется преодолевать? Или, может, вы думаете, что за счет разработки на другом слое при "занесении изменений" на usr вам меньше придется потом сравнивать объекты и сливать изменения? Если так, то это заблуждение...
А почему нет? Ну при условии что импорт в usr происходил бы конкретно в usr, с другим id отсутствующим в базе, но раз тут говорили о том что вноситься изменения то в usp а то в usr в независимости от того откуда сам взят xpo, то все отпадает данный вариант. Заодно было бы видно что и где конкретно не работает. (Меньше от того что не все объекты usr затронуты usp хотя бы по этому)
Хотя можно и проверить.
__________________
Axapta 3.0 sp 5 Oracle
Диплом Интернет-Университета Информационных Технологий: Основы бухгалтерского учета
Я могу взорвать вам мозг!!!
Старый 13.10.2010, 13:22   #19  
Bober is offline
Bober
Участник
 
311 / 104 (4) +++++
Регистрация: 29.05.2007
Murlin, ради бога, завязывайте, хватит уже. Вы какой-то фигней занимаетесь, и своим разработчикам гемор хотите устроить, и людей на форуме провоцируете на какие-то ненужные разборки, хоть бы прислушивались что вам объясняют, что ли.
Это сугубо личное мнение, я не могу вам запретить и дальше гнать волну..
Старый 13.10.2010, 15:46   #20  
Murlin is offline
Murlin
Возьми свет!!!
Аватар для Murlin
Самостоятельные клиенты AX
Злыдни
 
291 / 32 (2) +++
Регистрация: 22.09.2008
Адрес: Тюмень, Рашан Федерашан
Цитата:
Сообщение от Bober Посмотреть сообщение
Murlin, ради бога, завязывайте, хватит уже. Вы какой-то фигней занимаетесь, и своим разработчикам гемор хотите устроить, и людей на форуме провоцируете на какие-то ненужные разборки, хоть бы прислушивались что вам объясняют, что ли.
Это сугубо личное мнение, я не могу вам запретить и дальше гнать волну..
Я прислушиваюсь. Странный вывод какой то...
Нельзя ну нельзя, хорошо.... Таких нельзя еще миллион потому что кто то так сказал и захотел. Объясните почему нельзя.
Id пересекаются - нет не пересекаются.
usp глючит - неизвестно.
занесение не работает как нужно - хорошо.
В чем я собственное не прислушался?
Какой геммор я собирался сделать для разработчиков? Упростить им сведение и разработку?
__________________
Axapta 3.0 sp 5 Oracle
Диплом Интернет-Университета Информационных Технологий: Основы бухгалтерского учета
Я могу взорвать вам мозг!!!

Последний раз редактировалось Murlin; 13.10.2010 в 16:00.
Теги
слои

 

Похожие темы
Тема Автор Раздел Ответов Посл. сообщение
Создание проекта из объектов созданных на данном слое Asterisk DAX: Программирование 3 10.10.2006 13:38
Совместная работа заказчика и исполнителя в разных или одном слое? Кузин Владимир В. DAX: Программирование 6 08.08.2006 10:02
Кросс-слойная разработка OliaM DAX: Программирование 14 11.01.2006 20:30
Кто знает, что можно исправлять в Ах на USR слое без модуля "разработка"? sergey_alekseev DAX: Функционал 2 03.09.2003 11:44
Каким образом можно получить код для работы в конкретном слое ? Андре DAX: Функционал 9 18.02.2003 15:58
Опции темы Поиск в этой теме
Поиск в этой теме:

Расширенный поиск
Опции просмотра

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.
Быстрый переход

Рейтинг@Mail.ru
Часовой пояс GMT +3, время: 01:36.