Прямое обращение к СУБД, минуя Axapta

[e-Car]

Вас интересует как SQL отрабатывает обращения? Да, ему до лампочки сколько программ к нему обращается.
Меня обычно интересует как работает программа с точки зрения пользователя.

[somebody]

1) Возможно, придётся бороться с форматом дат, это может зависеть от региональных настроек сервера и клиента. Сталкивался с этим...
2) Cистемные таблицы, например, UtilIdElements, отсутствуют в БД SQL. Если в переносимой логике Аксапты они используются, надо будет делать свои хранимки, к примеру, для перебора имён таблиц...
3) Тут упоминали про блокировки, так можно читать с with (nolock)...
2AraraT: а что за программа, её нельзя, что ли, переделать на dirty read?

-----

Приложение: без приложений.

[AraraT®]

Цитата:

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

2AraraT: а что за программа, её нельзя, что ли, переделать на dirty read?

Смысла нету, потому что эта программа уже умирает потихоньку... все отчеты переносим в Аксу.

[KiselevSA]

Цитата:

Сообщение от AraraT®

Смысла нету, потому что эта программа уже умирает потихоньку... все отчеты переносим в Аксу.

Только не переносите отчеты, требующие выборок за длительные периоды. Лучше присмотритесь к OLAP

[murad]

Возвращаюсь к этой теме уже с конкретным вопросом:
Есть необходимость использовать хранимые процедуры SQL Servera.
Не будут они удалены Аксаптой при синхронизации (или других операциях)?

Пробовал создавать тестовую хранимку и проводил синхронизацию DataDictionary, процедура не была удалена. Но хотелось бы убедится, чтобы не переводить потом все хранимки на запросы

[Morpheus]

Допишите в метод dbSynchronize класса Application вызов проверки состояния Ваших хранимых процедур...

[murad]

Цитата:

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

Допишите в метод dbSynchronize класса Application вызов проверки состояния Ваших хранимых процедур...

А можно подробнее? Был бы признателен за примерный код

Всё что есть в этом методе:

boolean dbSynchronize(tableId tableId         = 0,   // 0 = all tables, non-zero is a valid table handle
                      boolean syncAsNeeded    = true,  // true = objects touched in the AOT, false = unconditional synchronize
                      boolean continueOnError = true,
                      boolean showProgress    = true ) // true = report all problems, but throw only after all tables are synchronized, false = stop synchronize after first error/problem
{
    SqlSyncPending  sqlSyncPending = new SqlSyncPending();
    boolean         ok;
    ;

    setPrefix("@SYS22807");

    ok = super(tableId, syncAsNeeded, continueOnError, showProgress);

    if (ok && this.isRunningMode())
    {
        SysApplicationSetup::saveApplicationVersion(SysApplicationSetupMode::Synhronize);
    }


    return ok;
}

[Maxim Gorbunov]

Business Views (Бизнес-представления, это Вы правильно нашли) входят в лицензию Business analysis. Если у Вас этих таблиц нет, значит просто не установлен этот лицензионный ключ.

Для того, чтобы "Проверка" дала эффект, надо чтобы в списке перечислимых текстов был хотя бы один Enum. Появляются они там, когда Вы создаете View (Представление) с использованием enum'ов. В общем, попробуйте. Функционал простой, работает как часы. Бережет время и нервы при работе извне с enum'ами, виртуальными компаниями, доменами, display-методами (там есть ограничения, продиктованные механизмом обновления значений).

До широкой общественности информация донесена с помощью white paper, который есть на установочном диске Аксапты.

[somebody]

2 murad

Цитата:

Есть необходимость использовать хранимые процедуры SQL Servera.
Не будут они удалены Аксаптой при синхронизации (или других операциях)?
Пробовал создавать тестовую хранимку и проводил синхронизацию DataDictionary, процедура не была удалена. Но хотелось бы убедится, чтобы не переводить потом все хранимки на запросы

Если речь о версиях 2.5/3.0, то никаких посягательств на процедуры Аксапта не совершает. Более того, даже триггеры её не волнуют (хотя своих триггеров она принципиально не имеет).
Проверено нескольколетним опытом на Аксаптах 2.5/3.0, SQL Server 2000/2005.
Насчёт AX 4.0 не в курсе.

[Alexius]

Цитата:

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

Более того, даже триггеры её не волнуют

Не совсем верно:
1. Переиндексация БД средствами Аксапты гарантированно удаляет триггеры
2. В 2.5 при удалении поля или изменении размера синхронизация грохает триггеры (думаю 3.0 ведет себя аналогично)
3. Иногда синхронизация таблицы иницирует переиндексацию, см. п. 1

[Gustav]

Цитата:

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

1. Переиндексация БД средствами Аксапты гарантированно удаляет триггеры

Подтверждаю существование этой проблемки для Axapta 3.0 SP4 на Oracle 9.2. После выполнения в "SQL Администировании" Аксапты для выбранной таблицы (с нашими самописными триггерами) команды "Индексы => Реиндексация", статусы всех триггеров этой таблицы в БД меняются на Invalid. Для возвращения в Valid приходится выполнять перекомпиляцию триггеров средствами Oracle. Слава Богу, что при всём при этом не удаляются тексты триггерных процедур! (типа "и на том спасибо")


P.S. А вообще, похоже, всё не так критично. Во всяком случае, для Oracle (для MS SQL Server не знаю). Вот что мне только что в "аське" написал мой коллега:

Цитата:

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

И это правда. Я проверил.

[Alexius]

Действительно забыл указать, что удаление триггеров я смотрел на MS SQL.

[gl00mie]

Может, не совсем в тему, но добавлю свои 5 копеек про использование триггеров на БД Axapta:
Триггеры - побочные эффекты использования