ТИС Файловая база!
Файл регистра партий приближается к 2 ГБ, какие риски могут быть ?
Свертку делать нужно? Но там тогда и периферийки надо сворачивать. Тоже вопрос. Но свертка особо ничего и не даст, слишком быстро растет документооборот, а 5 лет мне желательно держать в базе. У меня у ряда товаров гарантия как раз 5 лет. Сейчас база начинается с 01.01.2012.
Вроде все длл-ки для поддержки свыше 1 ГБ у меня стоят. И пока ничего не валится. Есть что-нибудь для поддержки свыше dbf-файлов свыше 2 ГБ?
Со скулем засада - сервер win 2008 R2. 1С 7.7 инсталлирована через 64-разрядный инсталлятор, лицензионная с ключом. Ставить скулевую версию 1С 7.7 32-разрядную на win 2008 - тоже проблема, я потому и искал в свое время этот инсталлятор 64-разрядный. Solution 5 и solution 6 у меня установлены в BIN.
Лучше бы всего если бы была поддержка файлов dbf до 4 ГБ. Тогда можно 5 лет оставлять и свертывать. Или все-таки переходить на скуль как-то???

1с 77 не нужно инсталлировать

(1) Но вот я-таки инсталлировал. И работает давно и без проблем. Но вот файл в 2 ГБ меня сильно беспокоят. Остальное не так критично

Если тебя сдерживает тольк это...

(3) Есть решения какие-то чтобы поддерживался DBF файл свыше 2 ГБ ???

(4) нет и не было

размер RA и RG этого регистра озвучь, для начала

(6)RA 411166, RG 1700831

(6) Вот что и как лучше делать? Вроде когда-то читал что есть варианты с поддержкой dbf до 4 ГБ. Но это было очень давно и проблемы у меня такой еще не было даже близко

(7) ну вот и ответ, собственна - незакрытый регистр.
RG при таком RA Должен быть максимум, 1700 весить

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

(9) ЕПРСТ. Так он и весит 1700. Регистр партий вообще-то закрывается у меня нормально. Никогда не бывает чтоб партии не распределялись при проведении документов. Как это проверить? RG это файл движений регистра - их же очень много. А RA файл остатков регистра. Он же не такой большой. Или у меня в мозгах перепуталось что-то?

(8) по стандарту дбф, файло в этом формате не может быть больше 2 гигов, априори

(11) ?
он у тебя весит 1.7 гига, а должен весить 17 метров. Разницу, чуешь ?

И он у тебя, не закрыт, от слова совсем.

(12)Что можно очень срочно сделать? Если свертывать, то что делать с периферийками? Это же их заново пересоздавать.

Ты тащишь незакрытые итоги из периода в период, табличка пухнет, результат - в (0)

(13) ЕПРСТ. Просто ничего не понимаю. Как может регистр движений весить 17 МБ???

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

(17) Не движений, а итогов

При файле движений в 400метров, файло итогов должно весить метров 20, при твоей базе.

а не 1.7 гига

(19) Так файл итогов весит 411 МБ, а файл движений 1,7 ГБ

(22) RG-это промежуточные ИТОГИ регистра, RA - это табличка движений

(23) прошу прощения. Это я от волнения. RA весит 1.7 ГБ, а RG 411 МБ

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

http://s55.radikal.ru/i147/0907/fc/0d1be61a68c2.jpg

(24) тогда, только свёртка.
Максимум, вырезать лишние измерения + обрезать длину числовых полей. Но, это не намного уменьшит табличку движений.

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

К примеру, если у тебя ТиС и нет розницы, можно смело выкинуть ЦенаПрод, если учет для одной фирмы - то фирму, если один склад - то выкинуть мол и т.д

(27) Будет ли 1С 7.7 работать на скуле на 2008 винде? Как-то все это очень и очень стремно. Какие измерения можно выпилить и до скольки можно можно уменьшить числовые поля? И что при этом будет с обменом УРБД. Это же огроменный файл получится.

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

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

(29) а че тебе до обмена урбд ?
Порежешь аналогично в перефирийках и без обменов.

Обмениваешься со всеми ПБ, стопоришь обмен. Делаешь не руками реструктуризацию регистра, пересчитываешь табличку итогов. Очищаешь табличку изменений. Работаешь дальше.
В ПБ делаешь аналогично.

(33) Что значит не руками? Ведь если я реструктурирую регистр в конфигураторе, то потом же вре равно придется делать обмен УРБД. Боюсь что файл обмена будет слишком большим. Или я просто туплю?

(34) ты пропустил фразу в (33) - "Очищаешь табличку изменений".

(35) Как ее очистить? И как тогда поменять конфигуратор на периферийках. Ведь он же меняется только через ЦБ или я просто чего-не знаю

(35) 1Supdts сохранить а потом восстановить? Но конфигуратор же нельзя менять на периферийках иначе как через обмен с центральной базой?

(36) Я делаю так - подменяю файл обмена на пустой. Прокатывает.

(37) да уж..

если че, всё можно.

(40) А как? Ситуация просто угрожающая уже

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

