Ограничение на работу с файлами большего размера, чем 2 ГБ
Доброго времени суток, господа. Проблема такая: ТиС, документы тянутся с 2006г., размер базы - 5ГБ!!! При работе в программе возникает ошибка и программа закрывается... Считаю, что связано это с размеров dbf-файлов... Регистр "покупатели" файл rg3445 - размер файла 2,14 ГБ. Как можно научить 1С 77 работать с файлами размера больше, чем 2 ГБ? Или необходимо делать свертку базы? Но тогда вопрос в следующем: как сделать свертку, если при обработке файла rg3445 программа завершает свою работу???
По теме из базы знаний
- Конфигурация для хранения любой информации, с предпросмотром файлов Word, Excel и картинок
- Очевидные советы по ускорению работы 1С (8.2, 8.3)
- MS Access и 1С. Что, когда и зачем?
- Обмен большими данными между клиентом и сервером
- Быстрый фронт в базе размером 6.8 терабайт – наши стандарты при разработке и рефакторинге запросов
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1)
никак ограничение в самом формате dbf ( на индекс 32 разряда )
Если перейдешь на sql там нет этого ограничения.
Можно также свернуть базу.
или можно свернуть только один этот регистр. а прошлое регистра либо в архивной базе
либо выгрузи прошлое регистра в какой либо sql ( express бесплатен )
Как можно научить 1С 77 работать с файлами размера больше, чем 2 ГБ?
никак ограничение в самом формате dbf ( на индекс 32 разряда )
Если перейдешь на sql там нет этого ограничения.
Можно также свернуть базу.
или можно свернуть только один этот регистр. а прошлое регистра либо в архивной базе
либо выгрузи прошлое регистра в какой либо sql ( express бесплатен )
(1)
Помоему обработки вам не помогут, ибо у вас уж очень база тяжелая.
Вот описывается метод свертки ОГРОМНЫХ баз с помощью компоненты УРБД. Весь фокус способа заключается в структуре УРБД файлов.
В файле сначала идет шапка сеанса (код базы источника, код базы приемника, внутренний id ист, внутренний id прием, номер сессии), а затем в файле идет описание данных которые нужно перенести. Путем подмены в шапке файла номера сессии или других данных можно переносить из базы в базу огромное количество данных за минимально короткие сроки, т.к. быстрее УРБД я еще пока не видел переноса данных.
Такой способ хорош если нужно сделать срочно свертку базы в середине года, т.е. оставить накопившиеся документы с начала года, а остальное обрезать. Обработками и другими переносами сделать это в 7ке достаточно долго.
Помоему обработки вам не помогут, ибо у вас уж очень база тяжелая.
Вот описывается метод свертки ОГРОМНЫХ баз с помощью компоненты УРБД. Весь фокус способа заключается в структуре УРБД файлов.
В файле сначала идет шапка сеанса (код базы источника, код базы приемника, внутренний id ист, внутренний id прием, номер сессии), а затем в файле идет описание данных которые нужно перенести. Путем подмены в шапке файла номера сессии или других данных можно переносить из базы в базу огромное количество данных за минимально короткие сроки, т.к. быстрее УРБД я еще пока не видел переноса данных.
Такой способ хорош если нужно сделать срочно свертку базы в середине года, т.е. оставить накопившиеся документы с начала года, а остальное обрезать. Обработками и другими переносами сделать это в 7ке достаточно долго.
(1)
Артем (ArBus).
По поводу "размер файла 2,14 ГБ"© посмотрите картинку:
Т.е. такого размера DBF файла не бывает. Если Вы не используете:
или
Проблемы с DBF-ами возникают уже раньше размер в 2 гигабайта:
Мой Вам совет - переходите на SQL-ную версию 1С-а.
Уже давно пора с такой базой... ;-)
Артем (ArBus).
По поводу "размер файла 2,14 ГБ"© посмотрите картинку:
Т.е. такого размера DBF файла не бывает. Если Вы не используете:
или
Проблемы с DBF-ами возникают уже раньше размер в 2 гигабайта:
Мой Вам совет - переходите на SQL-ную версию 1С-а.
Уже давно пора с такой базой... ;-)
(5) сначала на тестовой потом в основной базе делаешь следущее
выбирается дата скажем 01.01.2012 ( можно и больше период скажем 01.01.2011)
все ra до этой даты скидываешь в точно такую же таблицу в sql базе
также все rg до этой даты скидываешь в точно такую же таблицу в sql базе
В dbf удаляешь все ra до даты 01.01.2012
В dbf удаляешь все rg до даты 01.01.2012
Для таблицы 1sjourn для всех документов до даты 01.01.2012
ставишь в 0 rf тот самый который соответсвует ra
Все.после этого для этого отчета миним дата должна быть >= 01.01.2012
и все отчеты будут правильно работать.
также после этого нельзя перепроводить документы с датой < 01.01.2012 которые двигают твой регистр
Древние движения если они нужны вытаскивай из sql базы.
выбирается дата скажем 01.01.2012 ( можно и больше период скажем 01.01.2011)
все ra до этой даты скидываешь в точно такую же таблицу в sql базе
также все rg до этой даты скидываешь в точно такую же таблицу в sql базе
В dbf удаляешь все ra до даты 01.01.2012
В dbf удаляешь все rg до даты 01.01.2012
Для таблицы 1sjourn для всех документов до даты 01.01.2012
ставишь в 0 rf тот самый который соответсвует ra
Все.после этого для этого отчета миним дата должна быть >= 01.01.2012
и все отчеты будут правильно работать.
также после этого нельзя перепроводить документы с датой < 01.01.2012 которые двигают твой регистр
Древние движения если они нужны вытаскивай из sql базы.
Так как ошибка явно мешает работать, сделать надо что - то срочно и прямо сейчас, как говорится.
Я полностью согласен с (5), но только как временное решение.
Если регистр итогов двухгиговый - это значит как пить дать он не закрывается.
Если он не закрывается по какому - либо измерению - программируй и закрывай.
Потому что он может тормозить всю базу, ведь в него наверняка документы при проведении пишутся!, а в это время блокировка идет.
Если он не закрывается вообще, переводи регистр в оборотный. Я сам исправлял эту проблему за умником который сделал регистр остатков там где не надо.
Только сам переход от остаточного к оборотному делай на пустой базе с таким же мдшником, потом в рабочую тупо поверх копируешь мд и дд (ддс) файлы. иначе пересчет регистров начнется и это будет очень долго.
Я полностью согласен с (5), но только как временное решение.
Если регистр итогов двухгиговый - это значит как пить дать он не закрывается.
Если он не закрывается по какому - либо измерению - программируй и закрывай.
Потому что он может тормозить всю базу, ведь в него наверняка документы при проведении пишутся!, а в это время блокировка идет.
Если он не закрывается вообще, переводи регистр в оборотный. Я сам исправлял эту проблему за умником который сделал регистр остатков там где не надо.
Только сам переход от остаточного к оборотному делай на пустой базе с таким же мдшником, потом в рабочую тупо поверх копируешь мд и дд (ддс) файлы. иначе пересчет регистров начнется и это будет очень долго.
Свертку делать нужно однозначно, побробуйте обработку TORG_SvertkaOstatkovIzNovojBazy.ert, если не потянет, то что можно попробровать что-то почистиь вручную, в крайнем случае перенести справочники в чистую базу и вручную набить документы ввода остатков
если нет желания возиться-только переход на sql
или удаление ненужных регистров
находи самый большой дбф
смотри что в нем хранится
смотри насколько критичны движения регистров
у меня было с регистром накопления по акцизам так
просто убил регистр и заново создал и из 2 гиговоого файла осталось совсем чуть чуть
затем почистил обработку проведения чтоб по акцизам не проводилось
теперь порядок
в основном так пухнут файлы в которые идет движение приход выполнить
а движение расход выполнить нет
или удаление ненужных регистров
находи самый большой дбф
смотри что в нем хранится
смотри насколько критичны движения регистров
у меня было с регистром накопления по акцизам так
просто убил регистр и заново создал и из 2 гиговоого файла осталось совсем чуть чуть
затем почистил обработку проведения чтоб по акцизам не проводилось
теперь порядок
в основном так пухнут файлы в которые идет движение приход выполнить
а движение расход выполнить нет
(25) Фирма открыла новый склад.
предроложим есть регистр рстатки
товар, склад, ответсвенный
приход 01.04.2012
рельсы, 10 тн, Иванов
расход 06.04.2012
рельсы, 10 тн, Петров
больше закупок рельсов фирма не делала
по продажам все ок
по этому регистру на всех слещущих периодах будет по две записи итогов
если делать свертку итогов без ответсвенного все будет сходиться развернуто нет.
Если таких ситуаций одна то терпимо
когда таких ситуаций много то это и называется незакрытый регистр
предроложим есть регистр рстатки
товар, склад, ответсвенный
приход 01.04.2012
рельсы, 10 тн, Иванов
расход 06.04.2012
рельсы, 10 тн, Петров
больше закупок рельсов фирма не делала
по продажам все ок
по этому регистру на всех слещущих периодах будет по две записи итогов
если делать свертку итогов без ответсвенного все будет сходиться развернуто нет.
Если таких ситуаций одна то терпимо
когда таких ситуаций много то это и называется незакрытый регистр
Если в 7.7 есть желание просто начать базу "с начала" без документов и регистров, но оставить все справочники, есть нижеописанный вариант, не претендующий на суперметод, однако у себя им пользовались и значительно сокращали время создания срезов.
Найти подходящую обработку выгрузку-загрузку всех остатков, лучше во внешние файлы, и вывалить все остатки (для себя в конце концов написали свои, хотя сторонних выгрузок полно).
Потом клонируется база, в новой удаляются, как минимум, *.cdx, dh*.*, dt*.*, ra*.*, rg*.*, 1scrdoc.dbf, 1sdnlock.dbf, 1sjourn.dbf, 1sstream.dbf. Затем желательно сделать тестирование-исправление, всё пустышка готова.
Закачиваем ее различными вводами остатков и, например для ТиС, новыми ценами. Подглядываем в движения документов, отчетами и прочими методами проверяем достоверность данных и итогов.
Лишь как вариант, написал.
Найти подходящую обработку выгрузку-загрузку всех остатков, лучше во внешние файлы, и вывалить все остатки (для себя в конце концов написали свои, хотя сторонних выгрузок полно).
Потом клонируется база, в новой удаляются, как минимум, *.cdx, dh*.*, dt*.*, ra*.*, rg*.*, 1scrdoc.dbf, 1sdnlock.dbf, 1sjourn.dbf, 1sstream.dbf. Затем желательно сделать тестирование-исправление, всё пустышка готова.
Закачиваем ее различными вводами остатков и, например для ТиС, новыми ценами. Подглядываем в движения документов, отчетами и прочими методами проверяем достоверность данных и итогов.
Лишь как вариант, написал.
У меня ТИС в 7.7 (база около 5 Гб), свёртка не делается - после 4-х часов ошибка OUT of Memory. Лучше либо с Нового года на чистую базу, либо в SQL. в SQL шустро работает - одновременно до 20 человек - и никаких подвисаний (в SQL база более 7 Гб).
Например, мы пишем на какой-то счёт все операции клиента - просто для того, чтобы знать оборот по этому клиенту за любой период. В итоги, число клиентов растёт и растёт и файл итогов, так как "умная" 1С хранит все итоги за все периоды в одном файле (и не только 1С так делает).
Если итоги по клиенту не нужны каждый раз "мгновенно", а именно мгновенно 1С может показать итоги по счёту на какую-то дату, то можно вместо субконто использовать параметр проводки и делать выборку вручную (обороты по итогам).
А если более строго говорить, то итоги - они и в Африке итоги - мы же со счетами работаем - если же хочется какой-то аналитики, то для этого придуманы регистры - там каждый регистр в своих файлах и как бы мы не старались - так быстро 2 Гб не пройти.
Если итоги по клиенту не нужны каждый раз "мгновенно", а именно мгновенно 1С может показать итоги по счёту на какую-то дату, то можно вместо субконто использовать параметр проводки и делать выборку вручную (обороты по итогам).
А если более строго говорить, то итоги - они и в Африке итоги - мы же со счетами работаем - если же хочется какой-то аналитики, то для этого придуманы регистры - там каждый регистр в своих файлах и как бы мы не старались - так быстро 2 Гб не пройти.
Пробьлема острая быстрого лекарства нет, либо сворачивать базу либо еще что-то делать, такие тяжелые ДБФки больше подвержены разрушения и системным сбоям, я ж не говорю про время на переиндексацию
Кстати можно отрастить их до такого размера что свертка не может сделать на мощно сервере даже за 2-е суток
Кстати можно отрастить их до такого размера что свертка не может сделать на мощно сервере даже за 2-е суток
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот