Забаяню.
Размер файлов RA*.dbf, RG*.dbf и DT*.dbf превысил 1 ГБ.
Работа в разделенном режиме, к каким неприятным последствиям это ведет?

размер одного файла ?

Вроде же 2ГБ предел?

только одно - ошибка по чтению файла > ~1.1 гиг, и как следствие, радуга в отчетах.
При монопольном режиме, 1с-ина держит до 2-х..
С заплаткой от hogik, тоже до 2-х в разделенном режиме без ошибок.

RA99.DBF - 866 105 КБ
RG169.DBF - 1 164 460 КБ
DT3163.DBF - 1 473 355 КБ
...
DT2992.DBF - 2 097 134 КБ

(4) ставь заплатку от hogik и спи спокойно

и это, RG169.DBF - вот этот регистр закрой..

Вот этот регистр RG169.DBF надо бы почистить да и табличные части документов DT3163.DBF и DT2992.DBF

Сверни базу, по-народному "обрежь старый период".

RA169 поди в разы меньше ?

RA99.DBF - это остатки товаров, отчету по остаткам товаров еще можно верить?
RG169.DBF - 1 164 460 КБ - Взаиморасчеты. Тут в отчетах будет уже вранье?
DT3163.DBF - это расходная накладная. То что размер > 1 ГБ у ТЧ документа, будут проблемы по его чтению/записи?

RG169 партии небось...

RA169.DBF - 30 055 КБ.
Т.е. не закрыты остатки взаиморасчетов?

(9) см (8)

(5) Достаточно провести по всем контрагентам документ корректировка задолженности, который поставит в ноль все измерения?

(5) Заплаток ставить не хочу.

(8) Да, отчету по остаткам товаров еще можно верить. Просто не затягивай, когда база прекратит своё существование.
Начинай изобретать велосипед (зачеркнуто) свертку.
Сколько человек одновременно работает в базе? По сети или в терминале?
На своей первой работе я 6 лет каждые 3-4 месяца резал базу. Как вырастала до 600-700 метров (с индексами), наччинались тормоза, так и резал.

(8) остаткам можно верить, взаиморасчетам - нет, в разделенном режиме несколько раз понажимай на сформировать в типовом отчете - получишь разные циферки

(13) тогда только свёртка или переход на скуль.
А так, заплатка от Владимира - лучшее лекарство.

RA169.DBF - 30 055 КБ.  - это жесть..
:))

Тут нужно править регистр, а не пытаться его обмануть каким-то там документом корректировочным

(16) я знаю ее, пользовался.

(17) Как править? Научи

при таком файле, твой RG169 должен быть максимум..10 метров (или меньше)

(20) дать тебе файл на поглядеть?

(20)  Может, там... строка неограниченной длины и хранится в 1sConst? Или индексы на каждом поле... Хотя соотношение не здраво

(19) смотришь движения доков, которые делают приход и расход, думаешь..много думаешь.

У тебя приход в регистр с одним набором измерений, расход - с другими (или с незаполненными).
При открытии периода эти строки летят в следующий период  и т.д.

(21)  Покажи кусок .dd с описанием RG169

(21) не надо, перечисли структуру регистра лучше.

(23) Нет, там другая проблема. Отгрузку клиентам делают, а оплату не проводят, вот остатки и растут.

(26)  А смысл? Денех когда-то дают или нет? Всё в долг? ТОгда может имеет смысл нарисовать закрытие регистра по результатам месяца...

(24)

(24)
#==TABLE no 169    : Регистр УчетКредита
# Name    |Descr                         |Type[A/S/U]|DBTableName|ReUsable  
T=RG169   |Регистр УчетКредита           |A          |RG169      |1        
#-----Fields-------
# Name      |Descr               |Type|Length|Precision
F=PERIOD    |Period Registr      |D   |8     |0        
F=SP170     |(P)Клиент           |C   |9     |0        
F=SP405     |(P)КредДокумент     |C   |13    |0        
F=SP171     |(P)Долг             |N   |16    |5        
#----Indexes------
# Name     |Descr         |Unique|Indexed fields                                              |DBName    
I=PROP     |PERIOD+PROP   |0     |PERIOD,SP170,SP405                                          |PROP      
#

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

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

