Нарушена структура таблицы #646077

Доброе время суток. С прошедшим, всех, Новым Годом. :) Итак, предыстория. Стоял у нас 1С сервачок. Как-то раз он взял и навернулся, то бишь аварийно выключился, соответственно по-нормальному не завершив все свои 1С и SQL операции. С винтов вытащили базу 1С и базу SQL. Путем хитрых махинаций я смог вогрузить восстановленную базу на новую SQL. Но при запуске 1С в обычном режиме выдается - "Доступ к базе данных на сервере возможен только из одного каталога информационной базы". Стал копать дальше, перерыл весь гугл, перепробовал множество способов по решению данной проблемы. В итоге нашел что проблема может быть в _1SCONNECT, а точнее в ней и есть проблема. Нагуглил такой код: EXEC sp_configure 'allow updates', '1' RECONFIGURE WITH OVERRIDE GO update sysobjects set name='dummy' where name='_1sconnect' GO EXEC sp_configure 'allow updates', '0' RECONFIGURE WITH OVERRIDE GO GO EXEC sp_configure 'allow updates', '1' RECONFIGURE WITH OVERRIDE GO delete from sysobjects where name='dummy' GO EXEC sp_configure 'allow updates', '0' RECONFIGURE WITH OVERRIDE GO Потом еще разок прошелся DBCC CHECKDB. Теперь эта ошибка про "Каталог базы данных" не появляется, теперь "Нарушена структура таблицы SC746". Всё, на этом я встал. Что делать теперь? =(

Доброе время суток. С прошедшим, всех, Новым Годом. :) Итак, предыстория. Стоял у нас 1С сервачок. Как-то раз он взял и навернулся, то бишь аварийно выключился, соответственно по-нормальному не завершив все свои 1С и SQL операции. С винтов вытащили базу 1С и базу SQL. Путем хитрых махинаций я смог вогрузить восстановленную базу на новую SQL. Но при запуске 1С в обычном режиме выдается - "Доступ к базе данных на сервере возможен только из одного каталога информационной базы". Стал копать дальше, перерыл весь гугл, перепробовал множество способов по решению данной проблемы. В итоге нашел что проблема может быть в _1SCONNECT, а точнее в ней и есть проблема. Нагуглил такой код: EXEC sp_configure 'allow updates', '1' RECONFIGURE WITH OVERRIDE GO update sysobjects set name='dummy' where name='_1sconnect' GO EXEC sp_configure 'allow updates', '0' RECONFIGURE WITH OVERRIDE GO GO EXEC sp_configure 'allow updates', '1' RECONFIGURE WITH OVERRIDE GO delete from sysobjects where name='dummy' GO EXEC sp_configure 'allow updates', '0' RECONFIGURE WITH OVERRIDE GO Потом еще разок прошелся DBCC CHECKDB. Теперь эта ошибка про "Каталог базы данных" не появляется, теперь "Нарушена структура таблицы SC746". Всё, на этом я встал. Что делать теперь? =(

Доброе время суток. С прошедшим, всех, Новым Годом. :) Итак, предыстория. Стоял у нас 1С сервачок. Как-то раз он взял и навернулся, то бишь аварийно выключился, соответственно по-нормальному не завершив все свои 1С и SQL операции. С винтов вытащили базу 1С и базу SQL. Путем хитрых махинаций я смог вогрузить восстановленную базу на новую SQL. Но при запуске 1С в обычном режиме выдается - "Доступ к базе данных на сервере возможен только из одного каталога информационной базы". Стал копать дальше, перерыл весь гугл, перепробовал множество способов по решению данной проблемы. В итоге нашел что проблема может быть в _1SCONNECT, а точнее в ней и есть проблема. Нагуглил такой код: EXEC sp_configure 'allow updates', '1' RECONFIGURE WITH OVERRIDE GO update sysobjects set name='dummy' where name='_1sconnect' GO EXEC sp_configure 'allow updates', '0' RECONFIGURE WITH OVERRIDE GO GO EXEC sp_configure 'allow updates', '1' RECONFIGURE WITH OVERRIDE GO delete from sysobjects where name='dummy' GO EXEC sp_configure 'allow updates', '0' RECONFIGURE WITH OVERRIDE GO Потом еще разок прошелся DBCC CHECKDB. Теперь эта ошибка про "Каталог базы данных" не появляется, теперь "Нарушена структура таблицы SC746". Всё, на этом я встал. Что делать теперь? =(

ошибка появляется при старте конфигуратора?

С новым годом тебя, друг!!! Нафиг ты полез в таблицы, надо было просто переименовать каталог базы данных, зайти в базу, а потом при желании вернуть старое имя каталога. А сейчас уже все просто: "нарушена структура таблицы" значит нарушена. Сделай копию базы и в нее попробуй загрузить ее же мд-шник. Хотя вряд ли, канеш поможет. Делай все только на копии базы.

aka AMIGO> нет, в конфигуратор спокойно заходит. МастерВопросов> а у неё свой мд-шник и стоит. Сейчас попробую всё заного, только с дальнейшим переименованием базы. Мне просто папку переименовать и всё? =)

