Ошибка неуникального индекса #561163

Переносим базу с 8.1 (функционирует уже несколько лет) на 8.2. Сделали копию центральной базы, конвертнули. Дальше нужно создать периферийную (для одного из подразделений), но при создании начального образа периферийной базы получили ошибку 80040e2f. Внимательное чтение не сильно помогло. Ругается на объект dbo._Const14797 - выяснили, что это константа (тип - хранилище значений). Изменение ее типа на строку не помогло - те же яйца, только вид в профиль. При этом в обеих базах на 8.1 никаких сбоев не наблюдается, да и центральная база на 8.2 выглядит работоспособной. Как избавиться от ошибки?

есть по этой константе что нить - индексировать, полнотекстовый поиск?

полнотекстовый поиск в базе не хранится...

спс, не знал, пока не интересовался )

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

кто что добавит на свежую голову?

удали эту константа из планов обмена. всех

да я думаю - она и в конфигурации не сильно нужна - всего 3 упоминания нашел :-)

я думал ты разобраться хочушь

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

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

сохранение ЦФ-ника проходит нормально?

в этой базе не пробовал, но в той, из которой она получилась (через хранилище) - сохраняется без проблем, так что конфигурация вроде живая. правда, ТиИ выдало протокол на 13Мб (почему-то оно не началось с начала, а продолжилось с 55%, хотя я ранее его не запускал - возможно, напарник пытался когда-то еще в старой базе), но даже после этого ошибка устойчиво повторяется. А как можно определить объект метаданных по имени таблицы в SQL? скачал с инфостарта одну обработку, но почему она указывает на эту константу, если я удалил ее из конфигурации - я не понимаю. щаз попробую план обмена проверить...

зашел только что в планы обмена (в режиме предприятия) - вижу, что номера принятого/отправленного сообщения - 303, хотя при предыдущей попытке создания образа там было 319 (даже скриншот есть). мысли вслух: а если напарник не настроил новые пути к папкам обмена - может файл от другого обмена валить создание образа новой базы?

о, теперь на другую константу ругается. щаз буду ее удалять и еще раз пробовать...

у-у-у-у, теперь ругается на константу Const14802, но самое интересное, что обработка ПросмотрСтруктурыБазы1С (взял с инфостарта и конвертнул в 8.2) не знает ничего об этой константе...

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

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

хорошо бы сказать что за сервер БД... чтобы не брать такого. :)

мелкософтовский (хотя это очевидно из ), 2005-й...

блин, мож сервис-паков не хватает?

SQL Server 2005    требуется установка пакета обновлений 3 (SP3)

индексы погрохай

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

ты чо, Хауса не смотрел? админ ему клянется SQL Server 2005 RTM    9.00.1399 SP3 - это он наверное про Винду говорит

"с другой стороны, на этом же серваке вроде крутятся другие базы... " эти базы тоже 8.2?

нет - только 8.1, да и то - не "крутятся", а "созданы" (под горячий резерв). мужик толковый, вряд ли перепутал. просто сервака два, на втором - действительно SP4 (9.00.40xx), а здесь за ненадобностью забыли обновить. в общем - жду, пока админ обновит сервак...

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

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

на другом сервере SQL та же фигня. неужели придется ждать 8.2.15?

о да... и как это остальные работают с этой конфой

конфа наша - УПП 1.1 с дорощенным CRM и кучей местных прибабахов. но на 8.1 работают без проблем и центральная, и периферийная, и в 8.2 центральная база конвертнулась, и в моей рабочей (8.2) копия текущей оперативной базы тоже работает (там я добиваю новый налоговый кодекс из типовой УПП 1.3), но при создании начального образа периферийной базы - проблема. самое интересное, что в файловую версию начальный образ выгрузился, но попытка всосать его в серверную наткнулась на ту же ошибку. почему в центральной базе ошибка не проявляется? почему в файловой периферийной не проявляется? почему ошибка проявляется только при создании начального образа в серверную периферийную?

или ты имел в виду не "конфой", а "платформой"? просто меня такое специфическое проявление ошибки ставит в тупик.

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

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

да плевать на итерации. Нет ни разрядности сервера 1С, ни например как ты ловишь с помощью ТЖ в какой именно момент что валится, ни например попытки повторить тоже самое на другой СУБД - хотя бы 2008 МС СКЛ сервер, если нет ДБ2 9.7.1 или Постгре

Вот например читай: это происходит только на 32-битном сервере, на файловой или 64-битном сервере - не происходит

