Доброе время суток. С прошедшим, всех, Новым Годом. :)
Итак, предыстория. Стоял у нас 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
CREATE TABLE [dbo].[_1SCONNECT] (
   [CONNECTUUID] [char] (36) NOT NULL
) ON [PRIMARY]
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Совская конфигураторская штука которая сканирует базу и исправляет найденные в ней ошибки?) Если да, то пробовал. И кажется вылетела она у меня с ошибкой, не помню, честно...

Вот тут кстати чуток детально расписал проблему - http://www.sql.ru/forum/actualthread.aspx?bid=1&tid=994509

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

Запустил ТИИ. Спустя минуту-две выдал такое вот сообщение:

SQL State: 22003
Native: 0
Message: [Microsoft][ODBC SQL Server Driver]Числовое значение выходит за пределы допустимого диапазона.

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

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

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

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

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

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

Сообщение "Доступ к базе данных на сервере возможен только из одного каталога информационной базы!"

В некоторых случаях при запуске 1С:Предприятия появляется сообщение об ошибке:"Доступ к базе данных на сервере возможен только из одного каталога информационной базы!". Причиной появления такого сообщения может являться нештатное завершение работы 1С:Предприятия на одном из рабочих мест. Иногда в этом случае не закрывается соединение с БД на SQL Server и при попытке повторного или нового подключения пользователя к информационной базе (при условии, что к БД никто не подключен, т.е. этот пользователь - первый) появляется такое сообщение.

Проблема решается следующим образом:

1. С помощью монитора пользователей убедится, что с информационной базой никто не работает.

2. Запустить Enterprise Manager SQL Server и закрыть "зависшее" соединение (Kill process).

3. Средствами операционной системы убедиться,что файл в каталоге информационной базы "1Cv7.$ui" никем не открыт. Если существуют пользователи открывшие этот файл, то следует выполнить отключение  доступа (Disconnect) пользователей от данного файла.

4. Запустить 1С:Предприятие.

Источник
http://abc.vvsu.ru/Books/ebooks_iskt/%DD%EB%E5%EA%F2%F0%EE%ED%ED%FB%E5%F3%F7%E5%E1%ED%E8%EA%E8/1%D1/Documentation/Documentation/recom019.htm

Вот еще из яндекса ))
Диагноз: Такая ошибка возникает при попытке загрузить версию 1С для SQL после того, как один из пользователей некорректно вышел из системы. В редких случаях эта ошибка может быть результатом некорректной установки конфигурации.
Анамнез: После закрытия 1С на сервере NT освобождаются ресурсы, которые занимал пользователь. Однако в случае некорректного завершения работы не останавливается SQL-процесс, запущенный пользователем.
Рецепт:
Принудительно остановить SQL-процесс можно с помощью SQL Enterprise Manager. В нем все активные процессы перечисленны в ветке “Management\Current Activity\Process Info”. Надо найти в списке справа процесс, который мешает Вам жить, выделить его и в меню “Action” выбрать пункт “Kill Process”

Если пользователи работают по протоколу Named pipes, то можно просто закрыть файлы на SQL-сервере, открытые повисшим пользователем. Такие файлы имеют вид \PIPE\MSSQL$NAMEDSERVER\SQL\query.

Если вышеизложенное слишком сложно для Вас, Вы можете просто перегрузить SQL server. Надо только убедиться, что ни одна другая програма не использует его в этот момент.

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

1. Создал новую базу в файловом режиме. Что теперь?
2. Пользователей нет, если только зависшие процессы во время падения сервера. Сами посмотрите. Разве тут есть что-то лишнее?
http://s017.radikal.ru/i443/1301/f4/9336a704172a.png

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

Ну, собсна думаю снова пересоздать _1SCONNECT и уже потом разбираться с таблицей SC746.
После пересоздания - http://s57.radikal.ru/i156/1301/8c/ca4936675a6a.jpg
Таблица 746, что в ней не так? - http://i023.radikal.ru/1301/d2/fae564722e40.jpg

Посты (14) и (15)проигнорировал?

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

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

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

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

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

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

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

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

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

я правил этот dbf с помощью foxbase2.0.. работает..

