v7: проблема при изменении точки актуальности #747152

конфигурация  Производство+услуги +.. 7.7  при  изменении  точки  актуальности  появляется  ошибка  Error #:-120  writing to File   ...RG1247.DBF  .  САМ  ФАЙЛ  2031М(огромный) . после  появления  ошибки  в  каталоге  програмных  файлов  правились  библиотеки seven.dll и dbeng32.dll  (взято из статьи Kernel3x ) для  того чтобы снять ограничение  на  размер  базы.  Результата  не было. Понятно  что  нужно  делать  свёртку (архивирование периода) - однозначно  но  в  процессе  свёртки  бухитогов  проблема  та  же.  а  при  свёртке  регистров  ругается  на  недостаток  памяти. Какие  ещё могут  быть  варианты  (sql  не  подходит - дорогостоящий  вариант)

для начала сторонней прогой (тот же дбф нафигатор и т.д.) пожми (упаковка - удаление помеченных на удаление записей) этот RG1247.DBF ЗЫ тока про бэкапы не забывать

+ потом можно и извращаться со сверткой

ок

те обработки решают проблемы неставильной работы базы при превышении файла 1ГБ. А сама ДБФка не может быть более 2 ГБ, так что эти заплатки бесполезны при размере файла более 2 ГБ.Свёртку можно попробовать сделать и под скулем, только потом его удалить после свёртки и продолжать пользоваться файловым режимом ;)

Прежде всего, разберись, почему не закрывается этот регистр.