У него 900 обособленных подразделений, по ним долги не закрываются

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

(32): ты ж на Т1С есть вроде. там постеснялся вопрос задать потому что засмеют?.. )))

(33): сверни без переноса долгов - поможет хотя бы частично.

(25)
Измерения:
- Клиент - справочник.Клиенты
- КредДокумент - документ неопр. вида
Ресурсы
- Долг - Число.15.5
Реквизиты
- нет
(отбор движений, итогов, быстрая обработка движений: отключены)

(34) Там Ёпрст редко появляется

(35) А если не свернуть, а просто грохнуть регистр долгов, оставив в нем только настоящие долги?

(30) значит, по "особым клиентам" не двигай взаиморасчеты...

(39) Это надо БЫЛО делать, а что делать СЕЙЧАС?

(34) Тут засмеять гораздо легче... а обоср@ть - легче на порядок :-)))

(40) Ну, поксерь взаиморасчеты по ним напрямую, и пересчитай итоги

(42) Что такое поксерь?

ну, или как вариант - прямо в итогах по этим клиентам

(43)вместо "кс" употреби букву "Х"

(45) вместо "кс" употреби букву "икс"? )))

А про DT*.dbf что? Там не страшно превышение 1ГБ?

(47) в общем-то, да.
Но проверь количество помеченных на удаление записей

Если я просто в ноль закрою документом Корректировка остатки долгов клиентов в разрезе всех измерений, это уменьшит размер файл RG*?

(49) не сильно. только в последнем периоде

(47) по dt пофик, по-поводу взаиморасчетов - у тя всё зависло на кредДоках..

можешь свернуть и в кред док запихасть сам документ ввода останков.

(51) ой ли?

Простой тест:

ВыгрузитьИтоги сделай в ТЗ этого регистра и сверни по клиентосу увидишь, сколько "лишних" строк у тя в регистре (+ еще нулевые строки (с нулём в ресурсах после такой свёртки) надо прибить)

(52) да стопудово :)

чего там еще может быть при 2-х измерениях ?
Ну разве что оплаты не ведёт в этой базе ... совсем

(51) Это базу сворачивать придется. Если решения без свертки базы?

(55) ну да, оплаты не ведут по половине клиентов.

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

(47)  Для файловой любой файл ДБФ до 2 гигов пишется.
Больше 1 гига не успевает читать или кешировать данные или что там происходит - тебе писали "сформируй несколько раз подряд один и тот же отчет"

(57)  На будущее добавь контрагентам реквизит "вести оплату". И если вести - то путь ведется. Иначе нечего засорять регистр. А для упоротых бухов сделать отчет, но это уже выборка по документам, что некрасиво.

(58) имхается, что у него с чтением табчасти тоже будет "радуга"
Много лет проблем не было, а документы превышали 1 ГБ.
Инфа проверена?

(60) Реквизит уже добавил.

(61) у меня базы сиквельные, ибо большие...

а какой конкретно размер файла в байтах является гранично-проблемным 1ГБ...?

(64) Так тебе в байтах или гигабайтах?

(65) да хоть так, хоть так - лишь бы однозначно. Если 1ГБ = 1024МБ=1024*1024Кб=1024*1024*1024Б - то я и сам вычислю...

у меня та же самая проблема но в бухии - файл проводок стоит сейчас = 1010Мб.
ранее ятоже вылезал с этой проблемой.
Похерил часть забалансового учета ГТД - помогло но ненадолго.
Базу резать не дают.
Скульный движок - отсутсвует.
Заплатку Ходжика ставить - можно, но надо на программном уровне тогда прописывать проверку легитимности запуска конкретной базы на конкретном движке, бо заплатака "конфликтует" с прямыми запросами - которые у меня юзаются в торгбазе (но торгбаза не пухлая!).  А разные движки на разные базы - программную проверку стопудово надо влепить, а то выберут юзвери движок один, а базу - другую...

