InventLocationId в InventTrans

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

Цитата:

Сообщение от 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 триггер, при этом потребует от вас наименьших затрат, гарантируя при этом минимальное количество рисков.

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

[Pustik]

Цитата:

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

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

В Аксапте у каждой таблицы существуют методы. В том числе и Insert(),Update(),Delete(), которые и будут являться аналогами триггеров на SQL. Перекрывая их, Вы можете написать в них свой алгоритм, который отработает при каждом : добавлении записи - Insert(), обновлении - Update() и удалении - Delete().
Простейший пример можно увидеть посмотрев эти методы на таблице Справочника номенклатуры inventTable.
В методах Insert() и Update() автоматически проставляется краткое наименование номенклатуры :

this.setNameAlias();

void insert()
{
    #OCCRetryCount
    ;
    try
    {
        ttsbegin;

        this.insertInventItemOrderSetup();

        this.insertBOMTable();
        this.setNameAlias();

        super();
        ............
}

void update()
{
    InventTable         this_Orig       = this.orig();
    ItemGroupId         itemGroup_Orig  = this_Orig.ItemGroupId;

    ForecastSales   forecastSales;
    ForecastPurch   forecastPurch;
    ;

    ttsbegin;

    this.setNameAlias();
    this.inventModelGroup().inventModelType().preUpdateInventTable(this);

    super();
    .............
}

В методе Delete() автоматически будут удалены спецификации по версиям этой номенклатуры :

public void delete()
{
    BOMTable        bomTable;
    BOMVersion      bomVersion;
    BOMVersion      bomVersion2;
    ;

    ttsbegin;

    if( !isConfigurationkeyEnabled(configurationkeynum(BOMVersion)) && this.inventItemType().canHaveBOM())
    {
        while select bomVersion
                group by bomId
                where bomVersion.ItemId == this.ItemId
           notexists join bomVersion2
                where bomVersion2.bomId == bomVersion.bomId &&
                      bomVersion2.ItemId != this.ItemId
        {
            delete_from bomTable
                where bomTable.bomId == bomVersion.bomId;
        }
    }

    super();

    ttscommit;
}

[lev]

Цитата:

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

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

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

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

[Ilyaae]

Цитата:

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

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

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

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