Конфигурация "Управление торговлей для Казахстана".
Основной документ "Реализация товаров и услуг" (РТУ)
Пользователей в базе 20-25, из них активно забивающих РТУ в пиковые нагрузки 4-6 человек.
Основная забивка в РТУ, через сканер штрихкода.

Реализовал автосохранение документа через Записать()
Процедура Автосохранение() прописана в процедурах:
Процедура ОбработкаПодбора(ТабличнаяЧасть, ЗначениеВыбора) Экспорт
Процедура ТоварыПередОкончаниемРедактирования(Элемент, НоваяСтрока, ОтменаРедактирования, Отказ)
Процедура ТоварыПередНачаломИзменения(Элемент, Отказ)

Все это работало, около 3-4 лет, Документ до 100 позиции, отрабатывает без задержки. Документ 100+ чувствуется задержка, документы 200+ запись уже секунда и более, но было терпимо.
Ну вот недавно перешли на postgresql и началось :)

Отказаться от автосохранения, сами пользователи не хотят. Запись через промежуток времени нас не устроит, большой ассортимент товаров, в случае сбоя придется пересчитывать весь товар заново. А некоторые накладные бывает и по 30 минут забивают.
Пользователей научить нажимать самим периодически "Записать", не вариант.

Вообщем думаю реализовать автосохранение через локальную запись файла в *.txt в папке Temp. Как думаете взлетит? Или подскажите другие варианты?

(0) > большой ассортимент товаров, в случае сбоя придется пересчитывать весь товар заново.

С сколько было таких сбоев за 3-4 года?

(1)+ *С = А
> в случае сбоя придется пересчитывать весь товар заново. А некоторые накладные бывает и по 30 минут забивают.
Пользователей научить нажимать самим периодически "Записать", не вариант.

Авто-записывать через 10 введенных строк, тогда пересчитывать придется только последние 1-9 строк :)

(0) psql тормознутая штука, недавно на одном проекте пришлось отказаться от него, лечить тормоза будет дороже чем mssql купить. В общем то у нас при похожей задачи пишется в xml документ + хистори для отката при ошибках сканирования. Но в основном так было сделано чтобы бизнес-процессы сканирования (там сложные цепочки действий) не внедрять в типовую конфигурацию. Все работает замечательно

(1) Раз в месяц 1 сбой бывает. Но задача была поставлена, выполнил.

(3) Да мы возможно тоже купим SQL, потомучто вижу что перевод в управляемый режим блокировок, будет стоить не меньше по деньгам чем SQL.
Я вот тоже думаю txt или xml, просто мне показалось что в текст как то попроще будет.

(3) +1 Постгри реално тормознутая штука.
"Пользователей в базе 20-25" - Цена вопроса ~150 т.р.. Купите MsSQL.

(6) Ну по скорости то postgresql устраивает. Месяц на нем сидим.
Но вот блокировки да замучили уже.

(5) На xml проще, потом разбираешь его через xdto, работаешь как с объектом, на основании которого в дальнейшем заполняешь нужный тебе документ.

(4) >Раз в месяц 1 сбой бывает.
Вот эту проблему решить не дешевле выйдет, чем SQL?

(9) Не подумал. Озвучу руководству.

(3) ну от чела с таким ником было-бы странно что-то дргое услышать...

(11) Я людей знаю, которые поставили postgresql, а потом от него отказались.
Так как допиливать конфу под postgresql, не всегда дешевле, чем купить SQL.

(7) очень интересно.... упп - 1 база, постгри, 50+ пользователей, 20+ активных.... блокировки возникали довольно редко... но правда неплохой сервер

(12) конфы нетиповые?

+ (14) если нетиповые - се проблемы на совести разработчиков

(13) УПП для Казахстана допиленная была.
У нас типовая, но про управляемые блокировки ничего нет.
А у вас в режиме управляемых блокировок это работает?

(11) Ну мне это сам программер psql сказал, типа "чего вы хотите psql это не mssql, будет тормозить, работает медленнее". На вопрос заточить код psql по уму сказал, что во много раз проще купить mssql.
Сама задача стояла регулярно грузить номенклатуру миллионами в 1-2 дня, в общем заточили все на mssql

(17) + тоже была похожая ситуация

(16) типовая + немного внесено изменений в типовой функционал (в основном в подписках) + несколько своих документов в дополнение к типовым + несколько десятков отчётов + пара законченых подсистем (слабо интегрированы с функционалом упп, в основном интеграция в том, что документы этих подсистем используют те-же справоники и создают документы из иипового функционала). Всё что писали сами конечно на управляемых