1с - сейчас 32-разрядный. планировали использовать 64-разрядный, но он не взлетел. ТЖ не настраивал, но по имени таблицы в сообщении об ошибке пытался определить (обработкой с инфостарта ПросмотрСтруктурыБазы1С - написана для 8.1, я конвертнул ее на 8.2) объект метаданных, на который Скуль ругался - устойчиво на одной из констант (правда, уже получал 4 разных имени таблицы - но в перерывах между попытками и базу новую создавал, и реструктуризацию проводил, и первую константу, на которой затык произошел, удалял из конфигурации). теоретически - может действительно проблема в оперативке: на этом "сервере" 1С всего 4Гб, но сейчас есть свободных 1,8Гб, в течении дня этот объем скорее всего изменялся и в меньшую, и в большую стороны, но валится выгрузка примерно в один и тот же момент. сейчас попробую повторить эксперимент на другом сервере.

"правда, уже получал 4 разных имени таблицы "ты видешь в дата-студио или дата менеджер, не знакю как в МС СКЛ это называется - есть ли она такая в таблице констант?

сервер 1С рестартует каждую ночь по заданию (перед выполнением обмена центральной базы с периферийной). о, админ помог подготовить эксперименты на другом серваке 1С - там 16Гб оперативки, да и нагрузка на него меньше - по идее, не должен упереться в недостаток памяти. вижу, конечно. каждую из 4 :-) (не из головы же Скуль ее имя берет). Точнее, в центральной - видел, в периферийной - не всегда проверял. фикус-пикус в том, что база в один из экспериментов была пустая - то есть данные не могли мешать создать уникальный индекс.

попробуйте тогда все-таки с МС СКЛ 2008

скачать Експресс можно с МС сайта, ограничение на базу 10 Гиг.

хорошая идея, но у нас сейчас размер базы около 14Гб. То есть с пустой базой эксперимент провести сможем, а перейти на новую платформу, если он окажется удачным - не сразу (пока сисадмин не поставит полноценный 64-разрядный 2008-й Скуль).

попробовал повторить эксперимент на другом сервере 1С (тоже 32-разр.) при старте процесса создания начального образа размер свободной памяти - 7,118Гб, при вываливании ошибки - 6,940. Не похоже, чтоб кому-то не хватило оперативки. в системном журнале ничего плохого Скуль не сказал. есть где-то ФАК по настройке ТЖ, о котором рассказывает Гилев?

не, я  даже и не думал что из-за оперативки. Это я просто привел как пример "почему в центральной базе ошибка не проявляется? почему в файловой периферийной не проявляется? почему ошибка проявляется только при создании начального образа в серверную периферийную?" то есть нюансы могут быть... Лучший ФАК - это обработка с ИТСа для настройки конфигурационного файла.. и там же (на ИТС) вроде есть простенькая инструкция

пасиб! жаль только, что ближайший (первый на этом месте) ИТС прибудет к нам только через 2 недели... буду искать у друзей... о, уже у преемника на прошлой работе нашел.

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

2 это сделано специально чтобы отсеивать 1Сников у которых не хватает способностей абстрагироваться от своей рабочей базы, чтобы понять, что можно ее открыть в управляемом режиме в файловом варианте УНФ, там создать файл настойки, который потом положить для сервера... Такое вот своеобразное повышения порога вхождения...

ставишь любую файловую базу, (например есть готовая - УНФ для Украины, была на каком-то диске ИТС полная установка или пустую - но чтобы она открывалась в режиме с возможностью открывать управляемые формы) и открываешь эту форму. Готовишь файлик. записываешь его куда-то, копируешь на сторону сервера так как написано в инструкции, вуаля - пожинаешь сотни метров ТЖ... открываешь их бродишь по ним... потом тебя постигают какие-то идеи о том как из сотен мегабайтов сделать хотя бы единицы.. Открываешь файлик настройки заново, ставишь фильтры на базу, на события сиключения, на контекст исключений, смотришь, опять сохраняешь, опять копируешь на сервер, удалив предварительно предыдущие ТЖ.. ловишь опять... и так далее...

напомнило анекдот про шампунь для программистов: "нанести на волосы, вспенить, смыть, повторить..." ЗЫ: файловая есть - типовые Бух и УПП. Пасиб, едем дальше... (кроме перехода на 8.2 - приходится еще юзеров в существующей системе на 8.1 консультировать...)

