Компонента с исходным кодом (Delphi 6) и тестовой конфигурацией выложена здесь:

http://x-romix.narod.ru/vk_TerminalSleep.rar

Решил посмотреть, что же происходит, когда 1С ожидает блокировку.
Создал простейшую конфу, в которой есть всего один документ.
В модуль проведения вставил Предупреждение, чтобы она останавливалась и все блокировала.

// ********************
Процедура ОбработкаПроведения()
   Предупреждение("Имитация длительного проведения.");
КонецПроцедуры

Открываю другую копию той же конфигурации, и пытаюсь создать новый документ.
(или провести старый).

1С в этом случае загружает проц на 100% и крутится в непрерывном цикле, опрашивая время.

(0) так что делает компонента, я так и не понял?

Софтайсом останавливаю наугад - с большой вероятностью процессор попадает в этот цикл, и я могу пройти его по шагам.

Непрерывно жму F10 - действительно крутится в одном и том же цикле.

Нахожу осмысленные функции, заходя по F8 во вложенные CALL-ы

CALL [KERNEL32!LockFile] //Вызов системной функции LockFile
TEST EAX, EAX //Проверка на 0
JNZ 1F10EAD9 //Переход не выполняется
CALL [KERNEL32!GetLastError] //Вызов системной функции GetLastError
TEST EAX, EAX //Проверка на 0
JZ 1F10EAD9 //Переход не выполняется
CMP EAX,21 //Проверка на код ошибки 21h или 33 - файл заблокирован
JNZ 1F10EAB8 //Переход не выполняется


(комментарии я добавил сейчас вручную - SoftICE их, конечно же, не показывает).

(2) Устраняет 100% загрузку процессора, когда кто-то проводит документ, а кто-то второй пытается тоже начать его проводить.

(+4) Точнее, когда один юзер проводит документ, а другой пытается создать новый документ или провести другой документ - тогда в терминале (да и не в терминале тоже) все, что называется, встают.

(4) "устраняет" - вот это не совсем понятно, как она обходит платформу или что она делает (конечно можно исходник посмотреть, но может в двух словах... а то мне SoftIce, увы, ни о чем не говорит)

(6) Короче 1С-ка непрерывно долбится в функцию KERNEL32!LockFile, и пытается заблокировать файл. Программисты забыли вставить вызов sleep(), и поэтому при многопользовательской работе в 1С включаются тормоза.

Я перехватываю системный вызов GetLastError - возврат последнего кода ошибки. Если он равен 33 (21h), то я включаю паузу на указанное (при вызове внешней компоненты) количество миллисекунд.

(7) ага, понял, а ты этот вызов обходишь?

+9 все, уже прочитал

Я взял этот код из дампа (см. выше):
CMP EAX,21 //Проверка на код ошибки 21h или 33 - файл заблокирован

Код ошибки 33 MSDN расшифровывает так:
33 The process cannot access the file because another process has locked a portion of the file. ERROR_LOCK_VIOLATION

Инициализация компоненты в коде 1С:

Процедура ПриНачалеРаботыСистемы()
   ЗагрузитьВнешнююКомпоненту(КаталогИБ()+"..\DLL\TerminalSleep.dll");
   Tsleep=СоздатьОбъект("Addin.TerminalSleep");
   Tsleep.УстановитьПаузуПриБлокировке(1000);
КонецПроцедуры    // ПриНачалеРаботыСистемы


(12) т.е. проверка "проведенности" будет производиться не в вечном цикле, а с интервалом 1с, так?

(13) Короче, если кто-то другой проводит документ, то ты не можешь провести свой документ, и не можешь создать новый документ - 1С-ка ждет в цикле, пока другой пользователь не освободит таблицу. Я вставляю паузы sleep, которые не потребляют процессорного времени. Получается, что ожидание происходит с минимальной загрузкой проца и сети.

(14) спасибо, дошло :)

по ссылке (0) есть исходники и пример, но нет самой компоненты TerminalSleep.dll ?

(18) Посмотри сейчас.

(20) а ты компоненту свою потестировал в разделенном режиме :-) ?

(20) спасибо.

(21) Запускал 2 копии одной конфы на одном компе.
Как еще тестить, пока не придумал.
Блокировку ловит, что видно из отладочной печати.

(26) Загруженность процессора должна упасть до 0. Ты в Диспетчере задач ее смотришь?

(31) Точнее, время ожидания захвата таблиц = 15

