belugin
То есть проблема в том что на Аксапте возможно существование кривого партнерского решения?

Проблема в том, что база подается как манна небесная, а остальное пишут люди. И без разницы на чем, С#, Delphi, X++

belugin
ок. если можно со слоя dis и ниже.

я хз, что такое слой dis :-) я пришлю код Аксапты и SQL запрос :-)

belugin
Вы дочитали до того места, где описывается, как сделали в 4?[/b]


Читал. А Вы это читали? Вдумайтесь в цифры. База 3 раза может поместиться в ОЗУ! никакой проблемы с железом нет.. Процы, круче гор и оврагов... А эта ПОСТРОЧНАЯ АКСАПТА.... перемалывает и блокирует записи по одной штучке.... Маразм.. Читал и Плакал...


beluginЯ наверное, чего-то не понимаю в SQL сервере, но объясните, как избежать грязного чтения InventSum без блокировок. Например, если после обновления InventSum транзакцию придется откатить по причине какого-то сбоя, не получится ли так, что другая транзакция сможет списать оприходованное количество, а оно потом исчезнет в результате роллбека.

Видимо я не понимаю ничего. Зачем при приходе товара блокировать!!!! При продаже кстати тоже... блокировки не нужны :-))) Вопрос, как видите не с MS SQL а к логике, архитектуре. Именно ее я считаю ущербной...


belugin
Я нашел некий топик про то, как сделать аналог того, что делает конструкция merge на SQL2008.

Мне было бы интересно скорее архитектурное решение. Как бы вы сделали непострочную обработку более сложного процесса, чем просто обновление остатков. В аксапте же кроме этого бухгалтерская разноска, чтение и учет всяких скидок по оплате, накладных расходов и еще куча всего.


Тут я пас.. хз о чем речь..

belugin
В-общем, насколько я понял, у вас
стоит Ax3, причем не обновлявшаяся, года, наверное 3 (поддержку SQL2005 сделали тогда, выход релиза 2002 год)

стоит SQL 2000 (2000 г. релиза)

поверх этого партнерское решение, возможно кривое

поверх него какие-то модификации на слое usr, кривые


Все это сочетание тормозит, что является недостатком Аксапты.

Кстати, если у вас такие объемы как у вас RecID не кончились - тоже вроде могли бы пожаловаться (в версии 3 они были 32 битные и сквозные на всю БД, в 4 они 64 битные и потаблиучные)

Так и есть. Но логика построчной обработки записей, накладывает ущербный отпечаток на кодеров... Они не могут мыслить таблицами, большими объемами данных. В итоге даже код на MS SQL они пишут через курсоры...

mazzyVolochkova
belugin
ок. если можно со слоя dis и ниже.

я хз, что такое слой dis :-)
Пять баллов!

Volochkova
belugin
Мне было бы интересно скорее архитектурное решение. Как бы вы сделали непострочную обработку более сложного процесса, чем просто обновление остатков. В аксапте же кроме этого бухгалтерская разноска, чтение и учет всяких скидок по оплате, накладных расходов и еще куча всего.


Тут я пас.. хз о чем речь..


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

Я пока от Вас ни одного опровержения не видел. Мне одного того что для каждой записи RecID генерируется на клиенте достаточно..
Могу в картинках...

Если вы думаете что при апдейте записи на более "правильном" слое, записи на базе не блокируются. То тут точно 5 баллов!

И то что отпечаток накладывается, знаю... Мне
в sql коде хватает за глаза..
Переписал на массовую обработку, так процедура вместо 20 часов!!!!! работает 2 минуты :-))

belugin
Предположим такой сценарий

Есть две транзакции A и B.

А приходует товары a1 и a2 на склад С1.
B перемещает товар a1 c С1 на склад C2.

Сценарий

1. A увеличила остаток a1 на C1
2. В посмотрела на этот остаток (так как блокировки нет, она не знает что он "грязный" и что нельзя закоммититься) перенесла его на склад C2.
3. А пытается увеличить остаток a2 на С1 но что-то происходит и транзакция откатывается.

Итого:

- Нет ни одной приходной накладной
- На складе С2 есть остаток, который неизвестно откуда взялся.

Яркий пример такого отпечатка :-)
Видимо я путаю механизмы транзакции и блокировки...

Еще немного бреда...
Вот табличка.. уж ХЗ насколько она стандартная.. мне от не ведомо..
за половину рабочего дня.. у нее фрагментация 16% остается после 100% сделанных в ночь.

iscrafmbelugin
Предположим такой сценарий

Есть две транзакции A и B.

А приходует товары a1 и a2 на склад С1.
B перемещает товар a1 c С1 на склад C2.

Сценарий

1. A увеличила остаток a1 на C1
2. В посмотрела на этот остаток (так как блокировки нет, она не знает что он "грязный" и что нельзя закоммититься) перенесла его на склад C2.
3. А пытается увеличить остаток a2 на С1 но что-то происходит и транзакция откатывается.

Итого:

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

Дикость прямо с самой презентации видна, невооруженным взглядом.
:-)
Только в том примере, который тут в 3 строчки дали....
а если строк 10 скажем? и блокировки прут на уровни MS SQL, т.к. данные сильно фрагментированы и индексы тяжелые... т.к. по текстовым полям..

В итоге маразм выглядит так..
Первый пользователь...
Взяли первую строку... заблокировали ( заблокировалась целая страница данных)...
Взяли вторую строку... заблокировали ( заблокировалась целая страница данных)...
Взяли третью строку... заблокировали ( заблокировалась целая страница данных)...
А четвертую строку взять не можем, т.к. второй пользователь... наблокировал своих страничек... и ждет когда мы отпустим первую ...
И так блокировками поростает весь сервер...

И про 100 человек одновременно работающих... лично я не верю..
Выше описано... если база данных.. 3 раза помещается в ОЗУ... то проблема тормозов в архитектура БД и принципах обработки..

Это как приговор..
И полумерами.. описанными в презентации, вынесение... в промежуточные таблицы.. это еще один путь в коллапс... только более жестокий..

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

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

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

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

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

mazzyVolochkovaу нее фрагментация 16% остается после 100% сделанных в ночь.
/topic/650982&pg=7#7209568
Разберитесь наконец с индексами.

Гы.. и что там не так?
Индекс что кластерный, что нет.. эффект одинаковый.. база стоит колом :-))) только с кластенрым при 20 пользователях.. а без него на 5 :-)

Порядок полей ( если вернуть как было в Аксапте) база стоит раком в принципе :-)))

Ой... А что это за табличка?
Индексы не трогал....
А что за пробелы такие левые????
:-)