Ребят, надеюсь всё-таки на вас, что я отдохну до 8 января, а не буду работать в праздничные дни :))

В общем вот, сравнение двух таблиц. Лично я чего-то не врубаюсь, схожие ли данные иль нет...
http://i053.radikal.ru/1301/88/8b7aafa57632.jpg

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

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

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

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

Так точно, этот PK_SC746 присутствует - http://s020.radikal.ru/i723/1301/0b/060fb23483e7.jpg

"смотреть надо в файловом варианте - сохранить в скл - загрузить в дбф" - к сожалению не знаю как :( Я смотрю DDS через DDView.

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

(0) У меня такое было когда я не так скуль настроил при установке :)

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

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

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

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

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

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

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

(38) какая конфа-то?

(39)+100500

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

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

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

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

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

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

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

SQL2000?

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

1cv7.DDS

Вот, пожалуйста :) http://files.mail.ru/5ZLNBA

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

одна из возможных причин: отсутствие полей, касающихся НП
http://saveimg.ru/show-image.php?id=8ba42e8fb94ce10bd0d0950da346ad38
зы. не знаю, получилось-ли выложить изображение..

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

(38) никого не слушай...
делаешь так

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

далее тебе нужно сделать средствами скуля переиндексаци.

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

Сделал 53, см. скрины :(
По порядку, как шли ошибки так и скринил.
http://s017.radikal.ru/i439/1301/16/07a4a5fd2f0f.jpg
http://s001.radikal.ru/i194/1301/d2/13dafec5ef8d.jpg
http://s017.radikal.ru/i406/1301/2a/0bfe5a8007d0.jpg
http://s017.radikal.ru/i407/1301/71/9483eac9fbf1.jpg

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

(58) скуль какой? скорее всего 2009 ??? там с патчами могут быть танцы...

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

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

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

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

(62) скоорее всего получишь ряд ошибок.

далее есть 2 варианта лечения

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

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

ушел в реал, если чего будет не получатся - пиши на почту.

(по любому поднять все можно если есть копия сразу после краха)

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

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

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

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

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

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

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

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

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

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

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

(73) да здесь я (кстати перечитал все),

давай по порядку я озвучу ход своих мыслей
1. ты перенес базу на другой скуль? это так? каким методом переносил?

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

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

мой совет - скулевским экспортом потаблично гнать данные в новую пустую базу

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

таблицы на которых будут ошибки - озвучиваешь сюда вместе с описанием ошибок...

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

1. Перенес базу таким образом:
Поднял новый SQL 2000, создал в нем новую базу, выключил SQL 2000, заменил файл mdf на старый, удалил ldf, на основе старой mdf создал новый ldf. Вот как это выглядит в запросах:

USE master
GO
sp_configure 'allow updates', 1
reconfigure WITH override
GO

UPDATE sysdatabases SET STATUS= 32768 WHERE name = 'lCNew'
GO

DBCC REBUILD_LOG('lCNew', 'C:\Program Files\Microsoft SQL Server\MSSQL\Data\lCNew_Log.LDF')
GO


ПЕРЕКЛЮЧИТЬ В СИНГЛ


USE lCNew
GO
DBCC CHECKDB('lCNew', REPAIR_REBUILD)

USE lCNew
GO
DBCC CHECKDB('lCNew', REPAIR_ALLOW_DATA_LOSS)

USE lCNew
GO
DBCC CHECKDB('lCNew', REPAIR_REBUILD)


ПЕРЕКЛЮЧИТЬ В НОРМАЛЬНЫЙ РЕЖИМ

Итог DBCC CHECKDB:
http://s019.radikal.ru/i629/1301/7a/fa76a6ef1bc0.jpg

------------------------------------------------

Т.е. создать новую базу на основе МД и со старой через экспорт делать перегонку по таблично из базы в базу? Окей, сейчас будем пробовать, спасибо.

Torquader> и Ваш метод сейчас испробуем.

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

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

Попробовали сделать переиндексакцию:

USE lCNew
EXEC _1sp_DBReindex

Итог:

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 Files\Microsoft SQL Server\MSSQL\data\lCNew_Data.MDF'.

Connection Broken

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

http://s017.radikal.ru/i418/1301/a7/53f23b7082d1.jpg

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

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

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

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

А если отключить Torn page detection
http://www.sqlserverclub.com/articles/sql-server-msg-824-torn-page-detected.aspx

Такс, сделал как сказал vde69, перетаскивал каждую таблицу. В общем 3 таблицы которые при перетаскивании виснут вообще:
_1SCONNECT
DH11762
SC16315

Остальные 12 таблиц (ошибок) я заскринил, вот архив - http://rghost.ru/42672814

(88)

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.

http://www.sql.ru/forum/actualthread.aspx?tid=645650

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

(91), а потому-что вот - http://s017.radikal.ru/i427/1301/2d/d4d55797e35a.jpg
У нас винт из рейда вылетел и сервак вырубился. Т.е. корректного выключения небыло =(

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

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

в 1С

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

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

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

(97)Отключи сервер от сети, чтобы никто не ломился. Перезагрузи и попробуй снова. Может и глупость, но кто знает...

К серверу кроме меня никто не ломится, сотрудники у себя дома все бухают, а я тут эту 1С мастурбирую... =)

Почистить дефектные таблицы? Прости, не знаю как =( У меня есть только список таблиц которые я не смог перенести. А что именно с ними делать, я не знаю. Поэтому я тут, товарищи)

(100)До сотки добрался. Молодца. А где хоть один старый архив базы. Мог бы из неё недостающие таблицы подбросить.

В том то и дело что нет у нас старого архива базы SQL... Хотя щас еще тщательнее поищу...

>Прости, не знаю как

ну в смысле грохнуть все записи: truncate table

все эктеременты только на копии того что осталось

(102)Обычно при обновлениях делается архив на то рабочее место, с которого делалось обновление. Поищи на рабочем месте программиста.

+(104)Архив 1с-ный. А то я смотрю у тебя к конфигуратору 1С аллергия. )))

