База ТиС. При открытии периода возникает ошибка :

ERROR  # -120
Writing to file
…\RG328.DBF

Файл этот «Регистры партии наличие» размер 2.095 GB достиг предельного размера.
Регистр этот был не закрыт, так как из-за манипуляций с себестоимостью осталось много записей где количество номенклатуры равно 0 , а остаточная себестоимость есть.
Регистр я закрыл списав остатки себестоимости специальным документом, но размер файла файла это естественно не повлияло.
Мне нужно БЫСТРО оживить базу открыв период.  Корректность партионных остатков вообще не очень критична, так как организация через два месяца прекратит работу.

Рассматривал следующие варианты:
1.    Перевод на SQL – не подходит т.к загрузка ИБ будет идти с пересчетом итогов и займет более недели.
2.    Обрезание - не очень бы хотелось, так как нет людских ресурсов корректно вбить остатки  по взаиморасчетам. Обрезание тоже делать не быстро. И к тому же база фактически скоро будет неактуальна.
3.    Пересчет итогов  - будет идти слишком долго
4.    Kernel33 – в этом случае имхо не поможет
5.    Проведение только по регистру партии поможет ?

можно попробовать свернуть базу.

вот тока быстро это нефига не получится.

>>>>1.    Перевод на SQL – не подходит т.к загрузка ИБ будет идти с пересчетом итогов и займет более недели.


5-6 часов, не более

(3) это если на приличном серваке делать. А тут явно - обычный калькулятор.

(0) А сжать файлик не пробовали?

(5) не поможет

(0) 5. нет

(0) 3. при незакрытом регистре - долго, при закрывающемся - минуты на любом размере базы.

А так.. кастрировал лишнюю аналитику в регистре и.. забыл

(3,4) в последений раз говорят шла все новогодние праздники. СКЛ там нет

(8) ам данные с 2005 года и накосорезено достаточно. Добиться его  закрываемости нереально. Так как гоняли черное белое меж фирамами.

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

гы-гы-гы... следующий пошёл

(10) если не делать полный пересчет регистров, то ничего.
А вот во всех отчетах за прошлые года - болт.
Перепроведение доков - аналогично.

4. поможет, но там есть много нюансов

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

(13) не поможет. Превышен порог в 2 гига.

(13) я писал файл два гига
(14) файл как физически ужать чтобы сделать открытие периода ?

(15) ага, согласен, невнимательно прочитал. а как же они раньше-то работали?

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

(16) для начала, выкинуть delete всех строк, где значения всех ресурсов = 0 + сжатие.

Может, поможет
http://infostart.ru/public/17072/
использовала в похожей ситуации

(19)  Дело ! Может сразу все где количество равно 0 ?

(21) нет.
у тя могли "суммы" повиснуть

когда-то была такая разработка
DBEng32 - клиент/серверное использование DBFной версии 1С:Предприятие 7.7

(22) Я  их занулил документом корректировки себестоимости.

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

(8) А как проверить закрывается регистр или нет на больгшом объеме ?
Ведь закрываться он должен в каждом периоде ?

(26) достаточно посмотреть на размер RA328.DBF  и сделать выводы.
Он то поди, пару метров всего ?

(27)  475 Гб

(27) извини описался . метров естественно

(29) вот при таком размере RA , RG должен быть метров 100 и меньше.

Измерения то в регистре какие хоть ?

(30) это при большой оборачиваемости товара. А если супермегазапасы, созданные кучей мелких - приходов всегда будет дохренища "незакрытых" партий и соотношение будет поменьше... посмотрел у сеяб сейчас RA = 205 Мб, RG = 9Мб, но у меня партии по среднему... и крупнооптовые поставки

(32) да при любом расскладе, RG<RA

(33) убедил! ;-)

если только, не односторонее движение в RA (одни приходы, к примеру)

(35) это явно учет "закормов родины"..

(33) не при любом :-)

(31) стандартные

(37) а, ну-ка, растяни баян...

(39) см. сабж :-)

(38) ну, можешь всё на одну партию повесить, раз нужен только количественный учет.

(40) юморист, однако... ;-)

Детсад.
Намедни имел дело с чудом - RA 86 м, RG 1.4 гига. 10 измерений.

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

(44) книжки - вообще прикол. представь, например, что в ТиС ведут учёт упрощенец или вменёнщик - ну вот нафига ему книжки в ТиС сводить? а типовая "всё пишет, пишет..."

(45) угу... я вообще книги, кассу, банк, вообще отрубил регистрацию.

(44) Посмотрел модули проведения.
Ни один программист не заморачивался закрытием регистра "Партии".

(47) что свидетельствует о том, что вопросы себестоимости при торговле - не главный вариант.. ;-)

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

(49) Програмёры непричём.
Тупой работодатель - у него хороший прог тот, кто молча и быстро сделает.

(50) ну почему же тупой - работодатель получил видимо за свои деньги то что хотел на тот момент.
а вот текущий момент - он должен стоит гоооооооррррраааазззддоооооооооооооооооо дороже

У мну например аналогичная ситуевина - УРБД, 7.7, на точки мигрирует куча ненужной инфы и незакрывающийся регистр партий (поступления только в центре).. ну вот 1го числа и вывалилась аналогичная бяка - бо файло перевалило за 2 гига... по УРБД я не спец, поэтому посоветовал клиент унайти урбдшника... для крамотной свертки...

(51) Тупой работодатель получив в итоге то, что и должен был получить, пребывает в недоумении - куда "хорошие" программисты подевались.
Все кто приходит - через месяц уходят, поняв, что база в предсмертных агониях.
Работодатель принимает гениальнейшее решение - завтра быстренько и очень дешёво (опять) перейдём на УПП и всё будет как раньше.

(53) ;-) порадовал..