1с в схеме базы данных нет таблицы с именем

Обновлено: 23.01.2025

Обычно ошибка SDBL происходит при сохранении и обновлении конфигураций в момент реструктуризации базы данных, а также во время работы обменов данными.

Ожидается выражение (pos = ).
Выход за пределы размерности.
Поле таблицы не может принимать значение NULL.
Ошибка при полнотекстовом индексировании.
Попытка вставки значения недопустимого типа.
Поле определено неоднозначно.
Пропущена точка с запятой.
В схеме базы данных нет таблицы с именем…

Исправление ошибки SDBL

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

Перезагрузка сервера 1С и SQL-сервера

Самый простой способ, при условии, что на текущий момент в базе никто не работает.

Зайдите на сервер и выключите следующие службы:

«Агент сервера 1С»,
«SQL Server»,
«Агент SQL Сервера».

А затем запустите их обратно.

Очистка кэша на сервере и клиента, где проявилась ошибка

Как правило кэш расположен по адресу:

«%userprofile%\Local Settings\Application Data\1C\1Cv8» и «%userprofile%\Application Data\1C\1Cv8» для Windows XP,
«%userprofile%\AppData\Roaming\1C\1Cv8» и «%userprofile%\AppData\Local\1C\1Cv8» для Windows 7 и выше.

Перейдите в данный каталог и удалить все папки с генерированными именами вида « dg7c8re4-b89r…». При удалении будьте внимательны — в этой директории может присутствовать индекс полнотекстового поиска 1С, а также журналы регистрации, их удалять не нужно.

Перезаливка базы из DT-файла

Иногда помогает, казалось бы, парадоксальный способ — выгрузка базы данных в файл формата DT, а затем загрузка его обратно.

Войдите в режим «Конфигуратор», выберите пункт меню «Администрирование» > «Выгрузить информационную базу» и выберите каталог для сохранения файла.

Затем через аналогично через меню «Администрирование» > «Загрузить информационную базу» загрузите его обратно.

Тестирование и исправление Информационной базы

Для тестирование и исправление Информационной базы: войдите в «Конфигуратор», выберите пункт меню «Администрирование» > «Тестирование и исправление».

В случаях, когда невозможно запустить конфигуратор, воспользуйтесь утилитой chdbfl.exe. Это упрощенная программа-аналог тестирования базы, функции, которая запускается в режиме конфигуратора. Расположена она в папке «bin» установленной технологической платформы, например, C:\Program Files (x86)\1cv8\8.3…\bin\chdbfl.exe.

Пользоваться ей просто — указываете путь к файлу базы данных и ставите опцию, нужно ли сразу исправлять обнаруженные ошибки. Если нет — утилита только продиагностирует ИБ.

Обновление платформы до новой версии

В данном случае всё достаточно просто. Скачивает с сайта поддержки 1С дистрибутив свежей версии платформы, распаковываем и запускаем инсталятор setup.exe.

Очистка таблиц базы данных

В крайнем случае можно попробовать удалить таблицы БД, связанные с ошибкой — «dbo._ConfigChngR» и «dbo._ConfigChngR_ExtProps».

Производится это через менеджер SQL-скриптом вида:
use имя_базы_данных
delete from dbo ._ ConfigChngR
delete from dbo ._ ConfigChngR _ ExtProps

Помните, прямые SQL-запросы лучше доверить профессионалу, умеющему работать с SQL.

12 статей про обновление 1С

Типовую программу 1С легко обновить самостоятельно через конфигуратор или интернет. Ещё один способ — использовать cfu-файл. Если пропущено много релизов, вам сэкономят время промежуточные конфигурации.

После обновления не забывайте запустить особые процедуры.

Бывает выгоднее отдать обновление нетиповой 1С на аутсорсинг.

Что нового для вашей 1С?

Оперативная информация о выходе и содержании свежих для 24 типов конфигураций.

Рассылка осуществляется в день выхода обновления. Никакой рекламы, только полезная информация. Посмотрите пример →

День добрый. Есть Комплексная автоматизация 1.1.105.1. Платформа 8.2.19.130
PostgreeSQL.

Две базы, из одной в другую делается выгрузка данных.