ура, утро настало.... а спать еще охота :)

(89)
далее попробуй оставшиестя таблицы перенести без использования TDS (в настройках мастера галку снять), часть таблиц должна перенестись, а для остальных будут ДРУГИЕ ошибки

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

select count(1) from ИмяТаблицы - те таблицы которые вернут 0 переносить не нужно.

сформируй итоговый список неперенесеных таблиц (с количеством записей).


Таблицы на которых виснет

(106) прости, не смог найти где выключить TDS :( Не тут где-то?

http://s40.radikal.ru/i090/1301/47/330ed49eb1ec.jpg

(104) у нас программиста 1С уволили, мол он нам не требуется, мол и так всё работает, а мы только лишние деньги на него тратим. :)
Вот и уволили, теперь всё лежит))) Бэкапов нет.

ОФФ: муки рождения 1С-ника из админа.
Поищи бэкапы на рабочих местах. Расширение zip. Внутри должен быть файл 1cv7.md Есть надежда, что 1С-ник был вменяемым и не дерьмом. Тогда архивы должны быть.

(107) на память не помню где, а посмотреть негде (на работе 2009 скуль).

(108) за бекапы разве 1с ник отвечает???

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

По всей видимости за бэкапы не отвечал, раз нихрена не делал. Он таскал базы выгруженные домой, но дома уже давно всё удалил... Поэтому бэкапы висели на нас (двух сис. админах), а мы и знать не знали что они вообще не делаются. Да, осудить нас легко за это, но на самом деле там всё чуток сложнее чем кажется.... Не буду вдаваться в подробности, а просто скажу, что бэкапа SQL базы нет 100%. А вот 1С хренова туча.

Нашел MDшник от 23 октября 2012.

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

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

зы
кстати если готов дать удаленный доступ и оплатить результат - будет все гораздо быстрее :)

(111) какие способы нагуглил, такими и воспользовался.

(0) тебе сказали уже  люди у которых такое было: кури в сторону установки скуля - базу не трожь - ты не правильно скуль установил - он у тя в однопользовательском режиме работает.

(115) но тогда почему 4ая редакция запустилась на УРА?

(112)>>>Нашел MDшник от 23 октября 2012.

а сейчас какой мдешник ты используешь??????

(113) Пришло время для сакраментальной фразы: "Пригласите специалиста 1С". Редко и дорого встречаются админы серверов и 1С баз одновременно.

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

(112)Кроме мд-шника там должны быть и другие файлы. Какие?

(120) в скульной базе два файла и папки пользователей все - больше там ничего нет (МД и еще какой то :)  )

(115) херню не пори, дело не в скуле...

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

если автор был-бы 1с ником то с первой проблеммо он сам справился-бы....

могут быть еще всякие там библиотеки типа Formex и spydll и с++dll ну и там какие нить специальные по конфе

(117) который и стоял раньше с этой базой. Хм, а ведь это он и есть *facepalm*, его и использую)

(120)
http://s51.radikal.ru/i134/1301/57/0bd991dafaee.jpg

(121) если хочешь, перечитай пожалуйста всю тему с самого начала. Я уже говорил что там таблицы косячные, а некоторые вообще виснут при перекидывании из старой базы в новую - глючный SQL? Нет, база. Был аварийный СТОП сервера, а точнее винт из рейда вылетел, соответственно сохранилось всё так, как сохранилось.

vde69, есть уже идея с удаленкой, но пока повременим с этим =)

(123) это не влияет на саму структуру....

Universal - ищи САМЫЙ последний мд и его накати (через конфигуратор) на новую базу (в которую копировал), после этого повтори экспорт таблиц с ошибками.

Конечно правильнее было-бы сравить DDS этих мд-шников, но автору это не под силу

выложи dds файл

(125) для этого создать и новую 1С или можно и в этой? А этот MD-шник и есть последний, который на данный момент и находится в каталоге с базой.

(126) + из НОВОЙ базы

(124)Это не архив, сделанный 1С-ником. Там всего несколько файлов 1cv7.*

Новый DDS - http://rghost.ru/42674669
Старый DDS - http://rghost.ru/42674680

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

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

(127) дальше делаешь так

1. делаешь скульный бекап новой базы (и откладываешь)

2. заводишь ексель файл
в нем список неперенесенных таблиц, для каждой талицы смотришь список полей на которые ругалось при переносе, в dds находишь эти поля (у этих таблиц!!!) и пишешь в ексель
имяКолонки - имяРеквизита

3. Сюда-же пишешь Количество записей (как сделать я писал ранее) для каждой битой таблице

результат выкладывай сюда...

если все будет работать - выкинь куда подальше свой скуль и дай бухам работать в дбфной базе :) пока не разберешься как скуль настраивать а вде69 не слушай - он уже на руководящей работе все перезабыл  :)

(134) ну да ну да, зиповская база которая весит 3мб, ну да нуда...

(133) ты ему предлагаешь этой фигней все каникулы страдать? пожалей сисадмина то - пусть бэка ищет

и в дбфную его грузит - так быстрее и правильнее.

(135) зиповская база - которая весит 3 мб это скорее всего и есть последняя выгрузка базы - а тыдумаешь сколько она должна весить по твоему?  пример: у меня база 2 гига дбфная при выгрузке 28 мб.

(130) новый dds маленький, перезалей..

(138) в этих архива md файлы и user'ы за 2008 год ...

(138) 4 мб весит один md :) от тис

(141) у меня бухии дбфные - архивы через администрирование - выгрузить инф базу весят от 3 до 4 мб за 3 года база как то так.

(141) а новый dds столько и весит. Кажется надо заново всё это сделать, создать новую 1С базу и засунуть ей MDшник последней версии.... Я запутался уже чето.. Всё правильно?

Только новой базе 1С указывать старую sql-базу или новую?

во первых мы не знаем что за конфа у (0) , во вторых мы не знаем где он хранил архивы выгрузок - я обчно храню в папке АРХИВЫ1С и делаю их через администрирование - выгрузить инф базу ВСЕГДА - обзываю их обычно так 2012-10-25БУХОООВмм

пример что нужно сделать

//-------------------------------------------------------
таблица DH1049  |Документ ИнкассовоеПоручение  
поле  SP1027                |(P)ЛицевойСчет    

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

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

(143) примерно столько-же как и старый

