Месяц назад при выгрузке базы и загрузке ее у себя выдало сообщение.

Ошибка загрузки информационной базы. В информационную базу загружены не все данные
по причине:
Ошибка СУБД:
Превышен максимально допустимый размер внутреннего файла 'C:\Users\marat\Documents\InfoBase1/1Cv8.1CD'
по причине:
Превышен максимально допустимый размер внутреннего файла 'C:\Users\marat\Documents\InfoBase1/1Cv8.1CD'

Долго не стал разбираться перешел у себя для разработки на sql 2008.
Сейчас встал вопрос делать копию базы для фин директора.
Дело в том что база всего вести 2.8 гб а по отдельным таблицам максимальная 135 мб. В файовом варианте если не изменяет память то объем не превышал и 1 гб в момент возникновения ситуации.

Подскажите в чем модет быть проблема. ТИИ делал, сжатие базы делал.
Даже пробовал удалить данные РС в котором очень много данных.

+ 0
БАза самописка на 1с.8.3.3 релиз 678 пробовал на 8.3.4 на последнем релизе.

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

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

(0)Это значит пора на скуль переползать.

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

(1) По всем описаниям тут такое получается при превышении таблицы более чем 4 гб а у меня сама база еще целиком не более 2.8 гб. Вот и хочу понять в чем дело.

(5) Как раз и хочу понять куда копать.

(6) ну индексы там всякие могут быть довольно-таки большими

(0) платформу обновил до последнего релиза? на какой то версии был такой глюк

(0) Сверни базу. Или перенеси остатки в новую.

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

(10) каким боком размер внутреннего файла (а 1цд внутри по сути структура аналогичная фат32) относится к темпакам?

> Сейчас встал вопрос делать копию базы для фин директора.

зачем ему копия ?
пусть в боевой работает

(11) Совсем не ясно, почему превышен размер файла.

Говорят индексы разбухают при загрузке: http://infostart.ru/public/200268/

(12) База находится в вахтовом городке. Инет спутниковый очень слабый. В центральном офисе распределенка будет. В фин дир не сидит в одном месте ездиит по всей стране.

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

(13) сенкс, читаю

Как вариант базу можно просто запаковать и выкладывать куда нить.

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

(17) И для нее подымать скуль? И еще ключи покупать?

(14)[да и вообще хочу понять почему при такой маленькой базе вдруг база пришла к такому состоянию.]
путём флюда на форуме ты понимания не добьёшься

Скорее всего регистр сведений, точнее его индекс.
Тут поднималась уже такая тема.

+(20) а, так тебе в (13) все разжевали.

Обработка ПолучитьСтруктуруХраненияБазыДанных из 13 не подошла.
Сам написал типа

СтруктБД = ПолучитьСтруктуруХраненияБазыДанных(,Истина);
    Для Каждого ТекущаяСтрока Из СтруктБД Цикл
        Сообщить(ТекущаяСтрока.ИмяТаблицыХранения+";" +ТекущаяСтрока.Метаданные);
    КонецЦикла;


Но тут нет индексов. Как вытащить таблицы индексов???

ТекущаяСтрока.Индексы.Индексы    ИндексыКоллекции    ИндексыКоллекции

из вашего кода отладчиком вытащил)))

(24) Вот черт хотел же поковырять там.

Спасибо!

ДО сих пор не могу понять в какой таблице в каком индексе проблема. Кто-нибудь знает как искать из лога где проблема?

1. Выгружай в NTFS
2. Копируй средствами SQL.

Есть жестокий вариант: разрезать файл и кусочками

(27) У меня стоит вин 7 везде нтфс
Что значит копируй средствами sql? У меня задача понять и разобраться и по возможности оставить файловую базу Хотя бы для финдира.
БАза вечти всего до 2.8 гига самая большая талица едва 425 мб

Вот ссылка кто глзастее гляньте именно в какой таблице?

http://yadi.sk/d/hFF7lPfrFZurj

(0) утилиты ChDBFl и tool_1cd в помощь. А вообще SQL сервер не помешало бы поднять.

(31) Я уже в скуле. Но хочу понять как в (13) в чем причина и устранить эти недостатки.

Ауу народ помогите еще чуть чуть. Куда копать?

CREATE INDEX _AccumRg785_ByRegID_B (_RegID)
скорее всего

