InventLocationId в InventTrans

[Ilyaae]

Хорошо, а если заполнение складской аналитики повесить на SqlServer, триггером на вставку и изменение? Ведь склад нужен нам только для построения отчетов, а не менять логику работы АХ. Как по мне, то это решает многое.

[Владимир Максимов]

Цитата:

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

Хорошо, а если заполнение складской аналитики повесить на SqlServer, триггером на вставку и изменение? Ведь склад нужен нам только для построения отчетов, а не менять логику работы АХ. Как по мне, то это решает многое.

Это Вы себе кучу проблем создадите. Один раз синхронизировли таблицу с SQL-триггером из Axapta и нет больше триггера Можно, конечно, "подправить" алгоритм синхронизации, но оно того не стоит. Сопровождение подобной "многопалубной" системы сильно усложнится.

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

[Ilyaae]

Цитата:

Сообщение от Владимир Максимов

Это Вы себе кучу проблем создадите. Один раз синхронизировли таблицу с SQL-триггером из Axapta и нет больше триггера Можно, конечно, "подправить" алгоритм синхронизации, но оно того не стоит. Сопровождение подобной "многопалубной" системы сильно усложнится.

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

Так правильно, но эти поля должны заполнятся в inventtranse, а триггер как раз и позволит это делать в дальнейшем, после синхронизации, он же не разрушится(его повесить на inventdim). А решить, более быстрая выборка данных, не используя inventdim

[zelibobis]

Цитата:

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

..после синхронизации, он же не разрушится(его повесить на inventdim).

Цитата:

Сообщение от Владимир Максимов

Это Вы себе кучу проблем создадите. Один раз синхронизировли таблицу с SQL-триггером из Axapta и нет больше триггера Можно, конечно, "подправить" алгоритм синхронизации, но оно того не стоит.

при синхронизации триггер погибнет смертью храбрых. и вообще это как-то не "аксаптавей".

[Ilyaae]

Цитата:

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

при синхронизации триггер погибнет смертью храбрых. и вообще это как-то не "аксаптавей".

При синхронизации, которая пройдет 1 раз, он еще не нужен, а после его включить. Так за-то в АХ ничего не ломаем.

[Владимир Максимов]

Цитата:

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

Так правильно, но эти поля должны заполнятся в inventtranse, а триггер как раз и позволит это делать в дальнейшем, после синхронизации, он же не разрушится(его повесить на inventdim). А решить, более быстрая выборка данных, не используя inventdim

Какая связь между способом заполнения некоего поля и способом его использования (чтения значения этого же поля)?

Вы считаете, что если некое поле заполнять при помощи SQL-триггера, то выборки по этому полю будут работать быстрее, чем если то же самое поле заполнять средствами Axapta?

Цитата:

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

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

Как Вы думаете, спустя месяц..два, разработчки вообще вспомнит о том, что после синхронизации некой таблицы надо в ней вручную поднять SQL-триггер? А если синхронизируется несколько таблиц сразу в автоматическом режиме?

Цитата:

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

Так за-то в АХ ничего не ломаем.

Axapta - это не только теплый мех собственно приложение, но еще и база данных. Одно без другого не имеет смысла. Так что, Вы по любому "ломаете" Axapta. Просто в другом месте. Причем в таком, на которое разработчки подумает в последнюю очередь. Т.е. закладываете под себя "мину замедленного действия". Когда "рванет" точно не известно. Но точно известно, что "рванет"

[Ilyaae]

Цитата:

Сообщение от Владимир Максимов

Какая связь между способом заполнения некоего поля и способом его использования (чтения значения этого же поля)?

Вы считаете, что если некое поле заполнять при помощи SQL-триггера, то выборки по этому полю будут работать быстрее, чем если то же самое поле заполнять средствами Axapta?

Дело не в том как его заполнить. Смысл в создании и заполнении этого поля. Что даст прирост в скорости выполнения запросов(рассматривает t-sql)

