Имя: Пароль:
1C
1С v8
Получить структуру SQL-таблиц базы данных
0 Врадий
 
18.04.13
11:26
Надеюсь на отзывчивость тех, кто уже понял принципы построения 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 .
45 Рэйв
 
18.04.13
12:37
(0)На, держи.

Описание структуры данных.
http://zalil.ru/34448210
46 Infsams654
 
18.04.13
12:38
(43) прямыми (Ровные запросы, а не оптимизированные кривым оптимизатором 1С) сделаешь базу кривой. В резюме, потом напиши, что сделал суперские оптимизированные запросы
49 Infsams654
 
18.04.13
12:46
(47) абсолютно не при чем. "За державу обидно".
Меня устраивает "оптимизатор запросов 1С", хоть и не фан. Как, говорилось на этом форуме не раз, готовить запросы надо уметь.
50 mistеr
 
18.04.13
12:46
Почему-то все адепты прямых запросов не учитывают вероятности получить несогласованные данные.
51 ДенисЧ
 
18.04.13
12:49
(50) Это с какого перепою?
52 Врадий
 
18.04.13
12:52
(45) Спасибо!!! Смотрю...
ВСЕМ СПАСИБО
53 Sammo
 
модератор
18.04.13
12:53
(47) Флейм в тематике
54 Infsams654
 
18.04.13
12:55
(51) ну как с какого? В обход объекта 1С что-то писать...
55 Врадий
 
18.04.13
13:03
данные из 1С попадают в систему весовых терминалов....обрабатываются там....затем обратно в 1С....кто работает с весовым оборудованием??? средства 1С дают хорошие возможности??????
56 mistеr
 
18.04.13
13:04
(51) Часть блокировок живет в памяти сервера. Сторонне приложение о них не в курсе.

(54) Я про чтение.
57 Infsams654
 
18.04.13
14:04
(56) про чтение да. 100+
58 Infsams654
 
18.04.13
14:05
(55) а какие не дают ?
59 Serginio1
 
18.04.13
14:22
(56) Например у тебя больше чем 1 кластер ( рабочих процессов) как ты их блокировать то будешь?
v8: Разделяемый или Исключительный режим блокировки
60 Infsams654
 
18.04.13
14:27
(55) в продолжение темы для "адептов":
Для чего надо делать так (0):
ускорить шибко тугой запрос на уровне СУБД, или, запудрить тех, кто будет это хозяйство разбирать
Для чего не надо делать так:
1. БД зависимо
2. лицензионное соглашение и согласованность данных
3. даются средства высокого уровня, зачем лезть в кору
4. потом, после реализатора "нетленки" долго нужно разбираться - из прямых запросов к БД, т.к. это уровень не бизнес-логики
61 mistеr
 
18.04.13
15:38
(59) Блокировки хранит менеджер кластера.
62 Serginio1
 
18.04.13
15:41
(61) Как другой кластер (рабочий процесс) об этом узнает? Проще использовать блокировки БД
63 МихаилМ
 
18.04.13
17:58
(60)
запудрить тупых рисовальщиков формочек и отчётов

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

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

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

4. если делать через view с именами метаданных - то все равно.
64 mistеr
 
18.04.13
18:35
(62) Рабочие процессы обращаются к менеджеру. А другой кластер это другая база.
65 МихаилМ
 
18.04.13
18:49
(64)
с какого релиза?
66 Serginio1
 
18.04.13
18:53
(64) Рабочие процессы это реально разные процессы со всоей виртуальной памятью.
Другой кластер это другой компьютер а база у всех одна.
Так как ты будешь хранить эти блокировки? Неужто это будет эффективнее чем хранить блокировки в самой БД?
Меня интересует технический процесс.
67 etc
 
18.04.13
20:10
(17) чтобы этого не случалось в SQL есть роль db_datareader
68 mistеr
 
18.04.13
20:57
(65) (66) Народ, желтые книжки почитайте, я с них цитирую. Конечно я в исходниках платформы не копался, но оснований не верить нет.

Блокировок БД бывает недостаточно, поэтому вводятся блокировки прикладного уровня. Сам не раз реализовывал, в других системах. Некоторые СУБД предоставляют механизмы для того, чтобы и прикладные блокировки жили в БД. Грубо говоря API к своему менеджеру блокировок. Но в случае 1С кроссплатформенность и кросс-СУБД диктует свои правила. Поэтому прикладные блокировки живут в памяти сервера 1С. Очевидно они не могут быть свои у каждого рабочего процесса, поэтому в памяти менеджера кластера.
И не путайте "рабочий процесс" и "кластер".
69 mistеr
 
18.04.13
20:58
(66) Хранить блокировки только в БД разумеется эффективнее. Но это не всегда возможно, см. выше.
70 МихаилМ
 
18.04.13
21:40
(69)
"желтые книжки почитайте" -
- какую главу. если Вы сами не использовали что-то
то к ЖК лучше не аппилировать, тк это 1с.
В ней заявленое может не работать, рабочее может быть не декларированным.

поэтому и интересно, можете ли Вы точнее чем общий отсыл к  
ЖК или интернет подтвердить работу кластера с разными бд.
71 mistеr
 