Ошибка SDBL: В схеме базы данных нет таблицы с именем q_000_t_001 (яндекс и гугл, ни чего путного не выдают, хотя фразу поисковую выдают сразу )

Программно так же нельзя ни очистить план обмена ни зарегистрировать. Выбивает с ошибкой и Программа вылетает.

В файловой версии - такого глюка нет. Все отлично заходится и чистится. Тестирование и исправление, а так же стандартная утилита для тестирования структуры базы данных(chdbfl.exe) - ошибок не находят.

(23)т.е. ошибка снова возникает при следующем обмене.
А удалить полностью БД в постгри - пересоздать и уже в новую БД загрузить дт? или так и делал?)
Или рядом создать вторую базу и там проверить. Первое, что приходит в голову: структура баз изменилась после обновления, а правила обмена остались прежними.

(4) правила своевременно обновляются под релизы.

ошибка именно при попытке просмотреть что зарегистировано в плане обмена к обмену

ИМХО, тут-то собака и порылась, надо начинать с решения этой ошибки.

Кстати, а в файловом варианте эта ошибка тоже возникает?

(9) Написал выше, в файловом варианте все отлично работает.

Ну, тогда это какие-то косяки Postgre, тут я пас.

Разве что попробовать платформу обновить?

(11) Ох уж эти одноэсники. Вам бы только обновлять, да и то мифический страх перед нечетными релизами.

Почему регистр - потому что на сколько я помню, в узле плана обмена хранятся данные не во временной таблице, поэтому отпадает

(21) В них можкт храниться что угодно. В том числе временные метаданные при реструктуризации.
Но сами изменения конфы хранятся в таблице ConfigSave. Если Конфигуратор падает при запуске, надо дропнуть эту таблицу.

Я специально экспериментировал - в запросе помещал выборку во временную таблицу и её содержимое попадало в темповую таблицу скуля.

Когда в запросе написал ПОМЕСТИТЬ вт а потом УНИЧТОЖИТЬ вт, то квосты подчищалист и на сервре.
Просто однажды после разных падений и дисконнектов клиентов эта временная база забивалась и Конфигуратор падал при реорганизации.
Лечил перезапуском службы скуля.

(28) Я слегка термины перепутал и ввел в заблуждение. Не временная таблица, а виртуальная.

В вашем случае не понимаю, как временная таблица может влиять на конфигуратор, если только вы не о ConfigSave (она не временная), но если о ней, то не понимаю как вы ее

В случае ТС, идет какой-то запрос к бд, создается некая временная таблица q_000_t_001, и она падает. Это моё предположение.

Хотя скуль работал без сбоев. Просто 1С решила, что "и так много поработали, хватит".
На маленьких базах сойдет.

А выполнить операцию в файловой и загрузить результат в рабочую нельзя? (22) это как временное решение, так и делаю..
Но всё завязывается тогда на меня.. А нужно чтобы пользователи это делали (23)т.е. ошибка снова возникает при следующем обмене.
А удалить полностью БД в постгри - пересоздать и уже в новую БД загрузить дт? или так и делал?)
Или рядом создать вторую базу и там проверить.

(26)
в принципе только на этих выходных удалось получить в доступ сервер с 1С..

Помогло вот что..

1. Выгрузил базу в файловую и еще раз прогнал тестирование и исправление - особо ни чего не найдено
2. на всякий случай проверил внешней утилитой от 1С - ошибок нет

3. Удалил базу нафиг с сервера

4. заново создал в SQL базу и загрузил туда выгрузку

При этом как советовали ранее, пробовали и КЭШ чистить и у пользователе я и на сервере, и Остановку служб делать, это не помогало.

Только пересоздание базы..

Ну, это смотря что искать.

Волшебного заклинания типа "сим-салабим-ахалай-махалай" - да, нету, а вот пищи для размышлений - навалом:

То есть, причина проблемы - в точечной несовместимости 1С и имеющейся СУБД. Подтверждается это и тем, что в файловом варианте ошибка не воспроизводится.