походу  нет  никаких  помеченных на  удаление  записей( упаковка  таблиц  уже  делалась -  dbf редакторы не  находят

к  сожалению  пока  нет опыта  при работе  с регистрами

"нет ножек - нет и мультиков"©

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

Что за регистр?

в  файле  dd  указано  что rg1247.dbf это регистр партии - может из  него  выборкой  убрать  старые  записи  2008-2010  года а  потом  сжать или  всё  нужно  делать  только  процедурой  свёртки ?

Mikeware  -  не  могли  бы  с  этого  места  поподробнее  как  можно разбираться с закрытием регистра ?

Это программиста нужно позвать...

"Нет регистра - нет проблем" ©

или завести.....

программист не таракан, чтобы его заводить...

существенное  уточнение  .. гг

Сколько лет базе?

видимо, около семи...

Есть один нехитрый способ, когда прогера и скуля нет. Много лет назад на бухии прокатило. Должно и на оперучете проскочить

эээ имя файла rg*? ёк... это надо было стока незакрытых партий развести по остаткам...

+ вообщем простейший совет копируете базу грохаете все документы оставляя только справочники (удаляя dbf-ки нужные) причем возможно справочник партии тоже того далее переносите нужные остатки и документы с текущей кривой базы

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

"доктор сказал в морг - значит в морг"©

"все б им, хирургам, резать... попрыгай - сами отвалятся!"©

Дык уже отвалилось...

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

нулевые.

Не, видишь - еще дергается... ну хотя бы нули почисти, если их дохрена. только не забудь после того переиндексироваться

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

Однажды послали в космос двух собак и чукчу. Пошел первый виток, с Земли вызывают: - Белка! - Гав-гав! - Нажми красную кнопку! Пошел второй виток. - Стрелка! - Гав! - Нажми белую кнопку! Пошел третий виток. - Чукча! - Гав! - Ты чего гавкаешь?! Накорми собак и смотри, руками ничего не трогай! ©

смысл простой - в операциях прихода и в операциях расхода по партиям - набор измерений ДОЛЖЕН СОВПАДАТЬ. например: Регистр Измерения Приход - все понятно а расход тупой программер напрограммил, что списывается колво с указанием фирмы и номенклатуры... и все.. (_о_)

остались 0 по номенклатуре и косяки (не нулевые) по партиям...

ок  ,  сейчас  попробую убрать   записи  с  нулевыми суммами

ща ты наубираешь.... бэкап хоть сделай..

я  всё  делаю  на  резервной  базе

убрать  записи  сторонней  прогой -  dbf  редактором не  получилось (слишком  много  записей  >14млн.)- разные  пробовал  ,  а обработку  скачать  рейтинга  не  хватает  ,  люди  ,  кто-нибудь  может  отправить  на  мыло tt7171@mail.ru  ?

слабо Access'ом открыть и запросом того? это если XBase из 1С неизвестен...

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

оно не зависает... оно думает!!!!

возможно  - бесконечно  долго думает

гы... 14 лямов записей нет желания умножить на время обработки 1 записи (пусть 0,01 сек), затем поделить на 60 (получим в минутах) и еще раз на 60 (получим в часах) не?

+ у меня 38 часов вышло... примерно

и  причём  не  факт  что  это ещё что-то даст

Ну, если освободишь место для текущих итогов - то даст. проработать еще месяц.

поэтому правильный ответ

правильный ответ - в

гыы... он просто более универсальный а так =

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

%ом "хорошести" можно поинтересоваться?

чем ?

контора "накосячила", Вы снова ей даете работу, чтобы она и дальше "косячила" вот и интересна причина

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

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

или  косяки  делают операторы

не давай им - они уже один раз накосячили. У тебя тупо не закрывается регистр, даже если есть проблемы в учете разработчик должен был это предусмотреть, хотя бы в виде предупреждений/сообщений.

сколько различных товаров в среднем на остатках, сколько приходных накладных в месяц?

сейчас уточню

и заодно размер RA1247.DBF скажи. Примерно будет ясно - можно ли на этой базе и дальше работать в ДБФ после закрытия регистра или все же нужно переходить на скл. Например Експресс - он бесплатный.

накладных  100 прихдных 100  расходных , 400 перемещения итого 600  остатки   материалы -20 товары  - 30

я про RA спрашивал. Документооборот смешной - скорее всего после решения проблемы с регистром еще можно будет жить в ДБФ. Могу помочь в нерабочее время. Почта в профиле.

експресс то  может и бесплатный  а  за  изменение 1с лицензии    нужно  будет  платить  и я  подозреваю  что немалую сумму

64 ну есть такое. беглый гуглин показал цену в 36 тыр грн. Но думаю можно хорошую скидку выбить, или поискать б/у программу.

RA1247.DBF  - 603мб

тогда 100% косяки по незакрытым партиям в регистре ЗЫ как может таблица всех движений (за все года) быть меньше чем таблица остатков (текущих)

у Вас это должно было проявляться давно дикими тормозами при получении остатков товаров

немного  проясняется  картина

Ну вообще-то может... Если приход отделяет от расхода более 3 и более периодов - итоги будут вполне закономерно толще движений...

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

важен  вопрос  причины -  или  кривая  конфигурация  или  операторы

да согласен, если оборачиваемость никакая и штучный товар то вполне может быть такое типа пришло и лежит, лежит, а в RG* каждый месяц на 1-е число плюсует записи по всем остаткам но тогда 200% что срочно свертку делать, хотя бы тупейшей чисткой из RG* старых периодов по которым остатки уже не нужны

правильный ответ только один, кривой админ БД

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

вообщим переговорили с   фирмой  кот. осуществляет нам поддержку  1с  - и  они  согласились  свернуть  базу  но  только  до  2013 г.( в лучшем случае)  и  на  это  им нужно  предварительно  -  2 дня.  Хорошо  это   или плохо  сейчас  особо  выбор  небольшой -  ситуация   сложная.

а восстановить работоспособность и найти причину - пара часов.

огласите измерения регистра. А так, путей несколько. самый простой - прибить прошлые итоги, получить текущие + свёртка. Или, прибить лишнюю аналитику в регистре. По-уму - смотреть причину незакрытия регистра, для начала, глядеть движения прихода и расхода - там почти сразу очевидно, из-за чего.

И.. скорее всего, какой-то му-2 добавил/изменил измерения регистра.

из-за которых он перестал закрываться

за пару часов и заплотют "за пару часов" а вот за "нужно  предварительно  -  2 дня" можно чуть побольше срубить

платиться  за  то  что  "фирма"

тогда не понял цель выноса этого вопроса на форум... который , сразу бы обратились к "фирма" и не тратили время ЗЫ интересно что они  2-й день делают, как работают без смены ТА

при тех объемах им можно тупо курить это время. Никто и не заметит, что программа не работает. Это не 24*7*364, с допускаемыми 2 часами в месяц

цель  вынесения  следующая  -  я  искал  пути  решения проблемы  но  поскольку  своими  силами  решить  проблему  не  удалось  ...

как  говорится :  а  счастье  было  так  возможно ; и  так - возможно ; и  так - возможно

если  почистить  регистр   я  как то  и  смог бы  - то  провести  свёртку  грамотно  -  я  пока  не  готов

для свертки "типовых" есть "типовые обработки"

Эмпирические исследования позволят сделать все малой кровью (читатйе Епрста). Если заведомо есть партии по которым СТОПУДОВО не должно быть итогов - то можно тупо прямыми запросами поудалять движения и итоги с такими партиями. Все резко похудеет. Но надо аккуратненько, аккуратненько.

А свернуть вашу базу - два пальца об асфаль - свернуть именно технически. 1. внедрение универсального двигателя регистров - 10 мин. 2. заполнение УДР текущими остатками - ну пусть час... 3. удалить "лишнюю" аналитику (подменить креддокумент во взаиморасчетах на сам УДР и почистить ссылки на приходный доки в партиях - аналогично заменить на сам УДР). у себя именно так и сворачивал/разворачивал - п.2 делается автоматом с разбиением по докам с вменяемым количеством строк.

но это техническая свертка. в результате получится может как было 100 приходов по Фирме1 и 100 расходов по фирме2 - так и останется. То есть незакрыто. Регистр-то порежется и дальше работать можно будет, но снова пухнуть начнет. а я - !!очень сомневаюсь!! что фирма которая "подрядилась" сделать свертку будет делать что-то иное, кроме как "технической" свертки.

Короче - если не взлетит и дургой пипл не поможет - стучись предметно как-нить попозжее (но ядумаю пипл поможет).

Там проблема не только в RG1247. Есть еще один регистр на 905 метров и 1SENTRY уже перевалила за 1 гиг. Так что либо полноценная свертка, либо переход на скуль.

спасибо  всем  , особенно FN , Злопчинскому    нас  потжимают  сроки  поэтому  пришлось передать  базу ..  но  в  дальнейшем  думаю  что  Ваша  информация  мне  пригодится

В дальнейшем надо только одно - следить за размерами дбф