Восстановление по УИД #658251

Коллеги, добрый день. Я тут разбираюсь с проблемой задвоиности индексов, нашел таблицу проблемную, по сути в ней задовоиности нет, просто платформы пытается вставить не уникальное значение в индекс. Ну не в этом  дело, смотрю значения этой таблицы: Я так полагаю, что (поле kref) 0xA075001EC9EBA4BC11DFFD4159868477 это УИД?, как его можно восстановить что бы понять, что этой за значение? Хотя длина УИД 32 символа, здесь 34.

Сам то понял, что спросил?

нет

0x - это не символы.

И A075001EC9EBA4BC11DFFD4159868477 - тоже не символы.

проверил - 32 естественно без 0x.

а что значит восстановить?

Да, точно: УИД A075001EC9EBA4BC11DFFD4159868477

Соответственно Уид: A075001E-C9EB-A4BC-11DF-FD4159868477

А что же это по вашему ?

Набор чисел.

И букав

ну в базе сделать Справочники.ВашСправочник.ПолучитьСсылку(Новый УникальныйИдентификатор("A075001EC9EBA4BC11DFFD4159868477")); или ваша задача теперь выяснить конкретно: какой справочник это или документ.

Ошибаешься

Там надо переставить значения предварительно.

если я напишу так: Соответственно Уид: Вам легче спать будет?

Ты ошибся при преобразовании записи в таблице в уникальный идентификатор... Если в таблице поле = 0xA075001EC9EBA4BC11DFFD4159868477, тогда УИД объекта будет 59868477-FD41-11DF-A075-001EC9EBA4BC

почему такое преобразование идет? Какой алгоритм преобразования? Это точно ?

Точнее не бывает

Пока ты не поймешь, от какой таблицы твой УИД - ты не найдешь запись по нему

в скл нет типа УИД 1совского

Есть

uniqueidentifier так то. Правда хранится это в binary, наверное для того, чтобы sql сам новые значения не хреначил.

А какие поля у твоей таблицы вообще есть?

я всмысле ты уверен что тип значения uniqueidentifier идентичен 1совскому типу УникальныйИдетификатор?

Вот запрос: SELECT [_Period]

Я уверен, ибо проверял и юзал.

Отключи Итоги по Регистру Бухгалтерии, обновись, включи итоги по регистру Бухгалтерии.

Я так понимаю, что вот эти поля, которые ты хочешь узнать: [_RecorderTRef] [_RecorderRRef]

У полей REF тип binary

Ну да

Нет, нет, нет. Я ошибся, перепутал _AccRgED с AccRgAT. Итогами это не вылечишь.

По ним завдоение индекса идет

RecorderTRef - номер документа. Преобразуй его в int (например, если у тебя там 0000018B, тогда значение будет = 395)... Потом ищи таблицу _Document[твой получившийся номер] и в ней делай запрос SELECT * FROM _Document[твой получившийся номер] WHERE _RRef = 0xA075001EC9EBA4BC11DFFD4159868477

Текст ошибки скажи.

При добавлении субконто на счет: exec sp_executesql N'INSERT INTO _AccRgED21756 (_Period, _RecorderTRef, _RecorderRRef, _LineNo, _Correspond, _KindRRef, _Value_TYPE, _Value_RTRef, _Value_RRRef) SELECT T1._Period, T1._RecorderTRef, T1._RecorderRRef, T1._LineNo, , @P2, @P3, @P4, @P5 FROM _AccRg21728 T1 WHERE T1._AccountDtRRef = @P6',N' numeric,@P2 varbinary,@P3 varbinary,@P4 varbinary,@P5 varbinary,@P6 varbinary',0,0xB44B334DE4C5D19D4D7785E8F75E7ABE,0x08,0x000000C5,0x00000000000000000000000000000000,0x805D33BC049644DC4E1DE44B2F91458C Вылетает: Msg 2601, Level 14, State 1, Line 1 Cannot insert duplicate key row in object 'dbo._AccRgED21756' with unique index '_AccRg21756_ByPeriod_TRNRN'. The duplicate key value is (Oct  2 4009 11:25AM, 0x000001d6, 0x8f5d001ec9eba4bc11deaf18dc2e7afa, 1, 0xb44b334de4c5d19d4d7785e8f75e7abe, 0). The statement has been terminated.

