Всем доброго времени суток. Столкнулся со следующей проблемой:

Есть база в SQL. Пользователь выгрузил dt. Сделал несколько операций(не то что нужно) решил восстановиться из dt. При загрузке вылетела ошибка: Превышение индекса, данные загружены не полностью...

Посмотрев таблицу из ошибки нашел что есть измерение строки огромное по длинне... Вторая часть проблемы даже в файловом варианте dt не загружается (индекс 2к байт с копейками)

Вопрос: Есть ли какая-то возможно провести анализ dt и убить записи в этом регистре? Или прокатит ли восстановление из FULL бэкапа SQL(Предпочтительней). Проблема в том что база 1 и при ошибке восстановления dt.  уже понтеряна часть данных...(при том неизвестно каких)

Иными словами нужно все вернуть в первоначальное состояние... Или хотя-бы с потерей этого "крутого" регистра накопления. Кслову если нужно, регистр - Остатков

Совсем нет информации? Или вопрос настолько тупой что даже оскорблять лень?

(2) вопрос дебильный

как то лень в субботу ...

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

и про восстановление из фулл бакапа, кстати, такой же вопрос: умеешь поднимать из этого бакапа? нет? тогда зачем их делать?

Если есть бэкап то к чему с dt играть?

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

В ветку призываются Serg_1960 и Aleksey из А где можно почитать что 1С не рекомендует в dt бекапить? - главные мастера бэкапов средствами .dt

(8) Припомнил, молодец :-)

(0) >> прокатит ли восстановление из FULL бэкапа SQL

А по какой причине может не прокатить?

Я, если честно, вообще не понял в чем проблем.
Забудьте про dt. Конечно может умельцы и найдутся, готовые в нем ковыряться, но гарантий они вам не дадут.

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

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

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

Всем спасибо! dt делался непосредственно перед работой(которая была выполнена криво...) у пользователя нет ни знаний ни умений ни доступа делать бекапы SQL... У меня тоже доступа к скулю нету... Поэтому было сделано так... Ну теперь успокоился, что из бекапа скуля поднимется(очень надеюсь, что не будет какой-нить очередной ж..пы из-за круто огромного индекса...)

Делал не я... Операция по сути была простейшей.. но для некоторых юзеров и это оказывается не под силу..

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

а скульных бакапов нет?

Непонял а в файловую почему не загрузилось? Размер большой? Сечас файловую хоть на 100 гигов сделать можно.

(16) а индекс...

(16)
http://its.1c.ru/db/v839doc#bookmark:dev:TI000001287
Помимо длины индекса, ограничение по 4 гига на внутренний файл  также никто не отменял

(17) Индекс более 2к байт (файловая вытягивает максимум 1900)....

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

Всем большое Спасибо!

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

(18) В платформе 8.3.8 ограничение на 4гб сняли. http://its.1c.ru/db/v838doc#bookmark:adm:TI000000666
вот фото большой базы
[url=http://radikal.ru][img]http://s017.radikal.ru/i411/1610/b6/dcb6f2172842.jpg[/img][/url]

(21)Так получше будет.  http://radikal.ru/lfp/s017.radikal.ru/i411/1610/b6/dcb6f2172842.jpg/htm
Что теперь с индексами хз

(21) Ну я привел из документации на 8.3.9 ссылку.
Файл в 40 гигов всегда можно было сделать через 5 таблиц по 4 гига данных и 4 гига индексов или 2,5 таблицы по 4 гига данных, 4 гига индексов и 4 гига blob.

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

(23) Скорее всего не поменяли т.к. загрузилась только после конвертации стр. в 64 кб. Нужно еще поискать обработку которая покажет размер внутренних таблиц, какой там объем самого большого файла.

(21)В какой 8.3.8 ?

(25) в любой. В папке bin есть конвертер cnvdbfl.exe