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

[murad]

Есть стороннее приложение, которое должно работать с Axapta (+SQL Server).
Для ускорения работы запросов предлагается делать выборки напрямую
из SQL Servera, a запросы, модифицирующие данные, выполнять через логику Аксапты (через Com Connector)

В чем здесь могут быть подводные камни?
PS: при чтении данных нет необходимости проверять права на чтение. Считается, что приложение имеет максимальные права.

[George Nordic]

Ну, надо учесть DataAreaId.

С Уважением,
Георгий

[Gustav]

Если делать выборки напрямую, то я бы учёл следующее:

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

P/S:
5. В случае Oracle надо будет еще бороться с пустыми строками, выглядящими как Chr(2). Но раз речь об SQL Server, то неактуально.

P/S 23.01.07:
6. В случае Oracle я бы еще добавил, что нужно будет следить за регистром символов (особенно в условии WHERE)
7. Для любой СУБД нужно будет иметь в виду ситуации, связанные с использованием текстовых кодов (всякие id, accountnum и т.п.), выравненных по центру или по правому краю, когда в том же условии WHERE строку-фильтр нужно будет начинать слева некоторым количеством пробелов, которое не всегда очевидно (либо использовать славящийся своей неоптимальностью оператор LIKE '%<значение>%' ).

[KiselevSA]

А если пойти по обратному пути: запрашивать из Axapta данные для обновления из SQL, а само обновление производить через бизнес-логику. Одно дело, когда производится обновление полей в таблице, которые никак не завязаны на логику обработки, другое - обновлять данные, завязанные на разноску. По-моему, использование COM будет не быстрее связки методы Axapta -> данные в сторонней базе SQL

[murad]

Спасибо за развернутые ответы.
Думаю такие проблемы можно пережить в условиях имеющейся задачи.
Время выборки в данном случае является более критичным

[e-Car]

Если приложение будет грузить SQL Server тяжёлыми запросами, если запросы будут написаны некорректно и будут "вешать" эксклюзивные блокировки, то последствия будут плохо предсказуемыми.
Вообще, "сажать" два транзакционных приложения на одну базу чревато взаимными блокировками (Axapta не догадывается, что она не одна...). Если же речь идет об аналитическом приложении, то его уж точно надо строить над хранилищем данных, куда по тем или иным правилам переносить информацию из транзакционной системы.

[George Nordic]

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

С Уважением,
Георгий

[AraraT®]

Присоединяюсь к e-Car, у нас тоже есть сторонняя программа, которая строит разного вида отчета (ну неумели мы на тот момент программировать на X++), так вот, если Акса блокирует таблицу, то программа не может выбрать данные. Или же когда идет обновление приложения, АОС остановлен, а база доступна, что тоже создает некоторые осложнения.

[blokva]

Цитата:

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

Спасибо за развернутые ответы.
Думаю такие проблемы можно пережить в условиях имеющейся задачи.
Время выборки в данном случае является более критичным

+
А еще есть волшебная табличка InventDim например...и InventModule к примеру

[murad]

Цитата:

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

+
А еще есть волшебная табличка InventDim например...и InventModule к примеру

А что с ними не так?

[murad]

И ещё такой вопрос: если, например, для полнотекстового поиска повесить доп. индексы на таблицы Аксапты. То не будет ли аксапта удалять эти индексы при синхронизации или компиляции? И существует ли удобный механизм делать такой поиск средствами Аксапты, не считая варианта с ручным прописыванием запроса "INNER JOIN ... CONTAINSTABLE" ?

[Gustav]

Цитата:

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

...если, например, для полнотекстового поиска повесить доп. индексы на таблицы Аксапты.
То не будет ли аксапта удалять эти индексы при синхронизации...?

Будет ругаться, будет удалять - если индексы созданы средствами СУБД вне Аксапты.
Выход - создайте доп.индексы в самой Аксапте (в AOTе)


P.S.Forward

Цитата:

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

А можно ли создать полнотекстовый индекс средствами Аксапты, а не SQL Servera?
Насколько я знаю - нет.
(Axapta 3.0 SP3)

я не в курсе, врать не буду

[KiselevSA]

Цитата:

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