блин, осталось урезать СодержаниеПроводки и ПервичныйДокумент - получится сэкономить 248Мб
.
если Длину строковго реквизита поставить = 0 - программное обращение на чтение и запись в такой реквизит - не приведут к траблам?

(67): а разные сборки "движка" по разным папкам распихать? и стартовать "бушную" с kernel3x, а торговую без?..

(69) ну да, только при этом надо подстраховать, чтобы из списка баз выбирались НУЖНЫЕ для этого движка, а то попа будет. а альтернативне стартеры привлекать влом.

насчет конфликта с прямыми запросами - это я возможно погорячился

(69) и, внимание, вопрос: чем будет стартоваться бухняя база, открываемая по ОЛЕ из торговли?

О, приди, могучий Ёпрст!
kernel33 с прямыми запросами на DBF (посредство фокспрошного драйвера) - нормуль?

Почему такой запрос валит 1с без всяких объяснений:

Период с НачДата по КонДата;
ОбрабатыватьДокументы Проведенные;
Док = Документ.РасходнаяКредит21.ТекущийДокумент, Документ.РасходнаяКредит5.ТекущийДокумент, Документ.РасходнаяКредит6.ТекущийДокумент, Документ.РасходнаяКредит4.ТекущийДокумент, Документ.РасходнаяКредит3.ТекущийДокумент, Документ.РасходнаяКредит2.ТекущийДокумент, Документ.РасходнаяКредит.ТекущийДокумент, Документ.ПриходнаяКредитНов.ТекущийДокумент, Документ.ПриходнаяКредит.ТекущийДокумент;
Контрагент = Документ.РасходнаяКредит21.Клиент, Документ.РасходнаяКредит5.Клиент, Документ.РасходнаяКредит6.Клиент, Документ.РасходнаяКредит4.Клиент, Документ.РасходнаяКредит3.Клиент, Документ.РасходнаяКредит2.Клиент, Документ.РасходнаяКредит.Клиент, Документ.ПриходнаяКредитНов.Клиент, Документ.ПриходнаяКредит.Клиент;
Товар = Документ.РасходнаяКредит21.Товар, Документ.РасходнаяКредит5.Товар, Документ.РасходнаяКредит6.Товар, Документ.РасходнаяКредит4.Товар, Документ.РасходнаяКредит3.Товар, Документ.РасходнаяКредит2.Товар, Документ.РасходнаяКредит.Товар, Документ.ПриходнаяКредитНов.Товар, Документ.ПриходнаяКредит.Товар;
Кол =  Документ.РасходнаяКредит21.Количество, Документ.РасходнаяКредит5.Количество, Документ.РасходнаяКредит6.Количество, Документ.РасходнаяКредит4.Количество, Документ.РасходнаяКредит3.Количество, Документ.РасходнаяКредит2.Количество, Документ.РасходнаяКредит.Количество, Документ.ПриходнаяКредитНов.Количество, Документ.ПриходнаяКредит.Количество;
Мест = Документ.РасходнаяКредит21.Коэффициент, Документ.РасходнаяКредит5.Коэффициент, Документ.РасходнаяКредит6.Коэффициент, Документ.РасходнаяКредит4.Коэффициент, Документ.РасходнаяКредит3.Коэффициент, Документ.РасходнаяКредит2.Коэффициент, Документ.РасходнаяКредит.Коэффициент, Документ.ПриходнаяКредитНов.Коэффициент, Документ.ПриходнаяКредит.Коэффициент;
ВидПоставщика = Документ.ПриходнаяКредитНов.ВидПрихода1;
Функция КолВоКред = Сумма(Кол*Мест*Товар.Емкость);
Группировка Контрагент Без Групп;
Группировка Товар Без Групп;
Группировка Док;
Группировка СтрокаДокумента;
Условие (Кол <> 0);

