v7: ТИС ДБФ Непонятный сбой 1С 7.7. под win2008 R2 в терминальном режиме #670403

ТИС ДБФ Непонятный сбой 1С 7.7. под win2008 R2 в терминальном режиме. Второй раз за два месяца происходит сбой работы базы причем такой какого при работе на Win 2003 не было. Возникает ошибка блокировки при транзакциях и потом никто работать не может, у юзера у которого возникла эта ошибка (при проведении неподтвержденной заявки)слетел номер документа, а дальше все вроде работало, но только у него одного. При этом в журнале регистрации видно, что чеки ккм "сели" на заявки, накладные, с/ф, короче на все что делал этот юзер. Длилось это 12 минут, пока он не закрыл свой сеанс 1С. Месяц или полтора назад было примерно тоже, но только работать смогла одна касса (чеки ккм) и все эти чеки пришлось перебивать потом. Что скажете???

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

cисислог какой?

размер?

сюстем сдвинуть

Это как - сдвинуть???

Код смотри. И транзакцию, я понял, что там цепочка доков создается, к-рые друг к другу цепляются. Нетиповая явно?

на всякий случай если к базе стучаться по сети через шару - убрать нафиг антивирь на это

Да обычная заявка проводилась. Все более-менее типовое.

Спасибо. Помню про это, надо будет посмотреть

Оттестировал базу. Удалились вот эти левые недоделанные документы, которые налезли на чеки. И все. Тишь да гладь. Если все по цепочке блокировалось бы, то как этот юзер мог лепить документы??? И почему при этом больше никто ничего не мог делать. А после того как он вышел из 1С - все сразу заработали

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

Размер самого большого файла базы какой уже?

Да 1,092 ГБ. Но только одного (регистр движения партий), все остальные намного меньше размером

кернел 33 использую. Вроде проблем не было

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

У тебя партии не закрываются чтоли? Чего это он один так сильно вырос?

А кто заставил вас на Ось 2008 пересесть? :) Чем не понравилась Вынь 2003? :)

Дак у вас еще и DBF? И к тому же файлик уже распух :)

Да закрываются. Но я еще раз на него посмотрю внимательно. В журнале регистрации так: Объект: ЧекККМ Представление объекта: Заявка покупателя

Поэтому я и говорю что "налез" один тип документа на другой Да просто умер сервер отпахавщий 9 лет и тот сервер который планировался как SQL-сервер под 8-ку пришлось срочно переделывать под терминальный под осью 2008 R2 (тем более что мы это дело покупали)

Тогда что ты так тревожишься? Да проблемы были и будут, смирись, отпуска тебе не видать :)

Файлик бывал и больше. Я ежегодно свертываю базу, так чтобы было 3 года.

+ У вас есть УРБД?

Да отпуск хрен с ним. На старом серваке были ошибки блокировки но часто и таких вот вещей тем не менее никогда не было. Потом я их все-таки победил и через 2 недели помер сервер 2003. Знать судьба такая!!!

есть УРБД, как же без него

+ Ты пытался воспользоваться ссылкой ? Перед тем как спрашивать, а то большая часть ответов до такой степени однообразна, то быстрее по поиску получить ответ :)

Если бы это было часто, а пока что заметил 2 раза. Больше точно такого не было

Ну, вот тут как раз зло и спрятано. У нас такое же было и при Выни 2003 :) Как лечить, ХЗ, но обычно БД блокируется при обмене, при этом Блокируются Все, кроме одного, кто заблокировал. Пока блокировщик не покинет БД, все будут висеть :)

+ У нас так же БД была на SQL :)

Да смотрел я много чего на эту тему. И много чего поправил исходя из того что там советовали. И сам на мисте участвовал в ветках на эти темы

+ Я к тому, что проблема известна, но что с не делать ХЗ :)

Не было обмена, я их все мониторю. И все вообще длилось примерно 12 минут

Т.е. ты так уверенно пишешь, что это не твой случай? :) Но симптомы все на лицо. Ты замерь, когда делались обмены, нам график невидно. Когда делаются бекапы и делаются ли вообще, всего сервера. (админы любят хреней страдать) И кто вообще в этот момент не висит, если офис небольшой :) ...просто любопытно...