Выводы? Лично я сделал следующий: поскольку работа платформы 1С оптимизируется под MS SQL (там такая проблема вроде бы тоже случается, но это - только со слов знатока из (19), то есть смысл подумать о переходе на эту СУБД. Затратно, поэтому лучше сначала потренироваться на кошках копии базы.

Или, как более дешевый вариант - ковырять отладчиком код, вызывающий ошибку и переписывать его, пытаясь угадать - какие нужно внести изменения для того, чтобы Postgree отработал корректно?

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

(32) Тебе нужно попробовать с помощью Tool_1CD удалить таблицу CONFIGSAVE
По всей видимости твоя база упала в момент реструктуризации.

То есть таблица CONFIG должна быть живая.

(29) >Изначально думал поднять из сф новую базу и воспользоваться ПолучитьСтруктуруХраненияБазыДанных()

В базах даже с одинаковой конфигурацией будут разные идентификаторы.

То есть ПолучитьСтруктуруХраненияБазыДанных() даст разные данные.

выгрузите с помощью тулсиди данные и загрузите в новую . обработки загрузки есть на ис.
(42) Ключевой вопрос по DBSCHEMA - как исправлять в ней ошибки
это та самая схема в которой нет моей константы? как понять формат этого чтобы корректно внести данные?
таблица _CONST30015 в файле присутвует
(39) таблица CONFIGSAVE пуста, это как я понимаю копия конфигурации которую надо будет применить

(47) Пример как такое делать есть ?

У меня пару месяцев назад был подобный вопрос с базой.

Тоже ругалось на отсутствие в схеме базы данных.

Я не нашел способ редактировать DBSCHEMA и решил задачу выгрузкой данных через XML.

(51) Если нужно и не найдешь стукнись на мыло. Мыло в профиле. Сброшу.

Я не помню уже где скачивал.

(57) _CONST30015 переименуй в CONST30015 и будет тебе счастье .
(57) это обычный текст, не надо его разбирать
При желании, можно в json конвертнуть или в xml.. только, не за чем
(60) не выгружается падает с ошибкой
(58) у меня все таблицы тулс показывает начинаются с _
как надоест играться, выложи 1cd на файлопомойку и ссылку сюда
да выложить то могу, мне хочеться еще и разобраться как это чиниться
<"Const21517","N",21517,"",
>,"",0>,

>,"",0>,

>,"",0>
>,
,
,1,0,0>
>,1,"S",
<

>
>,
<

>
>,"",0,0>,

>,"",0>,

>,"",0>,

>,"",0>
>,
,
,1,0,0>
>,1,"S",
<

>
>,
<

>
>,"",0,0>
по идее надо имена полей и таблицы поменять и запихать обратно
(66) это развод, тк при удалении DBSchema 1с ее восстанавливает.

(68) да. не восстанавливает.проверил на 1с8.2. но как-то мне удалось восстановить DBSchema без моего участия. может подменой похожего или пустого и реструктуризацией.

Коллеги, а почему автор не хочет очистить таблицу CONFIGSAVE и просто вернуться к той конфигурации которая была ?
(71)архива с конфой-донором нет.но если типовая то конфу-донора можно сгенерировать.возвожно- это самое простое решение. очистка CONFIGSAVE не поможет. произошло рассогласование метаданных и структуры бд или таблицы проекции метаданных в структуру бд
,кот. хранится в записи dbnames из таблицы params

пока не совсем понимаю в чем различие, правильно ли я понимаю что сами метаданные это то что хранится в таблице CONFIG
структура бд это то что храниться в DBSCHEMA а проекция это то что в храниться в dbnames и dbnames должно соответвовать DBSCHEMA ?

нет. не правильно понимаете . в DBSCHEMA хранятся соответствия типов 1с и бд . и естественно DBSCHEMA должна соответствовать dbnames .но все , о чем я питсал относится к 1с8.2 . в 1с8.3 может быть по-другому.

(72) >если типовая то конфу-донора можно сгенерировать

А разве это не приведет к тому же что и создание новой базы с такой же конфой но при этом у объектов будут другие индентиффикаторы ?

(0) А как ты с этой базой столкнулся ? Может все таки есть какие то бэкапы.

Это какое то реальное безумие обновлять базу при полном отсутствии бэкапов.

(75) структура бд в новой базе может быть другой. задача - привести в соответствие метаданные , dbnames и структуру бд. поскольку тулсиди умеет выгружать-загружать конфигурацию замена конфигурации- более простая операция для файловой базы чем редактирование dbnames или изменение структуры бд.
+(75) а для серверной бд проще изменить структуру бд. и на последнем месте - правка dbnames и DBSCHEMA
Немного разобрался как свзяаны талицы. нашел свою константу в DBNames. Может ктото подскажет как ее отредактировать?
(81 )тулсиди вроде умеет выгружать- загружать таблицы. выгрузите парамс отредактируйте запись DBNames. загрузите обратно. если в DBNames будет абракадебра - то разожмите-сожмите ее c помощью v8unpack
(85) да уж.. выгружать нужно не всю таблицу, а только dbnames..только зачем ?
там нажимаешь на карандаш и внизу можно сохранить/загрузить целиком image
(90) благодарю проглядел. я вставал не поле имаж(колонка бинаридата) и жал дискетку
Мне как то попадалась база с такими симптомами, у меня сложилось впечатление что при обновлении базы записалась новая dbNames? а новая dbschema не записалась, поэтому и ругается и даже если если исправите проблему с этой конкретной константой, потом будет другая и еще другая константа, и а потом потом справочник итак далее. ДЛя исправления этого надо ручками прописать dbschema для новых и измененных объектов, а задача эта достатчно муторная. Либо проверить соответствие DBShema - dbNames? и все записи которых нет в DBShema удалить из dbNames. Затем что нибудь изменить в конфе чтобы пошел процесс реструктуризации.
Все это возможно сделать если перевести базу в SQL (у меня сработала выгрузка в dt/загрузка из dt), у меня сложилось мнение что на файловой сделать это нельзя. Хотя я уже не помню, но в SQL легче переписывать эти файлы.

:(
(94) ДЛя исправления этого надо ручками прописать dbschema для новых и измененных объектов, а задача эта достатчно муторная. как сформировать правильную схему?
Либо проверить соответствие DBShema - dbNames? да я пока вижу неторое количество новых констант. Как сопоставить пока не поинмаю только начинаю узучать

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

Поле ввода «Файл соответствия номеров» и кнопка «Замена TREF»

Иногда в процессе восстановления возникает необходимость переноса таблиц из одной базы в другую базу с такой же конфигурацией, но с несовпадающей нумерацией в DBNames. Например, разрушена таблица в центральной базе, но нужная таблица есть в периферийной базе. Кроме того, что в таких базах не совпадают имена таблиц и полей, которую можно решить правкой файла описания таблицы, есть еще проблема несовпадения типов ссылок, которые хранятся в полях с окончанием "TREF". Подробности описаны в разделе "Структура информационной базы 1С". Данный инструмент позволяет произвести замену всех значений во всех таблицах базы в полях с окончанием TREF. Список замен должен содержаться в файле, выбираемом в поле ввода. Файл представляет собой текстовый файл. В каждой строке файла содержатся два числа, разделенных табуляцией. Второе число - заменяемое. Все поля, содержащие такое значение, заменяются на первое число строки.

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

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

cf это метаданные 1С к sql отношения не имеют. из того же cf можно вообще сделать файловую базу.

а вообще - проводлжайте наблюдать, вас столько открытий ждет

В базе1 добавили новый справочник, появилась таблица _Reference131.
В базе1 удалил справочник, таблица _Reference131 удалилась.
В базе1 добавили новый справочник, появилась таблица _Reference132
На базу2 накатили обновление из базы1. в базе2 появился справочник с таблицей _Reference131
но если загрузить в 2 разных базы чистых одинаковый Цф - то и структура с большой долей вероятности будет одинакова

>но если загрузить в 2 разных базы чистых одинаковый Цф - то и структура с большой долей вероятности будет одинакова

одинаковы будут id по которым происходит "быстрая" сверка. также это будет гарантировать что данные не отвалятся при нахлабучивании изменений одной конфы на другую через "загрузить"

(6) Ага. Следует заметить, что отсортированный по имени объектов cf-ник и такой же без сортировки скорее всего даст разные имена таблиц и полей, если, конечно, количество объектов метаданных в каждом типе больше 1 :)
(7) это понятно, я про стуртуру таблиц ы скуле, она тоже совпасть должна

Ребята. Всем СПАСИБО!!

НЕОБХОДИМО из SQL-таблиц получать информацию для другого программного продукта (НЕ 1С). получается, что надо создавать таблицу соответствий что ли, чтооб не изменять код при чтении данных 1С из таблиц в другом программном продукте(базу 1С планируем обновлять. ведь можно разными способами получить базу данных обновленную чистую для учета с нового года, например).

Кто-нибудь решал такую проблему? Может кто подскажет оптимальное решение.

(15) снабди своё 1С вебсервисом, который будет отдавать то , что надо, и ни чего лишнего. Иначе однажды утром 1С не заведется потому. что какой-то осел нечаянно сказал DROP DATABASE не в то окно
(15) Образение через com в 1с и получение структуры оттуда.
Но обычно более эффективным считается работа от обратного, когда 1с отдает в нужном виде.
(15)
я решал при обнослении config
в случае необходимости пересоздается view
с именами метаданных.
+(17) Ащета лицензионное соглашение 1С запрещает лезть своими грязными пальцАми в 1Совские БД

(15) Другой продукт каждый раз при коннекте каким то образом инициирует ПолучитьСтруктуруХраненияБазыДанных(МассивИменМетаданных)
в конфиге и дальше работает через этот мапинг до конца коннекта.

Как реализовать вызов этой процедуры - уже технические формальности

Я создавал базу данных соответствий НазвваниеОбъекта- таблица SQL.так же с реквизитами. дальше запросом получал соответствие и формировал динамически запрос к базе данных. если менялось название какой либо таблицы или реквизита то я просто в базе соответствий менял значение. и запрос опять давал корректный результат. Это все делалось для сверки с 1С другой учетной системы
(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 с именами метаданных - то все равно.

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

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

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

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

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

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

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

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

(38) Ты опоздал, вроде как веб сервисами пользоваться умеют уже все, а поднимать веб сервер дорогого стоит
(71) Нашел.
Клиент-серверный вариант. Руководство администратора. 2.1.3. Сервисы кластера
На ИТС тоже есть.

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

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

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

Правда, перечитал еще раз про упр. блокировки, и появилось сомнение в (50). Если они действительно держатся ТОЛЬКО до конца транзакции, то ЧИТАТЬ извне вроде можно. Но не уверен до конца.
(76) Так и объектные блокировки имеют смысл без транзакции.
Управляемые блокировки только на уровне транзакции и на уровне БД. Не управляемы это уже уровень изоляции REPEATABLE READ. Но тогда и на уровне блокировок запросов нет смысла в объектных блокировках для клиент сервера. Для Локальных баз на уровне LockFile
(78) Давай прежде всего не путать объектные блокировки и управляемые. Первые с танзакциями не связаны, они чисто прикладные.
Вот про это я и говорю зачем мешать объектные блокировки и транзакционными блокировками бд. Объектные блокировки так или иначе не взаимодействуют с блокировками БД. Тогда какой в них смысл? Управляемые блокировки это блокировки БД в режиме изоляции Read Commited с помощью хинтов SERIALIZABLE,REPEATABLEREAD. Автоматические это уже на уровне Изоляции REPEATABLE READ.

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

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

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

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

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

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

ух разошлись про блокировки. Ну и что, выяснили что нибудь? Если, выяснили, то через несколько релизов платформы 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С хранит в себе бизнес модель на предметном уровне. Например, меня огорчает, что журнал регистрации не хранится в БД, но у производителя свои взгляды на продукт.

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

(93) .1 это точно управляемый режим новых версий 8.2?
.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). Но эти режимы встречаются крайне редко.

go1c --> go1c

Просмотр профиля При обновлении, прыжком через несколько релизов, доработанной УПП вываливается ошибка:
В процессе обновления информационной базы произошла критическая ошибка.
по причине:
Ошибка SDBL:
В схеме базы данных нет таблицы с именем Reference15271
Это ключевой релиз. cf с помощью которого обновляю как раз предназначен для перехода с того релиза какой у меня в конфигурации поставщика. переход между типовыми тех же релизов не вызывает проблем
Подскажите с чем может быть связана эта ошибка? Zaval --> Zaval

Просмотр профиля Смотрите, что за таблица.
Внимательно сравните типовую с текущей. go1c --> go1c

Просмотр профиля Смотрите, что за таблица.
Внимательно сравните типовую с текущей.
чем бы ее посмотреть? База файловая, пробовал искать эту таблицу программой Tool_1CD. в перечне таблиц такой таблицы как тексте ошибки - нет. Vofka --> Vofka

Просмотр профиля чем бы ее посмотреть? База файловая, пробовал искать эту таблицу программой Tool_1CD. в перечне таблиц такой таблицы как тексте ошибки - нет.
Ну так программа вам об этом и написала. Смотрите не свою базу, а ту базу, которая получается с cf-ника. Batchir --> Batchir

Просмотр профиля Сначала написал, а потом вчитался в вопрос. Но всё же может реструктуризация в ТИИ поможет. Zaval --> Zaval

Просмотр профиля Для начала возьмите типовую того же релиза, что сейчас у рабочей.
Запустите объединение его с цф рабочей.
Разворачивайте все веточки, ищите удаляемые и пересоздаваемые объекты. Batchir --> Batchir

Просмотр профиля Да и за релизом платформы следите, нечто подобное наблюдалось в 8.2.9.356 go1c --> go1c

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

Да и за релизом платформы следите, нечто подобное наблюдалось в 8.2.9.356
ТИИ попробовал первым делом. а с релизом платформы 8.2.11.236 нет подобных проблем? Batchir --> Batchir

Просмотр профиля Попробуйте обновить платформу, на 8.1.15.14 вроде как проблема уже не наблюдалась Zaval --> Zaval

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

Ага, только судя по результатам, логика далека от безупречности.
Объекты в конфу добавлял еще и разработчик(в типовую). И теперь эти объекты не согласуются с "логично добавленными" в рабочую.

Batchir --> Batchir

Просмотр профиля Попробуйте обновить платформу, на 8.1.15.14 вроде как проблема уже не наблюдалась
тю блин чего-то меня попутало, в общем попробуйте всё таки поставить обновления платформы go1c --> go1c

Просмотр профиля Объекты в конфу добавлял еще и разработчик(в типовую). И теперь эти объекты не согласуются с "логично добавленными" в рабочую.
я наверное чего то не понимаю. если я сравниваю рабочую конфигурацию с типовой того же релиза (это равносильно сравнению рабочей с конфигурацией поставщика), при чем здесь объекты которые добавил в конфу еще и разработчик(в типовую)? Может имелось ввиду сравнения типовой рилиз которой соответствует рабочей конфигурации с типовой релиза до которого идет обновление? Zaval --> Zaval

Просмотр профиля

Сравнение типовых релизов вообще ничего не даст - обновление типовой аналогичным скачком ведь норм проходит?

Самое информативное(но и марудное) - это сравнение текущей с обновлением. В каую сторону сравнивать - дело вкуса.
Искать нужно объекты, которые предлагается одновременно и удалить и добавить.
Такая ситуация может возникнуть, если в рабочую вместо обновления руками добавляли объекты, подглядывая в очередной релиз от разработчика.

go1c --> go1c

Просмотр профиля

Вы правы, конфигурация досталась по наследству, но видно что такие объекты присутствуют. Значит у них разные идентификаторы и соответственно 1с при обновлении воспринимает их как два разных объекта. Хорошо найду я такие объекты но как мне установить соответствие между ними? Zaval --> Zaval

Просмотр профиля

Хороший вопрос для пятничного вечера.
Навскидку:
1. Двойников в рабочей переименовать. Обновить конфигурацию БД.
2. Удалять лишние запретить, позволить добавить новые.
3. После обновления скопировать данные в режиме Предприятия.
4. Убедившись, что все нормально, можно удалить переименованные.

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

Способа добраться до тех идентификаторов я не знаю. И учтите, что нужные значения использованы другими объектами(иначе бы и проблемы не возникло). Так что в этом случае объем гемора непредсказуем.

Читайте также: