Одновременный учет несколькими пользователями

[dmites]

Компания, осуществляющая внедрение разводит руками - одноврменный учет невозможен из-за блокировки учетных таблиц. Результат - один пользователь учитывает -> второй ждет

[mazzy]

Да, именно так.

Уменьшайте время блокировки данных.
Либо программно, либо увеличивая мощность железа.

Для Аксапты методика повышения производительности описана здесь
http://axapta.mazzy.ru/lib/querytuning/
http://axapta.mazzy.ru/lib/mssqlsetup2/
http://axapta.mazzy.ru/lib/adjustment/
http://axapta.mazzy.ru/lib/dbgrowthsolution/

Для Навижина похоже, но есть особенности.
Во-первых, разберитесь с узкими местами (снимите данные счетчиков), во-вторых, разберитесь с индексами. В Навижине многие индексы можно выключить, много чего включить дополнительно. Но включать/выключать индексы можно только на основании данных измерения производительности.

[GalaM]

Да, именно так.
Ну с двумя пользователями это может быть и не заметно (хотя, если документ длинющий можно и заметить), а десяток пользователей точно не могут.

Кроме увеличения мощности железа, это может помочь, но не на 100%.
Можно еще попробовать пакетный учет - есть специальное задание - отбираешь нужные документы и учитываешь их одним махом.
пользователь может ставить признак ("к учету"), а специально написанная процедурка отбирает такие документы и учитывает.
При такой схеме ( и "правильной" мощности железа ) может ожновременно около 20 пользоватлей только "учитывать" документы (или правильнее сказать готовить их к учету).

Еще можно сократить длину строк в документе. Так журнал из 100 строк учтется в несколько раз быстрее, чем из 1000. Так что можно дробить документ (вручную или автоматически), определяя оптимальный его размер

[Fordewind]

dmites,

а что подразумевается под "сложным складом"?

Конечно, первым делом надо посмотреть на железо. Но, хорошо бы иметь своего человека, который бы мог пошариться по коду учета и оптимизировать его, выкуинв лишние LOCKTABLE, COMMIT. В особенности, если стандартный код был сильно расширен/изменен. Работа временами муторная (за нее берутся неохотно), но дает порой хороший результат.

[Yoil]

Поддерживаю gala. Если юзеры будут не учитывать документы, а, так сказать, ставить их в очередь на учет, то все будет гораздо лучше

[Sitizen]

Тож поддерживаю вариант отложенного учета.

[romtex_imported]

Не всегда можно делать пакетный учета, т.к. пока товар не купить его не переместить, пока не переместишь не продашь и т.д. и т.п.
Учитывать такие документы нужно в порядке заведения.
Зато небольшое колдовство над КЮ 12451 (даже не трогая 22) позволяет увеличть скорость учета внутренних перемещений, списания, инвентаризации, оприходования в 3-7 раз!!!
Конечно, в этом случае второй пользователь все-равно будет ждать, но гораздо меньше.

[romtex_imported]

Вот статистика к предыдущему сообщению.

[GalaM]

Цитата:

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

Зато небольшое колдовство над КЮ 12451 позволяет увеличть скорость учета внутренних перемещений, списания, инвентаризации, оприходования в 3-7 раз!!!
(

А что именно Вы правите? есть какие-то общие рекомендации?

Хорошо, конечно, если только акты списания такого объема, а когда все документы по системе большие, да еще их и много.... Что делать, сколько КЮ колдовать

Да и колдун нужен хороший

Да и переход на новую версию весьма сомнителен
Кстати в 4.0 указанного КЮ не обнаружино..

Так что мне кажется, что это крайний случай, когда ничего другого не поможет....

[Yoil]

Цитата:

Кстати в 4.0 указанного КЮ не обнаружино..

gala, это потому, что 4.0 международный А 12ххх и 14ххх - это уже местные поделки.

[romtex_imported]

Цитата:

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

А что именно Вы правите? есть какие-то общие рекомендации?

Хорошо, конечно, если только акты списания такого объема, а когда все документы по системе большие, да еще их и много.... Что делать, сколько КЮ колдовать

Да и колдун нужен хороший

Да и переход на новую версию весьма сомнителен
Кстати в 4.0 указанного КЮ не обнаружино..

Так что мне кажется, что это крайний случай, когда ничего другого не поможет....

ХИ-ХИ
То сначала рекомендаций просите, то крайним случаем обзываете. Нелогично.

Теперь по-порядку.
По-поводу рекомендаций.
Сервис - Монитор клиента - Старт.
Учитываем критический документик.
Сервис - Монитор клиента - Стоп.

Ищем критические точки по времени выполнения.
Собственно колдуем и тестируем.

По-поводу количества КЮ.
Если все документы большие то начинать нужно по порядку с самого критического. Ускорив учет одного типа документа вам будут ясны критические места и в других документах. А КЮ над которыми имеет смысл колдовать не так много и эффект от колдовства больше будет чем от железа.

По-поводу колдуна. Без него сейчас никуда. Боюсь даже до оптимизации не добраться

По-поводу новой версии. Сочуствую вашим клиентом, если они работают на голом Кронусе. Если это не так (я в этом практически не сомневаюсь), то сомнение отпадает само собой Да и чем же это сложнее перенести код по оптимизации чем код по пакетному учету в новую версию?

По-поводу крайнего случая. На все выпады ответил, поэтому, не вижу ничего крайнего. И остатки сразу видны и учет быстро идет и порядок докуметов не нарушается. Поэтому мне крайним больше представляется пакетный учет. Вообщем все ваши агрументы это лапша ленивого кодера и консультанта для клиента. Извиняюсь

[GalaM]

Цитата:

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

Вообщем все ваши агрументы это лапша ленивого кодера и консультанта для клиента. Извиняюсь

Ну, если обидела, то то же извиняюсь.

Никто не говорит, что в код лезть не надо (Это Navision ). А возможно ли так работать на голом КОРУСЕ?
Просто всегда у решения должна быть альтернатива.

Цитата:

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

А КЮ над которыми имеет смысл колдовать не так много и эффект от колдовства больше будет чем от железа.

Согласна. Сама бы предложила такую последовательность решения проблемы (по стоимости и простоте их решения)
- сократить количество строк в документах
- пакетный учет
- колдовтство на учетными КЮ
- еще индексы можно пооптимизировать и по-перестраивать...
- upgrade железа

Цитата:

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

И остатки сразу видны и учет быстро идет и порядок докуметов не нарушается.

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