Доброе время суток. С прошедшим, всех, Новым Годом. :)
Итак, предыстория. Стоял у нас 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". Всё, на этом я встал. Что делать теперь? =(

(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. ещё можно вести журнал изменений, в который в текстовом виде записывать все изменения объектов базы.