В общем в БД косяк, делаю бэкап-ресторе IBExpert-om, говорит:

IBE: violation of FOREIGN KEY constraint "".
     violation of FOREIGN KEY constraint "FK_REMAIN_WARE" on table "REMAIN".
     Foreign key reference target does not exist.

Понимаю что ругается на внешний ключ, гугл отчасти помог: "Нужно выполнить запрос, который покажет имеющиеся в детали и отсутствующие в мастере идентификаторы." Проблема в том что с SQL я не на ТЫ мягко говоря, а вручную искать месяц придется, записей в таблице очень много. Где б такой запросик то взять, либо может кто сталкивался с такой проблемой и решил по другому. Завтра надо по-любому кассу запускать, а они закрыться не могут, при любом обращении к БД ошибка выскакивает(

у фронтола есть своя утилита для фикса иб.
Судя по используемому софту, у тебя большой терминал с виндовс эмбед и файербердом на борту.
Крашнулись индексы - смотри бекапы.)
Для начала попробуй скопировать бд, если не копируется, то печалька.)

и я бы все таки вопрос на атоловском форуме задавал, а не на мисте, там грамотная и адекватно реагирующая поддержка.

(1) Угу, fixbase.cmd
(0) При нормально настроенном фронтоле - при каждом закрытии смены и при каждом простое делаются резервные копии. Смотреть - куда складываются - в настройках Фронтола. В крайнем случае - брать резервную копию оттуда.

(1) да все верно, на фаерберде база, она копируется. Проверка gfix-ом не помогает. Бэкап со сборкой мусора проходит, но при восстановлении из бэкапа ругается на внешний ключ один единственный, причем он восстанавливает базу до конца, но индекс оставляет неактивированным. При попытке активировать руками выдает ту же ошибку. На форуме атола зарегался, там ваще чо то пусто, либо меня не пускают пока модер не проверить, либо хз чо там еще

http://forum.atol.ru/

Завтра с утра там быстро помогут - если что и базу возьмут и поправят. Часто работники и вечером просматривают форум.

(5) именно там я и зарегался, но там пустует все(

(7)В смысле? - хотя там вроде регистрацию усложнили.

(8) ну вот например такая хрень выходит при активации аккаунта:

Регистрация
Спасибо. Ваша регистрация успешно завершена. Администрация форума должна проверить вашу регистрацию перед тем, как вы получите право отправлять сообщения. Администрация будет уведомлена о вашей регистрации.

(8) При попытке поиска выходит:

Обнаружена ошибка. Если вам неизвестны причины ошибки, попробуйте обратиться к разделам помощи.
Причина:
Вы не указали ни одного форума для поиска, либо вы указали защищенный паролем форум. Если это так, то вам необходимо авторизоваться в запароленном форуме, прежде чем вы сможете воспользоваться поиском там.


а тем форумов просто нет, их не видать. Видимо скрыты пока админы не дадут добро, завтра еще посмотрю.

(28) У меня была точно такая же ошибка. Причем не лечилось никаким фикс-бэйсом. Эта таблица отвечает за изменение остатка товара, поэтому я даже задумываться не стал, а просто сгенерил новую БД.

(1)(3)  а в чем помогут те бекапы? Продажи и движения между бэкапом и текущим временем где брать? В каком месте? Правильно  - в журнале регистрации. И нафих тот бекап нужен? Все данные все равно раз в день сливаются в учетную программу.

(11) я уже сам вылечил. Ты прав это таблица остатков (detail), которая привязана индексом в посте (0) к таблице товаров SPRT (master), так вот я запросом нашел что в таблице остатков имеются 3 записи, которые ссылаются в никуда в таблице товаров, удалил индекс, удалил эти 3 записи, заново создал индекс, заново сделал бэкап-ресторе для сборки мусора и вуаля, все летает)

(8) кстати, на форум Атол сегодня доступ одобрили)

(12) согласен, можно подойти к решению вопроса правильно ))  У меня "ремонт" составляет около 5-7 минут по удаленке с выгрузкой-загрузкой и закрытием смены :)

(14) так ведь я первый раз пол дня не мог победить) теперь когда знаешь куда копать тоже времени много не займет)

(14) с самого начала была мысль создать новую БД, в одном магазине месяц назад так и сделал. Но тут стало интересно и решил выяснить откуда ноги растут)

(14)Работаю с клиентами у которых около 70 касс на фронтоле - приблуда тестирования не помогла только в одном случае за 5 лет.

(11) Как это "Чем помогут", ну потеряется один-два чека, не сильно большая проблема. Мы лично не паримся по этому поводу. Хотя в 85% случаев все нормально из последней базы "_idle" или "_close" восстанавливается.

Если данные все же потерялись и очень захочется "все по правильному", то действительно, в журнале регистрации посмотреть какие продажи были в "потерянное" время, далее в драйвере фискальник перевести в режим "эмулятор" и набить этот чек еще раз.

Вариант же с "удалением индексов и записей" не гарантирует 100% решения проблемы, это разовая работа для умного человека (посмотреть в чем ошибка, проанализировать - нужные/не нужные проблемные записи, вручную SQL-запросы написать), тогда как варианты выше, это для персонала со средней квалификацией.