Index is out of date

[f13nd]

у меня тож такое было... интересно бы узнать из-за чего такое происходит? почему ордерс.дб бьется?

[SH]

Ну вообще, если принять на веру, что сам r-k работает со своими таблицами корректно, таблица (любая) может побиться в случае некорректного закрытия. Допустим, в нее идет запись и тут пропадает электричество. Поэтому на сервере всегда важен бесперебойник.
Еще может быть, что злоумышленник сохранил orders.db (без индексного файла), потом попробовал подкинуть его обратно, вместо таблицы, в которую были внесены изменения - но так как индексный файл относится уже к другой таблице, выдается подобная ошибка.
Из всего этого следуют два вывода:
1. На сервере обязателен ИБП (даже если сервер на кассе);
2. Доступ к серверу (физический и сетевой к DATABASE) должен быть исключен. Поэтому, в частности, сервер на кассе не желателен.
В последних версиях UCS постаралось защитить транзакции с таблицами по-максимуму. Ранее в некоторых версиях "удачной" перезагрузкой сервера в момент работы можно было добиться бесследного исчезновения данных о продажах. Поэтому рекомендуется использовать кассовые версии 6.81 и выше.

[f13nd]

Ну вообще, если принять на веру, что сам r-k работает со своими таблицами корректно, таблица (любая) может побиться в случае некорректного закрытия. Допустим, в нее идет запись и тут пропадает электричество. Поэтому на сервере всегда важен бесперебойник.
Еще может быть, что злоумышленник сохранил orders.db (без индексного файла), потом попробовал подкинуть его обратно, вместо таблицы, в которую были внесены изменения - но так как индексный файл относится уже к другой таблице, выдается подобная ошибка.
Из всего этого следуют два вывода:
1. На сервере обязателен ИБП (даже если сервер на кассе);
2. Доступ к серверу (физический и сетевой к DATABASE) должен быть исключен. Поэтому, в частности, сервер на кассе не желателен.
В последних версиях UCS постаралось защитить транзакции с таблицами по-максимуму. Ранее в некоторых версиях "удачной" перезагрузкой сервера в момент работы можно было добиться бесследного исчезновения данных о продажах. Поэтому рекомендуется использовать кассовые версии 6.81 и выше.

Ясно

[okis]

В другом заведении возникла такая же проблема. На это раз удалось вылечить при помощи pdxrbld. Спасибо PaViSу за прогу.

[VampireKB]

у БДЕ есть 1 плохая наследственность: она поддерживает лишь 1 подключение к базе(и,соответсвенно,выпол� �ение максимум 1 скрипта за раз)

Есть подозрение что одновременное сохранение заказов на нескольких станциях может привести к данной проблеме ....или на очень старых или на очень новых машинках...

[Admin]

1 подключение к базе(и,соответсвенно,выпол

видать кто-то подключился

[VampireKB]

Усё,обиделся я )
Вот что значит "хотеть спать"..даже предложение не дописал.... ...

*всем спок.ночи

[PaViS]

В другом заведении возникла такая же проблема. На это раз удалось вылечить при помощи pdxrbld. Спасибо PaViSу за прогу.

Тогда кнопочку жми

у БДЕ есть 1 плохая наследственность: она поддерживает лишь 1 подключение к базе(и,соответсвенно,выпол� �ение максимум 1 скрипта за раз)

Есть подозрение что одновременное сохранение заказов на нескольких станциях может привести к данной проблеме ....или на очень старых или на очень новых машинках...

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

[okis]

Тогда кнопочку жми

Кнопочку нажал там, где прога выложена.

[Александрр]

Добрый день возникла таже проблем c e_rest32 но только при обрашенни конкретно к меню все остально работает выдает следующю ошибку index is out of date Table:C\\\Db\Menu.db помогите ее исправить и если не сложно обьясните попонятнее ))