Опишите как можно подробней Ваш sql сервер (железо и софт).

HP PRoliant DL 380G5

данные из ЕМ:
Product: SQL Server Standart Edition
Product Version: 8.00.2039 (SP4)
Platform: NT INTEL X86
OS Memory: 3326(MB)
Processors: 8

одинесные хранимки не трогал?

trad писал(а) 01. Октября 2009 :: 09:57:


хп менялись (снимались стандартные 1Сные блокировки). на базу вешались триггеры. много чего сделано )

gls писал(а) 01. Октября 2009 :: 10:07:

как это исправления на лету ?
а если менялась структура данных ?
Даже если и не менялась полфирмы работает по старым правилам (алгоритмам) полфирмы по новым ?

Обработка не исправляет базу а ищет есть ли ошибки.
Где то в конце 2008 выкладывал также обработку по проверке всех регистров в базе.
кажется тема называлась "Проверьте Ваши регистры"

gls писал(а) 01. Октября 2009 :: 10:07:


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

Вашу обработку по документам пока не запускали. делаем стандартное 1Сное тестирование и исправление базы.

Цитата:

delete from _1soper where iddoc = ''
delete from ra*  where iddoc = ''
можно сделать не в монопольном режиме

Цитата:

если наложили монопольные блокировки на бух таблицы - по регистрам доки прекрасно проводятся


Цитата:

имелось в виду - DBCC DBREINDEX (@tablename)

Z1 писал(а) 01. Октября 2009 :: 10:20:

ага, заинтересуют, особенно последствия 

leshik писал(а) 01. Октября 2009 :: 11:25:

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

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

верни блокировки на свое законное место

trad писал(а) 01. Октября 2009 :: 11:44:

имхо: дело не том - менялись блокировки или нет
на 40+ базах нестандартные блокировки работают, и только на одной(!) имеем проблему.

тестили и со стандартными блокировками - проблема не исчезла

Цитата:

Это может произойти если Вы сняли все блокировки на все таблицы  и не наложили своих.
В стандартной 1с это ловиться.Мой же тест рушит только один документ и то без записи.

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

Так что если хотите чтобы Вам помогли можете рассказать свою систему постулатов и их реализацию.

Цитата:
ИХМО - бред ( ничего личного ) у Вас база
сыпется, а Вы в ней продолжаете работать. Какой смысл в работы
с базой которая уже логически противоречива. Нет целостности данных. Верить ни данным ни отчетам уже Нельзя.
ТАкже Вы ничего не ответили о дате последней копии.
Если сами не можете остановить работу то хоты бы Заявите об этом очень громко или покажите ветку Вашему руководству(кто может принять решение).

gls писал(а) 01. Октября 2009 :: 11:59:

ну вот и проверьте в ней есть ошибки или нет ?

Z1 писал(а) 01. Октября 2009 :: 12:02:


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

alexdd писал(а) 01. Октября 2009 :: 12:05:

а может в этой базе другие тригеры или какие то из тригеров отключены.

(0) Какая у Вас реальная авторизация sql базы ? (win, sql)
Под какими пользователями работаете в sql.

Цитата:
Проверьте права этой учетной записи.

Получается что под этой учетной записью часть тригеров не отрабатывает.

Z1 писал(а) 01. Октября 2009 :: 12:13:


1. на сегодняшнее утро в проблемной базе использовались стандартные 1Сные блокировки
2. авторизация - sql
3. под sa
4. делали запрос админам - проблемная учетка  ничем не отличается от беспроблемных

Цитата:

триггеров на документах нет
похоже что не отрабатывается код 1С, соттветствующий записи данных в _1sjourn

Цитата:
Тогда бы ни в одном сохраненном документе не было бы номера. Так как документы Вы видите значит они записываются.

Если документ не может записаться то 1с откатывается по транзакции
с ошибкой. Ход этих событий могут изменить тригеры своей внутренней логикой.

Z1 писал(а) 01. Октября 2009 :: 12:36:

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

gls писал(а) 01. Октября 2009 :: 12:26:

gls писал(а) 01. Октября 2009 :: 12:26:

Похоже, что это взаимоисключающие утверждения.

(0) база распределенная ?
Может у твоего неправильного пользователя иная локализация языка?

Если ты зашел из терминала в 1с под sa то все сессии равнозначны.
Может у Вас какие либо расхождения для разных пользователях 1с?
и этот Ваш некто работает под другим пользователем 1с и там все работает не так как у всех.Этот пользователь например переопределяет авторизацию или что-то еще.

Z1 писал(а) 01. Октября 2009 :: 12:55:


сейчас подключиться под ним не получается
ранее -  профайлер по его @@spid не показывал какие-либо действия с _1sjourn:
до записи дока - инфа была
запись - инфы нет. никакой

upd: видимо был разрыв сети.
повторное натравливание профайлера на проблемный процесс никаких отличий от нормального процесса не показал

(0) Создайте по Вашему md еще одну базу  1с sql пустую стандартную.В ней вообще изначально нет тригеров.
И в этой базе создай документ под плохой учетной записью и под хорошей учетной записью при этом файл пользователей 1с возьми
из базы где "псевдоошибка"

Z1 писал(а) 01. Октября 2009 :: 13:28:

1. вход под этой учеткой под другим пользователем дает ту же ошибку
2. так и сделаю.

gls писал(а) 01. Октября 2009 :: 14:40:

Я не знаю что ты тут ожидал получить.
Но если целью была блокировка до конца транзакции (т.е. до commit tran), то не хватает holdlock.

ps
а вообще, по фотографии лечить не умею

trad писал(а) 01. Октября 2009 :: 16:49:

Да уж. У автора subj стандартная 1с работает 
ps
Да уж из меня тоже плохой доктор   

trad писал(а) 02. Октября 2009 :: 05:00:

я знаю. я же смайлик  поставил.
ну а автору ты уже ответил

trad писал(а) 01. Октября 2009 :: 11:44:

gls писал(а) 05. Октября 2009 :: 06:17:

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

С символом кавычка у меня тоже были проблемы. Банковскую выписку обрабатываю прямым запросом sql. Иногда в назначение платежа был '  - Около месяца ловил этот эпизодически возникающий трабл.