mazzyVolochkovamazzyVolochkova
Но зато человеку достоверно известно:
Volochkova
Но логика построчной обработки записей, накладывает ущербный отпечаток на кодеров...

Я пока от Вас ни одного опровержения не видел. Мне одного того что для каждой записи RecID генерируется на клиенте достаточно..
Могу в картинках...
Вам же уже сказали:
1. читайте доку про update_recordset, insert_recordset
2. построчно на клиента переносятся результаты запросов. Запросы с агрегирующими функциями (типа select count(recid) from custtable group by custaccount) выполняются на сервере. Получившиеся результаты построчно переносятся на клиента. Но строк в результате гораздо меньше, чем в исходной таблице. Так работает курсор.

В общем, пилите дальше.

Это и есть построчная гемороидалья.... Можно дальше не пилить... :-)
Вместо отправки на сервер запроса - проведи документ и получить результат...
Пользователь сидит и ждет.. когда же для каждой строки отработают куча маленьких запросиков..
Достаточно взглянуть SQL профайлером, что делает процесс... как бегает курсором по таблицам.. :-)

Так что красивые маркетинговые фишки... это не клиент серверная обработка. :-)
Кстати, вот о чем сейчас подумал.

1.
Куча маленьких, одинаковых, заранее скомпилированных, закэшированных, параметризированных (чтобы сработал cost optimize) запросов бывает лучше, чем десяток монстроидальных запросов Поэтому пилите, пилите. Изучайте. Узнавайте больше.

2.
Я тут вспомнил одного клиента, у которого подобные "шпециалисты" выключили Аксаптовское кэширование таблиц. В результате у них Аксапта действительно занималась ddos-атаками на sql-сервер, постоянно запрашивая параметры (например, стандартную величину округления = 0.01 руб, или максимальную величину ошибки в проводках = 0.01 руб). Когда вернули таблицам стандартные параметры кэширования, то ddos-атаки прекратились, потому что Аксапта держала записи в своем кэше и не посылала запросы к этим таблицам на sql.

Если у организации, где работает Volochkova есть вменяемые люди, то проверьте свойства CacheLookup по крайней мере у таблиц CompanyInfo, LedgerParameters, InventParameters, CustParameters, VendParameters, Currency.

У этих таблиц совйство CacheLookup должно быть либо Found, либо EntireTable.
Разработчики Аксапты очень серьезно думали о производительности.
Не будьте волочковыми, думайте о последствиях своих действий.[/quot]

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

И про производительность ни черта они не думали.. Судя по тому что я вижу...
Ну или партнеры, которые решение продают...

To ALL... Прекращайте пытаться "спасти бедную Volochkov" :-) Топик про недостатки Аксапты..
Если надо будет, я задам вопросы на Аксфоруме.

V. GoncharenkoVolochkovaВидимо я не понимаю ничего
Вы действительно ОЧЕНЬ многого не понимаете
авторМне одного того что для каждой записи RecID генерируется на клиенте достаточно..
Вы это каким образом определили? Вообще RecId на сервере геренируется в большинстве случаев (за исключением толстого клиента)
авторЗачем при приходе товара блокировать!!!! При продаже кстати тоже... блокировки не нужны :-))) Вопрос, как видите не с MS SQL а к логике, архитектуре. Именно ее я считаю ущербной...

Такие понятия, как ACID , для нас пустой звук, но архитектуры обсуждать любим..
Вам бы выйти из режима агрессивного отрицания (см. "маразм" в каждом сообщении) и начать задавать правильные вопросы на профильных форумах. А пока что резюме такое
- Снятая с поддержки версия приложения
- Снятая с поддержки версия СУБД
- Непонятной кривизны партнерское решение

Гы... Ну сколько раз твердили миру...
И что что снятая с производства? СУБД а тем более версия Аксапты?

Пример плиз, генерации RecID на сервере... Сейчас это делает ну точно не MS SQL. А если так, то значит это делает клиент, АОС или сам клиент..

автор- Непонятной кривизны партнерское решение.
Вот не надо тут рака за камень заводить. Это между прочим продавалась как самое супер мега пупер решение.. работающие в крупных розничных сетях центральной части страны :-)

И возвращаясь к вопросу топика номер раз...
Получается что решение могут продать кривое/голове...
С поддержки не слазить, ибо станете Волочковыми :-)))
Готовьте бабки господа.. и огромные.. Ибо маркетологи пролечили уши...

Итого пока именно такое...

miklenewVolochkova
Вот табличка.. уж ХЗ насколько она стандартная.. мне от не ведомо..

Да уж. Когда я начинал изучать Axapt-у, то что такое слои было в первый день.
Ради интереса сдул пыль с книг по разработке. Ax 3.0 - 20 стр, Ax 4.0 - 40 стр.
Советую ещё раз вдумчиво почитать одну из этих книг.
Прежде чем мне доверили что-то оптимизировать, прошло месяца три не меньше.
Но я тогда уже основы знал как отче наш. И простых задач, но актуальных для организации много наделал. Знал не только как правильно, но и почему.
Да и у нас практиковался такой метод, как просмотр кода более старшими товарищами.
Axapta - отличная система, уже почти 3 года программирую на ней и средства что-то ускорить в ней есть. Я вообще стараюсь не лезть в БД.
То что действительно бывают проблемы как со скоростью или с неудачным архитектурным решением, это да. Но 98% случаях, это не стандартная Axapta, а то что написали либо партнёры (внедренцы) или на клиенте.
А вы не понимая, кто-что сделал наводите панику.
На axforum.info создать тему вы по какой-то причине боитесь или не хотите, чтоб вам помогли.
Пишите на непрофильном форуме, вполне конкретные проблемы вперемешку с поверхностными выводами.
Если проблем много, а подсказать доброжелательных старших товарищей нет, таких которые были в своё время у меня. Это плохо.
Могу помочь, стать тем самым старшим товарищем, 1-2 часа в день (по мере вашей в этом необходимости) проводить консультации по телефону или любыми другими удалёнными средствами.
Если интересно, то детали можно обсудить по почте kolosov82@inbox.ru.
PS: Сразу оговорюсь, на всякий случай, не терплю хамства.

Мыло записал. Будет необходимость, обязательно обращусь с конкретными вопросами.
Спасибо.