(143)"создать новую 1С базу и засунуть ей MDшник последней версии". Я бы так не делал...

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

vde69, прошу, icq 613748302.

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

Расскажите потом, если получится в чём была засада.

(144) Вопрос такой:
У вас был RAID - в нём вылетел один диск - это RAID не убивает, если у вас нулевого не было.
Потом остановили сервер или он сам завис ?
Дальше - база 1С (директория с MD-файлом) тоже на этом RAID-е была ? Или отдельно.
Если MD и DDS достали из рабочей базы и они не битые, то не может быть такого, что не соответствует структура - а если у вас есть несоответствие, то или вы взяли MD не из той директории или что-то произошло с SQL-базой.
Потом ldf-файл просто удалили, мне кажется, что этого делать не стоило.

1. RAID-5.
2. При слетел винта серв сам вырубился, соответственно ничего там не сохранил как надо.
3. Всё было на этом рейде, да.
4. Сам понять не могу почему так. Нам до этого программист 1С сказал что у нас очень огромный лес в этой базе, очень много внешних обработок, много привязок....
5. А без его удаления я не смог приаттачить к SQL базу. :(

(152) >>>Если MD и DDS достали из рабочей базы и они не битые, то не может быть такого, что не соответствует структура - а если у вас есть несоответствие, то или вы взяли MD не из той директории или что-то произошло с SQL-базой.


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


(153) >>>Нам до этого программист 1С сказал что у нас очень огромный лес в этой базе, очень много внешних обработок, много привязок....

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


зы
ответа на почту не получил...

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

Я так и не понял - структура нарушена или же всё-таки нет доступа к некоторым таблицам SQL??

(155)+1

в свете кривово сида на dba_owen может не быть доступа к отдельным колонкам таблиц и от сюда сабж

с трудом себе представляю ситуацию когда кто-то в здравом уме поменяет owner'a у части таблиц. 1С же может только под одним именем коннектиться одновременно! Ну во всяком случае, для старта необходимо чтобы все таблицы имели возможность доступа к ним под этим именем.

(156) к стати это наверно самая правдоподобная версия

Как рейд восстанавливали? Просто воткнули новый винчестер или как? Что таблицы смарта на винчестерах кажут?

(158) Я бы в сторону железа грешил. Что-то у них там нездоровое с железом творится.

(157) так он когда файл приконектил скуль востановил сид на SA , но часть таблиц была битой и после чекдб может иметь владельца SA но от старого скуля (с другим сидом)

(161) Теоретически такая ситуация наверное возможна, не спорю, сид мог подняться другой, но я никогда не встречался.

А вот бэдблоки или некорректное восстановление пятого рейда - вполне могли дать похожую картину.

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

http://msdn.microsoft.com/en-us/library/aa259618(v=sql.80).aspx - совет от микрософта по смене владельца объекта.

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

ихмо автору нужно создать пользователя с админскими правами и его назначить dbo_owner ом, после этого перенос в новую базу остатка таблиц должен сработать...

сейчас очень на ошибку доступа к отдельным полям похоже...

(163) +
sp_changeobjectowner - это хранимка из мастерс, для ее нужны права админа сервера (например SA)

Ну, насколько я понимаю, у ТС должны быть права админа сервера..

Если вы считаете, что мог поменяться владелец, то почему это произошло у некоторых таблиц.
Кроме того, незагрузка ЛОГа не может быть связана с правами.
Более вероятно, что в базе просто мусор вместо каких-то таблиц - тогда и ошибки доступа будут, если вместо SID-а запишется что-то случайное.
А вот про восстановление RAID интересно поподробнее.

(167) SID - содержит контрольное значение, по этому мусор не может быть признан сидом.

хотя гадать можно весь следующий год, пока автор не проявится все варианты имеют право на жизнь

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

vde69, извиняюсь что не написал. У меня тут просто один человек объявился чуть-чуть быстрее тебя, он пока пробует сам базу восстановить. Если не получится - обращусь уже к тебе. :)

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

Про рейд: его нам не восстанавливали, с него нам инфу вытащили и положили на отдельный винт. Считайте что рейда уже нет.

По завершению работы над базой я уже более детально всё распишу, что и как было сделано. А пока-что вот. :) Огромное спасибо всем за комментарии и советы.