прошу прощения - то есть
CREATE INDEX _AccumRgA97_ByDim_R (_Fld93RRef)
скорее всего

(0) Оч. странно. 2.8 Гб - это типа размер mdf у тебя? Или как ты размер смотрел?

(36)Это закрытая информация.

Ежели Reports - Disk Usage by top tables, то там раскладка и по индексам тоже.

(36) 2.8 Гб - это размер dt-файла :)

посмотри с помощью http://infostart.ru/public/82178/

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

Еще раз поясню для тех кто не понял.
1. С 1го июля пишу самописку через месяц понял что при фаловой базе есть торомоза. Юзеров тогда активных было 8-10.
2. Перевел базу в скульный убедился что скорость стало лучше.
3. Но сам разработывал в файловой и при этом каждый раз загружаая базу с данными.
4. В один  прекрасный день со скуля база в файлову отказался загружатся, выдав вышеуказанное сообщение.
5. Долго не думая также по советам тут я перевел свою девелоп-базу в скульную.
6. Но вопрос почему при такой маленькой базе выходит ошибка остался не выясненным.
7. Фин диру надо было ставить опять кпию базы или РИБ сделать для нее. Вот и решил почему же так проиошло и как я могу я вернуть возможность создавать файловый вариант.

mdf = 1,03 ГБ (1 114 439 680 байт)

(0) ТиИ. Проверить как закрываются регистры.

Как посмотреть в файловой базе, сколько весит какая таблица?

(30)(43) Может ошибаюсь, но есть подозрение, что у тебя проблема с использованием агрегатов в регистре накопления _AccumRg84.

(18) "И для нее подымать скуль? И еще ключи покупать?"
вам шашечки или ехать? а то в (0) идет спекуляция на должности основного пользователя, а когда предложили решение - сразу зажмотились на лицензии.

(46) Да при чем тут лицензии? Мне нет ссмысла ставить скуль и каждый раз ей грузить скульную базу.
Я не могу понять что база в скуле 1 гиг а в файловом пол гига и уже нет возможности работать в файле.

(45) вообще замочил этот регистр ошибка до сих пор есть

в (40) уже подсказали, где посмотреть таблицы, а ты до сих пор не удосужился понять в какой таблице у тебя проблема. Мог бы и в SQL посмотреть.

(49) Как я могу глянуть если у меня скульная база а в (40) надо глядеть в файловую?

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

>2.8 Гб - это размер dt-файла

>mdf = 1,03 ГБ

Что-то тут не так. Не может из mdf = 1,03 ГБ быть dt 2.8 Гб

как-то странно все. dt это сжатый файл и сама база может быть на порядок больше
вот простенькая база CD-389M, а с нее dt-33M
Т.е. из dt 2.8Г база может развернуться на 28Г

Размеры таблиц у меня давно известны. Самая большая таблица весит 133 мб

(51) mdf = 1,03 ГБ , Но если глнуть на свойсвах в скуле показывает 2.8 гб а выгрузка всего 52 мб а вот скульный бекап 101 мб

(53) Тогда нифига непонятно. Какая-то странная фигня происходит именно при загрузке. Раздувает одну из таблиц или индексов. Может, при пересчете итогов...

(50) что мешает сделать (40) в последней имеющейся файловой базе? или ты думаешь, что с тех пор динамика роста таблиц существенно изменилась?

(54) Ну я о том же.

Решил методом тыка найти, постепенно удаляю по одному регистру. В конечном счета наткнусь на этот регистр. ))

(55) Была такая мысля да платная оказывается. (((

(54) + В любом случае, это ненормально. Нужно доставать правильную траву и вдумчиво курить. Как вариант, я бы попробовал мониторить распределение диска по таблицам и индексам в процессе загрузки из dt в сиквел. Возможно, это натолкнет на какие-то мысли. Хуже всего, если это глюк именно файловой версии.

(53) теперь хоть ситуация понятно
dt-всего 52М т.е. база должна быть где-то 500...600М
так что как-то не очень понятно...

но для решения проблемы "делать копию базы для фин директора." можно попробовать использовать универсальную выгрузку/загрузку

А вот мне кажется вся проблема в системной таблице

REATE INDEX _SystemSett_ByKey_SSS (_UserId, _ObjectKey, _SettingsKey)'

(50) очень просто...я смотрела. выгрузила в файловую и выдала ошибку как у тебя. я посмотрела файл cd соответствующей программой и она показала мне размеры тем не менее этой файловой базы.

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

Не поверите постепенно удалил все РН а их было 20
Потом взялся за РС их тоже примерно столько же было остались еще 3 РС.
Картина та же.....

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

(64) Начни удаление со справочников!

типа Хранилище

(66) Черт! Дело говоришь. Ведь есть у меня справочник для хранения фото сотрудников.
Пробую...
увы нет не тот...

а в 8ке есть метод посмотреть размер базы справочников,документов,регистров? В 7ке дбфной все в файл-менеджере было видно, в скл тоже.

Пытаюсь удалить справочник "ДоговорыКонтрагентов"

вываливается ошибка

В процессе обновления информационной базы произошла критическая ошибка
по причине:
Ошибка SDBL:
Поле Fld440 таблицы AccumRgAggDict2h447 содержит висячую ссылку. Старое поколение не может быть удалено.

Причем AccumRgAggDict2h447 это РегистрНакопления.ЗаказыНаОтгрузку
Который уже не существует.
Что делать как быть?

(68) Визуально без спец обработки не увидишь выше есть ссылка на эту обработку. ДАже не обработка а програмулька.

(68) есть,  им надо просто воспользоваться

(70) ты не пробовал ее чтоли?

(70) будьте добреньки, кто не жадный киньте на почту. у меня на инфостарте 32 старто-копейки.

(72) В скуле глянул размеры и все. А для файловой у меня тоже нет денег в ИСе (((

гугл рулез!) нашла ссылку в инете на нее)

Интересно, что такое "висячая ссылка"?
В конфигураторе конфигурация-тестирование конфигурации сделай
Попробуй конфиурацию выгрузить в файловую загрузить

Может, поможет v8: Поле ID таблицы .... содержит висячую ссылку. Старое поколение не может быть удалено

(74) (73) http://rusfolder.com/27931727

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

Конфигурацию можешь выложить?
Посмотрим

а 8.3.4 в режиме совместимости с 8.3.3?

(81) До сих пор я все крутил ее в 8.3.3
Но 5 мин назад перевел в 8.3.4 и при этом режим совместимости стоит

(80) Конфу или базу? А если базу то скульную или dt?
Желательно не давать ни кому. Как вариаент кинуть только конкретному лицу.

Пля че за платформа блин?!
Пол года вроде ничего не было а тут удаляю в конфе объект РН и при этом делаю ТИИ. Но тем не менее в скуле остаются мертвые души в виде таблиц РН...

Или в скуле всегда остаются таблицы???

Пробовал делать сжатие не помогает...

Попробовал сделать следующее.
Из скулевой базы то что у меня осталось после всевоможных удалений объектов выгрузил cf.
Создал файловую из нее выгрузил в dt.
Загрузил в скулевую. При этом в скулевых таблицах исчезли все лишние таблицы от удаленных ранее объектов.

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

(14) Этого даже в 1С не знают. Поэтому и выпустили мини-сервер.

(53) Похоже на зацикливание. Возможно, повреждена конфигурация. Демоническое обновление не использовалось?

(69) Очень похоже на битую конфигурацию...

(88) Почему? Демоническое использовалось. Но серьезных нарушений не видел. ДА и ТИИ ничего страшного не показал.

(69) База сегодня мною убивалось но естественным путем. Удалял постепенно объекты но их слепки остались в скуле.

Вот я тему даже создал.
v8: В скулевой базе удаляю РС РН итп. Но в самом скуле эти таблицы остаются почему?

(89) кстати попробуй на cd программку чекдск использовать из папки bin.

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

Кстати, dt в клиент-серверный вариант загружается или нет?

(59) мне кажется, что в зависимости от размера базы применяются разные алгоритмы сжатия - иногда dt получается маленьким, иногда большим
(63) 1C при удалении забивает пространство нулями. Хотя как ведет себя при физическом удалении не знаю
(64) можно с помощью универсального обмена данными (в юнирепсах есть) делать выгрузку по каждой таблице в xml файл - так и найти самый большой

Используются ли планы обмена в базе?

(92) Размер dt сильно поменялся в 8.2.14. ЕМНИП - это по той причине, что в платформе 8.2.14 и позднее выгружаются еще и итоги по РН.

(0) мои мысли такие

1. Каждая таблица в файловом варианте состоит из 4х внутрених файлов
2. Единственный внутрений файл который может расти в процессе загрузки - это индексы (они полностью пересчитываются)
3. Индексы у разных версий платформы могут быть принцепиально разные по алгоритму.
4. кроме индексов есть "волшебные, служебные" таблицы и обмен.
5. в последней платформе изменен файл лога
6. 8.3 пока нестабильна

Идем исключением
1. перейти на стабильную платформу 8.2 (исключим п. 6,5,3)
2. исключим кеш, и системные таблицы (загрузку ведем на новом чистом компе в ПУСТУЮ базу!!!! обязательно в ПУСТУЮ !!!!!), так-же загрузка в пустую исключит "фантомные" таблицы
3. Исключим план обмена

вроде все...

Отвечу на вопросы.
Выгруженая со скуля dt  обратно грузится в скуль.
Но файловую так и не смог пока создать. При чем почти все удалил. Я бы дальше удалял но натолкнулся на "скелеты" удаленных  регистров в таблицах скуля.

(96) дт грузи в ПУСТУЮ базу, нельзя грузить в существующую...

(97) Пробовал и не раз.

(0) "Дело в том что база всего вести 2.8 гб а по отдельным таблицам максимальная 135 мб"

Можно скрин стандартного отчета из SQL manadgement studio - использование дисковой памяти верхними таблицами выложить на рабочей базе, а то что-то с трудом верится...

(96) Попробуй следующее:
I. Провести проверку конфигурации штатными средствами Конфигуратора.

II. Выполнить следующие действия:
1. Создать пустую базу.
2. Выполнить "Сравнение и объединение" со своей конфигурацией.
3. Выгрузить полученную конфигурацию в файл.
4. В копии базы выполнить "Загрузить конфигурацию из файла"
5. Применить изменения, выгрузить базу в dt.

После чего попробовать загрузить в файловый вариант.

Надо учесть, что во втором случае часть данных может потеряться.

(99) http://savepic.net/4228612.htm
(100) Примерно так  пробовал но еще раз сделаю

(101) С пустой конфигурацией выгрузку-загрузку тоже стоит проверить.

(102) С пустой базы выгрузка загрузка работает
Но то что в (100) не дал положительного результата.

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

ещё раз спрашиваю. Распределенка есть?

(105) Прошу прощения нет.

Кстати, я решил сделать распределенку отпочковать и с ПБ сделать нормальную базу.

(0) Очень похоже, что где-то в базе есть "закольцованность", типа "Элемент А" - Родитель "Элемента Б", и "Элемент Б" - родитель "Элемент А"

(106) Кстати, а размер файла 'C:\Users\marat\Documents\InfoBase1/1Cv8.1CD' когда выдало ошибку - не смотрел сколько? И еще можно посмотреть - размер свободного дискового пространства до загрузки и в момент ошибки - чтобы точно узнать - с размером файла связана ошибка или с чем другим.

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

все тоже самое попробовал сделать с помощью конфигуратора 8.3. ошибка такая же. осталось единственная надежда на более свежую платформу.

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

(109)  "выходит имеем новое ограничение в виде количества объектов метаданных"
Тогда бы и на пустой базе с проблемной конфигурацией таже ошибка была, а в (103) вроде загружается

Интересно а почему в 1С 8.3 действуют ограничения СТАРОЙ версии DBF (которое уже давно устранил разработчик формата)?

Там небось у них еще и зашиты CDX?

То есть теперь максимум не 2 Гб, а 2 Гб*длина записи в байтах, при сохранении 32-разрядной структуры всех индексов.

Думаю что проблему решил. Что я сделал.

1. Взял свежую копию скульной базы
2. В нем создал План обмена - назвал "КЛОН"
3. Включил полную миграцию всех объектов.
4. Отпочковал базу. Получилос ПБ файловая- клон скульной.
5. Удалил главынй узел. выгрузил в DT.
6. Загрузил в скуль
7. из скулевой базы выгрузил опять в DT.
8. Попробовал загрузить в файловую. Все ок загрузилось.
9. Удалил план обмена.
10 Вуаля! Надеюсь ничего не потерял если даже потерял то это было ошибкой.
БАза sql мдф - 2.7, выгрузка в dt- 47 мб,  файловая- 320 мб

Хм... Получается, дело было не в конфе, а в данных?

А вот почему произошел то что в теме я так и не узнал.
Есть предположение.
1. Демоническое обновление
2. копипаст (имопорт из конф) неторых документов с обычных форм с их обычными формами из 8.2
3. База какое-то время жила на ссд. может быть там что-то было. Хотя сервак новый и до сих пор пашет.
4. Проблема релиза 8.3.3.687...
5. разрабатывали конфу 2-3 человека при чем удаленые помощники быть может они какое то время разработывали в другом релизе....
6. короче фиг знает.

(115) Точно не скажешь. Ведь в 1с8 в файловой все в одном файле. Да и висячие ссылки тоже говорят что со структурой таблиц что-то не так.

(115) Я типа такого и предположил в (107).
З.Ы. У нас было дело еще на 7.7, когда из структуры подчинения "А"->"Б"->"В" сделали "А"->"В"->"Б". При загрузке первое переподчинение сработало и получилось "В"->"Б"->"В"->"Б" и т.д. при этом команда "Спр.Уровень()" уходила в бесконечный цикл и все вешалось.

Обломс
то что в (116) видимо не подойдет. База на первый взгляд норальный но некотороые документы не открываются.
Видать данные покоцаны или же все таки конфа виновата.

Может перенести данные в чистую конфу?

Я еще блин экспериментировал на новом релизе. 1с8.3.4

Для чистоты эксперимента надо было все делать в страром так и сделаю.

Если что придется переносить...

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

(119) dbcc checkdb без ошибок проходит?

(123) Все чисто

Продолжаю копать...
Выбрал следующий не легкий путь
Пробую отпочковая приферийку прямо в скульную базу.
И вот что получилось. Образ Пб не докноца содалось потому что не хватило место для нее. Инчаче гвооря база выросла до 22 гига.

И вот что за таблица топовое на моент не хватки места dbo._InfoRg959 1 427 312 мб

И что за регистр сведения?

(126) Это регистр сведений имеющий 2 измерения и один ресурс в виде даты. Полагаю проблема не в нем.
Это просто большой РС с данными.

видим надо еще глубже копать.

(127) Тебе надо смотреть не на самую большую таблицу, а на самый большой индекс. sql.ru подсказывает такой запрос:

DECLARE @pagesizeKB int
SELECT @pagesizeKB = low / 1024 FROM master.dbo.spt_values
WHERE number = 1 AND type = 'E'

SELECT
  table_name = OBJECT_NAME(o.id),
  rows = i1.rowcnt,
  reservedKB = (ISNULL(SUM(i1.reserved), 0) + ISNULL(SUM(i2.reserved), 0)) * @pagesizeKB,
  dataKB = (ISNULL(SUM(i1.dpages), 0) + ISNULL(SUM(i2.used), 0)) * @pagesizeKB,
  index_sizeKB = ((ISNULL(SUM(i1.used), 0) + ISNULL(SUM(i2.used), 0))
    - (ISNULL(SUM(i1.dpages), 0) + ISNULL(SUM(i2.used), 0))) * @pagesizeKB,
  unusedKB = ((ISNULL(SUM(i1.reserved), 0) + ISNULL(SUM(i2.reserved), 0))
    - (ISNULL(SUM(i1.used), 0) + ISNULL(SUM(i2.used), 0))) * @pagesizeKB
FROM sysobjects o
LEFT OUTER JOIN sysindexes i1 ON i1.id = o.id AND i1.indid < 2
LEFT OUTER JOIN sysindexes i2 ON i2.id = o.id AND i2.indid = 255
WHERE OBJECTPROPERTY(o.id, N'IsUserTable') = 1 --same as: o.xtype = 'IsView'
OR (OBJECTPROPERTY(o.id, N'IsView') = 1 AND OBJECTPROPERTY(o.id, N'IsIndexed') = 1)
GROUP BY o.id, i1.rowcnt
ORDER BY 3 DESC

(125) у тебя зацикленость данных...

Объект1.Родитель = Объект2
Объект2.родитель = Объект3
Объект3.родитель = Объект1

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

более простой вариант запроса из (128)
DBCC UPDATEUSAGE (0)
create table #t(name varchar(255), row varchar(255), reserved varchar(255), data varchar(255), inxex_size varchar(255), unused varchar(255))

insert into #t
exec sp_msforeachtable N'exec sp_spaceused ''?'''
select * from #t order by CONVERT(bigint,REPLACE(data,' KB','')) DESC
drop table #t

Вот картина и что с ним делать не пойму. все вроде ок.
Хотя при отпочковании базы в ПБ в скуле база выросла до 29 гб
_AccumRg1171    330330    41808    29696    12048    64
_AccumRgTn1286    85402    29600    15408    14184    8
_AccumRg1277    122157    28824    17776    10896    152
_AccumRg1245    130288    21456    16552    4800    104
_AccumRg1319    150262    19152    13512    5496    144
_InfoRg959    178413    17936    10056    7744    136
_Document63    30563    11928    9408    2200    320
_AccumRg1184    72566    9424    6600    2680    144
_AccumRg1121    69310    8912    6232    2568    112
_InfoRg1006    38203    8664    4136    4392    136
_InfoRg993    26226    8152    3384    4640    128
_AccumRg1134    37237    8144    6624    1408    112
_AccumRg1298    23726    5912    3464    2168    280
_AccumRg1093    42659    4944    3256    1584    104
_Reference21    7455    4456    1864    2192    400
_Reference16    7188    3944    1472    1864    608

Вобщем что я сделал.
1. Опять создал РИБ
2. Настройка миграции полная
3. Выгрузил в это раз в скульную периферийку.
4. БАза отпочковалась но заняло 28,5 ГБ (MDF)
5. Просмотр объема таблиц в скуле ничего подозрительного не показало.
6. БАза Пб нормально выгружает в файловую и обратно в скуль
7. НО как тольок удалил план обмена опять глюк. Не открывается самый сложный  документ да и объемы этого дока большие.
8. ТИИ не помогло. Сжатие базы не помогло.
9. Выгружаю эту базу в файлову вроде все нормуль.
ни каких выводов у меня нет до сих пор.

(133) база нетиповая? перенеси этот документ ВыгрузкаЗагрузкаДанных.epf в чистую базу.

Что с зацикленностью-то? Пробовал чистить таблицы справочников?

(132) А это результат какого из запросов? (128) или (131)?

(136) Это было (128) А это (131)

_AccumRg1171    330330         41808 KB    29696 KB    12048 KB    64 KB
_Reference35    1793           29376 KB    27080 KB    344 KB    1952 KB
_AccumRg1277    122157         28824 KB    17776 KB    10896 KB    152 KB
_AccumRg1245    130288         21456 KB    16552 KB    4800 KB    104 KB
_AccumRgTn1286    85402          29600 KB    15408 KB    14184 KB    8 KB
_AccumRg1319    150262         19152 KB    13512 KB    5496 KB    144 KB
_Document63    30563          15776 KB    12192 KB    2200 KB    1384 KB
_InfoRg959    178413         17936 KB    10056 KB    7744 KB    136 KB
_AccumRg1134    37237          8144 KB    6624 KB    1408 KB    112 KB
_AccumRg1184    72566          9424 KB    6600 KB    2680 KB    144 KB
_AccumRg1121    69310          8912 KB    6232 KB    2568 KB    112 KB
_InfoRg1006    38203          8664 KB    4136 KB    4392 KB    136 KB
_Document60_VT537    63530          3784 KB    3712 KB    32 KB    40 KB
_Document44_VT316    55828          3656 KB    3552 KB    32 KB    72 KB
_AccumRg1298    23726          5912 KB    3464 KB    2168 KB    280 KB
_InfoRg993    26226          8152 KB    3384 KB    4640 KB    128 KB

(134) Как вариант.
(135) Чистил пока не уперся в то что конфа начала показывать ошибку (69). Но думаю продолжу. Тем более в той базе остались доки да спр и их почти половина осталось от исходного.

(137) Любопытно узнать, что за справочник "_Reference35" который на 1793 строчка занимает второе место по занимаемому месту. И не при индексации ли этого справочника вываливается с ошибкой. (разумеется индексация не проходит и в этой статистике ее нет). Посмотреть бы еще последнюю операцию в профайлере перед падением.

(139) Это некий справочник называется-Справочник.ХранилищеДополнительнойИнформации
В нем я храню фотки сотрудников и вывожу их при открытии справочника физ лиц и еще отображается при прохождении по карточке в столовой.

+(140) фотки мы спецом обработываем перех хранением приводим в объем менее чем 50 кб

(140)  реквизиты этого справочника -сколько и их длина ?

(142) В этом справочнике есть 5 реквизитов.
Из них 2 типа хранилище 1 текс неограниченной длины.

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

(143) а реквизит текст неогранич длины индексируется или нет?

(143) А что с индексами на этих реквизитах?

В этих реквизитах одна индексируется а другая нет.

(146) Попробуй убрать индексы со всех реквизитов на этом справочнике. (или они реально очень нужны? для чего?)
и в (133)
"
БАза отпочковалась но заняло 28,5 ГБ (MDF) "
Размеры таблиц в (137) приведены из этой "распухшей" базы?

(147) Да из этой базы
Уже пробую убрать индексы.
Я даже пытаюсь реквизит неограниченной длины делать 250 символов.
И еще меня смущает что ревизиты названы "Объект" "ИмяФайла"

Кто-нибудь может подсказать как мне избавится от пустых таблиц в скуле от удаленных объектов как РН РС
Они у меня до сих пор висят. Пример
AccumRgAggDict1h446;
AccumRgAggDict2h447;
AccumRgAggDict3h448;
AccumRgDlK449;
AccumRgBfK450;
AccumRgSt451;
AccumRgAggDict1h461;
AccumRgAggDict2h462;
AccumRgAggDict3h463;
AccumRgDlK464;
AccumRgBfK465;
AccumRgSt466;
AccumRgAggDict3h478;
AccumRgDlK479;
AccumRgBfK480;
InfoRgOpt546;
InfoRgOpt559;
InfoRgOpt670;
AccumRgAggDict1h781;
AccumRgDlK782;
AccumRgBfK783;
....

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

(150) а вы кто по образованию если не секрет?

(150) DROP TABLE AccumRgDlK782

в скуле в QA или что там в новых версиях.

(152)+ Это если радикально :).

(151) Я по образвнию военный-инженер. Но вот уже 14 лет я не военный-инженер а 1сник.

(150) Чур меня чур от такого.

(155) Не понял. о чем вы.
Я удаляю чтоб понять на каком объекте у меня трабла.

Решил отписаться.
Перенос данных обработкой ВыгрузкаЗагрузкаДанныхXML
кажется помогло.
Еще проверю данные..

Но база начала загружатся в файловую.
Файловая весит 324 мб slq-ная 458 мб (mdf)

Разве такое возможно?

(157) Так размер mdf совсем не показатель того, сколько данные в скуле занимают.

(158) В скуле в свойствах показывает 402 мб А вот исходная БАЗА показывает 4.404 гб А после сжатия 1.102 ГБ

(157) давно уже известно что выгрузка в dt если в базе имеются  какие либо проблемы только увеличивает ее-эту проблему.

160 постов на тему, которая выеденного яйца не стоит. Все сказано в (51) "dt это сжатый файл и сама база может быть на порядок больше".

Плюс непонятно, нахрена выгружать dt, если скуля нет.
Просто архивировать 1CD и его кидать. 1С так и рекомендует, кстати.

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

(161) Прошу прощения в (51) Это не корректные данные.
Я позже уточнял.

(163) С чего бы он еще очень далеко. Читай (51).

(165) Еще раз уточню что и как было.
1. Самописку начал писать 1го июня 2013го.
2. База была файловой
3. Но поняв что для количества юзеров более 10 файловая по скорости слабовата, а терминал для половины юзеров нельзя создавать принял решение перевести на скуль. На тот момент база весил быть может десятки мб. Это где-то нчачало авгутса.
4. Разработка велась в то время на файловой. И я каждый раз данные чтоб были свежими со скуля грузил в файл.
5.Но в один прекрасный день база отказался грузится со скуля в файловый.
6. Пришлось мне перейти самому в скуль. Это в октябре.
7. Но туту я прочел что у файловой ограничеиние в 4 гига на талицу. А уменя база еще до 200 мб не дошло.
8. на момент поиска проблемы (начало года 2014) у меня скуль показывал от от 2.8 до 4 гига. Но выгрузка была всегда где-то 58-59 мб
9. После решения проблемы база в выгрузке стала 43 мб. А развернутая 324 мб а в скуле 400 мб.