chicago писал(а) 07. Октября 2009 :: 16:59:

С ней с УРБД всегда сложности.

Может есть за что зацепиться когда стартует подгрузка УРБД  ?
В этом весь и вопрос.

Сложности с УРБД есть большая вероятность отката всех изменений например документ блокирован кем то.

Далее когда подгружается УРБД то не выполняются модуль проведения ( и модуль отмены проведения документа ).

Если делать чистый 27 то как узнать что самый ранний документ не откатился за период нач константы изменения документов.

Если делать 27+28 то как помещать документы в очередь ?
(ведь модуль проведения не исполняется)

Как возможное из решений перед подгрузкой В sql процеcе подгрузки но уже в транзакции надо выполнить :
1.захватить монопол блокировку на таблицы журнал документов
2.создать (включить) тригер на изменение таблицы журнала документов
3.при срабатывании тригера учитывать 27 и 28

После окончания подгрузки тригер удалить ( или выключить )

Либо вместо всего этого узнавать произошла подгрузка успешно
и самим  анализировать zip файла что же мы подгрузили но
вдруг это не сработает а если 27+28 за время анализа еще попадут другие документы и порядок
очереди будет не такой - что тоже плохо.

(Захар Малиновский) Это ты о каком режиме блокировок говоришь ?
О стандартном или о чем то еще ?

Цитата:




Если свои блокировки и READPAST
что будет
пусть сейчас есть макс  id = 10
начали первое проведение из comp1
выставили READPAST
получили следущ id = 11

начали второе  проведение из comp2
выставили READPAST
получили следущ id = 11 ( тот же самый !!!)
Закончилось проведение на первом comp1
Закончилось проведение на втором comp2 -
что при этом произойдет точно не знаю либо откатимся по ошибке либо что-то еще ?

Если я ошибаюсь то поправьте меня.


PS
С помощью двух Предупреждение в модулях проведения
легко смоделировать ситуацию

chicago писал(а) 07. Декабря 2009 :: 08:25:


Так сделать, это себе вовред.  Я ж говорю - ИТОГИ начнут расходиться с суммой проводок. Несколько (два для простоты) подключений пользователей выполняющих код процедуры _1sp__1SENTRY_MaxRowID   _одновременно_  получат ,в твоём случае, rowid последнего , а НЕ СВОЕГО инсерта проводок.
Это если у тебя не более одного документа  одновременно проводится в системе тогда ты прав. Но ты в теме про отключенные стандартные блокировки 1с.

Дайте пример как можно сделать "себе вовред".
Запись проводок и пересчет итогов идет последовательно:
а).

exec sp_executesql N'Insert into _1SENTRY values( @P1,@P2,... 

б).

declare @P1 int
set @P1=0
exec _1sp__1SENTRY_MaxRowID @P1 output
select @P1 

в).

exec _1sp__1SENTRY_NewEntry... 

Какая вероятность того, что перед пунктом б). сесии №1 "вклинится" пункт а). сесии №2?

Покажите мне как можно сделать так что бы в SQL значение @@IDENTITY получить "НЕ СВОЕГО инсерта" если значения Duration пункта а). в 99% равно 0?

Спасибо.
[/quote]

Всё дело просто в том что между  а) и пунктом б)  есть  какой-то алгоритм. Т.е. какойто call , ret и еще много чего что может удлиннять промежуток времени между ИНСЕРТОМ и вызовом _1sp__1SENTRY_MaxRowID. А плюс много-задачность на терминальном сервере, приостановка процессов планировщиком.   Вопрос "А какая вероятность что ..." - ну не знаю. _Большая_ вероятность. Ибо такое у меня было.  
Два инсерта в одну и туже таблицу из двух сессий могут быть. и они могут выполниться подряд на скл сервере.

Z1 писал(а) 04. Декабря 2009 :: 16:46:


Z1, парня с надписью "God member" как то боязно расстраивать  , но твой пример я не понял.
Тут надо понять особенность отправки на сервер инсерта в 1entry и  последующего exec __1sp__1sentry_MaxRowID.
Они отправляються на сервер так что между ними сервер скл может вставить операторы других сессий.
Поєтому предлагаеться __1sp__1sentry_MaxRowID приказывать не брать во внимание (т.е. READPAST) сделанные инсерты другими сессиями (пока эти ДРУГИЕ сессии не скажут COMMIT). А ихний COMMIT будет позже нашего select max(rowid) from _1sentry (READPAST) _почти_ точно. А почти это потому что вдруг какой - то код , которого в 1с по стандарту нет, сделает инсерт и СРАЗУ commit. Вот тогда , может быть, нас не спасает READPAST. Но у меня такого нет.