(58) А руками у тебя работает подбор, когда ты активизируешь поле, медленно жмешь F4, потом первую букву, потом вторую и т.д.? Вставь паузы sleep между имитациями нажатий, чтобы в замедленном темпе увидеть, а что происходит. Я не помню, есть ли в компоненте (51) этот метод, но в компоненте (0) или здесь http://x-romix.narod.ru/Sleep.rar он точно есть, и его можно поюзать.

(60) Вот думаю для SQL-базы то же самое намутить, там наверняка тоже "порожний" цикл без выполнения пауз, и резко падает производительность...

(63) Ты в обработчике нажатия на кнопку (к примеру) можешь вызвать событие?
Еще вариант - событие попадает в форму справочника, т.к. там есть его обработчик.

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

в "другом" - ничего нет вообще, чисто. А в обработчик события отладчик не идет
Процедура ПриНажатииКнопкиКлавиатуры(прм_КодКлавиши,прм_Alt,прм_Shift,прм_Ctrl,прм_Символ,прм_ФСО)
   //Сообщить("Код клавиши: "+прм_КодКлавиши);
   чКодКлавиши=прм_КодКлавиши;
   стрА=Форма.АктивныйЭлемент();
       Если прм_Ctrl=1 Тогда
           Возврат;
       КонецЕсли;
       
       Если стрА="Улица" Тогда
           Если (ПустоеЗначение(прм_Символ)=0) Тогда
             глСервис.ВнешнееСобытие("FormEx","ВводСимвола",прм_Символ);
           КонецЕсли;
       КонецЕсли;
                                                                             
КонецПроцедуры
вот сюда попадает и все
глСервис.ВнешнееСобытие("FormEx","ВводСимвола",прм_Символ);

это только для дбф ?

(70) Хм, к сожалению нету у меня сегодня xp sp2, завтра посмотрю. На всякий случай, у меня 25 релиз 1С. DBENG32 7.70.0.14

(85) а если не через файл, а через сообщения или реестр?

(89) Надо чтобы на разных тачках его было видно. Файл-сервер же :-)

(87) Там короче надо открыть две копии конфы, в одной из них начать проводить документ, а в другой попытаться создать новый док. Без ВК загрузка процессора под 100%, с ВК загрузка = 0 (или близка к 0).

Отправил на адрес, который у тебя в карточке :)

Кстати, скачал и попробовал на ХР 0) Загрузка проца с ВК - от силы 2%.

+103) а без ВК - 52%. Проц Интел 3000, памяти 1Г. Здорово!

(112) ладно пользователь нажмет несколько раз повторить, а если работает обработка например обмена с клиент-банком, то она прервется с ошибкой.

(113) ну да прирвется. Она спросит повторить или нет, но при этом не будет 100 процентного висяка.

(114) не спросит, если самому через исключение не обрабатывать

(115) не так конечно лучше никто не спорит. Ладно будем ждать под СКЛ решение :)

(117) Ром, а 102) смотрел?

(112) В 0 тоже можно убрать. Однако хотелось бы чтобы работало по-человечески, и была возможность прервать массовую обработку, когда юзер запрашивает проведение своего документа.

(118) Нет еще, тока пришел, щас гляну..

Вообще кто ж грузит компоненты не в попытке ))

Под СКЛ когда можно будет тестировать ? Я готов стать тестером.

(124) Да я специально вынес в параметр - кому как больше нравится.
Помимо загрузки процессора, есть еще такая фишка, как задалбывание сервера лишними запросами - не факт что они кешируются, и не приводят к сбою позиционирования головок HDD, когда кто-то слишком часто долбится в одно и то же место...

(125) Да, наверное можно (даже лучше) и так - иначе приколы с языком раскладки в обычном SendKeys.

(133) Протестил - порадовало ))

Была проблемма с одно кассой - вечно че-то там захватывала, чеки с трудом проводила, ща крсиво все стало :)

(134) А что именно ты тестил? Для SQL или для DBF?

(137) Ну не знаю, я 8-ку боюсь :)

А можно ли в файл который пишется на диск при транзакции, писать имя пользователя? или любую информацию, которая поможет определить кто создал данную транзакцию

(144) Так что скажешь насчет ситуации, когда время ожидания в параметрах установлена в 0? Я всегда подозревал, что это не выход - надо процессу дать шанс подождать... 15 сек. + компоненте будет гламурнее?

(0) Эта проблема была решена давным-давно без всяких ВК.

и как?

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

