Подскажите пожалуйста, может ли помочь данная компонента, в проблеме ограниченного числа активных пользователей в базе 1С. На стандарных конфигурациях количество одно временно работающих пользователей редко доходит даже до 50, на самописных возможно увеличение количество пользователей до 100.
Однако, возможно с применением прямых запросов и оптимизацией конфигурации мы сможем получить на порядок большее количество одновременно работающих в базе, например 500 или 800?

А что вы не встречались с такой проблемой в 1С 77?
Вероятно, вызывано блокировками таблиц (файлов) в первую очередь.

P.S. Поделитесь реальными цифрами одновременных подключений к базе?

Муму говорил, что реализоввывал проекты где одновременно 750 пользователей работало(V77).

Krimskiy_xan писал(а) 25. Мая 2006 :: 09:43:

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

Если с помощью прямых запросов не просто "ускорять пару тормозных отчетиков", а ориентироваться на SQL, начиная с этапа проектировки структуры данных и бизнес-логики, то эффект получится са-авсем другой.

Систему, полноценно оптимизированную под СКуЛь, адекватно воспроизвести под ДБФом невозможно в принйипе (ИМХО)

Krimskiy_xan писал(а) 26. Мая 2006 :: 04:56:


Эхххх, вот и опять те же грабли.  
То, что я и называл "лишними телодвижениями".

Нее, соберусь все же как-нибудь, напишу статейку о системном подходе к бухучету.
Применительно к данному вопросу ключевой вопрос звучит так: а нахрена ты вообще при проведении снимаешь итоги? Наверное, чтобы себестоимость посчитать? Так ты ж их все равно наверняка неправильно считаешь - или у вас задним числом никто ничего не правит? А даже если и правильно - нафига они тебе нужны немедленно? Может, проще раз в неделю все правильно пересчитать, а в оперативном режиме тебе ведь нужно только правильный дебет на клиента повесить, да правильно количество списать; стоимость этого количества можно и позже посчитать.

Итак, предложения (независимые, кстати, от 1Сплюсплюсности)

1. Без описанных выше революционных преобразований - тоже есть вариант, но корявый:
А нафига считать итоги в модуле проведения?
ДО начала проведения считаем итоги. Передаем их в модуль проведения в качестве параметра. При отсутствии параметра модуль проведения работать отказывается.
В скорости не выиграешь, но от блокировок уходишь.
Только системный флажок придумай: установил флаг, посчитал итоги, сбросил флаг. А если кто-то втыкается в уже поднятый флаг, то "сделай паузу, скушай sleep(1000)" - в цикле, пока флаг не освободится. Правда, придется тогда все доки, двигающие 41й счет, с этим флажком знакомить.

2. Мыслим непредвзято (см. выше)
а) Вообще не считаем итоги. Только вешаем дебет и списываем штуки. Это называется "режим проведения 1"
б) В воскресенье перепроводим все нафиг в "режиме 2", т.е. полноценно. Кстати, в самой накладной полезно хранить режим, в котором она была проведена.

2+) Кстати, в воскресенье скорость проведения тоже имеет значение: ведь хочется еще и пива успеть попить.
Поэтому задумываемся: а нахрена мы каждый раз итоги пересчитываем?
Посчитаем их один раз перед массовым проведением, запихнем в глобальную табличку, и будем при проведении каждого дока эту табличку обновлять...

3) А накладные вообще-то построчно кем-то заполняются? вот и проводи их построчно! Транзакций много, но зато все короткие. Только птичку "Автоматическое удаление движений" не забудь сбросить, поскольку ОчиститьДвижения(), если надо, никогда не поздно и самому сделать. Ну, тут тонкостей вообще-то много - все сходу не упомнишь

3+) Правда, есть беда: 1Ска, сволочь, не знает, что ты построчно проводишь. И каждый раз перезаписывает весь документ. Когда строк - сотни и, тем паче, тыщи, накладно становится.
А нахрена тебе в документе строки? Заведи справочник и там все, что надо, храни. А в одном из полей - ссылочка на документ.
Правда, в этом варианте уж точно без прямых запросов нелегко придется.

Итоги рассчитывать необходимо для проверки правильности проведения документа, хватает или нет того или иного товара...

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

ЗЫ А вообще пункт 1 имеет право на жизнь... всяко...

Самый грамотный вариант, который я уже как пол года собираюсь реализовать, да времени нет, всё какой то лажой отвлекаю - это "2+"
Еще останавливает то, что его можно использовать только на отвлеченном от повседневной жизни перепроведении за пройденный период (типа запуск в воскресение). То есть не решает проблему блокировок днем, а тема начиналась с этого.
А во-вторых, как будет ворочиться 1Ска если у неё будет оперативно обновляться таблица примерно 30тыс на 40 (артикулы х склады).