по просьбе автора - отпишусь :)

всего таблицы которые явно битые sc13446 sc16315 dt3910 dh1499 dh11762 dt3836 dh16236 dh16146 1sentry учитывая специфику конфигурации для полного востановления проблемными являются только 4 из перечисленых.

Для начала пробовал select count(1) from ИмяТаблицы

1. действительно существуют проблеммы как связаные с немного кривым востанавление базы в новом скуле, о чем говорит
Could not find row in sysobjects for object ID 329364538 in database 'SC16315'. Run DBCC CHECKTABLE on sysobjects.

2. есть проблеммы в самом файле базы
I/O error (torn page) detected during read at offset 0x0000003153e000 in file 'D:\!TEST\test_Data.MDF

пробовал DBCC CHECKDB - не помогает...
смена владельца - заканчивается ошибкой
бекап - проходит а вот востановление в пускую базу - валится

но самы приколы начанаются далее
1. на одной таблице select count(1) from ИмяТаблицы проходит а вот select * from ИмяТаблицы - НЕТ, причины я не понял...
2. две таблицы содержат не правильные колонки (примерно так ID_DOC C2344), при чем колонки заполнены какими-то данными (разумеется не ID)
3. есть проблеммы с задвоением первичного ключа.
4. таблица проводок в середине имеет мусор в отдельных колонках.

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

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



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

жалко автора!

Странно, неужели ни один из бэкапов восстановить нельзя?
Тогда одмина выипать прилюдно
Если можно - восстановить и перебросить данные в эти проблемные таблички
По крайней мере не за весь период деятельности проверять/вносить

(172) мне о наличии бекапов не известно...

(173) Предположительно, если BackUp-ы и были, то в силу того, что использовался RAID-5, они делались на тот же самый дисковый массив.
Судя по тому, что написано в (171) базе пришёл конец в связи с тем, что вылетели отдельные сектора на диске. BackUp-ы - они архивированы, если сектор вылетел, то развернуть его уже невозможно - будет ошибка контрольной суммы.
Что касается странного поведения SELECT COUNT(1) и SELECT (*) то тут, как раз, всё понятно - таблица есть, все записи, как бы, на месте - когда мы их считаем, то система просто перебирает записи, и проверяет только служебную область (удалена запись и т.п.), а когда мы выбираем поля, то возможна ситуация, когда длина строки VARCHAR оказывается больше, чем максимальная длина строки (ну просто мусор в некоторых полях) и вылетает ошибка.

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

(174) Феерично если ты прав на счет места хранения бэкапов

нашли рабочий бекап за 2010 год, правда конфигурация не совсем та :)

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

после обеда это исправлю...

(176)+ кстати порка писал пост кое чего допер, понятно почему бекап не разворачивается, и вообще dbo сейчас разный по обьектно в базе...

(177) ужоснах, бегите оба

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

Версия SQL та же самая. За бэкапы бесполезно ругать, тут немного всё сложнее чем кажется. А упрекать любой может.
В следствии того, что сам я ни разу SQL'ку под 1С не поднимал, сделал я это как смог, поэтому и авторизация Windows, а не log\pass.

(180) >>>тут немного всё сложнее чем кажется

это точно :) одна только правовая форма организации чего стоит :)

прошел все кроме документов, пока потери
один мелкий справочник настроек, и 472 элемента важного справочника.

добрался до общего журнала, в нем какае-то бяка сидит. ТИИ на нем затыкается на дедлоке. Сделал 2 журнала завтра буду искать бяку, сегодня уже спать пора...

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

практический итог

пропали все платежки (можно загрузить из клиент банка)
и порядка 3500 документов (одного типа), за 2 года

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

ну еще по мелочи....

на мой взгляд работы 3м операторам примерно на месяц...

короче - делайте бекапы!!!

а что значит пропали ?
на них нет ссылок в табличке шапки/тч доков ?
или в самом 1sjourn нет записей ?

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