а ТИИ не пробовал? или перенести мд-шник в пустую базу.. там может появиться правильный SC746

Прошу прощения, но это не 1Совская конфигураторская штука которая сканирует базу и исправляет найденные в ней ошибки?) Если да, то пробовал. И кажется вылетела она у меня с ошибкой, не помню, честно... Вот тут кстати чуток детально расписал проблему -

ТИИ = Тестирование И Исправление, режим конфигуратора 1С

Запустил ТИИ. Спустя минуту-две выдал такое вот сообщение: Native: 0 Message: [Microsoft][ODBC SQL Server Driver]Числовое значение выходит за пределы допустимого диапазона.

Подозреваю, что в архиве базы не хранился МД-файл. Теперь в архиве одна структура, а МД-шник от другой версии, вот и разная структура. Так? В файле DDS описана структура таблиц, которая отличается от структуры метаданных в MDS (для файловой базы это DD и MD).

ОФФ: Беда коль сапоги начнет тачать пирожник... Ошибки помнить не надо. Достаточно сделать скриншот или в блокнотик забросить.

Начинай заново и возьми для сравнения ближайший архив.

Файлы базы 1С как лежали раньше до упада сервера, так и сейчас лежат. Мы их не трогали вообще. Никуда не перемещали.

Сейчас я сделал всё заново, показывает снова "Доступ к базе данных на сервере возможен только из одного каталога информационной базы". Что об этом вы можете сказать?

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

В некоторых случаях при запуске 1С:Предприятия появляется сообщение об ошибке:"Доступ к базе данных на сервере возможен только из одного каталога информационной базы!". Причиной появления такого сообщения может являться нештатное завершение работы 1С:Предприятия на одном из рабочих мест. Иногда в этом случае не закрывается соединение с БД на SQL Server и при попытке повторного или нового подключения пользователя к информационной базе (при условии, что к БД никто не подключен, т.е. этот пользователь - первый) появляется такое сообщение. Проблема решается следующим образом: 1. С помощью монитора пользователей убедится, что с информационной базой никто не работает. 2. Запустить Enterprise Manager SQL Server и закрыть "зависшее" соединение (Kill process). 3. Средствами операционной системы убедиться,что файл в каталоге информационной базы "1Cv7.$ui" никем не открыт. Если существуют пользователи открывшие этот файл, то следует выполнить отключение  доступа (Disconnect) пользователей от данного файла. 4. Запустить 1С:Предприятие. Источник

Вот еще из яндекса )) Диагноз: Такая ошибка возникает при попытке загрузить версию 1С для SQL после того, как один из пользователей некорректно вышел из системы. В редких случаях эта ошибка может быть результатом некорректной установки конфигурации. Анамнез: После закрытия 1С на сервере NT освобождаются ресурсы, которые занимал пользователь. Однако в случае некорректного завершения работы не останавливается SQL-процесс, запущенный пользователем. Рецепт: Принудительно остановить SQL-процесс можно с помощью SQL Enterprise Manager. В нем все активные процессы перечисленны в ветке “ManagementCurrent ActivityProcess Info”. Надо найти в списке справа процесс, который мешает Вам жить, выделить его и в меню “Action” выбрать пункт “Kill Process” Если пользователи работают по протоколу Named pipes, то можно просто закрыть файлы на SQL-сервере, открытые повисшим пользователем. Такие файлы имеют вид PIPEMSSQL$NAMEDSERVERSQLquery. Если вышеизложенное слишком сложно для Вас, Вы можете просто перегрузить SQL server. Надо только убедиться, что ни одна другая програма не использует его в этот момент. Если ошибка возникает постоянно, имеет смысл проверить правильность установки конфигурации: с одной базой данных на сервере пользователи должны работать из одного каталога с конфигурационными файлами. Иначе говоря, не могут одновременно работать две (даже идентичные) конфигурации, размещенные в разных каталогах и ссылающиеся на одну и ту же базу.