глупо лезть сейчас с 8.2.14 попробуй 8.2.13.219

дык вроде не зря окончательный выпуск 8.2.14 на месяц задержали - может успели все баги вычистить. к тому же - пока не слышал, что в ней кто-то наткнулся на грабли (хотя сам не люблю самые свежие релизы). а у нас проблема, похоже, где-то в конфе, но не в платформе...

последние 3 строки ТЖ: 31:36.6120-116,DBMSSQL,1,Sql="exec sp_executesql N'SELECT Creation,Modified,Attributes,DataSize,BinaryData FROM Config WHERE FileName = ', N' nvarchar', N'd41e87be-c953-40cf-9380-330ebbbf2e0b.0'" 31:36.6126-1,DBMSSQL,2,Sql='SELECT T1._Fld14790 FROM _Const14789 T1 WITH(NOLOCK) WHERE T1._RecordKey = ? p_0: 0x31 ' 31:36.6133-1,DBMSSQL,2,Sql='SELECT T1._Fld14790, T1._RecordKey FROM _Const14789 T1 WITH(NOLOCK)' 1) чем мне может помочь UUID N'd41e87be-c953-40cf-9380-330ebbbf2e0b.0'"? 2) имя объекта метаданных по имени таблицы SQL я сопоставить могу, но что мне делать с этой информацией, если речь идет о числовой константе "ИнтервалПроверкиНапоминанийВСекундах", значение которой в центральной базе установлено в 60 сек, а в периферийную не переносится (во всяком случае - в созданной базе это значение не установлено)?

я бы поисследовал Config - посмотрел бы что в ней за записи у которых поле Pl подобно 'd41e87be-c953-40cf-9380-330ebbbf2e0b.0'

попробовал бы их жахнуть... : ) например.. в копии конечно

да у меня это и так пока что тестовая база, так что жахнуть - не проблема! :-) понимать бы, чем эта безобидная константа 1Сине не понравилась... и почему она должна быть уникальной... ЗЫ: Config - я так понимаю - это имя таблицы SQL? щаз гляну...

попытка жахнуть успехом не увенчалась - та же ошибка на следующей таблице (константе). что-то тут не слава богу... продолжим эксперименты завтра...

упс, в таблице Config у всех объектов дата создания стоит 4011-07-27 (27 июля 4011 года). не здесь ли собака порылась? если я центральную базу создавал со смещением 2000 - может периферийную нужно создавать со смещением 0? завтра проверю...

кстати, объекта с FileName d41e87be-c953-40cf-9380-330ebbbf2e0b.0 там нет - есть почти такой (d41e87be-c953-40cf-9380-330ebbbf2e0b), без ".0" на конце...

Таблица констант в в8 - это плоская таблица с одной единственной строкой. Каждая константа, объявленная в конфигураторе является ячейкой (колонкой) в этой единственной строке таблицы констант...

2 ну что-то там со смещениями дат... и 2000 - я просто с МС СКЛ не очень

а у меня выходит каждой константе соответствие таблице ConstXXXXX через это мы тоже прошли - пришлось создавать центральную базу еще раз. но вчера я заметил, что в центральной базе в таблице Config даты создания и модификации таблиц датируются 2011-м годом, а в периферийной (которую я создавал из центральной созданием начального образа со смещением 2000) - 4011-й год. вот сейчас попробую периферийную создавать со смещением 0.

2"а у меня выходит каждой константе соответствие таблице ConstXXXXX" хм... может быть это как раз отличие 14-го релиза?

в таком случае я только удивлюсь "о да... и как это остальные работают с этой конфой" :-)

похоже, что ты прав: при попытке войти в центральную базу клиентом 8.2.13 получил ошибку SDBL "В базе данных нет таблицы с именем Consts"... перевариваю информацию...

... а пока запустил ТиИ в конфигураторе 8.2.13...

попробуй тогда развернуть тестовую на 8.2.13, загрузи ДТ-шник, создай образ и только потом сконверти их в 8.2.14

да, админ уже активировал 8.2.13 (он успел поставить ее до того, как руководство приняло (утвердило) решение переходить на 8.2, но потом вышла 8.2.14, и он по моей просьбе поставил и настроил ее). щаз буду загружать ДТшник. упс - исключительная ошибка во время ТиИ. видимо - придется заново создавать базу.

ну вот и все - в 8.2.13 периферийная база создалась без вопросов. что и требовалось доказать. блин, почти 2 недели - псу под хвост.