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

[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]

Цитата:

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

1. Присоединяюсь по DataAreaId к Георгию.
...
4. Енумы будут числами (для представления их "словами" можно сваять в БД дополнительный справочник всех енумов - я использую простенькую табличку AX_BASE_ENUMS из 4-х полей)

И зачем только разработчики Аксапты Business Views придумали?

Цитата:

Сообщение от George Nordic

Кстати, а почему бы не использовать ReportServer? Он и данные потихоньку подкачивает, и основную базу не нагружает... Есть же у него какаие-то временные базы? Может, кто занимался этим вопросом?

Reporting services использовать оччень неудобно (по крайней мере, пока). Есть проблемы с настройкой произвольных подитогов, форматированием отчетов. Не все поля корректно импортируются в Excel. Кроме того, мне не очень понятно, почему snapshot'ы отчетов можно делать только со значениями параметров по умолчанию (хотя здесь, возможно, я просто не уловил идею). Свои таблицы у сервера есть, и кэширование настроить можно. Другое дело, что это именно кэширование. То есть, обновление этих таблиц по расписанию (по ночам, например) мне настроить не удалось (в частности потому, что snapshot'ы работают только с параметрами по умолчанию). А вообще, Reporting services без Analysis services исплоьзовать, наверное, не стоит. Reporting services - это, все-таки, фронт-энд. Одна из его важных частей - report builder, с помощью которого пользователи могут построить свой отчет на лету. Вряд ли они при этом будут озабочены настройкой кэширования. А вот если данные, на основе которых отчет строится, будут лежать на analysis server, то администрирование всей системы будет проще.

[Gustav]

Цитата:

Сообщение от Maxim Gorbunov

И зачем только разработчики Аксапты Business Views придумали?

Ох, уж и не знаю. Может быть, и не надо было им заморачиваться, раз пытливые и любознательные, вроде меня, все равно по-новому для себя это всё открывают (я сейчас говорю конкретно о енумах)

То, что придумали - молодцы, конечно. А вот если бы как-то еще и донесли до широкой общественности, то цены бы им не было (в русском мануале "Администрирование" я об этом ничего не нашёл).

Я, как бы это сказать... "вхож" в два внедрения Аксапты 3.0, выполненными разными внедренцами. В одном из них эта фича присутствует. По меню это: "Администрирование - Настройки - Бизнес-анализ - Бизнес-представления - Перечислимые тексты". Причем, нажатие на кнопку "Проверка перечислимых текстов" и дальнейшее подтверждение языка "Ru" не имеет никакого эффекта - ничего не происходит. Тем не менее, уже вижу, хоть и пустые, но таблицы BASEnumTable и BASEnumValueLine, а также классы BASEnumDoAll и BASEnumEngine. Во втором внедрении такого пункта меню нет, не созданы таблицы в базе (хотя описание в репозитарии, конечно, присутствует). Видимо, вторые внедренцы решили, что "оно нам такое не надо" и фичу эту соответствующим ключом не открыли.

[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.

[somebody]

2 Alexius

Цитата:

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

1. Пользовались для переиндексации ТОЛЬКО средствами MS SQL. Поэтому с такой проблемой не сталкивался.
2. Да, в 3.0 триггеры удаляются при синхронизации, не только при удалении/изменении, но и при добавлении поля.
3. В каких случаях? Можно подробнее?

[gl00mie]

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

[Alexius]

Цитата:

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

3. В каких случаях? Можно подробнее?

Для АХ 2.5 + MS SQL переиндексация таблицы может инициировать :
- изменение кластерного индекса
- изменение свойств поля (напр. размер), входящего хотя бы в один индекс
- переименование поля
- удаление поля
- изменение структуры таблицы с большим числом полей
- перенос модификаций, связанных с изменением структуры БД, переподкладкой всего приложения

PS. Список не полный