1. Создал новую базу в файловом режиме. Что теперь? 2. Пользователей нет, если только зависшие процессы во время падения сервера. Сами посмотрите. Разве тут есть что-то лишнее?

Что еще делал, кроме скриншота?

Ну, собсна думаю снова пересоздать _1SCONNECT и уже потом разбираться с таблицей SC746. После пересоздания - Таблица 746, что в ней не так? -

Посты и проигнорировал?

Так я вон чуток выше спросил что именно надо убить в процессах. Лично я ничего лишнего не нашел. =(

Убей ВСЕ процессы и перезагрузи сервер.

Хм, может я чего-то недопонимаю... Но во-первых не на всех процессах светится кнопка "Kill Process", а во-вторых на коих она светится - жму, ничего не происходит. Перезагрузил SQL - тож самое.

Очисти папки пользователей, в которых может валяться файл блокировки.

Удалил всё что нашел из *.lck - всё-равно ....

А теперь сравни эту табличку с ее описанием в файле DDS...Как тебе советовали в

я встретил такую ошибку у нас, когда главбушка переносила справочники из одной базы в другую методом копирования файлов. Вот такая продвинутая.. во второй базе (обе файловые) отсутствовали 2 реквизита справочника. Естественно, возникала ошибка сабжа, а главбушка шипела на меня, аки кобра (в Новый год).. пока я не узнал её метод переноса.. оррригинальный..

кто-то из предыдущих прогеров ей такую штуку показал, без подробностей, естественно. я правил этот dbf с помощью foxbase2.0.. работает..

Ребят, надеюсь всё-таки на вас, что я отдохну до 8 января, а не буду работать в праздничные дни :)) В общем вот, сравнение двух таблиц. Лично я чего-то не врубаюсь, схожие ли данные иль нет...

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

судя по твоему скрину - это PK_SC746 в DDS смотрел? есть там такой реквизит?

смотреть надо в файловом варианте - сохранить в скл - загрузить в дбф

Кстати, если ругается, что слишком большое число, то нужно просто посмотреть, что в таблице - SQL хранит целые числа в виде 4 или 8 байтов в упакованном виде, а 1С ожидает, что там строка, и возможна ситуация, когда запись в файле базы SQL-сервера побилась - для него ничего страшного не произошло, просто число стало очень большим, а вот 1С уже его переварить не в состоянии.

Так точно, этот PK_SC746 присутствует - "смотреть надо в файловом варианте - сохранить в скл - загрузить в дбф" - к сожалению не знаю как :( Я смотрю DDS через DDView. Torquader> это сканирование я делал до пересоздания _1SCONNECT. Сейчас в базу пускает, но "Нарушена структура таблицы SC746". Кстати кроме этого больше ничего не пишет, жму ОК - выкидывает.

У меня такое было когда я не так скуль настроил при установке :) читай внимтельно что скуль спрашивает когда его ставишь "Доступ к базе данных на сервере возможен только из одного каталога информационной базы".  это ошибка скуля

В режиме Конфигуратор выгрузить информационную базу. В файловой версии (помнишь пустую?) загрузить информационную базу.

лечится только переустановкой скуля на компе

это не поможет - у него с базой все нормально. это скуль.

Да чего ты заладил то, скуль да скуль. У меня там база 4ой редакции запустилась же, а вот 5ка не хочет. Да и  уже решил проблему пересозданием этой _1SCONNECT. До этого я делал запрос select * from _1SCONNECT и он тупо зависал. А щас пересоздал и норм, заходит. Теперь надо решить проблему именно с SC746.

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

какая конфа-то?

+100500

Бюджетка какая-нибудь военная

Конфа - Предприетие. "выгрузить в конфигураторе, запущенном в скл" - а это как понять, простите? :) Точнее как сделать? Конфигуратор (Enterprise Manager) SQL или 1С? Захожу в конфигуратор 1С, Администрирование - Выгрузить данные -

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

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

