v7: v7 Ошибки в оперативных итогах #789910

Есть SQL база. Ядро 27. MS SQL 2000. 15Гб - небольшая. На основе ТиС 9.2. В ней все - ок. Проблем нет. Но с недавних пор: когда делаю периферийную новую файловую (через romix), то в новой базе некорректные опер итоги. Причем не разные позиции номенклатуры по разным месяцам дают некорректный итог. Некорректность в том, что не видит начальных остатков. Беру период побольше - видит. Пробовал Тии - непомогло. Частично помогает сдвиг назад ТА (на год назад) и перенос ее обратно без перепроведения документов. Большинство позиций пролечило. Но часть видимо надо больше чем на год назад сдвигать. Посоветуйте направление

Наверно в файловой индексы бьются...

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

направление простое: 1.реиндекс с предв.удалением индексов. 2. пересчет итогов (можно из ТиИ)

ну и макс размер файлика смотреть, конечно...

при загрузке базы итоги пересчитываются.

dbf - размеры?

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

на sql или на файловой? макс размер dbf не прошли еще. Самый большой регистр с партиями 1,1 Гб файл, остальные все до 1 гб

1-ое сделай скульную перефирию - посмотри как там с итогами 2-ое сделай не через ромикс - объем выгрузки файла сколько ? датовского

не через ромикс никак. объем большой. sql периферию попробую

up

чего ап? Итоги бьются только из-за индексов. И если ошибка появляется после полной переиндексации выгруженной базы - значит уже достигнут максимальный размер файла. Была разработка одна... она решала проблему "больших файлов ДБФ". Но помойму она померла.

вот этв:

на проблемной ПБ, конечно.. 1.1 Г - уже больше, чем можно в разделенном. сиквельные ПБ можно и склонировать. итоги могут съезжать в разделенном из-за  размеров. решение hogik'а живо. было бы желание...

Чет косяк какой-то:

а... миста подменяет ссылки.... ужАс :-))

приватизирует

вроде предел был 2Гб?

ну...  при 2 гигах вообще перестает работать. После 1 гига возможны ошибки

2 гига-это предельный размер дбф. В разделенном режиме при файле >1 гига идёт ошибка по чтению, отсюда, разные результаты в отчете. Итого, либо ставить это и работать дальше, или свётка/оптимизация табличек регистра.

Ну и это, огласи размер RG и RA проблемного регистра. Если RG у тебя > RA , то просто регистр не закрывается и нужно всего лишь его исправить (чтоб правильно закрывался). И усё.

RG328.DBF 1,2гб, RG328.CDX 1,1гб Регистр закрывается в 0. Файл индексов большой, т.к. у меня у измерений стоят галки отбор движений и отбор итогов. Много отчетов на этом регистре работают - для ускорения добавил

попробовал развернуть в sql периферию. загрузилась ромиксом нормально. Но при попытке формирования отчетов выдает sql ошибке 42000 Cannot resolve collation conflict for equal operation

RA328 Сколько ? поди 100 метров или еще меньше, да ? :))

sql ошибке 42000 - решил - кодировку не верно сам выставил RA328.DBF - 964мб / RA328.CDX - 160мб

дык и движения к пределу подкрадываются...

зобей в яндекс (но это для SQL) а с дбф я б уверен не был быстрое создание периферийной базы 1с 77

ну вот и ответ. RG> RA регистр не закрыт. При закрытом регистре, RG, даже с периодичностью в 5 дней был бы не более 300 метров.

тут только или ставить заплатку из или исправлять.

при такой разнице - он вполне может быть закрыт. а бОльший размер иметь из-за добавленных реквизитов.

все ключевые рабочие места  подключены к периферийным sql базам. т.е. я правильно понимаю, что потеря данных им не грозит? А если на файловой будет превышение (например, RA328 > 1,2 гб, т.е. потеря движений), то после обмена с центром, на центре все ок будет или там тоже потеряются часть движений? Все файловые в общем-то однопользовательские. Вот решили новую файловую для отчетов создать. Там только обмен с центром и запуск отчетов, никто не будет ничего вводить. закрыт. там просто больше 50т остатков реальных по разным складам. большой оборот