+ Рекомендую отрубить обновления ОС-и :) Это решит некие проблемы...

+ Антивирусник, еще посмотри, как настроен, не любит 1С тормоза :)

Вру, обмен был в как раз примерно в 12:00 и вакханалия и началась примерно в это же время, и ошибки блокировки 1CUPDTS были

На обеде я был. Когда пришел, уже тот юзер вышел из 1С и все заработали нормально

Таки значит "мой" случай...

поэтому я и не видел ни загрузки процессора, ни всего остального

А его нет, пользователь блокировавший БД, работает в этот момент в штатном режиме, почти монопольно :)

Видимо да. При этом в это же время уменя еще обмен с 8-кой (Розницей 2.0) происходил. Вот все в кучу и собралось. И как сделать чтобы такого не было??? Хотя обмен с 8-кой не прошел бы, так как при обмене УРБД взводится сигнальный файлик и обмен с 8-кой не начнется. Тем не менее начался и дал такие сбои тоже В журнале регистрации так: Объект: ЧекККМ Представление объекта: Заявка покупателя

Хотя насчет Ос-и могу ошибаться, может как раз тоже сидели на выни 2008, но у нас все работали локально по сети, так что трудно констатировать.

Все обмены происходят под моим пользователем.

не важно, счастливчиком может стать любой.. :)

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

(+44)И на 2003 винде вот таких последствий не было

(+44) И потом если обмен все таблицы блокирует, то как мог работать один юзер, причем без толку??? Ему все пришлось переделывать потом. Обмен шел не под ним.

а реально у дока (по иддоку) какой тип?

обмен не блокирует все таблицы.

Должна ьыла быть "ЗаявкаПокупателя"

В журнале регистрации так: Объект: ЧекККМ Представление объекта: Заявка покупателя Пробуешь щелкнуть на представление, сразу куча ошибок вылетает, ну правильно - ведт это же на самом деле ЧекККМ был

вот здесь смотрел? про таймаут блокировки у "работающих" юзеров проверь? у меня такие же грабли были года 3 назад - так и не разобрался в причине. Больше не воспроизводилось.

Вот это точно не в бровь а в глаз. Но почему-то на старом серваке аткого безобразия никогда не было

в общем ,если докопаешься до истины - надо будет "в копилку" сложить)))). У меня кстати ступор этот начинался тоже, возможно, в момент обмена УРБД. На СКЛь ни в каких видах подобного не встречал ни разу, ни при каких "висяках"

У меня 10 сек период ожидания захвата таблиц у всех кроме сканеров которые работать оп сети а не терминально. Работает кернел 37 (от ходжика). Попробую вернуться на ТерминалСлип от Ромикса. На Периферийках на которых терминальные серверы стоят под 2003 виндой - ни разу такого не было

в моем случае живой док оставался "налезший", т.е. ПКО, созданный в момент ступора, "счастливым" юзером, затирался РасходнымиНакладными и Перемещениями

Ну все равно - практически один к одному. Напишу я инструкцию всем юзерам, опишу ситуацию и порекомендую тут же закрыть программу 1С. Если других каких-то нештатных ситуаций не будет, а будет только такая, то постараюсь найти ее причины, поскольку буду знать что искать надо причины только этой проблемы!!!

Это моя темка. Победить так и не удалось. УРБД про которое тут пишут, у меня отсутствует. Правда база у меня крутится под Вайном. Систему пробовал менять, и версии Вайна разные. Проблема не ушла. Пока прикрутил костыль. Сидит бот, и периодически пытается создавать документы. Если подряд несколько раз не получилось, создает сигнальный файл. ОС увидев этот файл, прибивает все терминальные сессии ))) Несколько раз выручал )

Вайн, это линух шоли? :)

"ОС увидев этот файл, прибивает все терминальные сессии )))" - шикарный костыль))) но все же лучше чем перенабивка на след. день всех доков у одного юзера... "порекомендую тут же закрыть программу..." трабла в том ,что "счастливчик", особенно если он изолированно от остальных сидит (как в моем случае) ничего про ситуацию не будет знать)))

как вариант - перелезть на СКль "Там это реализовано")))

Ну не совсем, "прослойка" от Етерсофт, для работы 1С-ки под Линуксом

