Проблема: При попытке сканирования любого товара для продажи выдаётся просто эпическое количество ошибок:
При этом сама программа говорит о том, что она просто не может работать дальше с такими проблемами, собирает свои вещи и переезжает к маме в Тверь:
Система: 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 ошибок (или сколько их будет) скорее всего не будут после восстановления БД. Но такое происходит редко. Чаще всего просто не сохраняются активные ссылки.
Процесс работы сохранения информации выглядит примерно так:
В конце программа обязательно говорит "closing file, committing, and finishing." Это означает, что работа данной утилиты завершена. Можно переходить дальше.
8) Теперь восстанавливаем всю информацию в новую базу данных:
gbak -c -v -user SYSDBA -pas masterkey database.gbk new.gdb
Опять же сама служебная команда пишется так: gbak -c -v -user SYSDBA -pas masterkey database.gbk server:new.gdb с комментариями разработчиков "Обратите внимание, что при указании имени базы данных необходимо указать имя сервера и через двоеточие полный путь к файлу базы данных на сервере (обратите внимание, что если вы даже скопировали файл базы данных в одну папку с утилитой резервного копирования все равно необходимо указать полный путь к файлу). При указании имени архива следует указать только полный путь к файлу без указания имени сервера."
Однако в связи с тем, что файл БД скопирован в рабочую дирректорию, можно просто указать наименование файла.
Процесс работы утилиты по восстановлению выглядит примерно так:
В конце восстановления утилита обязательно активирует все ключи: внутренние и внешние. Без них работать БД не будет даже восстановленная.
9) Скопировать файл new.db обратно в папку, где хранится старая база данных. Старый main.db переименовать, например, в main-1.db, а новый new.db - в main.db
10) Запустить Atol Frontol. Всё должно работать!!
Пояснение: Должен сказать, что в 9 случаях из 10 БД после приведённых мною выше действий работает. Очень редко когда случается, что и после этого находятся какие-то проблемы. Вообще можно вновь созданных файл new.db проверить на ошибки, как в п.3 и п.4. Лишним не будет. Однако если после восстановления всё равно идут ошибки, значит, дело невероятно серьёзное. Возможно, что БД повреждена настолько, что восстановление не поможет. Если ещё вариант восстановить ее без внешних ссылок (индексов), а потом все активировать по одному. Однако это - по-настоящему работа кропотливая и достойная отдельной темы. Я её обязательно разберу.
Однако, если у вас не получилось "завести" свою БД и требуется именно более глубокое восстановление либо же вы просто сами не хотите возиться, то можете обратиться ко мне - greenand@rambler.ru. И я обязательно помогу вам в их устранении.
Подписывайтесь на канал "Кассовик" и ни одна, даже самая малейшая проблема не доставит Вам совершенно никаких неприятностей.