(41) чего как ? Как обновить конфу в ПБ ? Точно так же, как и в цб. Там нет никакой разницы, окромя пары системных табличек, в которой говорится, что это пб (она одна там такая, на самом деле)
мд, если че, будет одинаковым

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

(44) уменьшай. Просто в ПБ будет один мд, в цб - чутка другой.

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

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

потом тоже самое делаешь в пб.

+ нулевые итоги нужно выкинуть из таблички итогов. Чебур тут выкладывал на нимфостарте готовое изделие для этого. Хоть табличка итогов поменьше будет

(48) табличка итогов - будет существенно поменьше.

как вариант:
1. смотришь какие партии = 0.
то есть пришли и ушли.
и просто прямым запросом удаляешь в движениях и итогах регистров записи по этой партии. !!_Документы остаются_!!. база существенно худеет.

(48) на ИСе искать "Шиышки для мартышки"

А разве пересчет итогов не удаляет нулевые?

(51) Да когда-то была она у меня. Пробовал - эффекта не было. Может не так пробовал ??? Как хоть она называлась - ерт-шка? Попробую еще раз ее, но опять же как обмен тогда пойдет?

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

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

Ну и остатки же все сразу летят..

за прошлые периоды.

(55) согласен. а кто говорил что будет легко...
.
но тут смотрим и делаем как в типовой
есть реквизит ФлагСвертки - используем его, или свой добавляем .
для "почищенных" доков выставляем "ФлагЗапретдвижений=1", в процедуре проведения - смотрим флаг, если взведен то просто возврат и все...
.
у меня так сделано, и норм...

Опять же партионку можно сильно ужать если переделать с ФиФо на среднюю (но не всегда даст эффект)
.
тогда в регистре партий в движениях и итогах проводим "реформацию" по подмене и "свертке" записей... и получаем профит

(58) ага, и пюлюём на всю отчетность за эти периоды ?
Нафик такая база нужна ?

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

база должна за любой период существования показывать верные на 100% данные.
Тогда уж, лучше свёртка

(60) То есть вариант один: свертка и дальнейший переход на скуль. Только как будет скулевая 1С-ка работать на 2008 сервере? Не будет ли проблем?

(62) У меня RA328 растет примерно на 1 МБ в день

(63) если свёртка, то скуль не нужен.

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

(65) Но я сверну, база будет с 01.01.2013. Мне только год разрешают свернуть

(63) Скулевая 1С прекрасно работает на Win 2008 с SQL 200-2008. Конечно нужны некоторые действия для этого.
1. SQL 2000 - замена пары файлов, 1С штатная.
2. SQL 2008, ставится стандартно, 1С секретный релиз.
Все это работает более чем стабильно.
В любом случае для выгрузки в SQL использовать патч ромикса.

(67) переход на скуль повлечет за собой переписывание большей части кода, чтоб усё летало

(60) согласен.
подходить надо взвешенно.
в зависимости от ситуации.

(66) Снеговик конечно хорошо, но как из 7-ки Все наши доработки перенести в снеговик - сложный вопрос.

(71) почти всё переносится без проблем

(68)В любом случае для выгрузки в SQL использовать патч ромикса. Не работает он под 64-разрядной виндой. Не нашел работающий вариант для этого

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

(72) то есть, если что - на возмездной основе тебя можно будет привлечь на проект перехода на УТ?

(74) Не справится. Там архив выгрузки больше 2 ГБ. Проверял как-то

(74) не справится, упрётся в размер файла.
Ну и по времени..будет доооолго

(73) блин копирни базу на офисную машину и там сделай

(77) Выгрузка довольно шустро проходит. есть у меня один серверочек с 2003 виндой. Пробовал. Вполне нормально.

перенести можно прямым запросом, но, т.к структура чутка разная, придётся попотеть над их созданием. типа date time перенести в date_time_iddoc еще и в нужном формате

(78) Да выгрузку копирну без проблем.

(73) Я делал несколько месяцев назад, могу поискать. На 2008 х64 все работало.

(82) Если не трудно - поищи пожалуйста. почта моя [email protected]. Я правда не знаю можно ли в посте почту указывать по правилам форума

(83) Улетело.

(80) это ты про что?

(85) про перенос базы ручонками из дбф в скуль.

почти всё можно перенести один в один, только с доками повозиться.

(86) ээээ.. нафейхоа? в сложных ситуациях?

(73) Рабочий вариант выгрузки любого размера сейчас от Альфа с внешним архиватором.

(89) в смыслe?

(90) Альфавский configspy у меня с ним 8ГБ файл выгрузки проходил.

(84)  Builder Пожалуйста пришли еще раз. Случайно удалил письмо а в удаленных оно не сохранилось. Почта [email protected]

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

(93) не понял.
если скуль - то с таблицами работает скуль, ане 1С - и тогда зачем здесь свертка?

если любишь риск - вот вариант:
http://www.wirth.ru/forum/showtopic-34
я пробовал - работает.

(94) он намекает на временные таблицы, которые создаются для запросов и прочего)))