(159) Да счаз.. Ты не работал с большим числом пользователей на терминале. все 4 сожрет если пользователей много и представь 4 сессии начнут проводить доки, и распиханы эти 4 сесии по разным процам вот тебе и 100% загрузки сервака со всеми его процами, 5й пользователь начинает проводить док, на том проце, который проводит в данный момент: как результат - у того кто проводил было 25% проца, стало 12,5% еще лдин влез, и в результате имеем полностью остановившуюся базу т.к. заблокировано все из-за проведения, и допровестись проблема, т.к. несколько сессий отжирает проц этими циклами.

(162) ну ситуации разные бывают.

(170) Ты сам че-то зацикливаешься без пауз. :-)

погонял на рабочей базе при работе 20 пользователей с групповым перепроведением-работает нормально. задержка 10мс, время ожидания захвата 30с. единственное уточенние - путь к маркерному файлу надо указывать полный или относительно каталога ИБ, иначе он будет создаваться в рабочих каталогах пользователей, и обработка группового проведения их не увидит, а будет видеть только свой собственный файл, хотя даже при отсутствии проверки на файл документы у пользователей проводятся без задержки.

(185) Ты че-то маленькую задержку ставишь имхо. Я бы поставил секунду-две. Это опрос заблокированности таблицы, который завершился неудачей (объект заблокирован). Если объект свободен, то и паузы не будет. Слишком часто долбиться в одно место на диске - как бы дыру в нем не прожечь :-)

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

+(208)
Подтверждаю тормоза в ТиС (dbf) при подборе номенклатуры и даже при перемещении по перечню номенклатуры внутри документов. Изменение времени Sleep результатов не приносит.

DBF. работа в терминале. не важно, есть проведение в данный момент или нет... т.е. на мой вгляд происходит слип опроса всех таблиц...

(216) Ок, спасибо, вечером посмотрю.

(219) Патч только для 7-ки, и он исправляет явную ошибку 7-ки. К 8-ке он не имеет отношения, и работать там и не должен.

(229) см. http://1c.realnet.ru/forum/f.php?ak=27786#26

:-) убедил. Твое лучше.

(235) могу предполодожить что ошибка в
HANDLE WINAPI CreateMutex(
 LPSECURITY_ATTRIBUTES lpMutexAttributes,
 BOOL bInitialOwner,
 LPCTSTR lpName
);
я как то делал в тестовых целей для себя ВК работающей с mutex, так, надо было верно создовать.
могу вечером посмотреть как было дело. так вот, с Mulex1C возникло ощущение, что не верно инициализировался мутекс, и сессии под другими логинами его не видели.

(239) Да, я вчера пытался сделать, не получилось, сегодня буду продолжать попытку.

(228) под SQL не тестировалось, в dbf нормально
ждем твоих исправлений для dbf. Кстати и в текущем варианте тормозов не замечено в справочнике. Конфа самописная, транзакции исчезли :) за что большое спасибо.

Предложение модератору открыть новую ветку - уж больно "тяжела" страница для закачки ч/з Dial-up (настроек по разбиению на страницы не нашел)
И еще хотелось бы услышать о другом подходе к решению проблемы блокировок для SQL - именуемое как "гибкие блокировки". У кого это чудо работает и может быть даже подкинуть идеи тем кто только на этот путь становится...

(245)Не пробовал нажимать в 12345>> рядом с темой?

Ром! А можно узнать, как самому получить файл odbc33.txt из своей 32-й длл-ки, чтобы сравнить с той, что лежит в архиве?

tdump.exe ИмяDLL ВыходнойФайл

(208, Drok) Обновил компоненту для DBF, вставив проверку на источник вызова (смотрю на вершину стека, что там лежит). Проверить не на чем, т.к. у меня пролистывание справочников и журналов не тормозит. Если торможение будет продолжаться, прошу выслать справочник (перетащите его мышкой в пустую конфу).

Компонента лежит по адресу:
http://x-romix.narod.ru/vk_TerminalSleep.rar

Я добавил текстовое описание (порядок установки) и разделил на две папки с версиями для DBF и SQL.

(254) Результы теста: 2-х головый XEON 2.0, 8 гиг ОЗУ, SQL DE, Win2003 EE.
До патчинга скачек при блокировке транзакции до +40% (у сервака еще своя боевая нагрузка была). После патчинга... Скачков при блокировке небыло вообще. Delay оставил по умолчанию - 1000. Тест провел 3 раза. Каждый раз получая одинаковые результры.

Огромный респект автору.

Тоже пробовал компоненту Ромикса - положительный эффект есть, отрицательные есть, но несущественны.