Мда, всё-таки закончилось всё это несколько не так, как хотелось бы, и как предполагалось. :(
Из-за больших потерь данных и самой глючности 1С (мы её даже настроить не можем, те же права распределить, мы не 1С программисты) начальство решило всё-таки перейти на новую версию 1С 8v. А перейти они хотели давненько, да вот только глюкнутая база не дала бы это сделать. А тут такое происшествие случилось, что всё-таки задумались уже всерьез о переходе на 8ку. Они уже согласны с тем что будут забивать всё с самого нуля (3000 клиентов), всё восстанавливать вручную. То, что восстановил vde69, им мало, большинства необходимого для работы нет. :(
И что теперь делать, я не знаю. Они нанимают 1С программиста снова в штат, он им и будет всё делать. А деньги за "восстановленную" базу платить не хотят. Ведь тут такая политика - "А за что платить то? Он же ничего не сделал, так ничего и не работает, инфы же нету!".... Тупое начальство, сначала жлобится на новые сервера, потом само же и страдает.
За такую работу была оговорена сумма в 20 тыс руб. Но, т.к. никто платить из начальства не собирается, мы с напарником решили всё-таки как-то, да расплатиться... У нас конечно не московские зарплаты, всего по 15-20 тыс.... Так что хоть какую, то символическую оплату всё-равно произведем, зря что ли человек работу делал, столько полезного сделал.

P.S. Офигенно конечно получается. Просидел все новогодние праздники над этой долбанной 1С, и в итоге такое выходит. Обидно, особенно за vde69. :(
    vde69, Жду на мыло реквизиты, куда переводить. Лучше на карту.

(186)
>>>>Из-за больших потерь данных и самой глючности 1С (мы её даже настроить не можем, те же права распределить, мы не 1С программисты)

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


>>>> То, что восстановил vde69, им мало, большинства необходимого для работы нет. :(

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

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

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

Для меня загадки две
1. что будет делать начальство с периодом 11-12 год, ведь бекап 10 года, или им не нужна информация за эти 2 года? (а нужна только оперативка?), но по сколько я там глядел, там есть и ОС длительные договора, по этому я не понимаю как они обойдутся без этой базы.
2. почему отсутствие бекапа не повесили на автора? это было-бы в их духе. Оплатить а потом вычесть из зп автора :)


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

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

(187) mlg тоже в проё-е ?

(188) по логу можно вытащить представление обьекта (название справочника) и идентификатор.

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

по этому лог бесполезен...

(187) интересно как они годовой будут сдавать....

(189) надо было предоплату брать

(191) не все так просто, это ГУП...

ну ты же договор с ними тоже не стал заключать?

(192) ну и забить тогда

(193) договора бывают разные, в том числе и в устной форме...

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

(194) да я отношусь к ситуации спокойно, это не первые и не последнии кто не хочет платить.

(192) что есть ГУП?

(197)
Государственное унитарное предприятие

(198) а, понятно, я думал тут личное отношение к тем кто работу забрал а платить не хочет

(189) Вероятно, еще часть информации можно было из Индексов таблиц вытащить, но в целом... Бэкапы рулят! (ушел убедиться в наличии свежих бэкапов)

Короче сотрудники покопались и попробовали забить данные клиентов (11-12г) и в итоге отказались, потому-что 1Ска перестала присваивать лицевые счета, а они привязаны к каким-то документам. Ну и махнули они на это дело рукой и сказали что забивать нет смысла, проще уже всё с нуля на 8ке поднять. Так что решило наше начальство что будем удалять восстановленное. Такие вот дела. :(

Да, и кстати, все данные есть в бумажном варианте. Так что восстановить всё обратно в электронку - не проблема. Просто очень долго и нудно. Но это уже совсем другая история.... :)
Еще раз спасибо большое всем за комментарии и помощь.

Ладно - бывает.
У меня тут на днях состоялось знакомство с postgresql, правда без 1С, но там тоже была база, и пришлось возвращаться к бекапу недельной давности, так как ошибка контрольной суммы страницы, и в базе мусор.
В общем, SQL - вещь быстрая и хорошая, но также быстро и хорошо он умеет превращать данные в кашу.

Так что не забывайте делать BackUp-ы.
P.S. ещё можно вести журнал изменений, в который в текстовом виде записывать все изменения объектов базы.