Проблема с неуникальным индексом при переводе базы из файлового варианта в SQL
Здравствуйте, уважаемые коллеги.
Возникла интересная проблема - при загрузке в SQL-серверном варианте возникает следующая ошибка:
В файловом варианте все работает нормально, тестирование и исправление базы проходит нормально - никаких ошибок не выдает.
Ошибка с неуникальным индексом возникает, как при попытке загрузки в MS SQL 2008, так и в PostgreSQL (стоят на одной и той же машине).
SQL-сервер стоит на машине под 64хбитной Windows Server 2008 R2 Standart, сервер 1С:Предприятия стоит на машине под Windows 2003 Server R2 Enterprise x64 Edition SP2.
При чем, я обнаружил интересную штуку:
Установил на своей локальной машине (на которой установлена Windows XP) PostgreSQL (тот же, что стоит и на сервере) и сервер 1С:Предприятия, и в этот PostgreSQL база загрузилась без проблем, и работает!
Попробовал сделать средствами PostgreSQL резервную копию базы со своей локальной машины, и загрузить ее в PostgreSQL на сервер - база загрузилась, и даже открылась.
Но при тестировании и исправлении выдала ту же ошибку про неуникальный индекс, а при попытке перепровести какой-нибудь документ она портит его номер на кракозябры (вот пример юыло так "ИПО0057372", а стало так "Р˜РџРћ0057"), а если попытаться открыть и записать элемент какого-нибудь справочника - она начинает двоить, троить, четверить и т.п. группы и элементы справочников. Под PostgreSQL, установленном локально на моем компе с Windows XP, все работает нормально - ничего не двоит, не троит, никаких крокозябр в номерах документов нет, и тестирование и исправление базы проходит нормально.
Попробовал загрузить базу в MS SQL 2005, ОС MS Windows Server 2003 Enterprise Edition SP1, который установлен на другом сервере - возникла та же ошибка с неуникальным индексом (ругается на таблицу, которая соответстует табличной части "Товары" документа "Реализация товаров и услуг" (база Управление торговлей 10.2.11.1).
Версия платформы и сервера 1С 8.1.15.14.
Подскажите пожалуйста - в чем может быть загвоздка? - может быть, кто-то уже сталкивался с таким? (Смещение дат при загрузке в MS SQL делал и 0, и 2000)
P.S.
Да, и еще забыл сказать, что база довольно большая - в файловом варианте занимает на диске около 23 Гб, поскольку ведется с 2006 года.
При обращении к некоторым регистрам (касающихся взаиморасчетов с контрагентами) выдает сообщение о том, что системе не достаточно памяти, и система закрывается аварийно. Но эта ошибка возникает тогда, когда пытаешься построить отчет по взаиморасчетам с контрагентами, например, по всем контрагентам. Если формировать отчет по группе контрагентов, или по конкретному контрагенту - такой ошибки не возникает.
Возникла интересная проблема - при загрузке в SQL-серверном варианте возникает следующая ошибка:
Ошибка загрузки информационной базы. В информационную базу загружены не все данные
по причине:
Попытка вставки неуникального значения в уникальный индекс:
Microsoft OLE DB Provider for SQL Server: Выполнение инструкции CREATE UNIQUE INDEX прервано, поскольку обнаружен повторяющийся ключ для объекта с именем "dbo._Document133_VT3144" и индекса с именем "_Documen133_VT3144_IntKeyInd". Повторяющееся значение ключа: (0xa109001a4d4d010111dcaef25b8f25a2, 0x00000001).
HRESULT=80040E2F, SQLSrvr: Error state=1, Severity=10, native=1505, line=1
по причине:
Попытка вставки неуникального значения в уникальный индекс:
Microsoft OLE DB Provider for SQL Server: Выполнение инструкции CREATE UNIQUE INDEX прервано, поскольку обнаружен повторяющийся ключ для объекта с именем "dbo._Document133_VT3144" и индекса с именем "_Documen133_VT3144_IntKeyInd". Повторяющееся значение ключа: (0xa109001a4d4d010111dcaef25b8f25a2, 0x00000001).
HRESULT=80040E2F, SQLSrvr: Error state=1, Severity=10, native=1505, line=1
В файловом варианте все работает нормально, тестирование и исправление базы проходит нормально - никаких ошибок не выдает.
Ошибка с неуникальным индексом возникает, как при попытке загрузки в MS SQL 2008, так и в PostgreSQL (стоят на одной и той же машине).
SQL-сервер стоит на машине под 64хбитной Windows Server 2008 R2 Standart, сервер 1С:Предприятия стоит на машине под Windows 2003 Server R2 Enterprise x64 Edition SP2.
При чем, я обнаружил интересную штуку:
Установил на своей локальной машине (на которой установлена Windows XP) PostgreSQL (тот же, что стоит и на сервере) и сервер 1С:Предприятия, и в этот PostgreSQL база загрузилась без проблем, и работает!
Попробовал сделать средствами PostgreSQL резервную копию базы со своей локальной машины, и загрузить ее в PostgreSQL на сервер - база загрузилась, и даже открылась.
Но при тестировании и исправлении выдала ту же ошибку про неуникальный индекс, а при попытке перепровести какой-нибудь документ она портит его номер на кракозябры (вот пример юыло так "ИПО0057372", а стало так "Р˜РџРћ0057"), а если попытаться открыть и записать элемент какого-нибудь справочника - она начинает двоить, троить, четверить и т.п. группы и элементы справочников. Под PostgreSQL, установленном локально на моем компе с Windows XP, все работает нормально - ничего не двоит, не троит, никаких крокозябр в номерах документов нет, и тестирование и исправление базы проходит нормально.
Попробовал загрузить базу в MS SQL 2005, ОС MS Windows Server 2003 Enterprise Edition SP1, который установлен на другом сервере - возникла та же ошибка с неуникальным индексом (ругается на таблицу, которая соответстует табличной части "Товары" документа "Реализация товаров и услуг" (база Управление торговлей 10.2.11.1).
Версия платформы и сервера 1С 8.1.15.14.
Подскажите пожалуйста - в чем может быть загвоздка? - может быть, кто-то уже сталкивался с таким? (Смещение дат при загрузке в MS SQL делал и 0, и 2000)
P.S.
Да, и еще забыл сказать, что база довольно большая - в файловом варианте занимает на диске около 23 Гб, поскольку ведется с 2006 года.
При обращении к некоторым регистрам (касающихся взаиморасчетов с контрагентами) выдает сообщение о том, что системе не достаточно памяти, и система закрывается аварийно. Но эта ошибка возникает тогда, когда пытаешься построить отчет по взаиморасчетам с контрагентами, например, по всем контрагентам. Если формировать отчет по группе контрагентов, или по конкретному контрагенту - такой ошибки не возникает.
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
cool.vlad4, огромное спасибо за Ваш ответ и внимание к моей проблеме - с этой статьей Гилева я знаком (первым делом прочитал ее) - но еще раз прочитаю повнимательнее.
Меня вот какая штука смущает - почему в PostgreSQL, установленный локально на моей машине под Win XP, все загружается нормально и работает, а на серваки с серверными системами - нет?
Или причина может быть в сервере, на котором стоит сервер 1С:Предприятия?
Меня вот какая штука смущает - почему в PostgreSQL, установленный локально на моей машине под Win XP, все загружается нормально и работает, а на серваки с серверными системами - нет?
Или причина может быть в сервере, на котором стоит сервер 1С:Предприятия?
Отдампить и сделать архивную копию базы средствами постгре - это разве не одно и то же?
Я сделал архивную копию базы на своем локальном компьютере средствами постгре и загрузил ее на сервер - база стала глючить - стали возникать какие-то проблемы с кодировкой - при перепроведении документов портятся номера документов на крокозябры, а при сохранении элементов справочников, справочники начинают двоиться, троиться, четвериться и т.п., и текстовые поля перезаписанного элемента превращаются в крокозябры.
Я сделал архивную копию базы на своем локальном компьютере средствами постгре и загрузил ее на сервер - база стала глючить - стали возникать какие-то проблемы с кодировкой - при перепроведении документов портятся номера документов на крокозябры, а при сохранении элементов справочников, справочники начинают двоиться, троиться, четвериться и т.п., и текстовые поля перезаписанного элемента превращаются в крокозябры.
Локализации Windows - русские.
Postgre 8.3.8-1.1C.
Сейчас пока пытаюсь загрузить в Postgre - пробую вариант выгрузки через распределенную базу.
Уж больно не хочется искать косячную строку в таблицах, и править ее ручками (еще бы понять - как ее там найти).
Postgre 8.3.8-1.1C.
Сейчас пока пытаюсь загрузить в Postgre - пробую вариант выгрузки через распределенную базу.
Уж больно не хочется искать косячную строку в таблицах, и править ее ручками (еще бы понять - как ее там найти).
Спасибо Вам за Ваш совет, уважаемый plasmoid, но по-моему, раз 9я версия постгре пока есть только в тестовом варианте - ее лучше пока не пробовать. Тем более, что возни будет со боркой (сам ни разу не собирал, и даже не представляю, как это делается :oops: ), а ошибка, скорее всего, вылезет та же самая :) .
Решил все-таки попробовать исправить руками эту злополучную запись в таблице с дублирующимися ключевыми полями - пытаюсь запросом в постгре найти дублирующиеся записи в таблице _document133_vt3144, и не могу понять - как ему в запросе в условии задать, чтобы он нашел мне строки таблицы с полем _document133_idrref = 0xa109001a4d4d010111dcaef25b8f25a2?
попробовал написать вот такой запрос:
выдает ошибку:
Не могу, говорит, сравнить тип bytea с типом bit.
Подскажите пожалуйста, дорогие друзья - как правильно написать запрос? Как указать это загадочное значение 0xa109001a4d4d010111dcaef25b8f25a2 (на сколько я понял - это UUID) в виде не менее загадочного для меня типа bytea? :)
Решил все-таки попробовать исправить руками эту злополучную запись в таблице с дублирующимися ключевыми полями - пытаюсь запросом в постгре найти дублирующиеся записи в таблице _document133_vt3144, и не могу понять - как ему в запросе в условии задать, чтобы он нашел мне строки таблицы с полем _document133_idrref = 0xa109001a4d4d010111dcaef25b8f25a2?
попробовал написать вот такой запрос:
SELECT _document133_idrref, _keyfield, _lineno3145, _fld3146rref, _fld3147rref,
_fld3148rref, _fld3149, _fld3150, _fld3151, _fld3152rref, _fld3153,
_fld3154rref, _fld3155rref, _fld3156rref, _fld3157, _fld3158,
_fld3159rref, _fld3160, _fld3161rref, _fld3162, _fld3163rref,
_fld3164_type, _fld3164_n, _fld3164_rrref
FROM _document133_vt3144
WHERE _document133_idrref = X'a109001a4d4d010111dcaef25b8f25a2' AND _keyfield = X'00000001';выдает ошибку:
ERROR: operator does not exist: bytea = bit
LINE 7: WHERE _document133_idrref = X'a109001a4d4d010111dcaef25b8f...
HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts.
********** Ошибка **********
ERROR: operator does not exist: bytea = bit
SQL state: 42883
Подсказка:No operator matches the given name and argument type(s). You might need to add explicit type casts.
Характеристика:402
LINE 7: WHERE _document133_idrref = X'a109001a4d4d010111dcaef25b8f...
HINT: No operator matches the given name and argument type(s). You might need to add explicit type casts.
********** Ошибка **********
ERROR: operator does not exist: bytea = bit
SQL state: 42883
Подсказка:No operator matches the given name and argument type(s). You might need to add explicit type casts.
Характеристика:402
Не могу, говорит, сравнить тип bytea с типом bit.
Подскажите пожалуйста, дорогие друзья - как правильно написать запрос? Как указать это загадочное значение 0xa109001a4d4d010111dcaef25b8f25a2 (на сколько я понял - это UUID) в виде не менее загадочного для меня типа bytea? :)
не могу сказать про пг, но в ms sql надо просто найти док, где в ТЧ есть ссылка "a109001a4d4d010111dcaef25b8f25a2", синтаксис запроса будет как у Гилева описано.
но поскольку в ms загрузить не получается, можно попробовать найти саму ссылку в базе:
берете любую ссылку этого дока и преобразуете в (пример на моей базе),
ЗначениеВСтрокуВнутр(Ссылка) -> "{"#",2c975178-194b-4a42-8785-b696eeaf42be,131:bc7d001b78e134e011e05b86f088cb14}"
далее, подставим вашу сцылку "a109001a4d4d010111dcaef25b8f25a2" и сделаем обратное преобразование
ЗначениеИзСтрокиВнутр("{""#"",2c975178-194b-4a42-8785-b696eeaf42be,131:a109001a4d4d010111dcaef25b8f25a2}")
это даст вам ссылку на искомый док... по идее :)
но поскольку в ms загрузить не получается, можно попробовать найти саму ссылку в базе:
берете любую ссылку этого дока и преобразуете в (пример на моей базе),
ЗначениеВСтрокуВнутр(Ссылка) -> "{"#",2c975178-194b-4a42-8785-b696eeaf42be,131:bc7d001b78e134e011e05b86f088cb14}"
далее, подставим вашу сцылку "a109001a4d4d010111dcaef25b8f25a2" и сделаем обратное преобразование
ЗначениеИзСтрокиВнутр("{""#"",2c975178-194b-4a42-8785-b696eeaf42be,131:a109001a4d4d010111dcaef25b8f25a2}")
это даст вам ссылку на искомый док... по идее :)
Alchemist пишет:
WHERE _document133_idrref = X'a109001a4d4d010111dcaef25b8f25a2' AND _keyfield = X'00000001';
WHERE _document133_idrref = X'a109001a4d4d010111dcaef25b8f25a2' AND _keyfield = X'00000001';
а вот это вот " = X'... ", это какой-то вариант синтаксиса под ПостГри?
под ms sql это будет выглядеть так
WHERE _document133_idrref = 0xa109001a4d4d010111dcaef25b8f25a2 AND _keyfield = 0x00000001
romansun, спасибо за ценную фишку преобразования при помощи функции ЗначениеИзСтрокиВнутр() - пригодится.
Буквари по постгревому сиквелу покурил сегодня, на сколько смог - пока ничего не накурил. Накурил только - как нужно указывать шестнадцатеричные значения X'шестнадцатеричное_значение' :) .
Вот какая интересная штука получилась - решил, ради интереса, зацепиться к постгре на сервере через сервер 1С:Предприятия, который установлен на моей локальной машине (на которой стоит Windows XP), и база загрузилась нормально! Выходит - дело в сервере 1С:Предприятия, который стоит на сервере. Возможно, что проблема в 64-хбитном сервере 1С предприятия, потому что на моей локальной машине стоит 32-хбитный, и все работает.
Сейчас точно не помню, но, по-моему, так же база не загружалась и в ситуации, когда сервер 1С:Предприятия стоял на том же сервере, где установлен и SQL-сервер (тоже 64-хбитный) - завтра снова запущу сервер на том же сервере, где стоит SQL-сервер, и проверю еще раз, чтобы точно убедиться. Возможно, что это какой-то баг в 64-хбитной версии сервера 1С:Предприятия 8.1.15.14.
Еще попробую зацепиться теперь к загруженной базе через сервер 1С:Предприятия, который установлен на сервере (на который есть подозрения, что он глючит) - посмотрю - будет ли он крокозябрить базу, или нет...
Буквари по постгревому сиквелу покурил сегодня, на сколько смог - пока ничего не накурил. Накурил только - как нужно указывать шестнадцатеричные значения X'шестнадцатеричное_значение' :) .
Вот какая интересная штука получилась - решил, ради интереса, зацепиться к постгре на сервере через сервер 1С:Предприятия, который установлен на моей локальной машине (на которой стоит Windows XP), и база загрузилась нормально! Выходит - дело в сервере 1С:Предприятия, который стоит на сервере. Возможно, что проблема в 64-хбитном сервере 1С предприятия, потому что на моей локальной машине стоит 32-хбитный, и все работает.
Сейчас точно не помню, но, по-моему, так же база не загружалась и в ситуации, когда сервер 1С:Предприятия стоял на том же сервере, где установлен и SQL-сервер (тоже 64-хбитный) - завтра снова запущу сервер на том же сервере, где стоит SQL-сервер, и проверю еще раз, чтобы точно убедиться. Возможно, что это какой-то баг в 64-хбитной версии сервера 1С:Предприятия 8.1.15.14.
Еще попробую зацепиться теперь к загруженной базе через сервер 1С:Предприятия, который установлен на сервере (на который есть подозрения, что он глючит) - посмотрю - будет ли он крокозябрить базу, или нет...
Попробовал загрузить базу в постгре, который стоит локально на моем компьютере (который под Windows XP) через сервер 1С:Предприятия, который установлен на сервере - тоже вышла ошибка - косяк явно в сервере 1С:Предприятия!
В общем - теперь уже точно выяснилось, что база нормально загружается через 32-хбитный сервер 1С предприятия. При чем - загружается только в Postgre, в MS SQL выдает все ту же ошибку хоть под 32-хбитной версией сервера 1С предприятия, хоть под 64-хбитной.
Теперь вот какой вопрос встал передо-мной: можно ли как-то в файловом режиме в 1С сделать запрос по внутренним (системным) именам таблиц базы данных (а именно к таблице _Documen133_VT3144, чтобы посмотреть - что там за неуникальные значения ключевых полей)? - возможно ли это вообще?
Посмотрел, в каком виде в постгре выводится значение поля _Document133_IDRRef - выводится оно вот в таком виде "\256\265\000\032MM\001\001\021\335\361\331\365N#{" и как в это значение преобразовать "0xa109001a4d4d010111dcaef25b8f25a2" - пока ума не приложу.
И вот еще какой вопрос возник, уважаемые коллеги: а есть ли у кого-нибудь готовая 64-битная сборка PostgreSQL? На сколько я понял - сборка postgresql-8.3.8-1.1C 32-хбитная?
Теперь вот какой вопрос встал передо-мной: можно ли как-то в файловом режиме в 1С сделать запрос по внутренним (системным) именам таблиц базы данных (а именно к таблице _Documen133_VT3144, чтобы посмотреть - что там за неуникальные значения ключевых полей)? - возможно ли это вообще?
Посмотрел, в каком виде в постгре выводится значение поля _Document133_IDRRef - выводится оно вот в таком виде "\256\265\000\032MM\001\001\021\335\361\331\365N#{" и как в это значение преобразовать "0xa109001a4d4d010111dcaef25b8f25a2" - пока ума не приложу.
И вот еще какой вопрос возник, уважаемые коллеги: а есть ли у кого-нибудь готовая 64-битная сборка PostgreSQL? На сколько я понял - сборка postgresql-8.3.8-1.1C 32-хбитная?
Нарыл, наконец-то - как нужно правильно написать запрос - может, кому пригодится:
Выдал мне действительно 2 совершенно идентичных строки.
SELECT *
FROM _document133_vt3144
WHERE encode(_document133_idrref, 'hex') = 'a109001a4d4d010111dcaef25b8f25a2';Выдал мне действительно 2 совершенно идентичных строки.
Пришлось написать вот такой запрос для постгре для удаления одной из повторяющихся строк:
DECLARE cursor1 CURSOR FOR SELECT * FROM _document133_vt3144 WHERE encode(_document133_idrref, 'hex') = 'a109001a4d4d010111dcaef25b8f25a2';
FETCH FORWARD 1 FROM cursor1;
DELETE FROM _document133_vt3144
WHERE CURRENT OF cursor1;
(25)
и как в итоге? всё полечилось?
возможно, что прокатил бы способ найти-таки этот документ реализации и просто попробовать его перепровести, или отпровести или удалить, в конце концов.
способы с непосредственными запросами тож обычно прокатывают, но имхо, чуть более геморойнее
и как в итоге? всё полечилось?
возможно, что прокатил бы способ найти-таки этот документ реализации и просто попробовать его перепровести, или отпровести или удалить, в конце концов.
способы с непосредственными запросами тож обычно прокатывают, но имхо, чуть более геморойнее
(27)
полноценно чтение и запись? фиг...
можно вычислить, конечно, какой док, какая ссылка, но вот писать инсёрты и делейты можно только каким-либо движком. В случае sql-базы - средства sql, а в случае 1С - только чтение, но не запись.
Хотя, если читать вот это ( и мож кто и сподобился какой-нить типа редактор сделать..
полноценно чтение и запись? фиг...
можно вычислить, конечно, какой док, какая ссылка, но вот писать инсёрты и делейты можно только каким-либо движком. В случае sql-базы - средства sql, а в случае 1С - только чтение, но не запись.
Хотя, если читать вот это ( и мож кто и сподобился какой-нить типа редактор сделать..
Кстати, вспомнил - документ этот перепроводил (даже несколько раз), как раз в той базе, в которой потом удалял дублирующуюся строку в постгре - после перепроведения документа дублирующаяся строка в таблице не исчезла, так что перепроведение документа не исправляет ошибку.
Я бы мог сподобиться и написать редактор, но времени на это сейчас нет - а так - инструмент был бы полезным. Было бы здорово, если бы, фирма 1С сподобилась на это дело - у них же все есть для этого - исходники движка, и все прочее.
romansun, спасибо огромное за обработку - посмотрю обязательно.
И всем огромнейшее спасибо за внимание к моей проблеме и за участие в ее решении.
dvv01, спасибо огромнейшее за совет - пригодится. Дело в том, что в данном случае ситуация была не с датой (иначе, на сколько я понял, должна была помочь установка смещения дат для MS SQL) - и скуль бы ругался на неуникальное значение поля типа 'Date'. Здесь же он ругается на поля другого типа, поэтому смещение дат не помогло.
И всем огромнейшее спасибо за внимание к моей проблеме и за участие в ее решении.
dvv01, спасибо огромнейшее за совет - пригодится. Дело в том, что в данном случае ситуация была не с датой (иначе, на сколько я понял, должна была помочь установка смещения дат для MS SQL) - и скуль бы ругался на неуникальное значение поля типа 'Date'. Здесь же он ругается на поля другого типа, поэтому смещение дат не помогло.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот