Здравствуйте.  Описываю ситуацию: файловая база превысила 50Гб в размере (УТ 10.3) платформа 8.1.15.14  , было принято решение перенести ее на SQL, поставили MSSQL 2012. Кроме этой базы на сервере  живет розница 8.1, пока файловая. Между ними был настроен обмен, запускался из УТ 10.3 напрямую через подключение к базе Розница, запускался двусторонний обмен. Сейчас при запуске обмена выходят странные ошибки : Ошибка при вызове метода контекста ВыполнитьВыгрузку, переменная не определена "ВариантНастройки периода", ругался на диалоги в документах, помогло когда добавила #НаКлиенте... Другие странности. Чем можно такое полечить?

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

(1) можете и то, и то описать? Читала что платформа данная не дружит с MS 12, чтобы заменить сразу трудновато, с Розницей идет обмен по РИБам, их больше 20, получается там тоже менять надо сразу

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

то есть программист был или лентяй или чайник...

запусти проверку конфигурации с галочкой "сервер"

(2)
1. gdb dna
2. Пригласить специалиста

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

Нет, серьезно 8.1.15.14 под SQL2012 нормально работать не будет?

(6) У тебя версия скуля совершенно ни причём.
У тебя код кривой, не предназначенный для серверной версии.

(4) про gdb dna можно подробнее

(5) воодушевило, просто это новое место работы, 2 недели всего там , и на 2-ой неделе было с УТ ничего не сделать - превышен максимальный размер файла... 50ГБ, только начальство не понимает всех технич моментов - как это ведь все так хорошо работало? вы перешли на SQL, почему проблемы?

(6) поищите, Гилев выкладывал даже спец. скрипт под это дело

(5), (7) как грамотнее подойти без вызова спеца?

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

(8) так и скажи руководству:

старый прог видел, что скоро наступит биг барабум и свалил...

а вообще у вас есть и другой вариант - обрезка базы....

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

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

(7) Нет, не у меня - я не ТС. Мне просто интересно.

(13) или свертка+обрезка базы....

свертак не шла - тоже превышен доп размер файла

(0) ... файловая база превысила 50Гб...

Как-то не верится.

(10) такое сообщ выдавалось при проведении док. отчет о розничных продажах



(17)  розница файловая сейчас 40 Гб

(18) "такое сообщ выдавалось при проведении док. отчет о розничных продажах"

ты явно не понимаешь о чем я написал. Либо изучай и понимай, либо вызывай специалиста.

(18) Легко, ограничения стоят на одну таблицу, а количество таблиц может быть сотни.

(8) раньше (8.1) файловая блокировалась, если хотя бы один из трех сегментов (данных, индексов, строк н/д) превышал 2Гб. Сейчас видимо увеличили. Только файловая - зло по-любому.

(0) иди путем наименьшего сопротивления. Сначала правь код с явными ошибками. Затем подчищай неявные  -когда будет работать без вылетов

(21) всегда было 4ГБ

(20) не на таблицу. На внутренний файл.

(22) 3Гб база блокировалась

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

(24) Нет.

(25) Если работает один пользователь, то откуда тормоза? Скуль будет посасывать в сторонке

(27) Гм. С файловыми базами таких размеров не работал. Но могу сказать, что профессиональная под(д)елка OutGluuk при размере файла 10-12 Гб хорошенько тормозит комп. Особенно, если ей вбредёт в голову что-либо прооптимизировать.

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

спасибо за советы!!!

(30) попробуйте сделать ТИИ с реструктуризацией таблиц, может сократить размер БД, что позволить вернуться на файловый вариант и заиметь некий промежуток времени на тестирование и исправление ошибок в коде. Чтоб ненапрямую пациента резать

Кстати на счет овнокода без
#Если Клиент Тогда
#КонецЕсли

#Если Сервер Тогда
#КонецЕсли

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

Мы вот как то столкнулись в одной фирем с таким, база работала на SQL 5 лет, обмен РИБ запускали руками, а когда попытались запускать обмен через рег. задание, вот тут то и выяснилось что 1700 ошибок в коде. Исправили их кстати всего за 2-3 дня работы.

(32) хорошее слово МЫ))))

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

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

Но и еще момент, те ошибки в коде при выполнении на Клиенте и на Сервере - это же только при работе с обменами? Т.е. дописывание было "кривым" именно в этом месте.

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

(33) Мы просто несколько фирм обслуживали и мы - это команда ))

(35) а прозвучало как -  Мы, Повелитель ВсеЯ Вселенной )

(36) Спасибо, поржал )))