O сути проблемы - FoxPro совместимом формате доступа к DBFам.
Для управления блокировками записи используется функции Win API LockFile() и UnlockFile(). Эти функции обеспечиваю блокировку участка файла “полностью” и по записи и по чтению. Если использовать эти функции непосредственно к участкам файла эквивалентным самим записям DBFа, то теряется возможность чтения записи. Поэтому в FoxPro принят “хитрый алгоритм” – блокируются участки файла начиная со 2GB, упрощенно говоря, отдельные куски файла логически сопоставленные с номерами реальных записей DBFа. Таким образом, реальный участок файла можно читать, т.е. моделируется блокировка по записи, но не по чтению. Если же реальные записи начинают располагаться после 1GB, то “технологические блокировки” наезжают на процесс чтения. Возникает сбой по чтению. В 1С не обрабатывается должным образом аварийный код возврата. Например, в функциях найти по ключу в 1С - получают аварийны код возврата, а в программу пользователя (конфигурацию) возвращают признак – объект не найден.
В Kernel33 делается очень простая вещь. Все обращения к функциям Win API отправляются в kernel32. А для функций LockFile() и UnlockFile() к параметру, указывающему стартовый адрес блокировки, добавляется число 2GB и так отправляется в kernel32. Таким образом, технологические блокировки уходят в 4GB. А так как существует уже другое ограничение на размер DBFов в 2GB, то в 4GB никакая реальная запись не попадёт.
Другие решения для снятия ограничения на размер информационной базы данных в “1С:Предприятие 7.7”:
1) http://www.etersoft.ru/index.php?option=com_content&task=view&id=157&Itemid=1
2) //infostart.ru/projects/1359/
3) //infostart.ru/projects/811/
В разработках номер 2,3 размер таблицы ограничивается количеством записей – 2147483647 штук, а не размером файла.
Kernel3x - решение проблемы 1 гигабайта для DBFной версии 1С:Предприятие 7.7
База данных - Инструменты администратора БД
Скачать файл
ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.
| Наименование | По подписке [?] | Купить один файл | |
|---|---|---|---|
|
-
.1204118412 41,60Kb
2235
|
2235 | Скачать бесплатно | |
|
-
.1223930460 12,30Kb
737
|
737 | Скачать бесплатно | |
|
Kernel33.zip
.zip 16,61Kb
299
|
299 | Скачать (1 SM) | Купить за 1 850 руб. |
См. также
Инструменты администратора БД Программист Платформа 1С v7.7 Конфигурации 1cv7 Россия Абонемент ($m)
Блокировка открытия формы обработки одним пользователем.
1 стартмани
24.05.2023 888 igor7777 1
Инструменты администратора БД Системный администратор Программист Платформа 1С v7.7 Конфигурации 1cv7 Абонемент ($m)
Простецкий скрипт переименования файлов в папке в нижний регистр, будет полезен программистам и системным администраторам имеющим навыки програмирования в 1С. Можно легко настроить под себя, спасает мне периодически час времени, может, кому еще будет полезен.
1 стартмани
18.02.2022 4011 0 igor7777 6
Инструменты администратора БД Программист Пользователь Оперативный учет 7.7 1С:Торговля и склад 7.7 Управленческий учет Абонемент ($m)
Боремся с бардаком. Работы в прошлых датах запрещены. Непроведенные документы (по разным причинам) - автоматом переносятся в начало текущего дня при запуске любого первого сеанса 1С в текущем дне. Задержка старта 1С - практически незначима. Не требует настройки, не требует допрограммирования (исключая один оператор вставки в процедуру старта системы). Можно обработку выполнять вручную с любой периодичностью.
2 стартмани
25.05.2020 5875 2 CheBurator 3
Журнал регистрации Инструменты администратора БД Системный администратор Программист Платформа 1С v7.7 Конфигурации 1cv7 Бесплатно (free)
Рассмотрим систему на базе Elasticsearch, Logstash и Kibana (ELK Stack) для анализа логов 1С Предприятие 7.7 с целью визуализации и анализа событий 1С.
22.01.2019 11556 phsin 20
Инструменты администратора БД Системный администратор Программист Платформа 1С v7.7 Конфигурации 1cv7 Абонемент ($m)
Скрипт позволяет выполнить объединение конфигураций и реструктуризацию из командной строки. Объединение выполняется штатными средствами конфигуратора 1С 7.7, взаимодействие с которым происходит путем посылки нажатий клавиш. Пригодится, если есть необходимость обновить или постоянно обновлять множество ИБ.
1 стартмани
22.04.2017 15858 4 devlabnn 2
Инструменты администратора БД Бухгалтер Бухгалтерский учет 7.7 1С:Бухгалтерия 7.7 Украина Бухгалтерский учет Абонемент ($m)
Перепроведение по счету для конфигурации Бухгалтерский учет для Украины, 1С: Предприятие 7.7
1 стартмани
23.09.2016 3851 1 Genyak 1
Инструменты администратора БД Системный администратор Платформа 1С v7.7 Конфигурации 1cv7 Абонемент ($m)
Периодически сталкивался со следующими проблемами при печати в 1С: 7.7 работающей под терминалом: 1) После замены принтера на клиентской машине 1С пытается печатать на старый принтер. 2) Отсутствует предварительный просмотр при печати. 3) Не работает печать без предварительного просмотра (пакетная печать документов). 4) В некоторых формах печатает, в некоторых нет.
1 стартмани
09.06.2016 28035 19 tux 3
Инструменты администратора БД Системный администратор Программист Платформа 1С v7.7 Платформа 1С v8.3 Бесплатно (free)
Часто бывает необходимо отслеживать состояние часто повторяющихся регламентных заданий. Например, синхронизация данных с IP-телефонией, которая может производиться каждую минуту, синхронизация с сайтами, синхронизация данных с различными системами. Использовать для этих целей логирование 1С чрезвычайно неэффективно и не удобно. В таких случаях удобно использовать подход, применяемый в Unix-системах: писать логи в обычные текстовые файлы, а потом делать их обработку через эффективно работающие Unix-команды: grep, tail, cat, less и т.п.
18.05.2016 37106 rudjuk 21
Вот мой ответ (номер 21) на аналогичный вопрос от “СергейК” в “форуме” под разработкой . Там же (в обсуждениях) есть и более подробная информация на эту тему.
Сначала о самой сути проблемы - FoxPro совместимом формате доступа к DBFам.
Для управления блокировками записи используется функции Win API LockFile() и UnlockFile(). Эти функции обеспечиваю блокировку участка файла “полностью” и по записи и по чтению. Если использовать эти функции непосредственно к участкам файла эквивалентным самим записям DBFа, то теряется возможность чтения записи. Поэтому в FoxPro принят “хитрый алгоритм” – блокируются участки файла начиная со 2GB, упрощенно говоря, отдельные куски файла логически сопоставленные с номерами реальных записей DBFа. Таким образом, реальный участок файла можно читать, т.е. моделируется блокировка по записи, но не по чтению. Если же реальные записи начинают располагаться после 1GB, то “технологические блокировки” наезжают на процесс чтения. Возникает сбой по чтению. В 1С не обрабатывается должным образом аварийный код возврата. Например, в функциях найти по ключу в 1С - получают аварийны код возврата, а в программу пользователя (конфигурацию) возвращают признак – объект не найден.
В Kernel33 делается очень простая вещь. Все обращения к функциям Win API отправляются в kernel32. А для функций LockFile() и UnlockFile() к параметру, указывающему стартовый адрес блокировки, добавляется число 2GB и так отправляется в kernel32. Таким образом, технологические блокировки уходят в 4GB. А так как существует уже другое ограничение на размер DBFов в 2GB, то в 4GB никакая реальная запись не попадёт.
. Сейчас как видно по ссылке ограничения в 2 гига, и ограниченны они максимальным размером который поддерживает операционка -4096 МГб. Хотя в целом идеология описана првильно. Вот если ты сделаешь максимальный размер файла в 4 ГГб или более, это будет хорошо, а так пока минусую. У нас файл остатков в начале 2007 года был под один гиг, а к концу достиг 1,9 ГГб. При размере 1,7 ГГб начались проблемы, но подкинули дисков, убрали остальные базы, и ничего, доработали до конца года без глюков.
Теперь по пунктам:
1) “Максимальный размер файла такого размера, был ещё когда работали на VS 6.0.” – А 1С 7.7 и её СУБД написаны именно на VS 6.0. Но проблем не из-за этого.
2) “Сейчас как видно по ссылке ограничения в 2 гига, и ограниченны они максимальным размером который поддерживает операционка -4096 МГб.” – Думаю Вам пора переходить на другую ОС. Сейчас ограничения на размер файла другие. А ограничения на 4GB (или меньше) зависят от конкретной программы. Загляните в описание Win32 API.
3) “Хотя в целом идеология описана првильно.” – Жаль, что Вы её не поняли.
4) “Вот если ты сделаешь максимальный размер файла в 4 ГГб или более, это будет хорошо,” – Это уже сделано. Посмотрите другие мои разработки на этом сайте.
5) “размере 1,7 ГГб начались проблемы, но подкинули дисков, убрали остальные базы, и ничего, доработали до конца года без глюков.” – Важны не события, а наше отношение к ним. А НЕзнание – сила.
6) “а так пока минусую” – Жаль, что разработчики сайта запретили ставить минусы на комментарии к собственной разработке. Прошу считать мой Вам ответ как огромный минус.
Может неправильно пытались ее использовать? Мы переименовали ее в kernel33.dll, а все остальное уже было сделано для решения проблемы 1Г. Может надо было положить ее рядом с kernel33.dll?
hogik 26.12.2007
Цитирую:
>> Кстати, как работает с Kernel33.dll от ? Глючит?
Да. Поэтому и появился Kernel37. Но алгоритм у romix лучше.
>> Может в вашей компоненте заложить снятие ограничения в 1ГБ для ДБФ баз?
Данный алгоритм должен включатся до открытия файлов DBF. А алгоритм разработки может включаться и позже. Проще в разработке romix учесть при перехвате еще и имя Kernel33.
Из этого поста делаю заключение, что в kernel37 все же существует алгоритм решения 100% загрузки проца, так что она лежит не просто рядом, а выполняет две функции снятие проблемы 1Г и 100% загрузки.
Сегодня еще раз проверил по методике описанной в описании разработки - работает.
Спорить не буду хуже-лучше, но РАБОТАЕТ!!! И за это ей (и автору спасибо)
а вот как быть с vk_log_write_doc.dll?
До применения kernel33(37) исправно регистрировались открытия всех внешних отчетов, а после не регистрируется ни одного открытия.
То есть, либо vk_log_write_doc не грузится совсем, либо не получается у нее перехватить нужное событие.
Я проверил совместимость Kernel3x с vk_log_write_doc (версия от 25.10.2006). Да, в журнал ничего не пишется. Но и без Kernel3x ничего в журнал не пишется. Возможно я чего либо не так делаю. Я пробовал на тесте, включенном в эту разработку. И там про регистрацию "открытия ... внешних отчетов" ничего не говориться.
Цитата из прилагающейся документации:
Установка:
1) Скопировать в папку 1cv7\Bin файлы
- Hook_1C.dll
- patch_Hook_1C.exe
- папку Plugins.
Сделать резервную копию папки BIN.
2) Запустить программу-патчер patch_Hook_1C.exe
3) В файле Hook_1C.ini указать, какие плагины требуется загружать.
Ненужные в данный момент плагины можно закомментировать символом ';'
конец цитаты.
vk_log_write_doc пишет не в журнал, а в папку LOG_ERT в каталоге базы данных.
Проверил совместимость plugin_log_ert.dll (версия от 17.10.2006) с Kernel3x. Не работает и без установки Kernel3x. Однако по исходным текстам plugin_log_ert я не обнаружил возможных конфликтов с Kernel3x. Почему оно не работает - я не разбирался. Обратитесь к Роману (roMix).
(19)(rovix)
Дополнение к собственной фразе: "...я не обнаружил возможных конфликтов с Kernel3x".
Это при условии, что не проводится замена имени Kernel32 на Kernel33 в библиотеке Seven.dll. Для решения "проблемы 1 гигабайта", на самом деле, достаточно модифицировать только библиотеку DBEng32.dll. См. сообщения 33-34 в
место входа в отработку ошибки- :1F110ECE
содержит в первом сообщении -310 corrupt index file,
во втором вообщении еще имеется строка IDELETED
зависимости пока не нашел, но база не дошла до 1 гб ниодним файлом:
макс CDX 975605750 байт 1SACCSEL.CDX
макс DBF 757236620 байт 1SACCSEL.DBF
в ней же макс число записей - 16827474.
после упаковки смотрел 1SACCSEL.DBF
было 16827474 записей
стало 16925928 записей (тут уже работа идет - так что возможно просто прибавились)
индексы были 975 мегов, стал 440 мегов
он получается что файл не чистится?
пока удалось вылечить лишь сжатием базы до полугодия.
"...под win 2003 x64...начались проблемы"
1) Проблемы начались после установки Kernel3x ?
2) Как проявляются проблемы ?
P.S. См. сообщение (24) данной темы. У Вас такая ошибка? Мне, по таким случаям, много приходит писем. И у всех стоит Win2003 x64. Эта ошибка не имеет отношения к проблеме "1 гигабайт". И применение Kernel3x её не лечит.
p.s. Индексы восстанавливаю ежедневно (путем удаления *.cdx и запуска в монопольном режиме)
"...даже с ним стали вылетать ошибки индексов"
Могу, только, повторить еще раз. Ошибка -310 никак не связана с проблемой "1 гигабайта" и с помощью Kernel3х не лечится. По приходящим мне письмам складывается впечатление, что возможные причины ошибки -310 в следующем:
0) Действительно испорченные индексы.
1) Количество индексируемых записей в таблице больше 3-5 миллионов.
2) Большой размер ключа.
3) Выполняется большое обновление таблицы с ключевыми значениями с обратным порядком индекса.
4) Маленькая страница индексного файла. Её размер - 512 байт. И изменить это невозможно.
При этом сказывается различное сочетание событий пунктов 1-4.
Для себя я сделал вывод, что это ошибка в движке (CodeBase) на котором работает 1С 7.7 DBF-ной версии. В большинстве, приходящих мне, писем говорится об использовании "Windows 2003 x64" в терминал серверном режиме. Т.е. негативное влияние ОСа, на появление данной ошибки, я не исключаю.
В "CodeBase 6.5" такой ошибки не возникало. Кроме этого в нём можно увеличить размер страницы индексного файла.
Сергей.
Проверьте, пожалуйста, как себя поведет 1С, если у всех пользователей сделать доступ к каталогу базы данных, как к сетевому ресурсу (для "Windows 2003 x64" в терминал серверном режиме). Т.е. в запуске сессий 1С поставить "\\Сервер\Ресурс". Скорость работы 1Са снизится. А, интересно, ошибка -310 будет возникать?
1) Это я уже проверил, ситуация аналогичная.
2) Т.е. помимо описанного в (32) трюка ещё и с другой машины? (upd. Проверил, не помогает).
Теоретически можно перейти на SQL версию, но мне она нравится меньше. Одна база у меня работает на ней, по умолчанию все работало очень медленно. После замены ключевых тормозов на прямые запросы стало терпимо, но другие базы на SQL переводить все равно не хочется. Да и ситуация с 310 ошибкой на самом деле не совсем ужасная. И опыт борьбы с ней уже кое-какой имеется. помогает уменьшение файла, т.к. ошибка начинает появляться на файле большого размера, из-за чего и делался неверный как оказалось вывод о связи с проблемой гигабайта. Если штатными средствами ужать файл не получается, режу остатки за начальный период работы (например пару месяцев), обращение к которым маловероятно: в Foxе DELETE ALL FOR Rg283.period<{^2009-02-01} или DELETE FROM ra283 WHERE iddoc in (select iddoc FROM 1sjourn WHERE date<{^2009-02-01}) или DELETE FROM dt833 WHERE iddoc in (select iddoc FROM 1sjourn WHERE date<{^2009-02-01}), это мои 3 проблемных файла. А вообще скоро уже базу буду сворачивать резать, как это происходит ежегодно.
Такие вот дела, спасибо за ваши советы и помощь.
Кстати, уважаемый (hogik), насколько я понимаю в (32), когда упоминали другую СУБД имели в том числе и Ваши наработки по использованию CodeBase и Advantage?
"... упоминали другую СУБД .... в том числе ... CodeBase и Advantage?"
Да. Но сравниться по скорости с родными DBF-ами в терминальном режиме, может только разработка на "CodeBase 6.5" в режиме ПДБД. Работает ОНО быстрее и нет проблем с размером таблиц...
Так что (резюмируя), для себя я сделал выводы, что в действительности причиной ошибки 310 скорее всего является слишком большое число записей в какой-либо таблице (предположение высказывал hogik в (31) ), критическая граница в моем случае около 16-17 млн. записей. Хотя может истинная причина лежит поглубже, подожду коментариев более подкованных товарищей.
Возможно offtop, но может кому пригодится.
точек входа в эту ошибку вообщето далеко не одна, а как минимум 4,
и относятся к файлам индексов.
Так что патчем одной ошибки это врядли ограничится.
Приложение или библиотека c:\1См77\BIN\DbEng32.dll не является образом программы Windows NT. Проверьте назначение установочного диска.
Подскажите, что я сделал не так.
база в DBF формате, весит уже 8Гб. 2 таблицы больше 1 ГБ одна из них dbf -ка проводок,2-я CDX отбор счетов. Пользователей 20.
Воспользовалась kernel33.dll. Начали работать и вроде все ок Но примерно ч/з час снова начало выбивать ошибки либо не пускает в программу (пишет, что не может прочитать константу) либо тормозит проведение ожидание захвата таблицы. Установила vk_TerminalSleep,эффект тот же.Чем дальше тем у большего числа пользователей. После переиндексации какое-то время работает , потом снова. Может подскажите, что еще можно сделать?
1) "снова начало выбивать ошибки "(с)
2) "После переиндексации какое-то время работает"(с)
(
3) "Может подскажите, что еще можно сделать?(с)
а) 1С 8.х
б) 1С 7.7 + MS SQL +
4) "Установила vk_TerminalSleep"(с)
Меня это удивляет. Вы читали описание Kernel3x ?
4 Читала, там предлагалост еще kernel37.dll. и ссылка на vk_TerminalSleep. Не утверждаю что использовала это правильно, т.к с такими манипуляциями столкнулась впервые.
А последнее сообщение="Посмотрите какой я умный". Поздравляю,но я спрашивала не об этом. "Не стыдно чего-то не знать, стыдно не хотеть знать"
Очень странная и обидная, для меня, оценка моего сообщения. :-(
В конце описаний моих разработок написан мой e-mail.
У Вас есть возможность "списаться" со мной и получить мой номер телефона.
Позвонить мне и получить от меня любую консультацию по любой, известной мне, проблеме (задаче). Многие люди так и делают. Я денег за это не прощу и не получаю. Единственно, что от Вас требуется - понимать то, что я Вам буду говорить. А говорить мы будем очень о многом и очень долго. И начнем мы разговор с выяснения какие "начало выбивать ошибки"(с). Т.е. её содержание, а не сам факт появления ошибки...
P.S. А показать нашу переписку надо программисту, т.к. в моих сообщениях, думаю, есть решение (временное) проблем в Вашей системе. И у Вас, возможно, появится время для спокойного перехода на другие системы. Мой совет "показать программисту" - это не попытка "ткнуть Вас", а облегчение программисту поиска готовых (в рамках его специальности) решений.
P.P.S. У меня есть огромное подозрение, что база данных в Вашей системе сильно попорчена в результате сбоев. И избавление от факта "выбивания ошибок" - это не всё, что придется делать программисту.
Как это вообще по мировым стандартам, много ли?
Ну и наблюдаеться следующая проблемма: формируем анализ счета или еще какойнить стаддартный отчет,видим что у Иванова по 71 счету СКД 200$, жмем много раз ОБНОВИТЬ и там уже 300$,или нуль вообще ,у кого как. Не по всем субконтам но по многим.
кернелл33 тут поможет?Или как еще можно выкрутиться?
1) "закабаневшая ДБФка 2Гб"(с)
Ограничение на DBF - 2 гигабайта.
2)"Как это вообще по мировым стандартам, много ли?"(с)
Для DBF - очень много.
3) "...кернелл33 тут поможет?"(с)
Для решения этой проблему и сделан.
4) "Или как еще можно выкрутиться?"(с)
Переходить на другую СУБД.
Проблема типа "жмем много раз ОБНОВИТЬ и там уже 300$,"(с) возникает при размере файла больше 1 гигабайта. Именно эту проблему решает Kernel3x. А ограничение в 2 гигабайта снимается применением других СУБД. Это ограничение заложено в FoxPro совместимом формате DBF.
тоесть к33 снимет 2Гб ограничение, и базе можно будет отожраться до 4х ГБ ?
"Новый голос за "Kernel3x - решение проблемы 1 гигабайта для DBFной версии 1С:Предприятие 7.7" от пользователя andrewbc.
Оценка: -1"
Заглянул в тему. Минус стоит. Причина (комментарий) - отсутствует.
Автор "минуса" - может напишете причину?
Ошибка в программе? Или еще - что?
Андрей.
Спасибо, что пояснили своё "личное мнение, основанное на 7-летнем опыте работы с 7.7"(с) при вынесении вердикта - "минус". ;-)
В свой "список", известных Вам больших баз, можете добавить информацию о "моей" базе - 10 ГБ одних DBF-ов. Работает на родном движке 1С-а более 10 лет. Кстати, без единой свертки за это время. ;-) Но проблему "1ГБ" мы получили на второй год. Т.к. размер ОДНОГО файла превысил этот размер. У нас, примерно, на 0.9 ГБ в год прирастало.
В описании моей "разработки" написано:
"Одним из недостатков DBFной версии “1С:Предприятие 7.7” является ограничение на размер файлов – 1 гигабайт."(с) Там нет слов - ВСЕХ файлов. :evil:
И, если прочесть хотя бы второе предложение из моего описания "...а файл будет больше 1 гигабайта, то..." - это становится совсем очевидно. :-)
Не надо присоединяться к сообществу "фокусник"-ов (сообщение #5 данной темы).
Думаю, Вы не "фокусник", а программист... ;-)
Андрей.
Верните, пожалуйста, "минус" обратно.
Я пытался дать Вам шанс выйти из глупой ситуации с честью.
Вы этого не захотели или не смогли сделать. :-(
Мне будет приятней, если Ваше мнение о моей "разработке" будет "располагаться" рядом с "фокусник"-ом.
Visual FoxPro System Capacities:
Корни "проблемы" (текст из MSDN):
System Capacities for FoxPro 2.5 for MS-DOS
Last reviewed: April 18, 1995
Article ID: Q106269
The information in this article applies to:
Microsoft FoxPro for MS-DOS, versions 2.5, 2.5a, and 2.5b
SUMMARY
Below is a list of the system capacities for FoxPro for MS-DOS.
MORE INFORMATION
Some capacities may be limited by available memory. A indicates that the actual file size (in bytes) cannot exceed 2 gigabytes (GB) for single user or exclusively opened multiuser .DBF files. Shared multiuser .DBF files with no indexes or .IDX indexes cannot exceed 1 GB. Shared multiuser .DBF files with structural .CDX indexes cannot exceed 2 GB.
P.S. Дам пояснение по Вашей фразы: "автор неправильно истолковал смысл моего комментария"(с)
Естественно, я его иначе и не мог истолковать, исходя из ограничения размера одного DBF файла (СОВМЕСТИМОГО с FoxPro форматом) в 2 гигабайта. Или Вы о других базах и СУБД говорите?
Считаю подобные разработки бесценными, эти все проблемы в свое время должна была решить сама 1С, но они пошли другим путем - удачным маркетингом. Надежд на появление альтернатив мало, поэтому радует, что хоть кто-то латает существенные дыры программы.
"Что то не разу не сталкивался на ограничение 1ГБ"(с)
.....(mimos)
Скачайте Test.zip и столкнитесь. ;-)
Существует три причины "не сталкиваться" с этим ограничением.
1) В системе всегда работает один пользователь.
2) Уникальная схема базы данных и/или алгоритмы работы с информацией.
3) Пользователь не замечает ошибки. ;-)
Использую hook_1c с разными плагинами в том числе sleep (решение проблемы 100% загрузки проца), его немного поправил по подобию kernel33, т.е. перехватил не только lookfiles но и unlookfiles и младший dword адрес при вызове оригинала увеличиваю на 2 гига. Проблема 1 гига решилась. Если кому интересно, выложу.
.....(porese)
Конечно выкладывайте, отдельной публикацией.
У Романа решение проблем через hook_1c сделаны лучше.
Но!!!
Надо не забывать, что использование запросов через FoxPro могут вызвать проблемы при изменении способа блокировки. И, думаю, имеет смысл разделять (иметь возможность управлять активизацией) решение проблем "100% CPU" и "1GB". Т.к. первая проблема донимает всех, а вторая возникает только в "экзотических" случаях... ;-)
P.S. Управление должно быть до запуска (активизации) сессии 1С-а, а не на уровне ВК.
Владимир, скажи пожалуйста точно: каков допустимый максимальный размер CDX и DBF файлов, при использовании этой разработки?
У меня DBF-база, самые большие файлы - это регистры:
регистр1: DBF - 1.949.676.528 байт, CDX - 1.043.525.120
регистр2: DBF - 1.062.751.702 байт, CDX - 697.588.736
остальные файлы - менее 1Гб.
Сейчас возникла необходимость добавить в этих регистрах галочки "отбор движений", соответственно перестроится структура индексов, и размеры индексов увеличатся и скорее всего перевалят за 2Гб.
Получается после этого моя база перестанет работать?
Будет ли работать база после увеличения индексов если использовать эту разработку?
"Получается после этого моя база перестанет работать?"(с)
Да.
"Будет ли работать база после ... если использовать эту разработку?"(с)
Нет.
"скажи пожалуйста точно: каков допустимый максимальный размер CDX и DBF файлов"(с)
Для CDX - 2ГБ. Но, еще до достижения такого размера система перестанет работать по другим причинам.
Для DBF - 2ГБ при ОдноПользовательском использовании, 1 ГБ - при разделенном режиме.
При использовании "Kernel3x" - 2ГБ в обоих режимах.
Использую базу для ведения реестра (данные заносятся пользователями в справочник). Появилась необходимость добавить реквизит и столкнулся с тем, что в папке NEW_STRU при сохранении конфигурации индекс для DBF со справочником разрастается до размера более 2Гб и база вылетает с ошибкой -70. Сам DBF-файл весит около 150Мб, а его индекс в каталоге с базой всего 30. Что-то не так с базой или это нормально, что он так раздувается при принятии изменений во время сохранения конфигурации?
Пока не придумал ничего другого, как с помощью печати справочников сохранить данные в Excel, потом удалить все записи из базы и после ТИИ добавить нужный мне реквизит. Ну и соответственно потом загрузить данные обратно в справочник. В справочнике сейчас чуть больше 80 тысяч записей.
и вообще - поубирай в этом справочнике лишние сортировки и отборы на реквизитах в конфигураторе.
2.У меняверсия 1с 7.70.026, работает на серверной 2003 винде через сервер терминалов,в инструкции сказано что тестировали на 018 версии 1с и 2000 винде,на 0.26 будет работать?
3.может быть есть у вас уже отредактированные ДЛЛ от 026 версии?
Для получения уведомлений о новых публикациях автора подключите телеграм бот: Инфостарт бот
№ 15577
Создание 27.02.08 16:20
Обновление 08.05.12 03:32
Просмотры 76014
Загрузки 299
Рейтинг
114
Комментарии 135
Код открыт Не указано
Рубрики Инструменты администратора БД
Кому Программист
Тип файла Компонента, плагин (dll, vbs,..)
Платформа
Оперативный учет 7.7
,
Бухгалтерский учет 7.7
,
Расчет 7.7
Конфигурация Конфигурации 1cv7
Операционная система Windows
Страна Россия
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Абонемент ($m)