Делал запрос: SELECT _Period, _RecorderTRef, _RecorderRRef, _LineNo, _Correspond, _KindRRef, _Value_TYPE, _Value_RTRef, _Value_RRRef, Count(*) FROM _AccRgED21756 GROUP BY _Period, _RecorderTRef, _RecorderRRef, _LineNo, _Correspond, _KindRRef, _Value_TYPE, _Value_RTRef, _Value_RRRef HAVING Count(*) > 1 Завдоенности в самой таблице нет, просто идет попытка вставки значения, которое задваивает индекс

А что это за поля? ,[_Value_TYPE] ,[_Value_RTRef] ,[_Value_RRRef]

Значение субконто.

Посмотри, че за док Oct  2 4009 11:25AM сделал запись в РБ

Странно, что нет секунд

У меня такое ощущение, что в таблице остались записи от старого субконто "Статьи ДДС", сейчас его добавляю опять и потому идет задвоение. Не знаю уже что думать...

02.10.2009 в 11:25

Таких полно, почти на каждый регистартор ругается

А что тут думать - резервную копию - и delete from _AccRgED21756  where AccRgED21756 _KindRRef=0xB44B334DE4C5D19D4D7785E8F75E7ABE

delete from _AccRgED21756  where AccRgED21756. _KindRRef=0xB44B334DE4C5D19D4D7785E8F75E7ABE

Это что вы удаляете ?

Значения субконто для документов для ВидаСубконто "СтатьяДДС". Только убедитесь, что 0xB44B334DE4C5D19D4D7785E8F75E7ABE  - это точно СтатьяДДС. Отловите запрос ВЫБРАТЬ    1 КАК Поле1 ИЗ    ПланВидовХарактеристик.ВидыСубконтоХозрасчетные КАК ВидыСубконтоХозрасчетные в профайлере и убедитесь, что там _idref ваш.

Да, все верно: exec sp_executesql N'SELECT FROM _Chrc994 T1 WITH(NOLOCK) WHERE (T1._IDRRef = @P2)',N' numeric,@P2 varbinary',1,0xB44B334DE4C5D19D4D7785E8F75E7ABE Да вот только удаляться то все, у меня проблема с 57.1, нужно какой то условие добавлять на счет к этой таблице?

А причем тут счета?

Это тупо табличка значений субконт в разрезе документа.

Понял, сейчас на тесте попробую.

Вся аналитика слетела по Статье ДДС. Видимо все же нужен дополнительный отбор?

мммм, так.

Может по всем этим полям делать отбор, ну кроме периода конечно: (Oct  2 4009 11:25AM, 0x000001d6, 0x8f5d001ec9eba4bc11deaf18dc2e7afa, 1, 0xb44b334de4c5d19d4d7785e8f75e7abe, 0) ?

Вертаем пока табличку взад.

И отловим в профайлере такой запрос: ИЗ    РегистрБухгалтерии.Хозрасчетный.Субконто КАК ХозрасчетныйСубконто

Получим нечто подобное: exec sp_executesql N'SELECT FROM _AccRgED20737 T1 WITH(NOLOCK) WHERE T1._RecorderTRef + T1._RecorderRRef IN (SELECT T2._RecorderTRef + T2._RecorderRRef AS Q_001_F_000CRef FROM _AccRg20709 T2 WITH(NOLOCK) WHERE ((T2._AccountDtRRef = @P2) OR (T2._AccountCtRRef = @P2))) AND (T1._KindRRef = @P3)', N' numeric(1,0),@P2 varbinary,@P3 varbinary', 1, 0xA36F5219F3882D59474C2B8DF0E06657, 0xA2D9EF0AD9924E764E73FB1C43E874EE

И заменим Select на Delete

