Надеюсь на отзывчивость тех, кто уже понял принципы построения SQL-таблиц базы данных

1С:Предприятие 8.2 (8.2.17.157)
Управление производственным предприятием, редакция 1.3 (1.3.38.4)

Необходимо получить структуру SQL-таблиц базы данных, для этого используем язык 1С: Пример приведен для справочника «Номенклатура»

МассивИменМетаданных = Новый Массив();
МассивИменМетаданных.Добавить(Метаданные.Справочники.Номенклатура);
СтруктБД=ПолучитьСтруктуруХраненияБазыДанных(МассивИменМетаданных);

Если запустить эту обработку в первой и второй базе ( обе одной конфигурации УПП 1.3 (1.3.38.4)),  то имеем для первой базы имя таблицы SQL = Reference131, для второй имя таблицы SQL = Reference162. Если смотреть структуру полей таблиц, то видим, что имена полей различны.

Вопрос:   подтвердите или опровергните вывод: таблицы SQL создаются динамически и могут иметь различные имена (имена полей в том числе). При создании новой базы загрузкой конфигурации из *.cf –файла, получим таблицы новой базы с именами, отличными от имен таблиц базы, из которой был выгружен файл конфигурации *.cf .

(0)На, держи.

Описание структуры данных.
http://zalil.ru/34448210

(43) прямыми (Ровные запросы, а не оптимизированные кривым оптимизатором 1С) сделаешь базу кривой. В резюме, потом напиши, что сделал суперские оптимизированные запросы

(47) абсолютно не при чем. "За державу обидно".
Меня устраивает "оптимизатор запросов 1С", хоть и не фан. Как, говорилось на этом форуме не раз, готовить запросы надо уметь.

Почему-то все адепты прямых запросов не учитывают вероятности получить несогласованные данные.

(50) Это с какого перепою?

(45) Спасибо!!! Смотрю...
ВСЕМ СПАСИБО

(47) Флейм в тематике

(51) ну как с какого? В обход объекта 1С что-то писать...

данные из 1С попадают в систему весовых терминалов....обрабатываются там....затем обратно в 1С....кто работает с весовым оборудованием??? средства 1С дают хорошие возможности??????

(51) Часть блокировок живет в памяти сервера. Сторонне приложение о них не в курсе.

(54) Я про чтение.

(56) про чтение да. 100+

(55) а какие не дают ?

(56) Например у тебя больше чем 1 кластер ( рабочих процессов) как ты их блокировать то будешь?
v8: Разделяемый или Исключительный режим блокировки

(55) в продолжение темы для "адептов":
Для чего надо делать так (0):
ускорить шибко тугой запрос на уровне СУБД, или, запудрить тех, кто будет это хозяйство разбирать
Для чего не надо делать так:
1. БД зависимо
2. лицензионное соглашение и согласованность данных
3. даются средства высокого уровня, зачем лезть в кору
4. потом, после реализатора "нетленки" долго нужно разбираться - из прямых запросов к БД, т.к. это уровень не бизнес-логики

(59) Блокировки хранит менеджер кластера.

(61) Как другой кластер (рабочий процесс) об этом узнает? Проще использовать блокировки БД

(60)
запудрить тупых рисовальщиков формочек и отчётов

0 что значит бд зависимо? 1с примерно одинаково гененрирут названия полей для разных субд (всего 3 варианта)  

2 с учетом оговорок смысла не имеет. тк практически любой объект бд- метаданных можно привести к состоянию требующему разрешённому и рекомендованному фирмой 1с вмешательству.

3. вот тут верно. тк 1с8 на риалтайм систему не тянет.
лучше через коннектор.
мне через саповский коннектор в 10 раз удобней было работать с САП
чем на прямую в скл сервер писать.

4. если делать через view с именами метаданных - то все равно.

(62) Рабочие процессы обращаются к менеджеру. А другой кластер это другая база.

(64)
с какого релиза?

(64) Рабочие процессы это реально разные процессы со всоей виртуальной памятью.
Другой кластер это другой компьютер а база у всех одна.
Так как ты будешь хранить эти блокировки? Неужто это будет эффективнее чем хранить блокировки в самой БД?
Меня интересует технический процесс.

(17) чтобы этого не случалось в SQL есть роль db_datareader

(65) (66) Народ, желтые книжки почитайте, я с них цитирую. Конечно я в исходниках платформы не копался, но оснований не верить нет.