Падать 1С стала после того как я добавил строку:
ВидПоставщика = Документ.ПриходнаяКредитНов.ВидПрихода1;

(74) приду домой гляну

вопрос: база скульная или дБФ?

бегло? я бы тоже упал

(68) Сделай СодержаниеПроводки справочником...

(67) она не конфликтует с ними - никак.
Единственный минус - запрос на фоксе монопольно не выполнить. всё.

(73) нормуль

(76) дбф

Я спрашивал "А про DT*.dbf что? Там не страшно превышение 1ГБ?"
И что оказалось? У меня черный запрос в (74) обращается к документам, в том числе к одному, по которому размер превышен 1 ГБ. И что в итоге?
По всем документам кроме того, который превысил предел, цифры в отчете постоянные. Для превысившего - отчет каждый раз показывает разные цифры.
Значит, не только регистры, но и документы, DT*.dbf которых превысил 1ГБ, показывают в отчетах радугу!
Прошу подтвердить или опровергнуть мой вывод!!!

а в скуль или обрезку ?

+(82) Это в проявляется в разделенном режиме, пока пользователи активно используют этот документ на запись.
Если я запрос переделаю на регистры, то проблема уйдет?
База дбф. Это видно из названия файла.

+(82) Если работаю монопольно, то отчет показывает от раза к разу одни и те же цифры.

ты пытаешься выкрутиться с проблемы. я же спрашиваю или можно решить проблему с ее зачатка.

(86) Я понял. Будет обрезка базы. Но не сегодня, а завтра. А сегодня надо проблему решить по-другому и поставить диагноз, поэтому жду ответа на (82).

так скажи что не как до завтра или за 100500. может кто то и согласится за 5000 :)

с пнд поставил ходжиковскую заплатку на 1ГБ. все работает нормуль. даже вроде и монопольном режиме фоксовский провайдер тоже фурычит...
.
(87) так что ставь заплатку и все нормуль.. еще поживешь немного, пока к 2 ГБ не подтянется

(89) Нет, сделал копию базы, в ней отчет формирую монопольно. А завтра буду базу резать.

>>> Размер файлов *.dbf превысил 1 ГБ
О ужас, мы все умрем!!!???

>>>Работа в разделенном режиме, к каким неприятным последствиям это ведет?

Ряд неприятностей при работе с таким барахлом и пренебрегаем инструкцией свертки БД ежегодно или при достижении до 1Гб:
1. У вас перестанут нормально формироваться Запросы на языке 1С
2. У вас будут скакать остатки по этому регистру абы как и абы куда
3. У вас так же будут неадекватные обороты, и следовательно читай пункт № 2
4. При достижении 2Гб, вы поймаете "реального глюка" (лениград) http://www.youtube.com/watch?v=WvBrRFLwT_Q
При этом по пункту №4 у вас будет частичное потеря данных и более вы не сможете работать в БД. Решение одно, делать Бекапы "Бекап наше все" (жизнь Админа не делавшего бекап)
5. Так же возникнут различного рода транзакции и замедление работы с БД

(74)>>> Падать 1С стала после того как я добавил строку:
Парой, бывает, что стоит проникнуться во все тяжкие этими (91) пятью пунктами :)

Я что то не понимаю, в чем проблема sql express развернуть простейший? Я вообще не заморачиваюсь, даже ковырятся не надо превысили пи/дуйте на sql, нет денег юзайте sql express, благо все хорошо у 1с.

(93) Это 2005-ый? С которым не совместима 77?

у меня 7ка вообще на 2010 крутится, меняете длл и все работает.

(95) пардон, 2008r2

(95) и садитесь на поезд Москва-Варкута...

(97) Я может не понял юмор? или шутка была не смешная?

(98) ты прав. шутка совсем не смешная

(99) Куплено все у нас, когда еще деньги водились.

И гибкие блокировки от софт поинта и sql 2005 потом 2008 и toysql, и зачем то еще 50 лицензий winxp home, до сих пор валяются никому перепродать нельзя теперь даже)