18.04.13
21:50
(70 >подтвердить работу кластера с разными бд.
Не понял

Главу постараюсь найти.
72 sda553
 
18.04.13
23:45
(38) Ты опоздал, вроде как веб сервисами пользоваться умеют уже все, а поднимать веб сервер дорогого стоит
73 mistеr
 
19.04.13
02:55
(71) Нашел.
Клиент-серверный вариант. Руководство администратора. 2.1.3. Сервисы кластера
На ИТС тоже есть.
74 МихаилМ
 
19.04.13
08:25
(73)
спасибо.
75 Serginio1
 
19.04.13
11:00
(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: Кэши разные нужны, кэши нужные важны.

Пессимистическая на уровне блокировок в транзакции. Нет смысла городить огород там, где он не нужен. Но вот если будут реальные примеры объектных блокировок осообенно в контексте нескольких серверов приложений.
76 mistеr
 
19.04.13
12:00
Правда, перечитал еще раз про упр. блокировки, и появилось сомнение в (50). Если они действительно держатся ТОЛЬКО до конца транзакции, то ЧИТАТЬ извне вроде можно. Но не уверен до конца.
77 Рэйв
 
19.04.13
12:03
78 Serginio1
 
19.04.13
12:09
(76) Так и объектные блокировки имеют смысл без транзакции.
Управляемые блокировки только на уровне транзакции и на уровне БД. Не управляемы это уже уровень изоляции REPEATABLE READ. Но тогда и на уровне блокировок запросов нет смысла в объектных блокировках для клиент сервера. Для Локальных баз на уровне LockFile
79 mistеr
 
19.04.13
12:34
(78) Давай прежде всего не путать объектные блокировки и управляемые. Первые с танзакциями не связаны, они чисто прикладные.
80 mistеr
 
19.04.13
12:42
(76) Спасибо, но верстка там полных швах.
81 Serginio1
 
19.04.13
12:42
Вот про это я и говорю зачем мешать объектные блокировки и транзакционными блокировками бд. Объектные блокировки так или иначе не взаимодействуют с блокировками БД. Тогда какой в них смысл? Управляемые блокировки это блокировки БД в режиме изоляции Read Commited с помощью хинтов SERIALIZABLE,REPEATABLEREAD. Автоматические это уже на уровне Изоляции REPEATABLE READ.
82 mistеr
 
19.04.13
12:46
(77) Более полезная статья: http://ravepoint.narod.ru/aticles/tecnology/4techinf/4_1common/4_1_2.htm
Но там верстка еще хуже. Читатьможно только в Опере в режиме Fit to width.
83 mistеr
 
19.04.13
12:51
(81) Давай ты прочитаешь (82), с терминологией и общей концепцией все устаканится, потом продолжим.

Правда, там в тексте упоминается 8.1, кое-что могло и устареть.
84 ssh2006
 
19.04.13
13:11
(81) > Управляемые блокировки это блокировки БД в режиме изоляции Read Commited с помощью хинтов SERIALIZABLE,REPEATABLEREAD.

Это неправда, при наложении управляемой блокировки никакие блокировки в БД не накладываются.
85 Рэйв
 
19.04.13
13:19
(82)У меня на лисе нормально.
86 МихаилМ
 
19.04.13
13:33
(84)
раньше
(до 14 релиза)  
накладывались   блокировки субд.

сейчас может исправили.
87 МихаилМ
 
19.04.13
13:34
+(86) при управляемых блокировках
88 Serginio1
 
19.04.13
13:42
(84) Интересно, а почему Управляемые блокировки только в Транзакции. И уровень изоляции Read Commited?
Интересно а это что за блокировки http://www.sql.ru/forum/actualthread.aspx?tid=912872

(83) Ты мне так и не объяснил механизм объектных блокировок между рабочими процессами. Для этого нужен некий общий процесс к которому будут обращаться все рабочие процессы за блокировками. Это тебе не единое адресное пространство. Необходим маршалинг данных. Мало того кластеры могут находится на разных серверах. http://v8.1c.ru/overview/Term_000000126.htm#1
89 Infsams654
 
19.04.13
13:55
ух разошлись про блокировки. Ну и что, выяснили что нибудь? Если, выяснили, то через несколько релизов платформы 1С забудьте. Вам же ясно говорят, нечё лезть куда ни надо
90 MM
 
19.04.13
13:56
(88) Внутри одного из менеджеров кластера (процесс) запускается служба (в терминах 1С) транзакционных блокировок, конечно, это маршалинг, но если рабочих процессов больше одного, то без этого управляемые блокировки не организовать. Если рабочий процесс один то в предыдущих версиях этот механизм блокировок размещался в рабочем процессе, с тех пор рекомендация, на х64 запускать один рабочий процесс, если нет веских причин поступить по-другому.
91 MM
 
19.04.13
14:05
(88) Так и сказано управляемые блокировки используют Read Commited (или Snapshot Isolation в 8.3), а блокировки в разрезе объектов 1С держит менеджер блокировок.
(89) Так это и есть официально объяснение лицензионного запрета, вы там наулучшаете, а мы в свою очередь всё переделаем внутри в новой версии и в неё уже автоматом ничего не сконвертируется при обновлении, и могут обвинить в этом не улучшателя, а производителя.
92 Serginio1
 
19.04.13
14:06
(90) Объясни зачем городить огород если все это можно решить на уровне БД, для рабочих процессов больше 1?
Могут быть кластеры на нескольких серверах. Где выигрыш если рабочих процессов больше чем 1?
93 Serginio1
 
19.04.13
14:12
(91) Зачем в запрсах применять хинты
FROM _AccRg5523 T3 WITH(SERIALIZABLE)
LEFT OUTER JOIN _Acc6_ExtDim5518 T4 WITH(REPEATABLEREAD)

(91) Глупо изобретать велосипед, там где он уже эффективно работает.  Snapshot Isolation хорорша при чтении данных снимка данных до начала транзакции. Если же ты хочешь, что бы данные не изменялись до конца транзакции нужно накладывать блокировки явно.
94 MM
 
19.04.13
14:16
(92) Например, надо заблокировать одно значение субконто в регистре бухгалтерии по всем счетам, предложи как это сделать блокировками на уровне СУБД.
Менеджер блокировок просто запишет в своих структурах: Пространство блокировок (РБ.Хозрасчетный), Субконто, Его значение. И будет держать его до конца транзакции.
Всё дело в том, что, именно, сервер 1С хранит в себе бизнес модель на предметном уровне. Например, меня огорчает, что журнал регистрации не хранится в БД, но у производителя свои взгляды на продукт.
95 ssh2006
 
19.04.13
14:21
(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
96 ssh2006
 
19.04.13
14:22
(88) та по ходу автоматический режим
97 MM
 
19.04.13
14:24
(93)  .1 это точно управляемый режим новых версий 8.2?
.2 так это ради Оракла, который версионник, а не блокировочник как MS SQL, поэтому все блокировки они решили делать сами с учётом внутренней природы бизнес объектов (справочники, документы и тд.) и не объектов (регистры). А работать должно везде одинаково!
98 Serginio1
 
19.04.13
14:40
(96) Для автоматического режима хинт REPEATABLEREAD не имеет смысла.
(97) Для Оракла есть FOR UPDATE и DBMS_LOCK. Но не являюсь хоть каким то знатоком Оракула.
99 Serginio1
 
19.04.13
14:54
Хотя вот на оракуле
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). Но эти режимы встречаются крайне редко.
100 MM
 
19.04.13
14:59
(98) Я тоже не знаток оракла. PostgreSQL тоже версионник, есть ли там DBMS_LOCK ?
Но ключевой момент всё же то, что БД не знает про внутреннее устройство объектов 1С и значит не может учесть их природу. Возможно, для MS SQL можно было бы часть операций, таких, например, как расчёт итогов и управляемые блокировки, поместить в хранимые процедуры или .net сборки загруженные в процесс СУБД. Но они пошли по пути переписать под себя, ведь завтра множество поддерживаемых СУБД может расшириться.
101 ssh2006
 
19.04.13
15:02
(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
102 Serginio1
 
19.04.13
15:21
(100) А зачем знать внутренне устройство? Блокировки накладываются не только на запись но и на индекс.
103 MM
 
19.04.13
15:24
(99) не противоречит тому, чему меня учили в 1С. блокировки записи не мешают блокировкам чтения, эти эксклюзивные блокировки не похожи на одноимённые в MS SQL.
104 Serginio1
 
19.04.13
15:27
(101) Интересно какой смысл применять REPEATABLEREAD при UPDATE если на нё автоматически накладывается эксклюзивная блокировка?
105 Serginio1
 
19.04.13
15:30
(103) Интересно зачем Разделяемые и эксклюзивная?
Есть хинты NoLock но они не блокирующие.
106 MM
 
19.04.13
15:33
(102) Вы так и не объяснили как заблокировать одно субконто во всех таблицах бухгалтерии средствами sql? На этапе проверки остатков до начала изменений.
107 Serginio1
 
19.04.13
15:36
(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. В этом режиме для заблокированных таблиц запрещаются любые команды или параллельные блокировки любого уровня.
108 Serginio1
 
19.04.13
15:37
(106) То есть ты не знаешь как хранятся итоги и движения по субконто?
109 krbIso
 
19.04.13
15:44
о чем спор то?
в (0) вроде не блокировки спрашивал
110 Serginio1
 
19.04.13
16:11
(109) См 50,56
111 MM
 
19.04.13
17:07
(108) Если субконто не первое, то не будет подходящего индекса, а значит лишние блокировки при REPEATABLE READ и выше. (Хотя и для первого, как я погляжу, индекс требует период и организацию) Как работает for update при Read Commited я не знаю, просветите.
В (107) плохо описана работа for update.
112 Serginio1
 
19.04.13
17:29
(111) Там остатки в разрезах хранятся.
http://main.1c-ei.ru/Home/help/objectdb/dbschema#TOC--18

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

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

А в 1С нет блокировок updlock.
113 ssh2006
 
19.04.13
17:40
(112) > А в 1С нет блокировок updlock.

В автоматическом режиме конструкция ДЛЯ ИЗМЕНЕНИЯ d pfghjct дает UPDLOCK
114 Serginio1
 
19.04.13
17:48
(113)
Спасибо. Буду знать.
115 Serginio1
 
19.04.13
17:54
114 + Правда у них он не такой уж и UPDLOCK
v8: Оптимизация SQL
WITH(SERIALIZABLE, UPDLOCK)
интересное сочетание
116 MM
 
19.04.13
17:57
(112) В управляемом режиме Read Commited снимает блокировку сразу и, вероятно, for update игнорирует.
Лишние, я имел ввиду, что REPEATABLE READ блокирует все прочитанные записи, а в отсутствии индекса по блокируемуму измерению (или субконто) будет читаться лишнее.
Отдельный РС это разве не костыль? Если нарушить порядок наложения блокировок получим взаимоблокировку.
Или интересный вопрос, как бы вы блокировали данные которых возможно и нет? Как я помню в автоматическом режиме такая проверка остатков блокировала всю пустую или слабо заполненую таблицу.
117 Infsams654
 
19.04.13
18:02
(100) + 100500. Так, почему в 1С нет объектов типа хранимых процедур, функций и вьюх ? Казалось, бы, все просто, ан нет, СУБД то разные. Свой язык-транслятор сделать в Transact SQL, PL/SQL  и т.п. и во вьюхи разных диалектов ... к (60) п.1
118 mistеr
 
19.04.13
18:14
Читаю http://ravepoint.narod.ru/aticles/tecnology/4techinf/4_1common/4_1_2.htm и понимаю, что где-то уже читал. Покопался в книжках - так и есть. Это из книги Радченко-Хрусталевой Архитектура и работа с данными 1С:Предприятия 8.2. Глава 4. Почти Один-в-один. Вот те на думаю, причем же здесь "Автор: Белоусов Павел (Альтер Лого, Москва)"? Для 1С с ее отношением к авторским правам очень странно...

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

А вопросы есть. Например, где живут управляемые блокировки при работе с файловой базой. Единого сервера-то нет.
119 mistеr
 
19.04.13
18:17
Кстати, являюсь "знатоком Оракла". Могу пояснить по нему, что интересует. Опять же в отдельной теме.
120 MM
 
19.04.13
18:17
(117) Я имел виду использование хранимок для встроенных нужд, которые не связаны с языком 1С, в 7.7 они ведь были.
(118) В файловом режиме табличные блокировки, как сказано в приведённой статье, что очень упрощает их структуру; живут, вероятно, во временном файле.
121 mistеr
 
19.04.13
18:19
(120) Я не про табличные. Я про те которым нет места в СУБД. То же субконто в РБ.
122 Infsams654
 
19.04.13
18:24
(120) - какие хранимки были ?
к (63) п. 1 - если бы было так просто, то 1С крутилась бы на всех SQL-серверах
на 4 - к (117) в вьюху подцепить имя поля по-русски - реально ?
123 Ковычки
 
19.04.13
18:40
а чо в восьмерке нету ид вида объекта ?
124 MM
 
19.04.13
18:49
(123) Есть, например, _Value_TYPE есть в регистрах бухгалтерии, только у него тип binary(1) в MS SQL, а по сути целое число.
125 Ковычки
 
19.04.13
18:52
(124) а по адинесовски он доступен ?
126 fisher
 
19.04.13
18:56
Чо, реально что ли при создании новой базы из cf имена таблиц могут отличаться от базы-источника cf?
Я почему-то был уверен, что имена таблиц однозначно генерятся по внутренним идентификаторам метаданных...
127 MM
 
19.04.13
18:58
(125) Только в виде проверки на тип (ТипЗнч) или оператор ССЫЛКА в языке запросов. При сильном желании можно из ЗначениеВСтрокуВнутр(Ссылка) получить.
(126) хм, вряд ли объекты в CF идентифицируются по ГУИДам, а идентификаторы видов объектов маленькие числа, при свёртке были бы коллизии.
128 Serginio1
 
22.04.13
10:50
(116) Отдельный РС это как раз не костыль, а оптимизация.
Тебе не нужно накладывать лишние блокировки, особенно когда нужно накладывать блокировки на множество таблиц. А вот за последовательностью тебе нужно самому следить. Но для этого создаются общие процедуры накладки блокировок. На то они и управляемые. При автоматических, ты легко можешь получить взаимные блокировки сначала прочитав данные, а потом записывать. И может получится так, что другая транзакция тоже хочет записать данные и прочитала данные до записи первой. Делать блокировки на уровне Сервера приложений достаточно не дальновидно, так как в любой БД уже существуют блокировки и заново изобретать велосипед просто не стоит. Стоит оптимизировать блокировки. Например регистр остатков состоит как минимум из двух таблиц. Движений и остатков по периодам. Стоит выделить один регистр который хранил бы измерения которые были в движениях.
(124) binary(1) это в большинстве случаев boolean.
129 MM
 
22.04.13
12:16
(128) Легко ли унифицировать все способы блокировок для различных версий СУБД?
Насколько я понимаю, почти всегда достаточно заблокировать остатки на конец времён по тем измерениям, которые планируется изменить, и сделать это перед началом их чтения.
> Стоит выделить один регистр который хранил бы измерения которые были в движениях.
Можно по-подробнее?
тип составного реквизита boolean? скорее signed/unsigned char.
130 Serginio1
 
22.04.13
12:29
(129) Да. Я уже тебе давал ссылки. Мало того сама 1С ставит сочетание хинтов которые излишни.
А вот изобретение велосипеда может приводить к дополнительным ошибкам. Но если есть огромное желание изобретать велосипеды то никто конечно помешать не может. Тем более, что сочетание своих блокировок и блокировок СУБД ведет к излишним потреблением ресурсов.

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

Ну boolean как byte проще использовать.
В Delphi например true:= not false то есть true = 255 false = 0. Впрочем как и для олеаутоматион но там -1
131 Serginio1
 
22.04.13
12:30
У 1С хранится как 0 и 1
132 MM
 
22.04.13
12:44
(115) SERIALIZABLE- это они всегда с регистрами в автоматическом режиме так работали, чтобы победить проблему фантомов. (как вы с ней бороться предложили бы?) UPDLOCK - это ДЛЯ ИЗМЕНЕНИЯ.
(130) По ссылкам нет всех деталей механизмов, не заметил как у этих БД решается проблема фантомов.
READ COMMITED вроде не очень ресурсоёмкий уровень изоляции транзакций для БД.
> При наложении блокировок будут накладываться блокировки на все измерения по периодам, коих может быть множество.
Это об автоматическом или управляемом режиме? в Управляемом вроде граничных блокировок быть не должно.
133 Serginio1
 
22.04.13
14:15
По поводу блокировок и изоляций транзакций там одно и тоже. Те же хинты и те же изоляции.
А по сути они должны быть и во всех. Так например для расчета остатков нужно запретить любые движения по измерениям во всех периодах.
Другой вариант может приводить к взаимным блокировкам блокировкам, когда при при проведении за прошлый период задним числом, будут изменяться последующие остатки по периодам.
(123) В хинте WITH(SERIALIZABLE, UPDLOCK) нет смысла, так как SERIALIZABLE уже накладывает эксклюзивные блокировки.
134 Infsams654
 
22.04.13
14:24
Sergionol достал уже с этими блокировками. Блокировки для вопроса с (0) - частный случай, зависимости от реализации БД, возможно решаемый.
135 Serginio1
 
22.04.13
14:27
Во всех есть уровень изоляции SERIALIZABLE
Для того, что бы заблокировать на чтение нужно просто прочитать данные. Например
@Х=Select Count(*)  From .
(134) Почему я а не ММ См 50,56. Мы с ним неспешно ведем беседу.
136 Infsams654
 
22.04.13
14:35
(135) эта беседа вообще к теме о блокировках, а как они связаны с (0). Открывайте другую ветку, или скажите прямо, чем это поможет (0).
137 Serginio1
 
22.04.13
14:42
(136) Ну а ты чего раскипетился? По поводу 0 так все ясно, что базы с одинаковыми названиями реквизитов, могут иметь различное название полей в БД. Подтверждаю. Поэтому есть два режима как загрузка конфигурации так и объединение с файлом конфигурации.
138 MM
 
22.04.13
15:28
(133) Так управляемые сервером 1С блокировки эту проблему с остатками решают.
Есть ещё версия, что разработчики по-началу просто не разобрались с разными СУБД и начали построение велосипедов.
Странно, но в http://technet.microsoft.com/ru-ru/library/ms173763(v=SQL.90).aspx ничего не сказано про X-блокировки при SERIALIZABLE

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

   Блокировка диапазона устанавливается в диапазоне значений ключа, соответствующих условиям поиска любой инструкции, выполненной во время транзакции. Обновление и вставка строк, удовлетворяющих инструкциям текущей транзакции, блокируется для других транзакций. Это гарантирует, что если какая-либо инструкция транзакции выполняется повторно, она будет считывать тот же самый набор строк. Блокировки диапазона сохраняются до завершения транзакции. Это самый строгий уровень изоляции, поскольку он блокирует целые диапазоны ключей и сохраняет блокировку до завершения транзакции. Из-за низкого параллелизма этот параметр рекомендуется использовать только при необходимости. Этот параметр действует так же, как и настройка HOLDLOCK всех таблиц во всех инструкциях SELECT в транзакции.
139 Serginio1
 
22.04.13
15:37
(138) Так расскажи про механизм управляемые сервером 1С блокировки? Учитывая, что может быть несколько рабочих процессов на разных серверах?

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

http://social.msdn.microsoft.com/Forums/en-US/transactsql/thread/20d7a8e1-9098-4db0-aa77-7eb5f4d33dc2/
141 MM
 
22.04.13
15:51
В (139) написано про S-блокировку до конца транзакции с захватом соседних записей, но где там про U или Х?
Про технические детали управляемых блокировок можно только предполагать, но у 1С их меньше и они проще чем у MS SQL. С другой стороны этот механизм плохо управляемый, к примеру, невозможно отменить эскалацию при большом количестве записей в регистр.
142 Serginio1
 
22.04.13
16:03
(141) Особенно когда обновляются миллионы записей. Приходится напрямую писать не от хорошей жизни. И то, что в 1С нет возможности массового применения например Merge просто заставляет применять прямую запись. Да и нет кучу функция для чтения данных. Так, что приходится применять прямые запросы.
143 MM
 
22.04.13
16:07
Где-то встречал описание эскалации на 20 000 (или на 5000, не помню точно) записей при проведении документа и ничего с ними не сделаешь.
Сам сталкивался с закрытием месяца с одним пользователем в базе. Сервер 1С зависал на управляемых блокировках, совет производителя блокировать весь регистр бухгалтерии не помог, но установка блокировки на все счета, участвующие в документе, позволили наложить блокировки, которые поглотили все последующие блокировки при записи и позволили записать документ.
В менеджере кластера живет TransactionLockService (сервис транзакционых блокировок) rphost'ы к нему обращаются.

Кстати, упр. блокировки могут быть применены и при объектном чтении данных, я такими вещами не занимаюсь, но у менеджеров разных метаданных есть соответствующие методы (Выбрать, Остатки, Обороты).
(142) Каких функций для чтения нет?
144 Serginio1
 
22.04.13
16:40
Ну если несколько серверов приложений должен существовать общий сервер через который все блокировки должны взаимодействовать. Читал я про это. Просто когда объем транзакций вырастет, то у него премуществ перед блокировками на уровне БД никаких не будет, только одни сложности.  

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