Как Вы думаете, спустя месяц..два, разработчки вообще вспомнит о том, что после синхронизации некой таблицы надо в ней вручную поднять SQL-триггер? А если синхронизируется несколько таблиц сразу в автоматическом режиме?

Зачем что то поднимать, триггер не рушится, он создан и действует. А синхронизация нужна, до момента запуска триггера.

Axapta - это не только теплый мех собственно приложение, но еще и база данных. Одно без другого не имеет смысла. Так что, Вы по любому "ломаете" Axapta. Просто в другом месте. Причем в таком, на которое разработчки подумает в последнюю очередь. Т.е. закладываете под себя "мину замедленного действия". Когда "рванет" точно не известно. Но точно известно, что "рванет"

АХ-приложение, которое работает в связке с SQL and ORACLE. Триггер в данном случаи ничего не меняет в работе приложения, а дополняет его. Просто механизм заполнения нужных полей аналитики в InventTrans, ложится на триггер.

[Pustik]

Цитата:

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

АХ-приложение, которое работает в связке с SQL and ORACLE. Триггер в данном случаи ничего не меняет в работе приложения, а дополняет его. Просто механизм заполнения нужных полей аналитики в InventTrans, ложится на триггер.

а почему вы в цитате оставили
"
Как Вы думаете, спустя месяц..два, разработчки вообще вспомнит о том, что после синхронизации некой таблицы надо в ней вручную поднять SQL-триггер? А если синхронизируется несколько таблиц сразу в автоматическом режиме?

Зачем что то поднимать, триггер не рушится, он создан и действует. А синхронизация нужна, до момента запуска триггера.
" ?
Триггер, это, конечно, замечательная возможность в SQL. Но, она не имеет ни каких преимуществ перед аксаптовскими "триггерами". (да простят меня аксаптеры). В аксапте это делать намного проще, удобнее и быстрее, чем на SQL, это во вторых, а во-первых, управление данными, таким образом, вы перекладываете на две , скажем так системы, что в итоге может привести к конфликту. Аксапта сама способна сделать то, что может сделать SQL триггер, при этом потребует от вас наименьших затрат, гарантируя при этом минимальное количество рисков.

[Ilyaae]

Цитата:

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

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

А можно подробней, чем реализовать это в АХ? Где пример посмотреть?

[lev]

Цитата:

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

АХ-приложение, которое работает в связке с SQL and ORACLE. Триггер в данном случаи ничего не меняет в работе приложения, а дополняет его. Просто механизм заполнения нужных полей аналитики в InventTrans, ложится на триггер.

Так про то и говорят, что оно дополняет приложение, но только временно, а именно до первой синхронизации таблицы. При синхронизации таблицы триггер удалится.
А случиться эта синхронизация может когда угодно! Причем даже тогда, когда вы об этой таблице и не вспомните. Например при изменении свойства StringSize у EDT с типом String будет выполнена синхронизация всех таблиц (поясню, вы изменили длину поля ItemId, которое не имеет отношения к вашей таблице, а она отсинхронизировалась и до свидания триггер)!

P.S. просто совет, прислушайтесь к людям, и выполняйте изменение с помощью самой аксапты (ведь именно приложение, а не БД, управляет бизнес логикой), меньше проблем будет потом...

[Ilyaae]

Цитата:

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

Так про то и говорят, что оно дополняет приложение, но только временно, а именно до первой синхронизации таблицы. При синхронизации таблицы триггер удалится.
А случиться эта синхронизация может когда угодно! Причем даже тогда, когда вы об этой таблице и не вспомните. Например при изменении свойства StringSize у EDT с типом String будет выполнена синхронизация всех таблиц (поясню, вы изменили длину поля ItemId, которое не имеет отношения к вашей таблице, а она отсинхронизировалась и до свидания триггер)!

P.S. просто совет, прислушайтесь к людям, и выполняйте изменение с помощью самой аксапты (ведь именно приложение, а не БД, управляет бизнес логикой), меньше проблем будет потом...

А, понял. Сорри, спутал с синхронизацией данных. Вот и думал, чего б это триггеру пропадать