(251) ну что, восьмерку не смотрел еще?

(257) Тестировал на сервере, через терминал. Большого смысла патчить клиентские 1С ИМХО нет смысла. Пользователь обычно работает только с одной 1С. А для терминальника самое то. Сегодня вечером пользователи свалят из базы, поставлю в боевом режиме.

(259) Ну да, это для многопользовательского режима. В монопольном режиме патч никак не повлияет.
(260) Вот думаю, не сделать ли общий патч.
(261) Щас попробую заценить - я так понимаю, что надо чтобы модуль проведения писал что-то в периодические реквизиты...

(+258) 8-ка жж0т. Интересно, в 8-ке для SQL эта проблема тоже дает о себе знать?

(261) Проблема у меня не воспроизводится. Что именно вы делаете? Можно ли простейший случай на "почти пустой" базе?

Есть идея: перехватывать появления окна:
---------------------------
1С:Предприятие
---------------------------
При выполнении транзакции произошла ошибка!
Таблица: 1SJOURN
Ошибка обращения к данным при транзакции, выполняемой другим пользователем
Повторить попытку выполнить транзакцию?
---------------------------
Да   Нет  
---------------------------

Вместо вывода окна делать паузу, и имитировать, что пользователь нажал Да.
Тогда будет работать независимо, SQL или DBF. Для достижения полезного эффекта потребуется выставить время ожидания захвата таблиц в 0.

(241)Да собссно я имел ввиду не смену приоритета у задачи, а переключение на другой процесс, т.е. при любом обращении к системе вызывающий процесс принудительно освобождает процессорный ресурс, вплоть до ближайшего прерывания RTC или таймера внутреннего шедулера. Я работал с ОС реального времени, там эта процедура выполнялась всегда.

(261) Обновил патч для DBF - теперь он сделан не как внешняя компонента, а как патч+заменяющая DLL. И перехватывает окно (предупреждение) с ошибкой. Подробности - в readme.txt внутри архива (0).

Восьмерка у тебя явно неактуальный движок.

Я кажется понял, из-за чего у тебя тормоза. Возможно, ты не поставил патч SQL на 1С-ку, которая делает массовое проведение доков.

Кстати, административная установка - это всего лишь, когда папка BIN лежит на сетевом диске (и открыта юзерам только на чтение). А у юзеров на рабочем столе - только ярлыки в эту папку.  

А зашли мне плиз DBEng8.dll от новой версии 1С-ки... Я заценю что там новое.

У меня три терминал сервера на которых локально установлена 1С. Административных установок у меня вообще нигде нет и я ими не пользуюсь. На одном из терминалов, самом мощном, стоит и лежит база SQL.
Файл от восьмерки вышлю завтра.

Давай. Для DBF-ной базы 7.7 сейчас все проблемы я думаю решатся (т.к. я в новой версии перехватываю всего лишь окно сообщения, не вмешиваясь глубоко в движок 1С), а для SQL-ной - надо еще смотреть. Лог могу приделать, какие SQL-запросы приводят  к блокировке. Может у тебя там периодические реквизиты воду мутят...

Апаю. Внедрили в рабочей базе. Без траблов. СУПЕР!

(309) Ну здорово... Т.е. у вас убрались частые блокировки при транзакциях?

(310) Ну да, операторы теперь не тормозят, когда проводят документов кучу...

(311) Т.е. обработка массового проведения теперь не тормозит работу пользователей?
Или у вас так много пользователей, что они друг дружку все время тормозили?

(312) Пользователей - порядка 30, активных - человек 10. Операторы, когда набивали заказы, расходы - загружали весь процессор, сидели в ожидании и "нервно курили (с)". Теперь - тормозов нет. Еще раз спасибо.

(313) Да не за что.. Я просто не понимаю откуда такой сильный эффект. У вас терминал + SQL? И они курили, когда кто-то массово перепроводил документы обработкой, или даже без перепроведения обработкой - тоже курили?

(318) Да я думаю партнеры напишут, если окажется, что сеть 1С после этого работает намного лучше.

(315)В старых операционках (RSX-11 и др.)файл хранился в нескольких версия. И всегда использовалась самая последняя. Так, что идея хорошая! :)

Роман, если сделаешь и (315) - цены твоему творению не будет!

другую ветку, пусть все в одной будет.

Тему (315) с DLL для скачивания я выложил здесь:
Горячая замена конфигурации 7.7: md_chng.dll

(331) Сорри забыл уточнить. Внешняя компонента, которая умеет делать Sleep:

