<?php // Полная загрузка сервисных книжек, создан 2025-01-05 12:44:55
global $wpdb2;
global $failure;
global $file_hist;
///// echo '<H2><b>Старт загрузки</b></H2><br>';
$failure=FALSE;
//подключаемся к базе
$wpdb2 = include_once 'connection.php'; ; // подключаемся к MySQL
// если не удалось подключиться, и нужно оборвать PHP с сообщением об этой ошибке
if (!empty($wpdb2->error))
{
///// echo '<H2><b>Ошибка подключения к БД, завершение.</b></H2><br>';
$failure=TRUE;
wp_die( $wpdb2->error );
}
$m_size_file=0;
$m_mtime_file=0;
$m_comment='';
/////проверка существования файлов выгрузки из 1С
////файл выгрузки сервисных книжек
$file_hist = ABSPATH.'/_1c_alfa_exchange/AA_hist.csv';
if (!file_exists($file_hist))
{
///// echo '<H2><b>Файл обмена с сервисными книжками не существует.</b></H2><br>';
$m_comment='Файл обмена с сервисными книжками не существует';
$failure=TRUE;
}
/////инициируем таблицу лога
/////если не существует файла то возврат и ничего не делаем
if ($failure){
///включает защиту от SQL инъекций и данные можно передавать как есть, например: $_GET['foo']
///// echo '<H2><b>Попытка вставить запись в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>$m_comment));
wp_die();
///// echo '<H2><b>Возврат в начало.</b></H2><br>';
return $failure;
}
/////проверка лога загрузки, что бы не загружать тоже самое
$masiv_data_file=stat($file_hist); ////передаем в массив свойство файла
$m_size_file=$masiv_data_file[7]; ////получаем размер файла
$m_mtime_file=$masiv_data_file[9]; ////получаем дату модификации файла
////создаем запрос на получение последней удачной загрузки
////выбираем по штампу времени создания (редактирования) файла загрузки AA_hist.csv, $m_mtime_file
///// echo '<H2><b>Размер файла: '.$m_size_file.'</b></H2><br>';
///// echo '<H2><b>Штамп времени файла: '.$m_mtime_file.'</b></H2><br>';
///// echo '<H2><b>Формирование запроса на выборку из лога</b></H2><br>';
////препарируем запрос
$text_zaprosa=$wpdb2->prepare("SELECT * FROM `vin_logs` WHERE `last_mtime_upload` = %s", $m_mtime_file);
$results=$wpdb2->get_results($text_zaprosa);
if ($results)
{ foreach ( $results as $r)
{
////если штамп времени и размер файла совпадают, возврат
if (($r->last_mtime_upload==$m_mtime_file) && ($r->last_size_upload==$m_size_file))
{////echo '<H2><b>Возврат в начало, т.к. найдена запись в логе.</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>$m_mtime_file,'last_size_upload'=>$m_size_file,'comment'=>'Загрузка отменена, новых данных нет, т.к. найдена запись в логе.'));
wp_die();
return $failure;
}
}
}
////если данные новые, пишем в лог запись о начале загрузки
/////echo '<H2><b>Попытка вставить запись о начале загрузки в лог таблицу</b></H2><br>';
$insert_fail_zapros=$wpdb2->insert('vin_logs', array('time_stamp'=>time(),'last_mtime_upload'=>0, 'last_size_upload'=>$m_size_file, 'comment'=>'Начало загрузки'));
////очищаем таблицу
$clear_tbl_zap=$wpdb2->prepare("TRUNCATE TABLE %s", 'vin_history');
$clear_tbl_zap_repl=str_replace("'","`",$clear_tbl_zap);
$results=$wpdb2->query($clear_tbl_zap_repl);
///// echo '<H2><b>Очистка таблицы сервисных книжек</b></H2><br>';
if (empty($results))
{
///// echo '<H2><b>Ошибка очистки таблицы книжек, завершение.</b></H2><br>';
//// если очистка не удалась, возврат
$failure=TRUE;
wp_die();
return $failure;
}
////загружаем данные
$table='vin_history'; // Имя таблицы для импорта
//$file_hist Имя CSV файла, откуда берется информация // (путь от корня web-сервера)
$delim=';'; // Разделитель полей в CSV файле
$enclosed='"'; // Кавычки для содержимого полей
$escaped='\
Интересно, нужно посмотреть.
А что это за ограничение «на размер файлов – 1 гигабайт»? 2 — знаю, 1 — нет.
И можно узнать ноу-хау разработки?
“И можно узнать ноу-хау разработки?”
Вот мой ответ (номер 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 никакая реальная запись не попадёт.
(3) Толково обяснил. Коммет спокойно можно перенести в описание обработки. (Эх жаль, нет книги знаний….)
Зер ГУД, выручил 🙂
Если каждый, не умеющий читать, “Фокусник” будет ставить минусы разработчикам, то все “в минусах ходить будем”. Всё, что Вы написали, не имеет никакого отношения, к описанной мной проблеме 1GB в 1С 7.7.
Теперь по пунктам:
1) “Максимальный размер файла такого размера, был ещё когда работали на VS 6.0.” – А 1С 7.7 и её СУБД написаны именно на VS 6.0. Но проблем не из-за этого.
2) “Сейчас как видно по ссылке ограничения в 2 гига, и ограниченны они максимальным размером который поддерживает операционка -4096 МГб.” – Думаю Вам пора переходить на другую ОС. Сейчас ограничения на размер файла другие. А ограничения на 4GB (или меньше) зависят от конкретной программы. Загляните в описание Win32 API.
3) “Хотя в целом идеология описана првильно.” – Жаль, что Вы её не поняли.
4) “Вот если ты сделаешь максимальный размер файла в 4 ГГб или более, это будет хорошо,” – Это уже сделано. Посмотрите другие мои разработки на этом сайте.
5) “размере 1,7 ГГб начались проблемы, но подкинули дисков, убрали остальные базы, и ничего, доработали до конца года без глюков.” – Важны не события, а наше отношение к ним. А НЕзнание – сила.
6) “а так пока минусую” – Жаль, что разработчики сайта запретили ставить минусы на комментарии к собственной разработке. Прошу считать мой Вам ответ как огромный минус.
(7) Компенсирую (-:)
(8) Спасибо.
Но так хочется похвалы от “Фокусник”-а. 😉
при использовании Вашей разработки перестали работать ВК от romix (plugin_sleep_dbf.dll для обработки 100% загрузки процессора при ожидании блокировки таблиц, vk_log_write_doc.dll — для регистрации запуска внешних отчетов запускаемые с помощью hook_1c, не работает также ВК vk_sleep_1C.dll запускаемая из ГМ. Пробовали Вашу ВК kernel37.dll — тоже без эффекта 🙁
Может неправильно пытались ее использовать? Мы переименовали ее в kernel33.dll, а все остальное уже было сделано для решения проблемы 1Г. Может надо было положить ее рядом с kernel33.dll?
извинюсь, с kernel37.dll все получилось
(10-11)(rovix)
«с kernel37.dll все получилось»
Думаю, Вы ошибаетесь. Она просто лежит рядом с 1С и ничего не делает. Посмотрите сообщение #28 в .
(12)(hogik)
hogik 26.12.2007
Цитирую:
>> Кстати, как работает с Kernel33.dll от ? Глючит?
Да. Поэтому и появился Kernel37. Но алгоритм у romix лучше.
>> Может в вашей компоненте заложить снятие ограничения в 1ГБ для ДБФ баз?
Данный алгоритм должен включатся до открытия файлов DBF. А алгоритм разработки может включаться и позже. Проще в разработке romix учесть при перехвате еще и имя Kernel33.
Из этого поста делаю заключение, что в kernel37 все же существует алгоритм решения 100% загрузки проца, так что она лежит не просто рядом, а выполняет две функции снятие проблемы 1Г и 100% загрузки.
Сегодня еще раз проверил по методике описанной в описании разработки — работает.
Спорить не буду хуже-лучше, но РАБОТАЕТ!!! И за это ей (и автору спасибо)
а вот как быть с vk_log_write_doc.dll?
(13)(rovix)
Я не вижу связи (конфликта) между vk_log_write_doc и Kernel3x.
Поясните, пожалуйста, в чем суть вопроса (проблемы).
Я не зная, конфликт там или недопонятки у них (дээлэлок :)), но факт на лицо 🙁
До применения kernel33(37) исправно регистрировались открытия всех внешних отчетов, а после не регистрируется ни одного открытия.
То есть, либо vk_log_write_doc не грузится совсем, либо не получается у нее перехватить нужное событие.
(15)(rovix)
Я проверил совместимость Kernel3x с vk_log_write_doc (версия от 25.10.2006). Да, в журнал ничего не пишется. Но и без Kernel3x ничего в журнал не пишется. Возможно я чего либо не так делаю. Я пробовал на тесте, включенном в эту разработку. И там про регистрацию «открытия … внешних отчетов» ничего не говориться.
у нас версия от 17.10.2006 идущая в составе разработки hook_1c. Библиотека подгружалась с помощью hook_1c.dll при старте 1С. Для того чтобы работала hook_1c.dll делался патч seven.dll
Цитата из прилагающейся документации:
Установка:
1) Скопировать в папку 1cv7Bin файлы
— Hook_1C.dll
— patch_Hook_1C.exe
— папку Plugins.
Сделать резервную копию папки BIN.
2) Запустить программу-патчер patch_Hook_1C.exe
3) В файле Hook_1C.ini указать, какие плагины требуется загружать.
Ненужные в данный момент плагины можно закомментировать символом ‘;’
конец цитаты.
vk_log_write_doc пишет не в журнал, а в папку LOG_ERT в каталоге базы данных.
(17)(rovix)
Я пробовал В этой разработке нет «hook_1c». И, как я понимаю — не требуется. Дайте ссылку на то, что Вы используете. Или пошлите мне эту разработку на адрес из описания Kernel3x.
(18)(hogik)
Приношу свои извинения, речь шла про компоненту log_ert.dll из
(19)(rovix)
Проверил совместимость plugin_log_ert.dll (версия от 17.10.2006) с Kernel3x. Не работает и без установки Kernel3x. Однако по исходным текстам plugin_log_ert я не обнаружил возможных конфликтов с Kernel3x. Почему оно не работает — я не разбирался. Обратитесь к Роману (roMix).
+(20)
(19)(rovix)
Дополнение к собственной фразе: «…я не обнаружил возможных конфликтов с Kernel3x».
да, действительно, если убрать kernel33 из seven.dll, то все начинает работать. Спасибо.
Спасибо автору за разработку выручил (еще один + )
у нас похожая проблема — при попытке провести документы (притом не все, на некоторых проходит нормально) выпадет сообщение с заголовком «DATABASE ERROR» из dbeng32.dll функции по адресу call 1F113900
место входа в отработку ошибки- :1F110ECE
содержит в первом сообщении -310 corrupt index file,
во втором вообщении еще имеется строка IDELETED
зависимости пока не нашел, но база не дошла до 1 гб ниодним файлом:
макс CDX 975605750 байт 1SACCSEL.CDX
макс DBF 757236620 байт 1SACCSEL.DBF
в ней же макс число записей — 16827474.
после упаковки смотрел 1SACCSEL.DBF
было 16827474 записей
стало 16925928 записей (тут уже работа идет — так что возможно просто прибавились)
индексы были 975 мегов, стал 440 мегов
он получается что файл не чистится?
пока удалось вылечить лишь сжатием базы до полугодия.
продолжение сообщения 24…
1SACCSEL.DBF остался одним и темже размером — просто не сжимали помеченные на удаление записи в файлах.
(0) по первой ссылке ( ) не пускает без регистрации
У Вас нет прав для просмотра этого ресурса.
Вы должны зайти как пользователь.
Это такая раскрутка сайта? 🙂
Когда в базе стали проявляться разночтения при формировании отчетов, база была пропатчена (Kernel37 на терминальном сервере win 2003), работоспособность восстановилась, база работает до сих пор (размеры 6 самых больших файлов за 1гб в сумме весят 8гб). В другой базе, где 1с работает под win 2003 x64, 2 таблицы переросли 1гб и начались проблемы. Может ли разрядность операционки влиять на работоспособность этой бибилиотеки? Может кто-то сталкивался с такой проблемой, расскажите как её решали?
(27) (SVR27)
«…под win 2003 x64…начались проблемы»
1) Проблемы начались после установки Kernel3x ?
2) Как проявляются проблемы ?
P.S. См. сообщение (24) данной темы. У Вас такая ошибка? Мне, по таким случаям, много приходит писем. И у всех стоит Win2003 x64. Эта ошибка не имеет отношения к проблеме «1 гигабайт». И применение Kernel3x её не лечит.
В общем ситуация следующая: файл одного из регистров перерос 1гб. При открытии периода выходит ошибка codebase error -310. Собственно так и было примерно год назад на другой базе, которая работает под обычной 32-битной виндой. Её пропатчили kernel37 и проблема исчезла. Сейчас в той базе 6 таблиц размером больше 1гб и всё отлично работает. На 64-битной системе сделан абсолютно такой же патчинг, но получается даже с ним стали вылетать ошибки индексов.
p.s. Индексы восстанавливаю ежедневно (путем удаления *.cdx и запуска в монопольном режиме)
используя давно забытые со школы умения, поглядел библиотеку.
точек входа в эту ошибку вообщето далеко не одна, а как минимум 4,
и относятся к файлам индексов.
Так что патчем одной ошибки это врядли ограничится.
(29)(SVR27)
«…даже с ним стали вылетать ошибки индексов»
Могу, только, повторить еще раз. Ошибка -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» такой ошибки не возникало. Кроме этого в нём можно увеличить размер страницы индексного файла.
(29)(SVR27)
Сергей.
Проверьте, пожалуйста, как себя поведет 1С, если у всех пользователей сделать доступ к каталогу базы данных, как к сетевому ресурсу (для «Windows 2003 x64» в терминал серверном режиме). Т.е. в запуске сессий 1С поставить «\СерверРесурс». Скорость работы 1Са снизится. А, интересно, ошибка -310 будет возникать?
(32) попробовал, ошибка возникает.
Кстати, интересный факт, очередной период (1 февраля) открылся без ошибок. Если смещать ТА назад например на 25 января, то ошибка возникает.
(33)(SVR27)
Я бы, на Вашем месте, еще проверил работоспособность системы с этой базой:
1) В терминал серверном режиме на НЕ x64.
2) В файл серверном режиме.
И если ошибка будет возникать, то — переходить на другую СУБД…
(34)
1) Это я уже проверил, ситуация аналогичная.
2) Т.е. помимо описанного в (32) трюка ещё и с другой машины? (upd. Проверил, не помогает).
Теоретически можно перейти на SQL версию, но мне она нравится меньше. Одна база у меня работает на ней, по умолчанию все работало очень медленно. После замены ключевых тормозов на прямые запросы стало терпимо, но другие базы на SQL переводить все равно не хочется. Да и ситуация с 310 ошибкой на самом деле не совсем ужасная. И опыт борьбы с ней уже кое-какой имеется. помогает уменьшение файла, т.к. ошибка начинает появляться на файле большого размера, из-за чего и делался неверный как оказалось вывод о связи с проблемой гигабайта. Если штатными средствами ужать файл не получается, режу остатки за начальный период работы (например пару месяцев), обращение к которым маловероятно: в Foxе DELETE ALL FOR Rg283.period<{#k8SjZc9Dxk2009-02-01} или DELETE FROM ra283 WHERE iddoc in (select iddoc FROM 1sjourn WHERE date<{#k8SjZc9Dxk2009-02-01}) или DELETE FROM dt833 WHERE iddoc in (select iddoc FROM 1sjourn WHERE date<{#k8SjZc9Dxk2009-02-01}), это мои 3 проблемных файла. А вообще скоро уже базу буду сворачивать резать, как это происходит ежегодно.
Такие вот дела, спасибо за ваши советы и помощь.
Кстати, уважаемый (hogik), насколько я понимаю в (32), когда упоминали другую СУБД имели в том числе и Ваши наработки по использованию CodeBase и Advantage?
(35)(SVR27)
«… упоминали другую СУБД …. в том числе … CodeBase и Advantage?»
Да. Но сравниться по скорости с родными DBF-ами в терминальном режиме, может только разработка на «CodeBase 6.5» в режиме ПДБД. Работает ОНО быстрее и нет проблем с размером таблиц…
чем редактировать файлы библиотек?
(37)(kas4info)
1) «…файлы…» — см. сообщение (21) данной темы.
2) «чем редактировать…» —
Если уж тема немного ожила, добавлю еще немного из практического опыта. Практика действительно опровергает причастность «ошибки -310» к ограничению 1гб. Вывод я для себя сделал, когда в очередной раз возникла ошибка и я отрезал описанным в (35) способом все файлы, переросшие 1 гб. Результат был нулевой, т.е. все файлы базы были размером меньше гигабайта, а ошибка все равно возникала 🙂 Путем дальнейших поисков была выявлена «таблица-героиня», которой оказалась 1SCRDOC.DBF (её размер был «всего» 852 мб), в которой на тот момент было около 17 млн. строк. Я ее тоже немного «подрезал», удалив все ссылки на подчиненные документы с датой раньше, чем рабочий период базы. Ошибка исчезла. Но возникла вновь спустя каких-то 2 недели. Здесь я уже не стал тревожить большие таблицы, а сразу порезал перекрестные ссылки. Правда по ошибке вместо одного месяца удалил один день, и через день ошибка снова выскочила как чёртик из табакерки, т.е. получилось — отрезал день, получил возможность работать день. А патч на 1гб. — он работает. База, про которую я писал в (27), прекрасно работает с таблицами свыше 1 гб. (размер максимального файла 1,853 гб) на той же конфигурации. Так вот там 1SCRDOC.DBF весит 247 мб и около 7 млн. записей и повторюсь, все работает.
Так что (резюмируя), для себя я сделал выводы, что в действительности причиной ошибки 310 скорее всего является слишком большое число записей в какой-либо таблице (предположение высказывал hogik в (31) ), критическая граница в моем случае около 16-17 млн. записей. Хотя может истинная причина лежит поглубже, подожду коментариев более подкованных товарищей.
Возможно offtop, но может кому пригодится.
После замены kernel32.dll на 33, выходит следующая ошибка:
Приложение или библиотека c:1См77BINDbEng32.dll не является образом программы Windows NT. Проверьте назначение установочного диска.
Подскажите, что я сделал не так.
(40)
«Подскажите, что я сделал не так.»(с)
Алексей.
Не так внесли исправления в библиотеку. Чаще всего, в момент редактирования стоял режим «сдвига»(вставки), а не «забой» в HEX-редакторе.
Я менял с помощью WordPad. Не мог найти в интернете бесплатный Hex-редактор
(42)
См. сообщение #38 данной темы.
Проблема Следущая:
база в DBF формате, весит уже 8Гб. 2 таблицы больше 1 ГБ одна из них dbf -ка проводок,2-я CDX отбор счетов. Пользователей 20.
Воспользовалась kernel33.dll. Начали работать и вроде все ок Но примерно ч/з час снова начало выбивать ошибки либо не пускает в программу (пишет, что не может прочитать константу) либо тормозит проведение ожидание захвата таблицы. Установила vk_TerminalSleep,эффект тот же.Чем дальше тем у большего числа пользователей. После переиндексации какое-то время работает , потом снова. Может подскажите, что еще можно сделать?
(44)
1) «снова начало выбивать ошибки «(с)
2) «После переиндексации какое-то время работает»(с)
(
3) «Может подскажите, что еще можно сделать?(с)
а) 1С 8.х
б) 1С 7.7 + MS SQL +
4) «Установила vk_TerminalSleep»(с)
Меня это удивляет. Вы читали описание Kernel3x ?
(45)3б) это и собираемся делать, но надо найти временное решение пока переведем, т.к в конфе используются свои классы и после простой конфертации наши классы не работают. А на базе работать весьма проблематично, а это розн. магазин продуктовый постоянный большой документооборот.
4 Читала, там предлагалост еще kernel37.dll. и ссылка на vk_TerminalSleep. Не утверждаю что использовала это правильно, т.к с такими манипуляциями столкнулась впервые.
(46)
«…с такими манипуляциями столкнулась впервые.»(с)
Огромная к Вам просьба!!!
Наймите (пригласите) на работу программиста и покажите ему нашу переписку.
(47)Очень информативно, а главное «помогло». Я так поняла все возможные варианты вы дали в предыдущем сообщении и других нет.
А последнее сообщение=»Посмотрите какой я умный». Поздравляю,но я спрашивала не об этом. «Не стыдно чего-то не знать, стыдно не хотеть знать»
(48)
Очень странная и обидная, для меня, оценка моего сообщения. 🙁
В конце описаний моих разработок написан мой e-mail.
У Вас есть возможность «списаться» со мной и получить мой номер телефона.
Позвонить мне и получить от меня любую консультацию по любой, известной мне, проблеме (задаче). Многие люди так и делают. Я денег за это не прощу и не получаю. Единственно, что от Вас требуется — понимать то, что я Вам буду говорить. А говорить мы будем очень о многом и очень долго. И начнем мы разговор с выяснения какие «начало выбивать ошибки»(с). Т.е. её содержание, а не сам факт появления ошибки…
P.S. А показать нашу переписку надо программисту, т.к. в моих сообщениях, думаю, есть решение (временное) проблем в Вашей системе. И у Вас, возможно, появится время для спокойного перехода на другие системы. Мой совет «показать программисту» — это не попытка «ткнуть Вас», а облегчение программисту поиска готовых (в рамках его специальности) решений.
P.P.S. У меня есть огромное подозрение, что база данных в Вашей системе сильно попорчена в результате сбоев. И избавление от факта «выбивания ошибок» — это не всё, что придется делать программисту.
Сервак 2003виндовс х64, юзеры в терминалке работают,12Гб оперативки,,1С 7.70.026 ,DBF УПП,4Гб общий размер(в архиве 400кб),самая закабаневшая ДБФка 2Гб.Ведется с 2005 года, но обрзеалово ничего толкового не даст,росла она нелинейно по времени. если срезать по 2009г включительно — размер ополовиниваеться.
Как это вообще по мировым стандартам, много ли?
Ну и наблюдаеться следующая проблемма: формируем анализ счета или еще какойнить стаддартный отчет,видим что у Иванова по 71 счету СКД 200$, жмем много раз ОБНОВИТЬ и там уже 300$,или нуль вообще ,у кого как. Не по всем субконтам но по многим.
кернелл33 тут поможет?Или как еще можно выкрутиться?
(50)
1) «закабаневшая ДБФка 2Гб»(с)
Ограничение на DBF — 2 гигабайта.
2)»Как это вообще по мировым стандартам, много ли?»(с)
Для DBF — очень много.
3) «…кернелл33 тут поможет?»(с)
Для решения этой проблему и сделан.
4) «Или как еще можно выкрутиться?»(с)
Переходить на другую СУБД.
Ограничение на DBF — 2 гигабайта.<>Для решения этой проблему и сделан.
тоесть к33 снимет это ограничение, и базе можно будет отожраться до 4х ГБ ?
«Таким образом, технологические блокировки уходят в 4GB. А так как существует уже другое ограничение на размер DBFов в 2GB, то в 4GB никакая реальная запись не попадёт.»
тоесть к33 снимет 2Гб ограничение, и базе можно будет отожраться до 4х ГБ ?
(52)(53)
Проблема типа «жмем много раз ОБНОВИТЬ и там уже 300$,»(с) возникает при размере файла больше 1 гигабайта. Именно эту проблему решает Kernel3x. А ограничение в 2 гигабайта снимается применением других СУБД. Это ограничение заложено в FoxPro совместимом формате DBF.
А что за истрия про жмем много раз обновить?
так написано выше… при размере самой толстой ДБФки приближающемся к 2Гб итоги начинают «плавать» — тоесть один раз формируем бух. ит. по чемнибудь получаем одну сумму, формируем через 5 секунд еще раз с теми же параметрами — получаем другую… есстесственно за эти 5 секунд никто по этому счету ничего не вносил.
Пришло мне сообщение на электронный ящик:
«Новый голос за «Kernel3x — решение проблемы 1 гигабайта для DBFной версии 1С:Предприятие 7.7» от пользователя andrewbc.
Оценка: -1″
Заглянул в тему. Минус стоит. Причина (комментарий) — отсутствует.
Автор «минуса» — может напишете причину?
Ошибка в программе? Или еще — что?
(57) «Одним из недостатков DBFной версии “1С:Предприятие 7.7” является ограничение на размер файлов – 1 гигабайт.» — это абсолютно не верно, даже с добавкой «При этом если система эксплуатируется в однопрограммном режиме, то размер файла может быть 2 гигабайта, однако если появится второй пользователь, а файл будет больше 1 гигабайта, то система 1С начинает сбоить по ЧТЕНИЮ». Поэтому и минус (это мое личное мнение, основанное на 7-летнем опыте работы с 7.7). Владимир, я уважаю Вашу работу в плане глубокого тестирования платформы 1с, но могу со 100% уверенностью сказать, что по крайней мере 5 из известных мне баз работает с dbf-файлами размером более 2.5 — 2.7 Гб, а одна даже с 3.7, (регистры партии, покупатели, проводки, ссылки счетов), причем 2 из них работают в распределенном режиме, с одновременным количеством пользователей от 10 до 30. Проблема, наверное, не в размере файла, а размере конкретного файла (например, журнала документов или констант и периодических реквизитов, может, еще чего, нужно тестировать конкретную базу и конфигурацию) или алгоритмов обработки.
(58)
Андрей.
Спасибо, что пояснили своё «личное мнение, основанное на 7-летнем опыте работы с 7.7″(с) при вынесении вердикта — «минус». 😉
В свой «список», известных Вам больших баз, можете добавить информацию о «моей» базе — 10 ГБ одних DBF-ов. Работает на родном движке 1С-а более 10 лет. Кстати, без единой свертки за это время. 😉 Но проблему «1ГБ» мы получили на второй год. Т.к. размер ОДНОГО файла превысил этот размер. У нас, примерно, на 0.9 ГБ в год прирастало.
В описании моей «разработки» написано:
«Одним из недостатков DBFной версии “1С:Предприятие 7.7” является ограничение на размер файлов – 1 гигабайт.»(с) Там нет слов — ВСЕХ файлов. 👿
И, если прочесть хотя бы второе предложение из моего описания «…а файл будет больше 1 гигабайта, то…» — это становится совсем очевидно. 🙂
Не надо присоединяться к сообществу «фокусник»-ов (сообщение #5 данной темы).
Думаю, Вы не «фокусник», а программист… 😉
(59) К сожалению, уважаемый автор неправильно истолковал смысл моего комментария. «по крайней мере 5 из известных мне баз работает с dbf-файлами размером более 2.5 — 2.7 Гб, а одна даже с 3.7» — это значит, что не ВСЕ файлы, а размер по крайней мере ОДНОГО из файлов в данных базах имеет указанный объем. А общий размер каждой из этих ИБ — от 10 до 25 Гб. А к «фокусам», как вы правильно заметили, я не имею никакого отношения. Хочу только добавить, что, наверняка, ваша разработка не вредит работе 1с, но позиционировать ее как панацею от несуществующей на мой взгляд проблемы, думаю, не стоит. Повторюсь, наверное, стоит все-таки обратить внимание на совершенствование алгоритмов, имеющихся в конфигурации. Думаю, что с вашими способностями программиста это вполне реально и может принести гораздо большую пользу. 🙂 Хотя, если в вашей базе разработка решает какие-то проблемы, определенно, она имеет право на существование. В качестве примирения снимаю -, поставив +. Ок?
(60)
Андрей.
Верните, пожалуйста, «минус» обратно.
Я пытался дать Вам шанс выйти из глупой ситуации с честью.
Вы этого не захотели или не смогли сделать. 🙁
Мне будет приятней, если Ваше мнение о моей «разработке» будет «располагаться» рядом с «фокусник»-ом.
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 гигабайта. Или Вы о других базах и СУБД говорите?
Все… побежал за попкорном и колой…
Столкнулся с проблемой 1Gb (W2k3 x64). Kernel очень выручил — дал время для подрезки базы. Спасибо автору!
Да ну? ))
Буду побывать!
Ставлю Плюс.
Считаю подобные разработки бесценными, эти все проблемы в свое время должна была решить сама 1С, но они пошли другим путем — удачным маркетингом. Надежд на появление альтернатив мало, поэтому радует, что хоть кто-то латает существенные дыры программы.
Что то не разу не сталкивался на ограничение 1ГБ. Впёрся на 2 гигабайта — думал поможет )) но не помогло. Автору плюс за решение проблемеи.
(67)
«Что то не разу не сталкивался на ограничение 1ГБ»(с)
…..(mimos)
Скачайте Test.zip и столкнитесь. 😉
Существует три причины «не сталкиваться» с этим ограничением.
1) В системе всегда работает один пользователь.
2) Уникальная схема базы данных и/или алгоритмы работы с информацией.
3) Пользователь не замечает ошибки. 😉
Неоднократно сталкивался с проблемой 1гб, выглядить так: в монопольном режиме все ок, в разделенном при работе нескольких пользователей запросы по регистру (в данном случае партии более 1 гига) каждый раз разные результаты. Лечил обрезкой базы, но все равно пару месяцев приходилось работать в таком режиме (обрезка 1 раз в год в феврале по текущий год).
Использую hook_1c с разными плагинами в том числе sleep (решение проблемы 100% загрузки проца), его немного поправил по подобию kernel33, т.е. перехватил не только lookfiles но и unlookfiles и младший dword адрес при вызове оригинала увеличиваю на 2 гига. Проблема 1 гига решилась. Если кому интересно, выложу.
Будем проводить испытания. Спасибо!
(69)
…..(porese)
Конечно выкладывайте, отдельной публикацией.
У Романа решение проблем через hook_1c сделаны лучше.
Но!!!
Надо не забывать, что использование запросов через FoxPro могут вызвать проблемы при изменении способа блокировки. И, думаю, имеет смысл разделять (иметь возможность управлять активизацией) решение проблем «100% CPU» и «1GB». Т.к. первая проблема донимает всех, а вторая возникает только в «экзотических» случаях… 😉
P.S. Управление должно быть до запуска (активизации) сессии 1С-а, а не на уровне ВК.
Скажите пожалуйста кто нибудь еще продолжает писать на FoxPro? В свое время кажется 80% СССР писали в этой СУБД, кто знал это знали и структуру DBF
У нас часто DBF размер превышает 1Гб, SQL ставит дорогвато, наш спец разработал обработеку для ужаления старых записей, и после сжатия DBF становится нормальным, но это надо делать вручну, запускать обработку , выяснять какой dbf превысли размер 1 Гб
(72)(73)
Алик (mustakh).
Это вопросы, утверждения, предложения, пожелания, размышления, просьба, … ?
Что требуется от автора публикации?
Я не совсем понял 🙁
Владимир, скажи пожалуйста точно: каков допустимый максимальный размер 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Гб.
Получается после этого моя база перестанет работать?
Будет ли работать база после увеличения индексов если использовать эту разработку?
(76)
«Получается после этого моя база перестанет работать?»(с)
Да.
«Будет ли работать база после … если использовать эту разработку?»(с)
Нет.
«скажи пожалуйста точно: каков допустимый максимальный размер CDX и DBF файлов»(с)
Для CDX — 2ГБ. Но, еще до достижения такого размера система перестанет работать по другим причинам.
Для DBF — 2ГБ при ОдноПользовательском использовании, 1 ГБ — при разделенном режиме.
При использовании «Kernel3x» — 2ГБ в обоих режимах.
(77)
а как же у меня сейчас работает?
ведь два ДБФ-файла регистров превышают 1Гб, режим работы — разделенный
(78)
«а как же у меня сейчас работает?»(с)
Понятие «работает» относительное. 😉
В «публикации» описано как это проявляется.
И если в Вашей системе пользователи этого не замечают, то Ваша система — работает.
Уже давно использую kernel3x. Не представляю что бы я делал без этой разработки. Спасибо!
Есть такой вопрос. Совместима ли kernel3x с использованием прямых запросов для DBF базы, реализованных в 1cpp?
(80)
Андрей (АндрейКр).
Естественно — нет.
Это следует из самой сути данной «разработки» — она меняет «FoxPro совместимый формат доступа к DBFам».
Пробуйте использовать:
hogik, подскажите, при установке написано, что в библиотеке Seven.dll контекст «Kernel32.dll» заменить 2 раза,а в DBEng32.dll – один раз. У меня платформа 7.70.027. В Seven.dll нашел только 1 раз, а в DBEng32.dll не нашел вообще. Такое возможно?
Нашел. Оказалось все просто. Просто было написано заглавными буквами, а я искал только по строчным.
(83)
Ещё см. (21) сообщение данной темы.
hogik, т.е. для решения проблемы 1Гб можно seven.dll не модифицировать, а только DBeng32.dll ? Я правильно понял?
(85)
Да.
кернел33 — стоит, однако припроведении доков вываливается ошибка -310, подробности отписал в личку. Что делать?
(87)
Сергей.
А по телефону мне позвонить не получается? 🙂
Ставить и получить запас времени.
Далее сворачивать или переходить на SQL.
Ставить общаясь со мной по телефону или Skype.
1. Есть ли олее простой способ проверить активировалась ли KERNEL32.dll ,чем садить десяток бухгалтеров чтобы они писали в базу и читали одновременно и смотрели не скачут ли итоги?
2.У меняверсия 1с 7.70.026, работает на серверной 2003 винде через сервер терминалов,в инструкции сказано что тестировали на 018 версии 1с и 2000 винде,на 0.26 будет работать?
3.может быть есть у вас уже отредактированные ДЛЛ от 026 версии?
(89)
1) Использовать содержание Test.zip файла.
2) Тестировалось на 18,25,27 в Win2000,WinMe,WinXP,WinXPx64(ядро от Win2003x64).
В этих версиях файл DBEng32.dll не изменялся. Надеюсь, что и в 26 не изменялся.
3) Нет.
если используеться распределённая ИБ, можно ли на основной базе юзать кернелл33, а на удалённой стандартные длл? Может ли чтото сломаться в базах в процессе обмена выгрузками?
(91)
Можно. Не сломается.
Решение проблемы — 1С v8.
(93)
Вот, первые строчки из файла описания разработки:
«Kernel3x — решение проблемы 1 гигабайта для DBFной версии 1С:Предприятие 7.7
Разработано в 2001 году.»©
Поставил на терминалку 2003виндовс сервера — чтото периодически при запуске 1с рунтайм еррор вылезает, не всегда , но частенько.Что можно пошаманить попробовать?
ожидание захвата таблицы константы для записи… и потом этот самый еррор, перезагрузить сервак помогает но потом опять надо перезагружать через полдня..
(95)
«рунтайм еррор вылезает»(с)
Подробнее, пожалуйста. 😉
(96)
«и потом этот самый еррор»(с)
Если есть подозрение на Kernel3x — отключите. И подождите раза три по «полдня»(с).
Отпишите о результатах…
не может из за него вылетать, опенконфиг не стоит случайно (из за него было не раз, лечилось переустановкой опенконфа). И кстати стоит сервер поставить 2008, по сравнению с 2003 — небо и земля, сбоев меньше гораздо и работает шустрее. может еще какие хуки стоят или зараза кернел перехватывает.
Кстати база весит 12 гигов (файл проводок 1.6 гиг, партии 1.4гиг…), использую хук на основе керлер33, но переписанный со слипом. Проблем нет. Если кому интересно выложу.
(98) опенконф никакого отношения к режиму «Предприятие» не имеет вообще, он только для Пофигуратора предназначен.
Если кого интересует (98) хук называется sleep_dbf_1g кинул на
(99) если появляется только в режиме предприятия то да.