Дада, Бухгалтерия... Какие еще варианты будут? :(

МимохожийОднако> так я ж так и делаю, никуда не лажу, сразу в выгрузку...

выложи в обменник файл 1cv7.DD интересно, посмотрю, что у тебя там

SQL2000?

:)) тогда - отбой :)

1cv7.DDS

Вот, пожалуйста :)

Когда зайдешь в конфигуратор 1С. Открой конфигурацию, добавь в синоним пробел, потом убери. Появиться звёздочка. Нажми сохранить конфигуацию.Потом попробуй выгрузку снова.

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

получилось. снизу - наша бухия

никого не слушай... с текущи МД создаешь РЯДОМ НОВУЮ бузу, далее сравниваешь структуру таблицы старой и новой, обрати внимание на примари кей, по тому как обычно примари криво создается при ручных ковыряниях (в том числе и в _1SCONNECT). далее тебе нужно сделать средствами скуля переиндексаци.

угу, и vde не слушай, делай, как в :)

Сделал 53, см. скрины :( По порядку, как шли ошибки так и скринил.

мда.. придется тебе ждать, пока скл-гуру подтянутся..

скуль какой? скорее всего 2009 ??? там с патчами могут быть танцы... а вообще учитывая ошибку скуля - варианта только 2 1. я был прав с примари кей 2. в скуле есть ошибка - тогда лечить средствами скуля

SQL 2000. Повторюсь, было аварийное выключение сервера, то бишь всё как было включенным, как смогло сохраниться, так и сохранилось. Из этого состояния я и поднимаю снова базу.

пробуй средствами скуля чекдб (разумеется на копии)

DBCC CHECKDB? Уже делал.

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

Судя по третьему скрину. Не работает SQL с этой базой. Возможно, режим работы базы не тот. Надо смотреть свойства базы. Я в SQL не силен. Дальше подсказать не смогу. Можно попробовать файл SQL с данными положить в другое место и подключиться к новой базе.

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

(66+: или на "свеже-хрензнаеткак-поправленный"

Кто подменял MDшник то? Я вообще его не трогал, Господи ты Боже ж ты мой.... Махинации проводил я с SQL базой, а не с базой 1С.

не нервничай, до 8-го много времени.. потерпи малёк, скажут.. найдешь способ а пока будь с семьей :)

: структуру таблиц менять, значит.

Зачётный НГ у некоторых.

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

У нас сотрудники уже завтра хотели выйти на работу, благо 6ая и 4ая редакция работает, хоть в ней инфу добьют. А вот 5ка.... Ждем гуру =(

бэкапов, я чую, не делал никто?

не такое уж сложное дело написать системное задание на ночной бэкап. слёз на порядок меньше

да здесь я (кстати перечитал все), давай по порядку я озвучу ход своих мыслей 1. ты перенес базу на другой скуль? это так? каким методом переносил? 2. ты сделал DBCC CHECKDB, какие были сообщения и для каких баз ты это делал, после этого если в таблицах находятся дублирующие примари кей для нескольких записей - то у такой таблицы примари кей сбрасывается (отсутствует), по этому большая вероятность того что у тебя полно косяков с этим делом. Для тебя самый простой способ - это экспорт по таблично в новую базу средствами скуля 2. Ты пересоздал _1SCONNECT - нет никакой гарантии что она у тебя правильная, по этому правельнее ее вообще дропнуть, но по сколько у тебя есть шанс что в других местах дыры - лучше этого не делай. мой совет - скулевским экспортом потаблично гнать данные в новую пустую базу

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

Ребята, если навернулся файл базы SQL, то бишь не были записаны какие-то операции, то нужно разбираться с файлом базы SQL, то есть делать его копирование при остановленном SQL-сервере, и уже потом в копии пытаться делать тестирование и прочие операции. Пытаться запихнуть битый файл в 1С или что-то делать там с ним нежелательно, пока файл не будет восстановлен. Самое простое - попытаться выполнить SELECT COUNT(*) для всех таблиц базы, и посмотреть, на каких таблицах оно не выполняется. Удачи.

1. Перенес базу таким образом: Поднял новый SQL 2000, создал в нем новую базу, выключил SQL 2000, заменил файл mdf на старый, удалил ldf, на основе старой mdf создал новый ldf. Вот как это выглядит в запросах: USE master sp_configure 'allow updates', 1 reconfigure WITH override GO UPDATE sysdatabases SET STATUS= 32768 WHERE name = 'lCNew' GO DBCC REBUILD_LOG('lCNew', 'C:Program FilesMicrosoft SQL ServerMSSQLDatalCNew_Log.LDF') GO ПЕРЕКЛЮЧИТЬ В НОРМАЛЬНЫЙ РЕЖИМ Итог DBCC CHECKDB: ------------------------------------------------ Т.е. создать новую базу на основе МД и со старой через экспорт делать перегонку по таблично из базы в базу? Окей, сейчас будем пробовать, спасибо. Torquader> и Ваш метод сейчас испробуем.

Прошу прощения, но не совсем понял как мне на основе MD файла сделать новую базу SQL. :(

в конфигураторе 1С в пустой базе задаешь параметры базы (Администрироание, Параметры..). Далее загружаешь 1cv7.md

Попробовали сделать переиндексакцию: Итог: DBCC execution completed. If DBCC printed error messages, contact your system administrator. DBCC execution completed. If DBCC printed error messages, contact your system administrator. DBCC execution completed. If DBCC printed error messages, contact your system administrator. DBCC execution completed. If DBCC printed error messages, contact your system administrator. DBCC execution completed. If DBCC printed error messages, contact your system administrator. DBCC execution completed. If DBCC printed error messages, contact your system administrator. DBCC execution completed. If DBCC printed error messages, contact your system administrator. DBCC execution completed. If DBCC printed error messages, contact your system administrator. DBCC execution completed. If DBCC printed error messages, contact your system administrator. DBCC execution completed. If DBCC printed error messages, contact your system administrator. DBCC execution completed. If DBCC printed error messages, contact your system administrator. DBCC execution completed. If DBCC printed error messages, contact your system administrator. DBCC execution completed. If DBCC printed error messages, contact your system administrator. DBCC execution completed. If DBCC printed error messages, contact your system administrator. DBCC execution completed. If DBCC printed error messages, contact your system administrator. DBCC execution completed. If DBCC printed error messages, contact your system administrator. Server: Msg 823, Level 24, State 2, Line 1 I/O error (torn page) detected during read at offset 0x00000020c2e000 in file 'C:Program FilesMicrosoft SQL ServerMSSQLdatalCNew_Data.MDF'.

Бирюк> что-то не нашел я там пункта загрузить MD :(

в "Конфигурация"

Такс, загрузили MD-шник, а дальше то что? :)

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

Однако мог бы и про бэкапы в ответить. Некоторая ясность сложилась бы.

А если отключить Torn page detection

Такс, сделал как сказал vde69, перетаскивал каждую таблицу. В общем 3 таблицы которые при перетаскивании виснут вообще: _1SCONNECT DH11762 SC16315 Остальные 12 таблиц (ошибок) я заскринил, вот архив -

Server: Msg 7995, Level 16, State 1, Line 1 Database 'lCNew' consistency errors in sysobjects, sysindexes, syscolumns, or systypes prevent further CHECKDB processing. DBCC execution completed. If DBCC printed error messages, contact your system administrator. Server: Msg 7995, Level 16, State 1, Line 1 Database 'lCNew' consistency errors in sysobjects, sysindexes, syscolumns, or systypes prevent further CHECKDB processing. Clustered index successfully restored for object 'syscolumns' in database 'lCNew'. DBCC execution completed. If DBCC printed error messages, contact your system administrator. Server: Msg 7995, Level 16, State 1, Line 1 Database 'lCNew' consistency errors in sysobjects, sysindexes, syscolumns, or systypes prevent further CHECKDB processing. DBCC execution completed. If DBCC printed error messages, contact your system administrator.

А ещё, кстати, вопрос - почему такая хитрая схема загрузки базы в SQL - с помощью подмены файла? Там же вроде есть что-то типа "Подключить базу"?

, а потому-что вот - У нас винт из рейда вылетел и сервак вырубился. Т.е. корректного выключения небыло =(

выгрузить/загрузить никак?

что именно Вы имеете ввиду? Базу в 1С или в SQL?

в 1С

Так а что я буду загружать, если нет новой выгруженной базы до падения сервера? =(

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