http://x-romix.narod.ru/Sleep.rar

Есть и другие способы.

Спасибо, скачал, на досуге попробую

Ну чё, компонента таки не работает, или у Маньяка кривые ручонки??

Про скуль, семёрку.... ХЗ что происходит, но блокировки временами появляются. Хотя народу человек 60 всего....

(338) Проверить можно так: сделать тестовый документ с предупреждением в модуле проведения. Начать проводить его. С другого компа начать проводить другой док. Если при этом на другом компе загрузка процессора = 100%, то патч не работает. Если 0% - то работает. Для 8-ки кстати - тот же тест. Другие ситуации (например, со справочниками) я не разруливал - если кто-то мне даст легко воспроизводимый тест (ситуацию, когда возникает пожирание ресурсов при блокировке), сделаю и для этого случая.

А что тогда Sleep_1C.dll?

+341 Причем, некоторые пользователи утверждают, что в загруженной сети наблюдается достаточно резкое улучшение.

(343) :-)

(345) Че-то я в упор у себя не вижу такой библиотеки...
Для DBF: Sleep_1C.dll
Для SQL: odbc33.dll
Для 8-ки: Sleep_v8.dll

Поправил патчер для 8-ки: теперь он патчит подстроку по любому смещению (подходит для любого известного мне релиза 1С v8).

(345) Есть подозрение, что на сервере лежит более одной копии папки BIN.
Когда кто-то заходит во вторую копию, в системе сбивается ссылка в реестре.

Возможно, проблема исчезнет, если положить искомую DLL в папку SYSTEM32.

Я имею в виду ошибки транзакций. А то есть 3-комповая рабочая группа, так мне не удалось застать проблему, но по словам девочек-менеджеров, там что-то пишется про транзакции и 1С вылетает. Релиз 25.

Не могу зарегистрировать dll-ку. И вопрос Sleep_1C.dll - это и есть TerminalSleep.dll ?
не получается применить , подскажите пожалуйста

Пробовал на win2003server   пи регистрации dll пишет "dll была загружена но найти точку входа для DllRegisterServer не удалось". 1С при запуске пишет "Ошибка при создании объекта из компоненты E:\1Cbase\ts93_25\DLL\TerminalSleep.dll (отсутствует CLSID)"

аналогично на XP SP2

(355) Слушай, может тебе Нуралиеву все-таки стоит позвонить ? :)

(355) А вообще автору респект и уважуха - у себя протестил, действительно лучше стало :)

(359)А не забила ли фирма "1С" на такие вещи?

Сумашедшая ветка!

(361) Походу уже давно :), эта проблема и в ранних релзах была :)

(356) Это простая DBF-ка, ее не надо регистрировать.
Читай readme.txt, там надо пропатчить patch_dbeng.exe и просто положить эту DLL в папку BIN

(369) Нашел - оно только один раз выводится. Я принудительно выставляю время захвата таблиц в 0 в настройках 1с 1Cv7.CFG.

Ну так это ж вроде было еще в версии от 17.04.2006  01:44           141 824 odbc33.dll. И почему у той, что сейчас в архиве, время 23:34?

Кстати, у меня, когда я еще до патча на тестовой базе(которая в архиве с патчем) попробовал провести документы с 2х компов одновременно, второй сразу сказал типа не удается произвести  транзакцию, продолжить да-нет? А после установки патча ждет указанное в ini кол-во секунд.... Что-то немного разошлось с описанным здесь...

(382) Спасибо, сейчас зазырю

Еще одна поправка:

[Options]
Delay=1024

(было 1000).

ОК

Во первых большое человеческое спасибо автору!!!
И два вопросика:
1. Для 8-ки работает и для файлового и клиент-серверного вариант, или?
2. Может кто знает не решена ли эта проблема в 13 и 14 релизах. В описании изменений платформы про это не слова, но есть фраза типа "... исправлены ошибки предыдущих релизов", за которыми может скрываться все что угодно

Установил всё как надо. При расчете записей журнала расчетов вылетает ошибка:

жр.Рассчитать();
{Документ.СуммыКРасчету.Форма.Модуль(868)}: SQL State: 40001 Native: 1205 Message: [Microsoft][ODBC SQL Server Driver][SQL Server]Transaction (Process ID 54) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

