Возможно ли изменение ROW_ID? #344427

Всем доброго времени суток. Проблема в следующем: Есть НЕстандартная конфигурация 1С и большая база (~25 гиг) на SQL. Из конфигурации удалили один вид документа (таких документов в базе не существовало никогда). При обработке изменений, 1С проверяла наличие ссылок на этот вид документа, но так как эта процедура длительная, пришлось ее отменить (путем снятия задачи конфигуратора и удаления файла  1srecalc.cmd). Внимание вопрос:  Могли ли измениться значения row_id в таблице _1sjourn из-за описанной выше процедуры? Если нет, то из-за чего могли? Спасибо.

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

Уверенность возникла из следующих заключений: - первый раз задача конфигуратора была снята через 1,5 часа после начала проверки, при попытке зайти в базу, 1С попросила режим конфига и досчитать. - при запуске конфигуратора он начал производить поиск ссылок и за 30 минут не проверил и одного регистра, точнее не проверил даже его половины. плюс в профилере 1С постоянно вызывала sp_cursorfetch параметры сейчас к сожалению не вспомню. Опустим упоминание о "этапе поиска ссылок", вопрос остается в том же виде:

прерывание работы произвелись после нажатия на кнопочку "принять", плюс - содержимое restruct.log Анализ изменений в структуре информации. Generating new SQL DD... Генерация структуры SQL базы данных New DDSQL open process... Old DDSQL open process... DB open access... Обработка справочника:  Подразделения Изменена последовательность документов: Основная Обработка журнала документов. Create Doc Journal Table [skip] Документ ПриходованиеУслуг, реквизит Клиент - изменен тип. Обработка  шапки документа: ПриходованиеУслуг Документ ПриходованиеУслуг - изменен состав отбора, журнала или подчинения документа [skip] Новый документ - Ремонт. Обработка  шапки документа: Ремонт Обработка  табличной части документа: Ремонт Документ Заправка - удален. Create _1SCRDOC_NEW table [skip] Meta Data File write progress... Meta Data File write complete... Copy new files to main directory progress... Drop old tables and rename newly created... Drop old procedures... Create new procedures... Copy Recalc file Copy SQL Data dictionary file Copy MetaData file Copy new files to main directory complete... Delete table CJPROP Delete table CL Delete table DH1983 Delete table DT1983

MDMigrDel 1983       DELTYPE   121983      0

Насколько я знаю, row_id в таблице _1sjourn вообще никогда не меняются. Незачем

>>Уверенность возникла из следующих заключений: Ипать-колотить... чего прицепился именно к row_id? а iddoc не поменялись, может они поменялись а не row_id? :)

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

Изменение iDDOC - страшнее чем ров_ид, хочется верить в лучшее

+

Кто придумал привязываться к row_id? Ты в курсе что он может поменяться например при реструктуризации? Это просто колонка identity А что прервал - конечно идиот У нас на точке грузанули сервак, подумали что завис (а шел обмен УРБД) - база ушла в суспект (такие же идиоты, мля нету слов)

+ Даже если бы не прерывал  - все равно бы данные поменялись, этим можно утешиться... бугога Ответственность можно переложить на ламеров которые его юзали

Так я не понял оно меняется или нет. Row_Id может поменяться при любой реструктуризации? "А что прервал - конечно идиот" - как посмотреть, непрерывное производство + продукция скоропорт, три-четыре часика на солнышке и все... А на такой базе оно бы часов за 10 закончило бы (при самых лучших раскладах) Да знаю базу надо резать.

Произошло следующее: 1. Была создана новая(!) таблица _1sjourn; 2. Скопированы данные из _1sjourn.old в _1sjourn.new; Но так как row_id identity-поле, то записи по этому полю перемешались. Это норальное поведение для 1с. Фактически поле row_id не является ключевым для 1с.

Экспериментальным путем выяснено, row_id меняется при реструктуризации таблицы журнала, независимо от корректности окончания выполнения действий описанных в файле "1srecalc.cmd". Всем спасибо за внимание. Особенное Спасибо Кириллке.

ОК. То есть я как бы непонятно объяснил :) Меняется ров_ид НЕ ПРИ ВСЯКОЙ реструктуризации журнала (например) Если удалить общий реквизит например - все будет нормально (вроде как)

Непонятно зачем 1С чешет курсорами... ведь можно ускорить многократно запросом