#=============================================================================== #==TABLE no 249    : Регистр ПартииНаличие # Name    |Descr                         |Type[A/S/U]|DBTableName|ReUsable   T=RG328   |Регистр ПартииНаличие         |A          |RG328      |1         #-----Fields------- # Name      |Descr               |Type|Length|Precision F=PERIOD    |Period Registr      |D   |8     |0         F=SP4061    |(P)Фирма            |C   |9     |0         F=SP330     |(P)МОЛ              |C   |9     |0         F=SP331     |(P)Номенклатура     |C   |9     |0         F=SP340     |(P)СтатусПартии     |C   |9     |0         F=SP341     |(P)Партия           |C   |9     |0         F=SP1554    |(P)ДатаПартии       |D   |8     |0         F=SP7404    |(P)ЦенаПрод         |N   |16    |2         F=SP342     |(P)Количество       |N   |16    |5         F=SP421     |(P)СуммаУпр         |N   |16    |2         F=SP343     |(P)СуммаРуб         |N   |16    |2         F=SP344     |(P)СуммаБезНДС      |N   |16    |2         #----Indexes------ # Name     |Descr         |Unique|Indexed fields                                              |DBName     I=PROP     |PERIOD+PROP   |0     |PERIOD,SP4061,SP330,SP331,SP340,SP341,SP1554,SP7404         |PROP       I=VIA330   |VIA330        |0     |PERIOD,SP330                                                |VIA330     I=VIA331   |VIA331        |0     |PERIOD,SP331                                                |VIA331     # #=============================================================================== #==TABLE no 250    : Регистр (Дв.) ПартииНаличие # Name    |Descr                         |Type[A/S/U]|DBTableName|ReUsable   T=RA328   |Регистр (Дв.) ПартииНаличие   |A          |RA328      |1         #-----Fields------- # Name      |Descr               |Type|Length|Precision F=IDDOC     |ID Document's       |C   |9     |0         F=LINENO    |LineNo              |N   |4     |0         F=ACTNO     |Action No           |N   |6     |0         F=DEBKRED   |Flag Debet/Kredit   |N   |1     |0         F=IDDOCDEF  |ID Def Document     |C   |4     |0         F=DATE      |date                |D   |8     |0         F=TIME      |Time                |C   |6     |0         F=SP4061    |(P)Фирма            |C   |9     |0         F=SP330     |(P)МОЛ              |C   |9     |0         F=SP331     |(P)Номенклатура     |C   |9     |0         F=SP340     |(P)СтатусПартии     |C   |9     |0         F=SP341     |(P)Партия           |C   |9     |0         F=SP1554    |(P)ДатаПартии       |D   |8     |0         F=SP7404    |(P)ЦенаПрод         |N   |16    |2         F=SP342     |(P)Количество       |N   |16    |5         F=SP421     |(P)СуммаУпр         |N   |16    |2         F=SP343     |(P)СуммаРуб         |N   |16    |2         F=SP344     |(P)СуммаБезНДС      |N   |16    |2         F=SP347     |(P)КодОперации      |C   |9     |0         F=SP6818    |(P)ПродСтоимость    |N   |19    |2         F=SP7685    |(P)Выручка          |N   |16    |2         #----Indexes------ # Name     |Descr         |Unique|Indexed fields                                              |DBName     I=IDLINE   |of IDDOC+LineN|0     |IDDOC,LINENO,ACTNO                                          |IDLINE     I=VIA347   |VIA347        |0     |SP347,DATE,TIME,IDDOC,LINENO,ACTNO                          |VIA347     #

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

вот готовая поделка

но всё равно, он не закрыт по партиям.

выгрузи итоги в тз, там и так всё видно, почему, и по какому измерению не закрывается

согласен.

под заплаткой имеется ввиду Kernel3x?

или лучше DBEng32 ?

решение в

у нас оно работало не один год, ибо основные регистры были 1.8-1.9 гигов и база в дбф > 20 гигов, и ничего, шевелилась

развернул новую периферию на sql там тоже есть ошибки с остатками в партиях в старых sql таких нет ошибки. получается это еще 1 проблема? или это 1 корни?

не должно такого быть. Данные все мигрируют?

как перефирийку то создавал ?

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

Это же не наш метод! :)

В скуле проверь регистры этим, хотя бы

не наш :-) но ихний :-)))

или

да, стандартным способом, только ромикс

проще клонировать

подскажи другой способ. Только надо что обмен с центром потом работал

это и есть самый прстой способ.

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

по итогу получилось: обработкой сжал rg328 раза в 2-3. Но RA328 уже подходит к пределу = 1,1Гб

Можно еще слегка урезать. Тебе там нужно Количество.15.5? Измерение ЦенаПрод, ДатаПартии нужно? Убить если не нужно, это тот случай когда ломать быстрее чем строить...