И ещё такой вопрос: если, например, для полнотекстового поиска повесить доп. индексы на таблицы Аксапты. То не будет ли аксапта удалять эти индексы при синхронизации или компиляции? И существует ли удобный механизм делать такой поиск средствами Аксапты, не считая варианта с ручным прописыванием запроса "INNER JOIN ... CONTAINSTABLE" ?

По поводу индексов посмотрите тему Не удалять индексы при синхронизации

По поводу запросов - почему бы не присмотреться к executeQuery с передачей запроса к SQL "открытым" текстом?

[murad]

Цитата:

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

Будет ругаться, будет удалять - если индексы созданы средствами СУБД вне Аксапты.
Выход - создайте доп.индексы в самой Аксапте (в AOTе)

А можно ли создать полнотекстовый индекс средствами Аксапты, а не SQL Servera?
Насколько я знаю - нет.
(Axapta 3.0 SP3)

[blokva]

Цитата:

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

А что с ними не так?

Да все с ним так, просто на первую ссылаются очень многие таблицы в разных контекстах, ведь там хранятся разные комбинации аналитик. Вторую просто надо иметь ввиду, например при определении ЕИ номенклатуры в зависимости от ситуации (Закупки, хранение, продажи)...
Я просто к чему, это требует повышенного внимания при посторении запросов напрямую...

[sergeypp]

Стоит учесть что эта база не является рабочей.. В ней создаются заказы и только.. Может быть заказ будет помечаться как обработанный, но это можно сделать избежав блокировок необходимых для выборки страниц.. Все бизнес процессы будут приосходить в рабочей базе, куда будут передаваться обработанные (или подтвержденные ) заказы. Одновременно будет работать ну максимум человек 5.. Я не думаю.. что они будут тормозить систему.. Если блокировки и будут создаваться, то можно использовать схему запроса с NOLOCK. Я не думаю, что для вывода информации из текущей базы нужны актуальные данные.. Если даже в дальнейшем там и появятся какие то бизнес процессы, они не будут оказывать большого влияния на быстродействие системы.. Что касается аналитик, то аналитики будут только по складу и ячейке, причем на каждом складе будет максимум 1 ячейка.. в Течении дня будет создаваться максимум 100 строк заказов.. Так что размер INVENTDIM будет не существенен...
2 e-Car.. а можно уточнить про "(Axapta не догадывается, что она не одна...)" а что?? в аксапте есть система управления блокировками??? мне не понятен смысл этого выражения.. поясните, будьте так добры..

[e-Car]

С одной базой работает 2 приложения. Работает много пользователей. Они периодически жалуются на какие-то ошибки, которые то возникают, то нет. В одних и тех же ситуациях. В тестовых условиях ошибки не воспроизводятся. Что будете делать? Включать трассировку SQL на всё время работы, на все выполняемые с базой операции? Опрашивать кто что делал с 10 до 11? В каком из приложении и в каком именно месте искать ошибку? А если ошибки нет, а просто одно приложение не учитывает, что другое приложение (про поведение которого это первое ничего не знает, поскольку создавалось отдельно, как самостоятельное приложение) тоже может изменять данные, блокировать (не дай Бог эксклюзивно) таблицу на ма-а-а-аленький промежуток времени? Вы, я так понимаю, ошибок в коде не допускаете? Так сказать "сделай правильно с первого раза". Тогда я Вас обрадую - в Аксапте ошибок хоть отбавляй, особенно если в ней меняли хоть что-то в качестве доработки.
P.S. Если база не рабочая, то можете делать с ней что хотите. Хоть десять приложений "навешать". Мои соображения относятся только к работающим системам. В начальном вопросе не было ничего про "Стоит учесть что эта база не является рабочей.. В ней создаются заказы и только.."

[sergeypp]

Про ошибки все понятно... полностью соглашусь.. Просто фраза прозвучала след образом

Цитата:

Сообщение от e-Car

Вообще, "сажать" два транзакционных приложения на одну базу чревато взаимными блокировками (Axapta не догадывается, что она не одна...).

Т.е. с ваших слов ситуация когда, один пользователь в Аксапте блокирует другого пользователя коренным образом отличается от ситуации, когда одно приложение блокирует другое.. Я же не вижу принципиальных различий. Блокировки обрабатываются на уровне скуля. И нет разницы кто и как заблокировал приложение. Разве не так??

[e-Car]

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

[somebody]

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

-----

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