1С Зарплата и Кадры 25 версии, сервер двухпроцессорный. Почитал в инете, вроде говорят в 1С на двухпроцессорном сервере такие ошибки бывают. Но у меня без компоненты их не возникало никогда. Сейчас убрал её(компоненту) - всё работает. Но медлено, когда народу много :-( Может можно бороца как-нибудь с этим??

(387) Мне сообщают, что для клиент-серверного варианта (где трехзвенка и SQL) проблема со 100% загрузкой при ожидании блокировки не существует ни на клиенте, ни на сервере.

(392) а зачем? есть же статья в КЗ
Книга знаний: Ускорение 1С:Предприятие 7.7;

Мда? Ну может быть

(396) Проделайте тест (390). Мне сообщают, что проблема не существует в клиент-серверном варианте.

400

(401) Я даже не смотрел 8-ку SQL, т.к. нету у меня ее.
И мне сообщают, что с ожиданием блокировки там и без моего патча все хорошо работает. :-)

Странно, что 7.7 DBF, 7.7 SQL и 8.0 1CD содержат одну и ту же ошибку, которая сильно мешает терминальным пользователям (и не только) работать в многопользовательской среде.

(391) По поводу "Transaction (Process ID 54) was deadlocked..." я у себя могу проверить. Мой емаил [email protected]

