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

базу переписывать

ставить всем 0.

Вот это поставь, полегче будет.
http://x-romix.narod.ru/vk_TerminalSleep.rar
А вообще, курить где тупит и переписывать на прямые...

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

Если в запросе условие по подразделению он ведь блокирует толко эти записи или нет?

(5) Нет.

(5) запрос вообще ничего не блокирует.

(5)Запрос блокирует весь список данных, которые использует :)
Начни разбираться в структуре хранения данных в 7.7 и все поймешь :)

... так же запросы во время проведения, это зло :)

+7 блокировка, только ежели кто-то чего-то проводит, ибо проведение - это всегда транзакция.

(7)Может быть, но ты записать, то же нечего не смогешь :)
Только читать

(8) Гон.
1с-кий запрос построен на "грязном чтении" и он не блокирует ничего.

(10) да ну ?

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

При формировании отчетов

выборка блокирует как я понимаю?

(15) нет

(15) Твоя задача, чтобы проведение и запись шли быстрее

(11)Ну не гони, у нас как раз вот запросы от 1С и блокировали всю базу, при этом это просто отчет по регистру :)
При этом, пока не выкидывали сего пользователя, все курили :)

а как тогда? одна делает расчет другая формирует отчет и ошибка но записей пока нет если перебор не влияет то что?

(19) Вот как разсчёт и блокирует...

весь журнал расчетов?

(18) ты бред то не неси..

нет смысла ставить секунды да хоть 500? просто расчет мин 20 идет

(22) Руками в тот отчет транзакцию влепили, вот и блокировал походу.

тогда на 20 мин все записи заблокированы транзакцией? Отчет не может?

(25) Ну не так чтобы все, но общий журнал блокирует, а без него все висит...

в отчете нет ранзакций

как тчеты формировать тогда что не правильно

какой общий?

Еще раз - ошибка блокировки возникает только при записи/проведении объектов ИБ..
и всё.

Ну я понял это у расчетчика которая хочет сформировать отчет вылазит данная ошибка

(31) ты это понял или ты это видел ?

вот видел

(22)Сам был поражен, но запрос был по дебиторке и брал данные за год :(

(34) да хоть за 100..

(33) чего видел ? Ленина ?..

вобщем если один человек формирует отчет, а у другого проводится расчет то у которого отчет вылазит ошибка блокировки данных другим пользователем

(37) не верю.
Что за конфа ? Что за отчет ?

(30) Не говори оп, пока не перелетел через забор 1С-ных глюков :)
К примеру если делать запрос типо

Запрос=СоздатьОбъект("Запрос");
...тут сам запрос
...Апосле еще раз ту же переменную
Запрос=СоздатьОбъект("Запрос");

И так в подряд 20 раз, то на 3-ем цикле, сеи запросы вообще покажут что нет данных, но они есть :)
Пока не занулил (Запрос=0;) перед каждым запросом... отчет показывал бред

...Конечно это не относится к блокировкам, но сея 7.7 полна неожиданностей :)

(38)Я ему верю :) И еще как :)
(0)Совет, пиши прямые запросы :)

сказочники.

(29) 1sjourn вестимо. Как правило одинэсовские запросы его джойнят, а во время проведения он заблокирован полностью, вот и обломинго с отчетом.

ага на него ругается на 1sjourn правильно понял

и как быть?

(44) я ж тебе сразу сказал, базу надо переписывать

(44)Убрать запросы из модуля проведения :)
Оптимизировать сам метод проведения, постараться не писать в другие справочники, во время проведения...
Пользователям стараться вдалбливать, что не кашерно делать один документ с 20000 строк :) Лучше 20000 документов, но с одной строкой :)

Для всех сказочников, делаем простой тест:

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

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

Обработка расчет зарпалты, она там блокирует

когда считаем зарплату

Там используются транзакции

не документ

(48) п..ц.
Ты разницу между отчетом - это чтение данных и Обработкой расчет зарпалты - которая вносит изменения в саму ИБ не видишь???

как не вижу я понимаю

там транзакции используются

+(47) вот именно
все запросы в 1с ке выполняются грязночтением...как то так


если посмотреть профайлер то только и видно хинты
(nolock)

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

Если так? тогда зачемошибка если просто чтение

убрать транзакции?

доки ни кто  вэто время может не проводит

только расчет, и отчеты

(0) На каких именно строчках модулей ошибки возникают?

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

(48) бу га га

это далеко не отчет

(57) Не тупи - сам же сказал - что в обработке твоей транзакция +, на сколько я помню Зик - эта обработка делает запись в ИБ..

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

уберу транзакцию

и нафиг

не туплю а по твоему размышлению у человека который формирует отчеты не должно быть ошибки

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

(47)Сказочник... не дальновидный, сделай наоборот!!!
Запусти отчет по регистру, за год... сделай его так что бы он работал час, как мин, напиши не прямыми запросами :) (короче не оптимизируй его :))

Потом попробуй провести документ по тому же самому регистру :)
И удивляйся...
При этом в тесте усложним.... Запусти в параллельно... тот же самый запрос на 10-ти разных ПК!!! (или разных терминальных сессиях)
...
Поразись... реальной обстановкой... а не альфо тестером на одном ПК!!