Блокировок БД бывает недостаточно, поэтому вводятся блокировки прикладного уровня. Сам не раз реализовывал, в других системах. Некоторые СУБД предоставляют механизмы для того, чтобы и прикладные блокировки жили в БД. Грубо говоря API к своему менеджеру блокировок. Но в случае 1С кроссплатформенность и кросс-СУБД диктует свои правила. Поэтому прикладные блокировки живут в памяти сервера 1С. Очевидно они не могут быть свои у каждого рабочего процесса, поэтому в памяти менеджера кластера.
И не путайте "рабочий процесс" и "кластер".

(66) Хранить блокировки только в БД разумеется эффективнее. Но это не всегда возможно, см. выше.

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

поэтому и интересно, можете ли Вы точнее чем общий отсыл к  
ЖК или интернет подтвердить работу кластера с разными бд.

(70 >подтвердить работу кластера с разными бд.
Не понял

Главу постараюсь найти.

(38) Ты опоздал, вроде как веб сервисами пользоваться умеют уже все, а поднимать веб сервер дорогого стоит

(71) Нашел.
Клиент-серверный вариант. Руководство администратора. 2.1.3. Сервисы кластера
На ИТС тоже есть.

(73)
спасибо.

(73) Понимаешь блокировки так или иначе происходят на стороне БД смотри v8: Разделяемый или Исключительный режим блокировки сообщение 37.
Организовывать свою систему блокировок не имеет смысла.
Это имело бы смысл если бы сервер приложений был в единственном процессе, где доступ к объектам был бы в одном адресном пространстве. Когда существует не только множество процессов но и кластеры на различных компьютерах, то любое обращение должно приводить к маршалингу данных как между процессами на одном компьютере так и между другими компьютерами.
Просто мне интересно приведи пример блокировок на уровне менеджера кластера, что бы знать о подводных камнях.
http://v8.1c.ru/overview/Term_000000126.htm#1

Мало того в 8 ке применяется оптимистическая блокировка. Управляемые блокировки используют хинты SERIALIZABLE,REPEATABLEREAD

Здесь тоже писатели про оптимистическую и пессимистическую блокировку
http://langslab.com/ebooks/prof-dev2/tome1/pr-dev-t1-ch04

Оптимистическая блокировка осуществляется на уровне поля ._Version  v8: Кэши разные нужны, кэши нужные важны.

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

Правда, перечитал еще раз про упр. блокировки, и появилось сомнение в (50). Если они действительно держатся ТОЛЬКО до конца транзакции, то ЧИТАТЬ извне вроде можно. Но не уверен до конца.

(76)
http://www.ravepoint.narod.ru/aticles/tecnology/2methodics/2_3.htm

(76) Так и объектные блокировки имеют смысл без транзакции.
Управляемые блокировки только на уровне транзакции и на уровне БД. Не управляемы это уже уровень изоляции REPEATABLE READ. Но тогда и на уровне блокировок запросов нет смысла в объектных блокировках для клиент сервера. Для Локальных баз на уровне LockFile

(78) Давай прежде всего не путать объектные блокировки и управляемые. Первые с танзакциями не связаны, они чисто прикладные.

(76) Спасибо, но верстка там полных швах.

Вот про это я и говорю зачем мешать объектные блокировки и транзакционными блокировками бд. Объектные блокировки так или иначе не взаимодействуют с блокировками БД. Тогда какой в них смысл? Управляемые блокировки это блокировки БД в режиме изоляции Read Commited с помощью хинтов SERIALIZABLE,REPEATABLEREAD. Автоматические это уже на уровне Изоляции REPEATABLE READ.

(77) Более полезная статья: http://ravepoint.narod.ru/aticles/tecnology/4techinf/4_1common/4_1_2.htm
Но там верстка еще хуже. Читатьможно только в Опере в режиме Fit to width.

(81) Давай ты прочитаешь (82), с терминологией и общей концепцией все устаканится, потом продолжим.

Правда, там в тексте упоминается 8.1, кое-что могло и устареть.

(81) > Управляемые блокировки это блокировки БД в режиме изоляции Read Commited с помощью хинтов SERIALIZABLE,REPEATABLEREAD.

Это неправда, при наложении управляемой блокировки никакие блокировки в БД не накладываются.

(82)У меня на лисе нормально.

(84)
раньше
(до 14 релиза)  
накладывались   блокировки субд.

сейчас может исправили.

+(86) при управляемых блокировках

(84) Интересно, а почему Управляемые блокировки только в Транзакции. И уровень изоляции Read Commited?
Интересно а это что за блокировки http://www.sql.ru/forum/actualthread.aspx?tid=912872

(83) Ты мне так и не объяснил механизм объектных блокировок между рабочими процессами. Для этого нужен некий общий процесс к которому будут обращаться все рабочие процессы за блокировками. Это тебе не единое адресное пространство. Необходим маршалинг данных. Мало того кластеры могут находится на разных серверах. http://v8.1c.ru/overview/Term_000000126.htm#1

ух разошлись про блокировки. Ну и что, выяснили что нибудь? Если, выяснили, то через несколько релизов платформы 1С забудьте. Вам же ясно говорят, нечё лезть куда ни надо

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

(88) Так и сказано управляемые блокировки используют Read Commited (или Snapshot Isolation в 8.3), а блокировки в разрезе объектов 1С держит менеджер блокировок.
(89) Так это и есть официально объяснение лицензионного запрета, вы там наулучшаете, а мы в свою очередь всё переделаем внутри в новой версии и в неё уже автоматом ничего не сконвертируется при обновлении, и могут обвинить в этом не улучшателя, а производителя.

(90) Объясни зачем городить огород если все это можно решить на уровне БД, для рабочих процессов больше 1?
Могут быть кластеры на нескольких серверах. Где выигрыш если рабочих процессов больше чем 1?

(91) Зачем в запрсах применять хинты
FROM _AccRg5523 T3 WITH(SERIALIZABLE)
LEFT OUTER JOIN _Acc6_ExtDim5518 T4 WITH(REPEATABLEREAD)

(91) Глупо изобретать велосипед, там где он уже эффективно работает.  Snapshot Isolation хорорша при чтении данных снимка данных до начала транзакции. Если же ты хочешь, что бы данные не изменялись до конца транзакции нужно накладывать блокировки явно.

(92) Например, надо заблокировать одно значение субконто в регистре бухгалтерии по всем счетам, предложи как это сделать блокировками на уровне СУБД.
Менеджер блокировок просто запишет в своих структурах: Пространство блокировок (РБ.Хозрасчетный), Субконто, Его значение. И будет держать его до конца транзакции.
Всё дело в том, что, именно, сервер 1С хранит в себе бизнес модель на предметном уровне. Например, меня огорчает, что журнал регистрации не хранится в БД, но у производителя свои взгляды на продукт.

(86) версия 8.1

Код 1С

   
   БлокировкаДанных = Новый БлокировкаДанных;
   ЭлементБлокировки = БлокировкаДанных.Добавить("РегистрСведений.НоменклатураКонтрагентов");
   ЭлементБлокировки.Режим = РежимБлокировкиДанных.Исключительный;

   НачатьТранзакцию(РежимУправленияБлокировкойДанных.Управляемый);
   БлокировкаДанных.Заблокировать();

В профайлере:

SET TRANSACTION ISOLATION LEVEL READ COMMITTED
go
SELECT spid, blocked FROM master..sysprocesses WHERE blocked > 0 AND lastwaittype LIKE 'LCK_%'
go
BEGIN TRANSACTION
go

(88) та по ходу автоматический режим

(93)  .1 это точно управляемый режим новых версий 8.2?
.2 так это ради Оракла, который версионник, а не блокировочник как MS SQL, поэтому все блокировки они решили делать сами с учётом внутренней природы бизнес объектов (справочники, документы и тд.) и не объектов (регистры). А работать должно везде одинаково!

(96) Для автоматического режима хинт REPEATABLEREAD не имеет смысла.
(97) Для Оракла есть FOR UPDATE и DBMS_LOCK. Но не являюсь хоть каким то знатоком Оракула.

Хотя вот на оракуле
http://my-oracle.it-blogs.com.ua/post-37.aspx
Блокировка транзакций TX устанавливается при выполнении следующих операторов insert, delete, update, select for update. Блокировки транзакций работают только в режиме (lmode) - 6 exclusive (X) монопольная блокировка. Блокировки транзакций всегда осуществляются на уровне строк: блокируется строка и предотвращается изменение строки другими транзакциями до тех пор, пока не буде выполнен откат текущей транзакции или транзакция не будет зафиксирована. Чтобы была установлена блокировка TX, сначала устанавливается блокировка TM для таблицы в режиме 3 (RX). Затем устанавливается блокировка TX в режиме 6 (X). Блокировка TX не будет установлена, если другая транзакция установила блокировку TX на эту же строку.

Блокировки могут быть еще в режиме 4 (разделяемая блокировка таблицы share mode, генерируется, например, оператором lock table <…> in share mode) и 5 (разделяемая блокировка таблицы и монопольная блокировка строк share row exclusive; генерируется, например, оператором lock table <…..> in share row exclusive mode). Но эти режимы встречаются крайне редко.

(98) Я тоже не знаток оракла. PostgreSQL тоже версионник, есть ли там DBMS_LOCK ?
Но ключевой момент всё же то, что БД не знает про внутреннее устройство объектов 1С и значит не может учесть их природу. Возможно, для MS SQL можно было бы часть операций, таких, например, как расчёт итогов и управляемые блокировки, поместить в хранимые процедуры или .net сборки загруженные в процесс СУБД. Но они пошли по пути переписать под себя, ведь завтра множество поддерживаемых СУБД может расшириться.

(98) запрос при проведении документа, автоматические блокировки

exec sp_executesql N'UPDATE _Document6303
SET
_Marked = P1
FROM _Document6303 WITH(REPEATABLEREAD)
WHERE
_Document6303._IDRRef = @P2 AND _Document6303._Version = @P3',N'P1 varbinary(1),@P2 varbinary(16),@P3 varbinary(8)',0x00,0x840D00151730A35011E22F1E926C06FC,0x0000000001493E2A

(100) А зачем знать внутренне устройство? Блокировки накладываются не только на запись но и на индекс.

(99) не противоречит тому, чему меня учили в 1С. блокировки записи не мешают блокировкам чтения, эти эксклюзивные блокировки не похожи на одноимённые в MS SQL.

(101) Интересно какой смысл применять REPEATABLEREAD при UPDATE если на нё автоматически накладывается эксклюзивная блокировка?

(103) Интересно зачем Разделяемые и эксклюзивная?
Есть хинты NoLock но они не блокирующие.

(102) Вы так и не объяснили как заблокировать одно субконто во всех таблицах бухгалтерии средствами sql? На этапе проверки остатков до начала изменений.

(100) http://wiki.dieg.info/postgresql для
?
ACCESS SHARE MODE. Устанавливается автоматически командой SELECT для таблиц, из которых производится выборка данных. В заблокированных таблицах запрещается выполнение команд ALTER TABLE, DROP TABLE и VACUUM. В этом режиме для заблокированных таблиц также запрещаются параллельные блокировки уровня ACCESS EXCLUSIVE MODE.

?
ROW SHARE MODE. Устанавливается автоматически командами SELECT, содержащими секцию FOR UPDATE или FOR SHARE. В заблокированных таблицах запрещается выполнение команд ALTER TABLE, DROP TABLE и VACUUM. В этом режиме для заблокированных таблиц также запрещаются параллельные блокировки уровней EXCLUSIVE MODE и ACCESS EXCLUSIVE MODE.

?
ROW EXCLUSIVE MODE. Устанавливается автоматически командами UPDATE, INSERT и DELETE. В заблокированных таблицах запрещается выполнение команд ALTER TABLE, DROP TABLE и CREATE INDEX. В этом режиме для заблокированных таблиц также запрещаются параллельные блокировки уровней SHARE MODE, SHARE ROW EXCLUSIVE MODE, EXCLUSIVE MODE и ACCESS EXCLUSIVE MODE.

?
SHARE UPDATE EXCLUSIVE MODE . Устанавливается автоматически командами VACUUM (без FULL), ANALYZE и CREATE INDEX CONCURRENTLY.

?
SHARE MODE. Устанавливается автоматически командами CREATE INDEX (без CONCURRENTLY). В заблокированных таблицах запрещается выполнение команд INSERT, UPDATE, DELETE, ALTER TABLE, DROP TABLE и VACUUM. В этом режиме для заблокированных таблиц также запрещаются параллельные блокировки уровней ROW EXCLUSIVE MODE, SHARE ROW EXCLUSIVE MODE, EXCLUSIVE MODE и ACCESS EXCLUSIVE MODE.

?
SHARE ROW EXCLUSIVE MOOE. Специальный режим блокировки, практически идентичный режиму EXCLUSIVE MODE, но допускающий установку параллельных блокировок уровня ROW SHARE MODE.

?
EXCLUSIVE MODE. Запрещает выполнение команд INSERT, UPDATE, DELETE, CREATE INDEX, ALTER TABLE, DROP TABLE и VACUUM, а также команд SELECT с секцией FOR UPDATE. В этом режиме для заблокированных таблиц также запрещаются параллельные блокировки уровней ROW SHARE MODE, ROW EXCLUSIVE MODE, SHARE MODE, SHARE ROW EXCLUSIVE MODE и ACCESS EXCLUSIVE MODE.

?
ACCESS EXCLUSIVE MODE. Устанавливается автоматически командами ALTER TABLE, DROP TABLE и VACUUM. В этом режиме для заблокированных таблиц запрещаются любые команды или параллельные блокировки любого уровня.

(106) То есть ты не знаешь как хранятся итоги и движения по субконто?

о чем спор то?
в (0) вроде не блокировки спрашивал

(109) См 50,56

(108) Если субконто не первое, то не будет подходящего индекса, а значит лишние блокировки при REPEATABLE READ и выше. (Хотя и для первого, как я погляжу, индекс требует период и организацию) Как работает for update при Read Commited я не знаю, просветите.
В (107) плохо описана работа for update.

(111) Там остатки в разрезах хранятся.
http://main.1c-ei.ru/Home/help/objectdb/dbschema#TOC--18

Что значит излишнее? Я для таких случаев делаю регистр сведений и на нем делаю блокировки когда нужно заблокировать несколько таблиц, но по одинаковым измерениям.

По поводу для изменения посмотри v8: блокировки при записи в регистр сведений

А в 1С нет блокировок updlock.

(112) > А в 1С нет блокировок updlock.

В автоматическом режиме конструкция ДЛЯ ИЗМЕНЕНИЯ d pfghjct дает UPDLOCK

(113)
Спасибо. Буду знать.

114 + Правда у них он не такой уж и UPDLOCK
v8: Оптимизация SQL
WITH(SERIALIZABLE, UPDLOCK)
интересное сочетание

(112) В управляемом режиме Read Commited снимает блокировку сразу и, вероятно, for update игнорирует.
Лишние, я имел ввиду, что REPEATABLE READ блокирует все прочитанные записи, а в отсутствии индекса по блокируемуму измерению (или субконто) будет читаться лишнее.
Отдельный РС это разве не костыль? Если нарушить порядок наложения блокировок получим взаимоблокировку.
Или интересный вопрос, как бы вы блокировали данные которых возможно и нет? Как я помню в автоматическом режиме такая проверка остатков блокировала всю пустую или слабо заполненую таблицу.

(100) + 100500. Так, почему в 1С нет объектов типа хранимых процедур, функций и вьюх ? Казалось, бы, все просто, ан нет, СУБД то разные. Свой язык-транслятор сделать в Transact SQL, PL/SQL  и т.п. и во вьюхи разных диалектов ... к (60) п.1

Читаю http://ravepoint.narod.ru/aticles/tecnology/4techinf/4_1common/4_1_2.htm и понимаю, что где-то уже читал. Покопался в книжках - так и есть. Это из книги Радченко-Хрусталевой Архитектура и работа с данными 1С:Предприятия 8.2. Глава 4. Почти Один-в-один. Вот те на думаю, причем же здесь "Автор: Белоусов Павел (Альтер Лого, Москва)"? Для 1С с ее отношением к авторским правам очень странно...

К чему это я? Советую всем прочитать/перечитать эту главу. Желательно в книге, но если нет, то статью по ссылке. Потом можно обсуждать интересующие вопросы про блокировки на должном уровне, но В ОТДЕЛЬНОЙ ТЕМЕ. Эта уже становится мусоркой.

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

Кстати, являюсь "знатоком Оракла". Могу пояснить по нему, что интересует. Опять же в отдельной теме.

(117) Я имел виду использование хранимок для встроенных нужд, которые не связаны с языком 1С, в 7.7 они ведь были.
(118) В файловом режиме табличные блокировки, как сказано в приведённой статье, что очень упрощает их структуру; живут, вероятно, во временном файле.

(120) Я не про табличные. Я про те которым нет места в СУБД. То же субконто в РБ.

(120) - какие хранимки были ?
к (63) п. 1 - если бы было так просто, то 1С крутилась бы на всех SQL-серверах
на 4 - к (117) в вьюху подцепить имя поля по-русски - реально ?

а чо в восьмерке нету ид вида объекта ?

(123) Есть, например, _Value_TYPE есть в регистрах бухгалтерии, только у него тип binary(1) в MS SQL, а по сути целое число.

(124) а по адинесовски он доступен ?

Чо, реально что ли при создании новой базы из cf имена таблиц могут отличаться от базы-источника cf?
Я почему-то был уверен, что имена таблиц однозначно генерятся по внутренним идентификаторам метаданных...

(125) Только в виде проверки на тип (ТипЗнч) или оператор ССЫЛКА в языке запросов. При сильном желании можно из ЗначениеВСтрокуВнутр(Ссылка) получить.
(126) хм, вряд ли объекты в CF идентифицируются по ГУИДам, а идентификаторы видов объектов маленькие числа, при свёртке были бы коллизии.

(116) Отдельный РС это как раз не костыль, а оптимизация.
Тебе не нужно накладывать лишние блокировки, особенно когда нужно накладывать блокировки на множество таблиц. А вот за последовательностью тебе нужно самому следить. Но для этого создаются общие процедуры накладки блокировок. На то они и управляемые. При автоматических, ты легко можешь получить взаимные блокировки сначала прочитав данные, а потом записывать. И может получится так, что другая транзакция тоже хочет записать данные и прочитала данные до записи первой. Делать блокировки на уровне Сервера приложений достаточно не дальновидно, так как в любой БД уже существуют блокировки и заново изобретать велосипед просто не стоит. Стоит оптимизировать блокировки. Например регистр остатков состоит как минимум из двух таблиц. Движений и остатков по периодам. Стоит выделить один регистр который хранил бы измерения которые были в движениях.
(124) binary(1) это в большинстве случаев boolean.

(128) Легко ли унифицировать все способы блокировок для различных версий СУБД?
Насколько я понимаю, почти всегда достаточно заблокировать остатки на конец времён по тем измерениям, которые планируется изменить, и сделать это перед началом их чтения.
> Стоит выделить один регистр который хранил бы измерения которые были в движениях.
Можно по-подробнее?
тип составного реквизита boolean? скорее signed/unsigned char.

(129) Да. Я уже тебе давал ссылки. Мало того сама 1С ставит сочетание хинтов которые излишни.
А вот изобретение велосипеда может приводить к дополнительным ошибкам. Но если есть огромное желание изобретать велосипеды то никто конечно помешать не может. Тем более, что сочетание своих блокировок и блокировок СУБД ведет к излишним потреблением ресурсов.

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

Ну boolean как byte проще использовать.
В Delphi например true:= not false то есть true = 255 false = 0. Впрочем как и для олеаутоматион но там -1

У 1С хранится как 0 и 1

(115) SERIALIZABLE- это они всегда с регистрами в автоматическом режиме так работали, чтобы победить проблему фантомов. (как вы с ней бороться предложили бы?) UPDLOCK - это ДЛЯ ИЗМЕНЕНИЯ.
(130) По ссылкам нет всех деталей механизмов, не заметил как у этих БД решается проблема фантомов.
READ COMMITED вроде не очень ресурсоёмкий уровень изоляции транзакций для БД.
> При наложении блокировок будут накладываться блокировки на все измерения по периодам, коих может быть множество.
Это об автоматическом или управляемом режиме? в Управляемом вроде граничных блокировок быть не должно.

По поводу блокировок и изоляций транзакций там одно и тоже. Те же хинты и те же изоляции.
А по сути они должны быть и во всех. Так например для расчета остатков нужно запретить любые движения по измерениям во всех периодах.
Другой вариант может приводить к взаимным блокировкам блокировкам, когда при при проведении за прошлый период задним числом, будут изменяться последующие остатки по периодам.
(123) В хинте WITH(SERIALIZABLE, UPDLOCK) нет смысла, так как SERIALIZABLE уже накладывает эксклюзивные блокировки.

Sergionol достал уже с этими блокировками. Блокировки для вопроса с (0) - частный случай, зависимости от реализации БД, возможно решаемый.

Во всех есть уровень изоляции SERIALIZABLE
Для того, что бы заблокировать на чтение нужно просто прочитать данные. Например
@Х=Select Count(*)  From .
(134) Почему я а не ММ См 50,56. Мы с ним неспешно ведем беседу.

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

(136) Ну а ты чего раскипетился? По поводу 0 так все ясно, что базы с одинаковыми названиями реквизитов, могут иметь различное название полей в БД. Подтверждаю. Поэтому есть два режима как загрузка конфигурации так и объединение с файлом конфигурации.

(133) Так управляемые сервером 1С блокировки эту проблему с остатками решают.
Есть ещё версия, что разработчики по-началу просто не разобрались с разными СУБД и начали построение велосипедов.
Странно, но в http://technet.microsoft.com/ru-ru/library/ms173763(v=SQL.90).aspx ничего не сказано про X-блокировки при SERIALIZABLE

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

   Блокировка диапазона устанавливается в диапазоне значений ключа, соответствующих условиям поиска любой инструкции, выполненной во время транзакции. Обновление и вставка строк, удовлетворяющих инструкциям текущей транзакции, блокируется для других транзакций. Это гарантирует, что если какая-либо инструкция транзакции выполняется повторно, она будет считывать тот же самый набор строк. Блокировки диапазона сохраняются до завершения транзакции. Это самый строгий уровень изоляции, поскольку он блокирует целые диапазоны ключей и сохраняет блокировку до завершения транзакции. Из-за низкого параллелизма этот параметр рекомендуется использовать только при необходимости. Этот параметр действует так же, как и настройка HOLDLOCK всех таблиц во всех инструкциях SELECT в транзакции.

(138) Так расскажи про механизм управляемые сервером 1С блокировки? Учитывая, что может быть несколько рабочих процессов на разных серверах?

Про блокировки SQL http://msdn.microsoft.com/ru-ru/library/ms187373.aspx
SERIALIZABLE  
Равнозначен аргументу HOLDLOCK.  Накладывает дополнительные ограничения на совмещаемую блокировку: удерживает ее до завершения транзакции вместо снятия блокировки сразу после того, как таблица или страница данных больше не требуется, независимо от того, завершена ли транзакция. Просмотр выполняется с той же семантикой, что и транзакция, запущенная на уровне изоляции SERIALIZABLE. Дополнительные сведения об уровнях изоляции см. в разделе SET TRANSACTION ISOLATION LEVEL (Transact-SQL).

138 Посыпаю голову пеплом. Что то у меня замутило. SERIALIZABLE   не накладывает эксклюзивные блокировки.
Поэтому WITH(SERIALIZABLE, UPDLOCK)  вполне правильная инструкция. И WITH (XLOCK, SERIALIZABLE) должны накладывать и X блокировки на вставляемые данные

http://social.msdn.microsoft.com/Forums/en-US/transactsql/thread/20d7a8e1-9098-4db0-aa77-7eb5f4d33dc2/

В (139) написано про S-блокировку до конца транзакции с захватом соседних записей, но где там про U или Х?
Про технические детали управляемых блокировок можно только предполагать, но у 1С их меньше и они проще чем у MS SQL. С другой стороны этот механизм плохо управляемый, к примеру, невозможно отменить эскалацию при большом количестве записей в регистр.

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

Где-то встречал описание эскалации на 20 000 (или на 5000, не помню точно) записей при проведении документа и ничего с ними не сделаешь.
Сам сталкивался с закрытием месяца с одним пользователем в базе. Сервер 1С зависал на управляемых блокировках, совет производителя блокировать весь регистр бухгалтерии не помог, но установка блокировки на все счета, участвующие в документе, позволили наложить блокировки, которые поглотили все последующие блокировки при записи и позволили записать документ.
В менеджере кластера живет TransactionLockService (сервис транзакционых блокировок) rphost'ы к нему обращаются.

Кстати, упр. блокировки могут быть применены и при объектном чтении данных, я такими вещами не занимаюсь, но у менеджеров разных метаданных есть соответствующие методы (Выбрать, Остатки, Обороты).
(142) Каких функций для чтения нет?

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

Да куча. Например работа с датами, строками. Те же Выбрать первые v8: v8: Вcтречаем! Версия 8.2.18, вышла в релизе 8.2.18.61 смотри 228 сообщение. И еще куча всего.