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

Пробовал Тии - непомогло. Частично помогает сдвиг назад ТА (на год назад) и перенос ее обратно без перепроведения документов. Большинство позиций пролечило. Но часть видимо надо больше чем на год назад сдвигать.

Посоветуйте направление

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

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

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

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

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

>15Гб - небольшая
dbf - размеры?

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

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

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

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

up

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

Была разработка одна... она решала проблему "больших файлов ДБФ". Но помойму она померла.

вот этв: http://catalog.mista.ru/public/15211/

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

Чет косяк какой-то: http://catalog.mista.ru/public/15211/

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

(16) приватизирует

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

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

(18) 2 гига-это предельный размер дбф. В разделенном режиме при файле >1 гига идёт ошибка по чтению, отсюда, разные результаты в отчете.
Итого, либо ставить это
http://catalog.mista.ru/public/15577/
и работать дальше, или свётка/оптимизация табличек регистра.

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

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

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

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

sql ошибке 42000 - решил - кодировку не верно сам выставил

(22) RA328.DBF - 964мб / RA328.CDX - 160мб

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

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

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

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

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

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

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

(29) закрыт. там просто больше 50т остатков реальных по разным складам. большой оборот

(30) #===============================================================================
#==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    
#

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

http://catalog.mista.ru/public/180018/

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

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

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

(33) согласен.

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

(39) или лучше DBEng32 ?

(39) решение в (20)

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

(42) развернул новую периферию на sql там тоже есть ошибки с остатками в партиях

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

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

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

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

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

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

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

http://www.1cpp.ru/forum/YaBB.pl?num=1228926967

(50) или http://catalog.mista.ru/public/61025/

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

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

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

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

(55) вроде все сделал для http://catalog.mista.ru/public/15577/

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

1cpp загрузил

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

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