(71) Не тупи.. у нас юзверов до 80 в базе - таких проблем нет и не было никогда.

(72)Ну я же пишу... не оптимизируй запросы, на прямые и период возьми по само использованному регистру за год, а не за 10 дней , как макс :)

+71 Если ты такой неверующий Фома- смотри профайлер в скуле, например, там везде хинт nolock в запросе..
Табличка никогда не блокируется, хоть за пятилетку строй запросы свои.

+(72)И повиснит твоя база... не забудь отрубить ВК :)

(75) Хорош чушь пороть, не позорился бы..

(74)Но и записать ты при этом не смогешь, 1С требует при записи в табличку (7.7) монопольного доступа, т.е. лочит всю таблицу :)

(76)Вот я то же бы утверждал, что код в (39) не реален... но он так себя и ведет :)

(77) С какой радости то???
Еще раз - ЗАПРОС в 1с не лочит НИЧЕГО.

(79)Тоже сам все еще поражаюсь :(
Сам многому удивляюсь в 7.7, за все годы работы :)

FEAS, http://softpoint.ru/feedback_id40.htm
У софтпоинта спроси, может помогут.

(79)Я тоже поразился, что он при 1С-ных запросах ложет туже самую таблицу, но во временные файлы :)

Ты там не отмазывайся...сказочник.

(83)Если бы... я тебе пишу, что и палка стреляет ;)
И твои утверждения, что нечему лочиться там тоже ошибочные :) Не ты же писать платформу 7.7 :)

(84) оставайся дальше в своих грёзах.. только вот тут не надо этого писать..

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

При транзакции запрос не может счиать или нет  Ёпрст3?

(87)Видишь ли (85) все время твердить, что нет этого у тебя, т.е. реально ты пишешь фигню и нечего не "лочится" :)
А я вообще сказочник, мне это привиделось :)
...Ты начни думать своей головой, у нас другие ошибки и баги в 7.7... Ты многие найдешь и в 8-ке :) И так же повстречаешь новые, для тебя, 7.7 :)

Более 99-и процентов в 1С 7.7. идут с хинтом nolock - что означает грязное чтение. бывают исключения(очень специфические) но очень редко. В случае (0) думаю все идет действительно с грязным чтением. Поэтому основа для понимания - проведение несложного эксперимента. Документы действительно блокируют друг друга а вот отчеты практически на 100 процентов нет.  

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

То 88. Я редко верю тому что говорят пользователи. Поставь систему мониторинга либо проведи эксперимент и убедись в обратном.   Я уверен что если у FEAS спросить а проводил ли он лично одновременно документ(запрос в цикле на х итераций в отчете и предупреждение в конце проведения документа) и отчет и видел ли блокировку? -  скажет скорее всего нет. А ведь это несложно сделать.

Единственное но - не нужно путать отчеты и обработки. Обработка выполняя в транзакции определенные действия на изменения действительно может вступать в блокировку.

(89)Я практик... мне твое написано... мало что говорит.... как правил у нас Аналитик, так красиво расписал программу, щас смотрю на ее реализацию, в 7.7.
Думаю, он много с экономил на программистах, код писали школьники, ужо не говоря про студентов с бух. факов

когда отчеты формируются ошибка вылазит за чем что то проверять, сам вижу, в это время работает обработка на запись в ИБ. Документы мне пока не нужны

+(89)Не поленись... проведи експеремент на 10 различных ПК и на данных годовой давности и тогда и пиши, то что написал программер, что бы от него отвалили :)

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

То FEAS. Ну тогда приведи точно название ошибки, название отчета и название обработки. Бывает исключение из правил (менее 1 процента) но я очень сомневаюсь что это тот случай.

У нас переписанная конфига ЗП не даст название , отчет например Расчетная ведомость обработка расчет зарплаты.
вот такая хрень вылазит
Если ЖрнЗарплата.ВыполнитьРасчет()=0 Тогда
{Обработка.РасчетЗарплаты.Форма.Модуль(232)}: Таблица: 1SJOURN Ошибка обращения к данным при транзакции, выполняемой другим пользователем

(97)Где то была библиотечка, которая в дбф-е снимала нагрузку на базу при транзакции :)
Но не помню как называлось, вроде ромикса :)
Тебе она нуна

(89) Это смотря как написать отчет.

100

То 99. Ну можно в отчете открыть транзакцию и в ней перепроводить документы:)
То 97. не используются никакие сторонние компоненты?

(96) При обращениях к 1SCONST это не такая уж редкая ситуация.

(102)Только щас понял, что речь про ЗиК :))))
Да только Формек + 1С++, так же это УПП, а вернее я бы сказал, даже ТиС :)
При этом формекс без пред настроек, также 1С++ все берет по дефолту, ни каких настроек ;)

+(104)(102)База SQL

даже когда одни отчеты печатают в которых нет транзакции всеравно выходит данная ошибка

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

(107) Старый добрый способ ускорения клюшек :))))
Из отчетов убрать всякую каку типа РассчитатьИтоги и ПолучитьРезультатРасчета или что нить в этом духе, что вешает блокировки на таблицы движений и итогов.