Вот как раз он увидел то что опписано в ссылке То есть него при проведении  заявки слетел номер документа!!! + Пытки пользователя показали: Что-то "моргнуло", у документа исчез номер, и она не смогла его провести. Повторить подобное не удается.

ну, у меня тоже раз-два в месяц при попытки записи/проведения  "объект заблокирован", причем пишет, что заблокировал тот же юзверь, кто в нем сидит и пытается провести... За 7 лет так поблему и не решил. На мой взгляд что-то с сетью или сетевыми соединениями сервера.

на СКЛь? при этом стартанул обмен УРБД и док не был записан?

Ну у меня-то ДБФ

на сиквеле. Правда, в основном это когда более 70-75 юзверей в базе. А вот взаимосвязей с обменом, с приемом заявок с КПК/EDI/почтовыми роботами, с клиент-банкаи, выгрузками в снеговика, формированнием оотчетов для поставщиклв и т.а. - не обнаружено. ветви сети тоже меняются.

А этот симптом уже проблема самой сети, лечится завершением сеанса 1С. При этом БД не блокируется :)

У нас было на SQL и люди работали локально.

Раз на 2003 винде такого не втречается, выходит что проблема связана с виндой 2008. Если новых нештатных ситуаций кроме этой в течении длительного периода возникать не будет то тогда буду копать эту проблему точно зная что других нештатных ситуаций нет

Походу, да... нечего извращаться и стоит просто работать на обычном 2003-тем :)

ssamm В планировщике винды нет же проверки на наличие файла. То есть есть задача которая через каждую минуту отрабатывает на предмет проверки такого сигнального файла???

Что касается самого файлика - у Ромикса в ТерминалСлип есть возвможность создания такого файлика. И если он объявился несколько раз подряд в течении скажем 3 циклов обработки ожидания, то тогда прибивать сеансы. И кстати, чем можно прибить все терминальные сеансыЮ какой командой ОС???

У меня есть Константа.Блокировка. Если она = 1 то все юзеры из 1С автоматически вылетают довольно корректно, кроме админа

Я писал что у меня не винда... а константа здесь не поможет (при открытых монопольных окнах, она не выкинет пользователя)

Вот сейчас опять та же ситуация. У кого была незавершенная транзакция даже не стал разбираться. Просто сервер перезагрузил и потом базу переиндексировал, но на одном из сеансов (сканер и заходит не в терминале а по сети) была ошибка Error 50 1SBCONST.DBF

locking 1SBCONST.DBF. Понятно что это база где и константы и все периодические реквизиты спраовчников сидят

Знать бы железо, сеть или сама 1С???

В семёрке было много сюрпризов, но в итоге пришлось делать конструкцию с попытками для выполнения транзакций: Штатно, при ошибке внутри код (что-то делаем) транзакция отменяется сама, но были ситуации, когда она почему-то была активной (то есть ФлагЧтоТоНеТак оказывался равным 1).

бяка. открывать транзакцию внутри попытки - есть бяка. НачатьТранзакцию; КонецПопфтки

Ну да. Это я знаю. Только куда вставлять этот код??? Пока что мониторю ситуацию. {Глобальный модуль(ДокБухт.Записать; {Глобальный модуль(15338)}: Таблица: 1SJOURN Ошибка обращения к данным при транзакции, выполняемой другим пользователем   И так раз 20 подряд. А собственно проводилось очень большое перемещение тмц

не трахай нам мозг ;-) . ШТАТНЫЕ Перемещения в ТОЧКЕ АКТУАЛЬНОСТИ проводятся практически мгновенно. Ставлю на то, что проведение делал задним числом..? . А что у тебя в перемещении делается с бухтами? - вот там и собака порылась..?

Штатные перемещения проводятся мухой. Это точно. Но перемещению соответствовал большой документ бухт. Но он тоже проводится мгновенно. Документ перемещение проводился гарантированно задним числом.

> Документ перемещение проводился гарантированно задним числом. - бросай заниматься этой хренью. перемещения делай в ТА. какова скорость проведения перемещения задним числом и что там у тебя при этом делается в документе бухт - хз. А если ты в проведении перемещения генеришь и проводишь еще дополнительно и документ бух - хз что там происходит