Критическая ошибка Atol Frontol при работе с базой (internal gds software)
Проблема : При попытке сканирования любого товара для продажи выдаётся просто эпическое количество ошибок:
При этом сама программа говорит о том, что она просто не может работать дальше с такими проблемами, собирает свои вещи и переезжает к маме в Тверь:
Система : Windows 7 x64, Atol Frontol 5.15.0 Торговля.ЕГАИС
Немного о проблеме : Проблема очень и очень серьёзная. Это на самом деле проблема не программного обеспечения Atol Frontol. А самой СУБД (системы управления базы данных) Firebird. Именно через эту СУБД работает Atol Frontol. И служба Atol Service просто является посредником, которая отдаёт приказы на запись или чтение того или иного куска данных. Поэтому тут в первую очередь требуется восстанавливать данные.
ВАЖНО. Если вы не являетесь очень и очень опытным пользователем компьютера и СУБД аки программист или системный администратор, то возможно вам не стоит вообще самому пробовать проводить всё то, что я буду описывать ниже. И следует вызвать действительно системного администратора, который уже сталкивался с такой проблемой. Потому что очень легко убить базу окончательно, в результате чего после потратить огромное количество времени на настройку базы с нуля. Если же вы уверены в своих силах, то в первую очередь делайте копию вашей базы данных. И всегда при любом ремонте делайте копию базы данных и уже только после этого производите какие-то манипуляции.
1) В папке, где хранится база данных Atol Frontol есть два файла: log.mdb и main.mdb. Их там, конечно, может быть и больше, если просто совершали копирование, но нам интересны эти два. А конкретно — main.mdb. Копируем его в каталог Bin в папке, куда был установлен сервер Interbase/Firebird/Yaffil. Я лично использую для подобных манипуляций Total Commander. Через него удобнее всего копировать и запускать все консольные приложения. Единственное, что всегда ещё стоит делать: запускать Total Commander под Администратором. Иначе можно натолкнуться на кучу проблем.
2) В моём конкретном случае рабочая папка СУБД расположена: C:\Program Files (x86)\FireBird\FireBird_2_1\Bin . Захожу туда в Total Commander. И уже там запускаю внизу в командной строке консоль. Таким образом есть возможность работы в консольном окне с правами администратора. Файл базы данных main.mdb уже предварительно скопирован в указанную мной дирректорию
3) Пробуем произвести проверку базы данных, введя команду:
gfix -v -full -user SYSDBA -pas masterkey main.gdb
Именно поэтому я и предлагаю скопировать базу в дирректорию СУБД, чтобы не вводить каждый раз длинный путь. ВАЖНО: SYSDBA и masterkey — это логин и пароль по умолчанию, что устанавливается в Firebird вообще и, в частности, в Atol Frontol. Если вам кто-то настраивал со стороны и решил указать другие логин и пароль для получения доступа, то у вас ничего не получится. И можно хоть до посинения проводить работу по исправлению, но не получить доступа к файлу БД. Я лично один раз с таким сталкивался и очень долго пытался рассказать по телефону системному администратору, насколько он был не прав.
4) Если утилита отработала и не выдала ничего на экран, то с базой все нормально (но в рассматриваемом мною случае такое быть просто не может, иначе всё бы работало нормально).
Если есть повреждения, то попытаемся исправить их:
gfix -mend -full -ignore -user SYSDBA -pas masterkey main.gdb
В частности, в результате этого может появиться нечто в стиле:
Видны отлично ошибки. всего-навсего 525 (5+14+506) ошибок. Вот они все сразу и выдавались в окне, что я указал на первой картинке.
5) Теперь можно проверить, остались ли ошибки, введя команду, как указано в п.3
6) Если ошибки остались (даже если они уменьшились), и никак не исправляются повтором п.4, то необходимо записать информацию в Bak-файл, а потом восстановим в другой новой базе данных.
7) Запись информации:
gbak -b -v -ig -g -user SYSDBA -pas masterkey main.gdb database.gbk
Вообще сама по себе команда служебная проходит как gbak -b -v -ig -g -user SYSDBA -pas masterkey server:database.gdb database.gbk , но у меня работает всегда отлично с прямым указанием файла базы данных.
Здесь применены следующие ключи:
- -b — создавать архивную копию базы;
- -v — выводить на экран подробный лог;
- -ig — игнорировать ошибки в данных;
- -g — запретить сборку мусора при чтении из базы.
То есть получится так, что ошибочные записи не будут сохранены. Будьте готовы, что те 525 ошибок (или сколько их будет) скорее всего не будут после восстановления БД. Но такое происходит редко. Чаще всего просто не сохраняются активные ссылки.
Процесс работы сохранения информации выглядит примерно так:
iBase.ru Forum
Форум по InterBase, Firebird и Yaffil
проблемы с БД
проблемы с БД
Сообщение Вера » 05 мар 2005, 11:05
Скажите, пожалуйста, насколько подлежит восстановлению БД в такой ситуации:
При сохранении документа выскочила ошибка IB-902: internal gds software consistency check (can’t continue after bugcheck).
1) при Database Validation (с флагом Validate record fragments) обнаруживается 4 database page errors. В log’е соответственно 4 строки «page xxxx is an orphan»
если после ругани на ошибки я ставлю флаг «repair» и больше не получаю никаких сообщений и строк в log-файле — значит ли это, что эти ошибки исправились во всяком случае, при повторном validation они не обнаруживаются.
но в ПО картина при этом не меняется
2) при попытке перекачать данные в новую БД на одной из таблиц возникает ошибка General SQL error. internal gds software consistency check (wrong record length (183) и практически на всех последующих таблицах ошибки General SQL error. internal gds software consistency check (can’t continue after bugcheck)
-> в полученной после перекачки базе часть данных просто отсутствует
3)при бекапе выдается следующее:
Backup started on Fri Mar 04 17:55:32 2005.
gbak: gbak version WI-V4.1.0.194
gbak: Version(s) for database «C:\SHouse263\upgrade\ib_sh247_ac.gdb»
InterBase/x86/Windows NT (access method), version «WI-V4.1.0.194»
on disk structure version 8.0
internal gds software consistency check (wrong record length (183))
gbak: gds_$receive failed
gbak: Exiting before completion due to errors
internal gds software consistency check (can’t continue after bugcheck)
Backup exited unsuccessfully on Fri Mar 04 18:03:47 2005
—————————————————————————
При этом БД кажется вполне рабочей за исключением невозможности просмотреть пару документов.
Возможно ли починить такую БД?
Обратилась к разработчикам ПО с вопросом, нельзя ли средствами IB удалить эти проблемные док-ты и все, что с ними связано (известны их типы,номера, склады и пр. атрибуты). Сама не могу попробовать, поскольку они не открывают структуру БД. Получила ответ, что коль не проходит backup, то и скрипт по удалению объектов не сработает.
Насколько это так
IB 4.1
база R-Keeper SHouse (складской учет ресторанного ПО)
размер БД порядка 500Мб
Ошибка Frontol 5, 6 при работе с базой (internal gds software consistency check)
Опубликовано в Статьи по ККТ 24.01.2020
При продаже товара выскакивает критическая ошибка «Ошибка работы с базой! Internal gds software consistency check (can’t continue after bugcheck)» и работа базы прекращается, любые повторные попытки войти в базу приводят к огромным количествам не понятных ошибок, сбоев, зависаний и вообще может выдать что база не обнаружена (перемещена или удалена). При попытка остановить/перезапустить службу Frontol она вообще зависала и помогала только перезагрузка терминала
В один прекрасный день произошло зависание ПК где был установлен Atol Frontol 6.1.0 , после загрузки и входа в режим продажи посыпалось больше количество ошибок и база отказалась напрочь работать….. магазин встал…. Любые попытки зависти базу не увенчались успехом и были готовы к тому, что все данные потерянны и придется все настраивать по новой, пришло понимание что БД убита.
Копии БД делались, но как восстановить из копии не кто внятно сказать не мог, интернет отправлял с одного форума на другой где было десятки команд и в каком порядке, что куда вводить не ясно, кто то вообще утверждал что бэкапы Frontol служат не для полного восстановления БД, а для частичного, если какие то данные утеряны но база работает, не ясно тогда вообще зачем нужны такие бэкапы (вообщем вопросов становилось все больше).
Простое решение восстановление БД Frontol которое помогает решить проблему в большинстве случаев, любому системному администратору.
Полное описание команд и их параметров можно найти на сайте: https://www.ibase.ru/gbak
ВАЖНО!! Этот метод работает даже если бэкапы не когда не делались.
Мы будет тестировать убитую базу на ошибки, исправлять эти ошибки и после исправлений записывать уже без ошибок в новую копию этой базы.
Рабочее место кассира: Windows 10 x64, Frontol v. 6.1.0 Торговля.Стандарт.
Исправление ошибок с Базой Frontol 6
1. Подготовка:
Прежде чем начать манипуляции с базой надо остановить службу FrontolService, иначе он просто не даст ничего с ней делать (она будет заблокирована для каких либо действий).
После остановки службы переходим в каталог с базой, в нашем случае «C:\DB\» (если не знаете где его найти ищите по имени фалов базы), там лежат два файла БД: log.mdb и main.mdb. Из этих файлов нам нужен — main.mdb это файл самой базы данных.
ВАЖНО! Обязательно делаем копию этих файлов и папок. И все делаем на копии!
Для упрощения написания команд файл базы данных main.mdb рекомендуется перенести в папку с утилитами по исправлению базы данных (иначе придется всегда прописывать длинный путь к утилитам): C:\Program Files (x86)\FireBird\FireBird_2_1\Bin.
Открываем командную строку под Администратором и начинаем и переходим в исправлению ошибок.
2. Исправление ошибок базы данных Frontol
Переходим в папку с утилитами: «cd C:\Program Files (x86)\FireBird\FireBird_2_1\Bin», если возникли трудности по работе с командной строкой команды можно легко найти в интернете (cd.. — назад, D: — смена диска).
в итоге у вас должно получиться такое окно.
Важно! Пользователь и пароль для базы Frontol по умолчанию SYSDBA и masterkey. Его не рекомендуется менять.
Проверяем базу данных на ошибки, введя команду:
gfix -v -full -user SYSDBA -pas masterkey main.gdb
Если после проверки утилитой на экран ничего не вывелось значит с базой все нормально и она рабочая, в нашем случаю было иначе:
Пытаем исправить ошибки командой:
gfix -mend -full -ignore -user SYSDBA -pas masterkey main.gdb
Бывает, что помогает и ошибки уходят совсем либо их становится меньше, либо же утилита выдаст такое же окно с таким же количеством ошибок как на скрине выше. Если это не помогла идем дальше.
Запишем базу в новый Bak-файл, а потом восстановим из этого Bak-файл в другой новой базе данных на смену битой.
Для записи базы в Bak-файл выполняем команду:
gbak -b -v -ig -g -user SYSDBA -pas masterkey main.gdb database.gbk
Если первый вариант команды не сработал пишем с указанием полных параметров сервера где расположена база:
gbak -b -v -ig -g -user SYSDBA -pas masterkey server:database.gdb database.gbk
Краткое описание параметров gbak:
-b — создать архивную копию базы.
-v — выводить на экран подробный лог (не обязательный).
-ig — игнорировать ошибки в данных.
-g — запретить сборку мусора при чтении из базы.
После выполнения команды будет создан Bak-файл, где будут очищены или перезаписаны все ошибки и битые записи (возможна частичная потеря записей но не всегда). Выполнение займет какое то время.
После выполнения команды будет сообщение о завершении «closing file, committing, and finishing».
Заключительный шаг, необходимо из созданного Bak-файл восстановить всю информацию в новую базу данных, которая в дальнейшем и станет рабочей.
Для восстановления выполняем команду:
gbak -c -v -user SYSDBA -pas masterkey database.gbk main_new.gdb
Если первый вариант команды не сработал пишем с указанием полных параметров сервера где расположена база:
gbak -c -v -user SYSDBA -pas masterkey database.gbk server:main_new.gdb
где main_new.gdb — это имя новой базы, выполнение команды занимает продолжительное время в зависимости от размера базы.
После выполнения команды будет сообщение о завершении «finishing, closing, and going gome».
После этого в каталоге в котором мы работали «C:\Program Files (x86)\FireBird\FireBird_2_1\Bin» должна появиться новая база Frontol с исправленными ошибками main_new.gdb.
3. Завершение и запуск
После всех проделанных команд готовый файл базы данных main_new.gdb копируем в папку где располагалась база в нашем случае «C:\DB\», старый файл MAIN.gdb можно переименовать, а новый необходимо назвать его именем. Лог файл можно оставить без изменений.
Запускаем службу FrontolService, либо перегружаем ПК.
Все должно работать. Frontol должен запуститься в штатном режиме все настройки должны быть сохранены, товары, скидки, продажи и т.д.