exec sp_executesql N'DELETE FROM _AccRgED21756 T1 WITH(NOLOCK) WHERE T1._RecorderTRef + T1._RecorderRRef IN (SELECT T2._RecorderTRef + T2._RecorderRRef AS Q_001_F_000CRef FROM _AccRg21728 T2 WITH(NOLOCK) WHERE ((T2._AccountDtRRef = @P2) OR (T2._AccountCtRRef = @P2))) AND (T1._KindRRef = @P3)', N' numeric(1,0),@P2 varbinary,@P3 varbinary', 1, 0x805D33BC049644DC4E1DE44B2F91458C, 0xB44B334DE4C5D19D4D7785E8F75E7ABE Так?

Такую вот ошибку выдает: Msg 1087, Level 16, State 1, Line 2 Must declare the table variable "@P1".

Ну что же ты. exec sp_executesql N' delete FROM _AccRgED20737 WHERE _AccRgED20737._RecorderTRef + _AccRgED20737._RecorderRRef IN (SELECT T2._RecorderTRef + T2._RecorderRRef AS Q_001_F_000CRef FROM _AccRg20709 T2 WITH(NOLOCK) WHERE ((T2._AccountDtRRef = @P2) OR (T2._AccountCtRRef = @P2))) AND (_AccRgED20737._KindRRef = @P3)', N'@P2 varbinary,@P3 varbinary', 0xA36F5219F3882D59474C2B8DF0E06655, 0xA2D9EF0AD9924E764E73FB1C43E874EE

некорректно. могут быть удалены  не те данные

Например?

Ты это 1С-ке скажи.

Михаил, что там с не теми данными?

пример

Передай это в 1С. Я серьезно.

не припомню ,что бы мы на "ты" переходили

Здесь, на форуме - можно.

лицензионным соглашением запрещено влезать не средствами платформы. Если передаст в 1с, его в черный список занесут.

Даже профайлер запрещен?

Планы запроса разрешено смотреть, даже в тех журнале можно, норм всё

Ничего подобного, я обращался в 1С по поводу задоиности индексов, вот их ответ: Протестируйте вашу базу до попытки вставки субконто. Попробуйте выгрузить базу в dt (если возможно) и загрузить ее в файловую версию, протестировать ее там и добавить субконто. Другой способ - внести изменения в таблицу MS SQL Server Определить имя проблемной таблицы можно с помощью SQL Trace или технологического журнала, если включить в него запись событий EXCP со всеми свойствами. Включите дополнительно запись событий DBMSSQL. Для этого нужно добавить: </event> Конфигурационный файл нужно положить на компьютер, где установлен сервер 1С:Предприятия 8. Смотреть результаты в подкаталоге rphost_ХХХ. Например, </config> В журнале должна присутствовать запись события DBMSSQL с текстом CREATE UNIQUE INDEX .... По ней можно определить таблицу, в которой есть дублированный ключ. Нужно найти продублированные записи и удалить лишние. Например, Ошибка произошла пм создании этого индекса : create unique clustered index [_InfoR18755_ByPeriod_TRS] on [_InfoReg18755] (_Period, _Fld18756RRef, _Fld18757) Запрос SELECT _Period, _Fld18756RRef, _Fld18757, Count(*) FROM _InfoReg18755 GROUP BY _Period, _Fld18756RRef, _Fld18757 HAVING Count(*) > 1 выдаст список записей, которых в базе больше одной по этому ключу. ----------------- Это говорит о том, что они официально разрешают влазить в БД

Сейчас попробую этот запрос, отпишусь

Да, удаление помогло, единственное что, у корр счета тоже аналитика слетает в части статей ДДС: Ну да ладно, заполнить не проблема. Единственное НО, я не знаю как поведет себя база в дальнейшем, это же внесение изменений в физические таблицы базы уже. Если честно как то не очень хочется влазить в рабочую уже базу. Написал запрос в 1С, что они скажут, посмотрю. Но что самое странное, вообще запрещено действительно влазить в БД не средствами платформы, хотя они же сами и рекомендуют это сделать.

для испарвление ошибок - рекомендуют, а работа повседневная - это нарушение

Есть Convert(binary,NEWID)