2 romix. слушай столько постов и исправлений... может лучше версию dll ставить? а то разбираться напряжно :(

(405) Я вот думаю... А это сообщение же предполагает, что надо ПОВТОРИТЬ транзакцию еще раз? Если я это сделаю - не уберет ли это еще один "баг" 1С-ки?
Глядишь, и на двухпроцессорных системах в SQL она начнет нормально работать...

to romix
Обнаружен глюк, проявившийся после применения патча для dbf 7.7 версии. Глюк состоит в том, что пользователь, нажимая enter в подборе, получает РЕДАКТИРОВАНИЕ справочника номенклатуры в СПИСКЕ, при том что

1. нормальным поведением по enter является добавление строки с номенклатурой в ТЗ (как в стандартной ТиС)
2. у пользователя напрочь отсутствуют права на редактирование справочника номенклатуры
3. редактирование справочника стоит В ДИАЛОГЕ

Других глюков пока не замечено и в принцепе весчь работает, однако юзеры, не глядя на экран, уже "отредактировали" несколько наименований и весчь пришлось отключить :(((

(411) Вообще-то версия для DBF перехватывает окно MessageBox с текстом
"Ошибка обращения к данным при транзакции, выполняемой другим пользователем"
и принудительно нажимает там ОК.
Так что справочник тут как бы вообще получается ни при чем.
У вас точно правильная DLL вызывается у всех пользователей?

(407) Вроде как это глюк не 1С. Попробую SQL Server 2000 Service Pack 3a найти поставить. Может поможет. Непонятно только почему с твоей компонентой этот глюк вылазит, а без неё нет.

+414 Если интересно, вот что нашел по этой теме: http://support.lime-systems.com/sqldba/Deadlocks/ и http://www.1csql.ru/materials/faq/admin.html#96

(414) Я сделал обновление под твою ошибку, теперь она вылезать не должна. Сейчас зашлю (надо проверить, работает ли).

+(422) все пропатчил как написано...

(423) Есть еще другой вариант патча - при помощи внешней компоненты. Он находится там же в архиве old.rar. Если хочешь, стукнись в аську.

(424) ок. Попробую ВК. А там видно будет...
Спасибо.

(426) Если что стучись в аську, мне не на чем файл-сервер DBF проверять.
Если все работает, сообщи, я тот вариант тогда уберу.

ок

(426) Есть способ программно выставить время ожидания.
http://1c.realnet.ru/forum/f.php?ak=27786#78

(425) Не надо переводить на файл-сервер!
Скажи пожалуйста, наблюдается ли на клиент-сервере проблема со 100% загрузкой процессора при проведении тестового документа?

(+430) Речь о 8-ке

(432) Тогда патч не нужен. Он решает именно проблему 100% загрузки проца в этой ситуации.

(435) да сейчас (после плотной работы с профайлером) вроде не шибко медленно. Настройка своя с нуля. Оперативный + бух. учет. Грешим на бух. учет. Т.к. основной процент времени на запросы по нему. А время среднее такое: документ 15-50 строк -> 3 - 5 сек., 1000 строк -> 30 сек. Когда работает до 20 - 25 пользователей все ок. А при 30 - 40 пользователях блокировки сыпятся, и проводятся существенно медленее. 95 % документов по 15 -50 строк, когда работают только с ними даже 30 пользователей, жить можно :) Но как только кто-то зацепил большой док., тут и траблы :(

(436) А попробуйте пожалуйста следующее: создайте тестовый док, который проводит товар, например, в регистр Остатки, а также делает проводки по бухии. И останавливается на Предупреждении. Есть подозрение, что тут и вылезет косяк со 100% загрузкой, на клиенте или на сервере.

(438) Ну да, в конец наверное...

(437) Ни, и в этих условиях работает нормально, т.е. загрузка проца не прыгает не на клиенте, не на сервере. (2 сеанса, в одном завис проводясь док с предупреждением, во втором того же типа документ проводим. Блокировка наступает, но загрузка процессоров примерно на том же уровне, что и до проведения).

(417)Поставил odbc33.dll от 03.05.2006. Вроде народ работает, никаких ошибок теперь не вылетает :-) Спасибо.

(441) Понятно, спасибо, похоже 8-ка клиент-сервер уже изначально ускорена как надо. :-)
(442) Здорово :-) Теперь можно спокойно 2 проц врубать, и этой ошибки не будет.

SQL, W2K3SP1, odbc33.dll от 03.05.06, тестовая конфиурация. Запущено 2 экземляра, в одном иммитируется проведение документа. При попытке во втором экземпляре создать новый/провести существующий документ, этот экземпляр через некоторое время вываливается (время колеблется от нескольких секунд при заданном времени ожидания захвата таблиц = 0 до 16 минут при значении 999).

(444) Проверил (Windows 2000, SP4). Если речь идет об ошибке:

---------------------------
1С:Предприятие
---------------------------
При выполнении транзакции произошла ошибка!
SQL State: HYT00
Native: 0
Message: [Microsoft][ODBC SQL Server Driver]Timeout expired

Повторить попытку выполнить транзакцию?
---------------------------
Да   Нет  
---------------------------

То она у меня тоже "вываливается". Так и должно быть (т.е. внешних отличий от того что было нет - просто проц перестает загружаться за счет вставленных пауз).

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

Нет, она по-настоящему сворачивается в коврик без каких либо сообщений
или предупреждений, была 1С - и нету. Вышеуказанное сообщение
появляется без использования патча.

(446) Подтверждаю это падение в новой версии компоненты на XP SP2.
Щас попробую решить.

Действительно был косяк (ошибка). Причем, глупая (недоставало stdcall в объявлении функции). Проявлялось в падении 1С без каких-либо сообщений при любой ошибке. Исправил.
Новая версия odbc33.dll от 04.05.06, 10:40, 142336 байт.

я чета не понял... а что теперь реклама и в постах?

Предлагаю вообще забить на транзакции - и проблема отпадёт!

(449) Где реклама в постах?
(450) Пользователям удобнее когда у них 1С не зависает на пол-часа, а позволяет и проводить документы (причем, сразу в неск. потоков), и работать пользователям.

(451) "веб симинар 6 Июня 2006" картинка весит на 0 посте

(448) Ром, мы работаем на патче для Скула 7.7 на Вин03 уже недели наверное полторы. Проблем нет. Ошибка с stdcall - это было только в "предпоследней" ДЛЛ?

(451) я шутю. Ветка длиннющая! Твоя компонента разве не решила сабж?

(453) Да. Она пыталась решить ошибку при deadlock - если у вас эта проблема возникает, то ставьте новую, если нет, то не надо.

(454) Решила - я просто добавляю еще одно исправление (насчет deadlock).

(456 ) успехов

(0) а 8-рочный вариант работает исключительна под 12 версией платформы?

Здравствуйте.
XEON 2.4/2Gb/SCSI RAID
1С 7.7 DBF|Терминал W3k|1.3Gb|25 пользователей
Периодически возникает сообщенеи с заголовком romix, file acces denied, жмем раз 6, и продолжаем работу, версия библиотеки последняя, вссе делал по инструкции, спасибо. Кстати

Достаточно неприятный момент, пользователи 1С, стали висеть на печати, после выбивания пользователя, в терминале 1Ска перестала запускаться вообще... :(

Я сейчас обновлю ВК для 7.7 DBF по образцу 8.0 и SQL, должно получиться более аккуратно.

Алгоритм будет следующий: при неудачной попытке заблокировать файл (LockFile) будет делаться пауза (sleep) 1 мс. При следующей неудачной попытке LockFile - 2 мс, затем 4,8,16,32,..,1024 мс.

да пересоздай ты ветку уже

(+461) vk_sleep_1c.dll 04.05.2006 17:25
Подключается по технологии ВК, пример приведен в тестовой конфигурации в архиве.
Лучше будет выставить Сервис - Параметры - Время ожидания захвата таблиц значение, отличное от 0. Например, 15 секунд. Это можно сделать программно

(462) Да я хочу рекорд по длине ветки поставить. :-) Страницу можно смотреть по частям, нажимая на цифры
Все сообщения  1  2  3  4  5  6  7  8  9  10

(+463) Старый патч тока надо будет снести (восстановлением из бэкапа папки BIN).

(464) Если каждый, кто твое решение применил, пару раз ветку подымет - то и быть ей самой длинной!

(468) Для SQL патч (так проще, т.к. там динамически подгружается ODBC32.dll).
А для базы DBF я сейчас сделал ВК (были варианты, решил на ВК остановиться).
Хотя при пожелании - могу сделать как вариант и патчем тоже.

Обновил ВК для SQL - теперь при ожидании блокировки внизу окна высвечивается надпись (т.е. нет внешних отличий от того, как работало без патча, просто убирается загрузка процессора).

Версия: odbc33.dll 05.05.2006 13:36 142336 байт.

(469) Что имеется ввиду для SQL - имеется ввиду sql движок платформы?
и про 8-ку поподробнее плиз, что там имеется ввиду под SQL

Для ДБФ качать по ссылке?

(473) Да, по ссылке в (0).

(472) У меня несколько вариантов патчей: для 7.7DBF, для 7.7 SQL и для 8.0 файл-сервер.

Я кстати объединил патчи для 7.7 DBF и 8.0 файл-сервер в одну ВК, т.к. они оказались очень похожи (различаются 1 строкой кода).

(475) я совершенно запутался - все таки патчи или ВК
я так понимаю что патчем патчим файлы и все  - больше делать ничего не нужно?
а ВК нужно прикручивать к конфигурации - я прав?
и еще вопрос какие файлы патчатся?

Мдя... ап-петит приходит во время еды :)))
Можно ли извне управлять списком таблиц для который будет срабатывать Sleep в odbc33? Как минимум таблица констант еще необходима.

(479) Обновил.
odbc33.dll 142336 байт 06.05.2006, 13:34
vk_sleep_1C.dll 95774 байт, 04.05.2006, 17:25

(480) Убрал в версии для SQL 7.7 зависимость от таблицы: теперь одинаково работает со всеми таблицами (а чтобы не было лишних задержек, использует нарастающий sleep).

(485) А если я реализую это в 1С, коньяк дашь ?

(486) Да, можно и в 1С это сделать, но потребуется в конфе везде вставить сигнальные файлы (или константы) и их отслеживание. Т.е. перекроить конфу. И это кстати не очень надежно (если клиент выставит признак и подвиснет, то подвиснут все). Опять же, нет хорошего способа сделать sleep, хотя можно наверное попытаться...

Установил патч на SQL 7.7, версия от 6 мая 2006 г., 13:34:18. БОЛЬШОЙ РЕШПЕКТ автору - загрузка процессора сразу упала... Но, к сожалению, осталась старая проблема дедлоков, причем, явно не зависящая от конфигурации и периодически "убивающая" базу. Если дедлок происходит у пользователя, который пытается сдвинуть ТА (проведение нового документа) в тот момент, когда в базе идет автообмен (в разделенном режиме :)), то:
1.Документ сообщает, что не проведен и пишет ошибку-дедлок;
2.В SQL базе снимаются блокировки с таблиц, которые были установлены для проведения (1SJornal, 1SSystems и т.д.);
3.Самое печальное: У пользователя остается блокировка на файле "1SSYSTEMS.$lk" в каталоге базы... Соответственно, двигать ТА теперь может только он, со всеми вытекающими... :( База стоит, пока пользователя из неё не выкинешь :(.
Как програмно разблокировать файл после этой ошибки? Или это тоже косяк платформы? И как его исправить? Please Help...

(488) Вообще-то не должно быть в новой версии никаких дедлоков.
Если ошибка 40001
//SQL State: 40001 Native: 1205 Message: [Microsoft][ODBC SQL Server Driver][SQL Server]
         //Transaction (Process ID 54) was deadlocked on lock resources with another process and has been chosen as the deadlock victim.
         //Rerun the transaction.

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

(488) Есть подозрение, что автообмен УРБД у вас делался непропатченным клиентом (папка BIN там тоже должна быть пропатчена).

Да, имеет место именно такая ошибка (40001). К сожалению, я не появлюсь на работе до 10 мая - праздники... Как только появится возможность, проверю предположение (490), о результатах отпишусь... Удачных выходных!