Где хранится база sql 1с
Обновлено: 08.07.2024
Сервер "1С:Предприятия" и SQL-сервер
В данном разделе рассмотрены особенности настройки SQL-сервера для обеспечения взаимодействия сервера "1С:Предприятия 8" с SQL-сервером. Напомним, что в качестве SQL-сервера предполагается использовать Microsoft SQL Server 2000 с установленным Service Pack 2 или Microsoft SQL Server 2005. Далее по тексту под SQL-сервером будем понимать именно этот продукт. Поскольку использование "1С:Предприятия 8" в варианте "клиент-сервер" подразумевает хранение данных в SQL-сервере, для безошибочной работы "1С:Предприятия 8" необходимо уделить внимание следующим вопросам:
- распределение SQL-сервера и сервера "1С:Предприятия" по компьютерам;
- проверка наличия и версии SQL-сервера и компонента доступа к данным;
- выбор протокола передачи данных между сервером "1С:Предприятия" и SQL-сервером;
- настройка прав пользователя сервера "1С:Предприятия 8".
Рассмотрим подробнее каждый из перечисленных вопросов.
Распределение SQL-сервера и сервера "1С:Предприятия" по компьютерам
SQL-сервер и сервер "1С:Предприятия 8" могут быть установлены как на одном компьютере, так и на разных компьютерах, в зависимости от предполагаемой загрузки (см. руководство: "1С:Предприятие 8. Клиент-сервер. Особенности установки и использования"). Сервер "1С:Предприятия 8" взаимодействует с SQL-сервером через специальный компонент доступа к данным - Microsoft OLE DB Provider for SQL Server, входящий в состав Microsoft Data Access (MDAC), который, в свою очередь, взаимодействует с SQL-сервером либо непосредственно, если SQL-сервер установлен на том же компьютере, что и сервер "1С:Предприятия", либо через некоторый протокол передачи данных, если SQL-сервер и сервер "1С:Предприятия" установлены на разных компьютерах.
Проверка наличия и версий SQL-сервера и компонента доступа к данным
Для нормальной работы сервера "1С:Предприятия 8" необходимо, чтобы на компьютере, на котором установлен сервер "1С:Предприятия", присутствовал компонент Microsoft OLE DB Provider for SQL Server, который обычно входит в состав операционной системы Microsoft Windows 2000 и более новых и расположен в файле C:\Program Files\Common Files\System\OLE DB\sqloledb.dll. Маршрут используемого файла sqloledb.dll можно посмотреть в ветке
HKEY_CLASSES_ROOT\CLSID\\InprocServer32
системного реестра. Чтобы узнать его версию, необходимо открыть закладку Versions диалога свойств этого файла. Версия должна быть 08.10.9030 или более поздняя. Если это не так, то необходимо установить клиентские компоненты Microsoft SQL Server. Он также входит в состав Microsoft Data Access 2.6. Еще необходимо обратить внимание на файл C:\WINNT\system32\ntwdblib.dll, который должен иметь версию 8.00.194 или более позднюю.
В качестве SQL-сервера должен использоваться Microsoft SQL Server 2000 с установленным Service Pack 2 или Microsoft SQL Server 2005. Проверить версию SQL-сервера можно при помощи утилиты Enterprise Manager, входящей в комплект SQL-сервера. Запустите ее на компьютере, на котором установлен SQL-сервер, выберите ветку Console Root -> Microsoft SQL Servers -> SQL Server Group -> (Local), откройте окно ее свойств и на закладке General обратите внимание на строку Product version. Должна быть версия 8.00.534(SP2) или более поздняя. Если это не так, установите Microsoft SQL Server 2000 Service Pack 2 или Microsoft SQL Server 2005.
Выбор протокола передачи данных между сервером "1С:Предприятия" и SQL-сервером
Если сервер "1С:Предприятия" и SQL-сервер установлены на разных компьютерах, то передача данных осуществляется посредством сетевого протокола. Установки сетевых протоколов на SQL-сервере и у компонентов доступа к данным должны быть согласованы между собой. Для установки сетевых протоколов на SQL-сервере можно воспользоваться утилитой SQL Server Network Utility. Ее загрузочный модуль обычно находится в файле "C:\Program Files\Microsoft SQL Server\80\Tools\Binn\svrnetcn.exe". Эта утилита отображает диалог, в котором на закладке General представлен список включенных и выключенных протоколов. Для надежной работы "1С:Предприятия 8" рекомендуется включить протокол TCP/IP (первой строкой) и Named Pipes (второй строкой) и выключить все остальные протоколы.
Компьютер, на котором установлен сервер "1С:Предприятия", является по отношению к SQL-серверу клиентом, и для определения его сетевых протоколов воспользуйтесь утилитой SQL Server Client Network Utility. Ее загрузочный модуль обычно находится в файле "C:\WINNT\system32\cliconfg.exe". Она отображает диалог, в котором на закладке General представлен список включенных и выключенных протоколов. Рекомендуется использовать протокол TCP/IP, поскольку это исключает дополнительные проблемы с настройкой системы безопасности Windows и обеспечивает наибольшую производительность системы. Остальные протоколы лучше выключить. Обратите внимание на закладку Alias. Упоминание на ней имени используемого "1С:Предприятием" SQL-сервера может изменить выбранный сетевой протокол и привести к неожиданным эффектам.
Настройка прав пользователя сервера "1С:Предприятия 8"
Для повышения гибкости настройки прав рекомендуется использовать SQL Server Authentication.
Перед созданием первой информационной базы выполните следующие настройки. Запустите утилиту Enterprise Manager, входящей в комплект SQL-сервера, выберите ветку Console Root -> Microsoft SQL Servers -> SQL Server Group -> (Local), откройте окно ее свойств. На закладке Security переключатель Authentication установите в положение SQL Server and Windows и нажмите Ok. Выберите ветку Console Root -> Microsoft SQL Servers -> SQL Server Group -> (Local) -> Security -> Logins. Создайте учетную запись, имя и пароль, которой вы будете задавать в качестве имени и пароля пользователя SQL при создании информационной базы (Локальное Меню -> New Login. ). На закладке General отображенного диалога: в строке Name задайте имя пользователя; переключатель Authentication установите на SQL Server Authentication и задайте пароль пользователя; укажите master в качестве Default Database. На закладке Server Roles включите роль Database Creators, а на закладке Database Access найдите базу данных master и включите для нее роль public. После этого информационную базу можно создавать.
После создания информационной базы эта учетная запись станет собственником созданной базы данных и будет иметь возможность чтения данных из системных таблиц базы данных master, что и требуется для нормальной работы сервера "1С:Предприятия". От имени этой учетной записи могут быть созданы и другие базы данных. Если это нежелательно, то в свойствах рассматриваемой учетной записи на SQL-сервере на закладке Server Roles роль Database Creators можно выключить. Более подробную информацию по администрированию SQL-сервера можно найти в документации к Miсrosoft SQL Server.
Вопрос такой:
Слетел сервер. На нем крутился SQL с базами 1С.
Все основные базы перенес. Не могу найти 1 базу. Видимо её размещали где-то в другом месте.
Можно ли как то узнать где SQL хранил свои базы? В реестре винды я такой информации не нашел.
А в реестре её и нет. Эта инфа в master лежит (-ала)Поиском по всем дискам пройдись, ибо в сети её быть не может что значит слетел сервер?
к старым таблицам сервера есть доступ? дело в том что просто mdf - на дисках не нахожу.
Бухгалтер утверждает что работала с этой базой.
Захожу в конфигурацию 1С - вижу что в нем записано название базы на этом сервере. по этому названию базу mdf най ти не могу. Может Имя базы не соотвтетствовать файлу? +(1)автору может не стоить лесть к SQL, раз про поиск не знает) (7) . а если так. Могу ли я как то убедится что на SQL сервере точно была такая-то база? Перефразиру. Могу ли я где-то (в реестре Винды или реестре(?) SQL) на снятом диске увидеть какие базы были и где лежали?
(9) а сейчас что у тебя с скл сервером? он работает? или ты новый переустановил?
вообще тебе бы получить базу данных master
там внутри все что надо есть.
вопрос в другом. есть ли доступ к этой БД на "рухнувшем" сервере
Физически всю инфу со старых дисков прочитать могу.
C:\Program Files (x86)\Microsoft SQL Server\MSSQL\Data\master.mdf
ПРИАТТАЧ к новому SQL серверу. как базу master_old (например)
+(17) я не знаю можно ли 2000-го базу к 2005 приаттачить
но попробуй.
в этой базе в таблице sysdatabases
перечислены ВСЕ БД которые были на том серваке
(со всеми путями файлов)
Можно. Обратно нельзя +19 только не забудь когда аттачить будешь имя базы поменять)) а то приаттачишь ее как MASTER
потом новую тему создавать придеться))
хотя врдя ли конечно скуль допустит. (20) ну тогда остается надеяться что она приаттачится
и не упадет в суспект например Можно попробовать найти Логи от СКУЛЯ , там может пишут пути ? (25) он mdf найти не может, а ты ему ldf искать предлагаешь. Да и нет в них ничего (26) Я предлогаю логи от скуля искать, которые про Бекапи и реиндексы. вот только не помню пишет он там пути или нет
(26) он имеет в виду не журнал транзакций
а лог когда скуль пишет что делал и во сколько и иногда зачем и почему
(25) проще приаттачить да глянуть вообще была ли такая база или нет
база из системных msdb в ней Tables дальше System Tables открой на просмотр таблицу dbo.backupfile там поле
physical_name то что тебе надо
SELECT TOP 1000
[logical_name]
,[physical_drive]
,[physical_name]
если базу подключишь с именем не msdb то в запросе измини на твое название
c:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\MSDBData.mdfmsdb обычно лежит тут (39) ты напиши человеку как оттуда взять он задолбается лазить по мастеру дай ему готовый запрос. (41) другой разговор.по вопросу было понятно что человек не сильно шарит в SQL (45) 1c то какая если 7.7 то папка с пользователями и с файлом конфигурации должна быть в конфигураторе можно посмотреть настройки базы там видно имя сервера sql и имя базы.может у него база вообще крутилась на другом сервере имя файла базы будет соответствовать имя базы + .mdf (должно так быть) (0)Автор поис то ведешь по всем папкам, в том числе и по скрытым? (0) в системе видны все диски что были раньше может база крутилась на отдельном диске(а он не виден в системе)?
база не аттачится, пишет
ADDITIONAL INFORMATION:
An exception occurred while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.ConnectionInfo)
There is already an object named 'sysnsobjs' in the database.
Converting database 'master_old' from version 539 to the current version 611.
Database 'master_old' running the upgrade step from version 539 to version 551. (Microsoft SQL Server, Error: 2714)
вот это немного пугает There is already an object named 'sysnsobjs' in the database.
Вопрос такой:
Слетел сервер. На нем крутился SQL с базами 1С.
Все основные базы перенес. Не могу найти 1 базу. Видимо её размещали где-то в другом месте.
Можно ли как то узнать где SQL хранил свои базы? В реестре винды я такой информации не нашел.
А в реестре её и нет. Эта инфа в master лежит (-ала)Поиском по всем дискам пройдись, ибо в сети её быть не может что значит слетел сервер?
к старым таблицам сервера есть доступ? дело в том что просто mdf - на дисках не нахожу.
Бухгалтер утверждает что работала с этой базой.
Захожу в конфигурацию 1С - вижу что в нем записано название базы на этом сервере. по этому названию базу mdf най ти не могу. Может Имя базы не соотвтетствовать файлу? +(1)автору может не стоить лесть к SQL, раз про поиск не знает) (7) . а если так. Могу ли я как то убедится что на SQL сервере точно была такая-то база? Перефразиру. Могу ли я где-то (в реестре Винды или реестре(?) SQL) на снятом диске увидеть какие базы были и где лежали?
(9) а сейчас что у тебя с скл сервером? он работает? или ты новый переустановил?
вообще тебе бы получить базу данных master
там внутри все что надо есть.
вопрос в другом. есть ли доступ к этой БД на "рухнувшем" сервере
Физически всю инфу со старых дисков прочитать могу.
C:\Program Files (x86)\Microsoft SQL Server\MSSQL\Data\master.mdf
ПРИАТТАЧ к новому SQL серверу. как базу master_old (например)
+(17) я не знаю можно ли 2000-го базу к 2005 приаттачить
но попробуй.
в этой базе в таблице sysdatabases
перечислены ВСЕ БД которые были на том серваке
(со всеми путями файлов)
Можно. Обратно нельзя +19 только не забудь когда аттачить будешь имя базы поменять)) а то приаттачишь ее как MASTER
потом новую тему создавать придеться))
хотя врдя ли конечно скуль допустит. (20) ну тогда остается надеяться что она приаттачится
и не упадет в суспект например Можно попробовать найти Логи от СКУЛЯ , там может пишут пути ? (25) он mdf найти не может, а ты ему ldf искать предлагаешь. Да и нет в них ничего (26) Я предлогаю логи от скуля искать, которые про Бекапи и реиндексы. вот только не помню пишет он там пути или нет
(26) он имеет в виду не журнал транзакций
а лог когда скуль пишет что делал и во сколько и иногда зачем и почему
(25) проще приаттачить да глянуть вообще была ли такая база или нет
база из системных msdb в ней Tables дальше System Tables открой на просмотр таблицу dbo.backupfile там поле
physical_name то что тебе надо
SELECT TOP 1000
[logical_name]
,[physical_drive]
,[physical_name]
если базу подключишь с именем не msdb то в запросе измини на твое название
c:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\DATA\MSDBData.mdfmsdb обычно лежит тут (39) ты напиши человеку как оттуда взять он задолбается лазить по мастеру дай ему готовый запрос. (41) другой разговор.по вопросу было понятно что человек не сильно шарит в SQL (45) 1c то какая если 7.7 то папка с пользователями и с файлом конфигурации должна быть в конфигураторе можно посмотреть настройки базы там видно имя сервера sql и имя базы.может у него база вообще крутилась на другом сервере имя файла базы будет соответствовать имя базы + .mdf (должно так быть) (0)Автор поис то ведешь по всем папкам, в том числе и по скрытым? (0) в системе видны все диски что были раньше может база крутилась на отдельном диске(а он не виден в системе)?
база не аттачится, пишет
ADDITIONAL INFORMATION:
An exception occurred while executing a Transact-SQL statement or batch. (Microsoft.SqlServer.ConnectionInfo)
There is already an object named 'sysnsobjs' in the database.
Converting database 'master_old' from version 539 to the current version 611.
Database 'master_old' running the upgrade step from version 539 to version 551. (Microsoft SQL Server, Error: 2714)
вот это немного пугает There is already an object named 'sysnsobjs' in the database.
Если запустить эту обработку в первой и второй базе ( обе одной конфигурации УПП 1.3 (1.3.38.4)), то имеем для первой базы имя таблицы SQL = Reference131, для второй имя таблицы SQL = Reference162. Если смотреть структуру полей таблиц, то видим, что имена полей различны.
Вопрос: подтвердите или опровергните вывод: таблицы SQL создаются динамически и могут иметь различные имена (имена полей в том числе). При создании новой базы загрузкой конфигурации из *.cf –файла, получим таблицы новой базы с именами, отличными от имен таблиц базы, из которой был выгружен файл конфигурации *.cf .
cf это метаданные 1С к sql отношения не имеют. из того же cf можно вообще сделать файловую базу.
а вообще - проводлжайте наблюдать, вас столько открытий ждет
В базе1 удалил справочник, таблица _Reference131 удалилась.
В базе1 добавили новый справочник, появилась таблица _Reference132
На базу2 накатили обновление из базы1. в базе2 появился справочник с таблицей _Reference131
но если загрузить в 2 разных базы чистых одинаковый Цф - то и структура с большой долей вероятности будет одинакова
>но если загрузить в 2 разных базы чистых одинаковый Цф - то и структура с большой долей вероятности будет одинакова
одинаковы будут id по которым происходит "быстрая" сверка. также это будет гарантировать что данные не отвалятся при нахлабучивании изменений одной конфы на другую через "загрузить"
(7) это понятно, я про стуртуру таблиц ы скуле, она тоже совпасть должна
Ребята. Всем СПАСИБО!!
НЕОБХОДИМО из SQL-таблиц получать информацию для другого программного продукта (НЕ 1С). получается, что надо создавать таблицу соответствий что ли, чтооб не изменять код при чтении данных 1С из таблиц в другом программном продукте(базу 1С планируем обновлять. ведь можно разными способами получить базу данных обновленную чистую для учета с нового года, например).
Кто-нибудь решал такую проблему? Может кто подскажет оптимальное решение.
(15) Образение через com в 1с и получение структуры оттуда.
Но обычно более эффективным считается работа от обратного, когда 1с отдает в нужном виде.
(15)
я решал при обнослении config
в случае необходимости пересоздается view
с именами метаданных.
+(17) Ащета лицензионное соглашение 1С запрещает лезть своими грязными пальцАми в 1Совские БД
(15) Другой продукт каждый раз при коннекте каким то образом инициирует ПолучитьСтруктуруХраненияБазыДанных(МассивИменМетаданных)
в конфиге и дальше работает через этот мапинг до конца коннекта.
Как реализовать вызов этой процедуры - уже технические формальности
(21) это легко оспорить в суде и вертеть потом на вертеле. Другое дело, что это не разумно и не безопасно. Вот это уже вертеть чревато
(24) если данные только получать для отчетов и сверок- то это ничем не чревато. а вот если писать в базу то тут существует опасность.
(25)
какие опасности существуют при записи в таблицы (представления) ?
(16) а чем чревато создание собственных функций, процедур, вьюшек etc в одинесовской базе?
(25) ему придется отдать насторону огин и пароль к кишкам, из которых получить можно что угодно и ни кто не знает, что потом будет по факту получаться и куда передаваться. Это все равно, что голую задницу в интернет выставить
(28) всё-равно побаиваюсь. Создать другую базу и в ней создаю всё это хозяйство
(30) Ничего не будет. Я индексами игрался, функции и вьюхи создавал - всё работало как часы
(29) Можно ведь создать еще одно юзера к кишкам с доступом на ридонли
данные из 1С читать надо только, обрабатываться будут в другой системе
(31) единственное, наверно, если создавать архив средствами 1С, то потеряется. Но, это не страшно
Создай базу данных в которой будут вьюхи и процедуры(которые будут читать данный из рабочий базы)-как уже сказали зверя создать только на чтение.
я не рискнул вьюхи и процедуры создавать в рабочей базе. данные получал в другую базу во вьюхи.
(33) есть штатный безопасный механизм, дающий любой необходимый программный интерфейс к чему угодно. Вебсервисы. Надо научиться ими пользоваться, а не городить велосипеды с квадратными колесами.
(39) так я думаю это самое верное решение. т.к. на этапе проектирования не один пуд соли съел)))
все-таки, еще раз вопрос - что в 1С не хватает ? (38) + - изобретать велосипид, БД зависимый. Типа, круто, на asm ваять, а vb - отстой
(38) прямые (Ровные запросы, а не оптимизированные кривым оптимизатором 1С) запросы гораздо быстрее выполняются напрямую-если важна скорость
(34) Значит все средства интеграции, которые предлагает 1С штатно, мы вертели на вертеле? Или просто лень почитать?
(43) прямыми (Ровные запросы, а не оптимизированные кривым оптимизатором 1С) сделаешь базу кривой. В резюме, потом напиши, что сделал суперские оптимизированные запросы
(47) абсолютно не при чем. "За державу обидно".
Меня устраивает "оптимизатор запросов 1С", хоть и не фан. Как, говорилось на этом форуме не раз, готовить запросы надо уметь.
Почему-то все адепты прямых запросов не учитывают вероятности получить несогласованные данные.
данные из 1С попадают в систему весовых терминалов. обрабатываются там. затем обратно в 1С. кто работает с весовым оборудованием. средства 1С дают хорошие возможности.
(51) Часть блокировок живет в памяти сервера. Сторонне приложение о них не в курсе.
(56) Например у тебя больше чем 1 кластер ( рабочих процессов) как ты их блокировать то будешь?v8: Разделяемый или Исключительный режим блокировки
(55) в продолжение темы для "адептов":
Для чего надо делать так (0):
ускорить шибко тугой запрос на уровне СУБД, или, запудрить тех, кто будет это хозяйство разбирать
Для чего не надо делать так:
3. даются средства высокого уровня, зачем лезть в кору
4. потом, после реализатора "нетленки" долго нужно разбираться - из прямых запросов к БД, т.к. это уровень не бизнес-логики
(61) Как другой кластер (рабочий процесс) об этом узнает? Проще использовать блокировки БД
(60)
запудрить тупых рисовальщиков формочек и отчётов
0 что значит бд зависимо? 1с примерно одинаково гененрирут названия полей для разных субд (всего 3 варианта)
2 с учетом оговорок смысла не имеет. тк практически любой объект бд- метаданных можно привести к состоянию требующему разрешённому и рекомендованному фирмой 1с вмешательству.
3. вот тут верно. тк 1с8 на риалтайм систему не тянет.
лучше через коннектор.
мне через саповский коннектор в 10 раз удобней было работать с САП
чем на прямую в скл сервер писать.
4. если делать через view с именами метаданных - то все равно.
(64) Рабочие процессы это реально разные процессы со всоей виртуальной памятью.
Другой кластер это другой компьютер а база у всех одна.
Так как ты будешь хранить эти блокировки? Неужто это будет эффективнее чем хранить блокировки в самой БД?
Меня интересует технический процесс.
(17) чтобы этого не случалось в SQL есть роль db_datareader
(65) (66) Народ, желтые книжки почитайте, я с них цитирую. Конечно я в исходниках платформы не копался, но оснований не верить нет.
Блокировок БД бывает недостаточно, поэтому вводятся блокировки прикладного уровня. Сам не раз реализовывал, в других системах. Некоторые СУБД предоставляют механизмы для того, чтобы и прикладные блокировки жили в БД. Грубо говоря API к своему менеджеру блокировок. Но в случае 1С кроссплатформенность и кросс-СУБД диктует свои правила. Поэтому прикладные блокировки живут в памяти сервера 1С. Очевидно они не могут быть свои у каждого рабочего процесса, поэтому в памяти менеджера кластера.
И не путайте "рабочий процесс" и "кластер".
(69)
"желтые книжки почитайте" -
- какую главу. если Вы сами не использовали что-то
то к ЖК лучше не аппилировать, тк это 1с.
В ней заявленое может не работать, рабочее может быть не декларированным.
поэтому и интересно, можете ли Вы точнее чем общий отсыл к
ЖК или интернет подтвердить работу кластера с разными бд.
(70 >подтвердить работу кластера с разными бд.
Не понял
Главу постараюсь найти.
(71) Нашел.
Клиент-серверный вариант. Руководство администратора. 2.1.3. Сервисы кластера
На ИТС тоже есть.
Мало того в 8 ке применяется оптимистическая блокировка. Управляемые блокировки используют хинты SERIALIZABLE,REPEATABLEREAD
Оптимистическая блокировка осуществляется на уровне поля ._Version v8: Кэши разные нужны, кэши нужные важны.
Пессимистическая на уровне блокировок в транзакции. Нет смысла городить огород там, где он не нужен. Но вот если будут реальные примеры объектных блокировок осообенно в контексте нескольких серверов приложений.
(76) Так и объектные блокировки имеют смысл без транзакции.
Управляемые блокировки только на уровне транзакции и на уровне БД. Не управляемы это уже уровень изоляции REPEATABLE READ. Но тогда и на уровне блокировок запросов нет смысла в объектных блокировках для клиент сервера. Для Локальных баз на уровне LockFile
(78) Давай прежде всего не путать объектные блокировки и управляемые. Первые с танзакциями не связаны, они чисто прикладные.
Вот про это я и говорю зачем мешать объектные блокировки и транзакционными блокировками бд. Объектные блокировки так или иначе не взаимодействуют с блокировками БД. Тогда какой в них смысл? Управляемые блокировки это блокировки БД в режиме изоляции Read Commited с помощью хинтов SERIALIZABLE,REPEATABLEREAD. Автоматические это уже на уровне Изоляции REPEATABLE READ.
(81) Давай ты прочитаешь (82), с терминологией и общей концепцией все устаканится, потом продолжим.
Правда, там в тексте упоминается 8.1, кое-что могло и устареть.
(81) > Управляемые блокировки это блокировки БД в режиме изоляции Read Commited с помощью хинтов SERIALIZABLE,REPEATABLEREAD.
Это неправда, при наложении управляемой блокировки никакие блокировки в БД не накладываются.
(84)
раньше
(до 14 релиза)
накладывались блокировки субд.
сейчас может исправили.
(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 хорорша при чтении данных снимка данных до начала транзакции. Если же ты хочешь, что бы данные не изменялись до конца транзакции нужно накладывать блокировки явно.
Менеджер блокировок просто запишет в своих структурах: Пространство блокировок (РБ.Хозрасчетный), Субконто, Его значение. И будет держать его до конца транзакции.
Всё дело в том, что, именно, сервер 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
.2 так это ради Оракла, который версионник, а не блокировочник как MS SQL, поэтому все блокировки они решили делать сами с учётом внутренней природы бизнес объектов (справочники, документы и тд.) и не объектов (регистры). А работать должно везде одинаково!
(96) Для автоматического режима хинт REPEATABLEREAD не имеет смысла.
(97) Для Оракла есть FOR UPDATE и DBMS_LOCK. Но не являюсь хоть каким то знатоком Оракула.
Блокировки могут быть еще в режиме 4 (разделяемая блокировка таблицы share mode, генерируется, например, оператором lock table <…> in share mode) и 5 (разделяемая блокировка таблицы и монопольная блокировка строк share row exclusive; генерируется, например, оператором lock table <…..> in share row exclusive mode). Но эти режимы встречаются крайне редко.
Читайте также: