Поле SYS_NUM в Acheck/APcheck/ARcheck.db

[iArt308]

Доброго всем дня!
Прошу помощи или совета!

Дано:
RKeeper v.6.97 (win), выделенный сервер (на отдельном компьютере, Win2k3Serv).
Через модуль Data Transport делается выгрузка за некоторый период в склад.
В папке Stock создаются соответствующий набор файлов.

Проблема:
Поле SYS_NUM таблиц Acheck.db/APcheck.db/ARcheck.db должно (по идее) содержать уникальный номер чека в системе.
И до определенного момента так и было.
Сейчас же поле SYS_NUM для всех записей содержит исключительно одно значение 2120000000
Это приводит к проблемам в работе с этими данными в нашей складской программе.

Вопрос:
Из какого источника берутся данные для заполнения поля SYS_NUM?
Возможно ли "исправить" этот источник?

Заранее благодарен всем тем кто откликнется на мою просьбу!!!

[okis]

Из какого источника берутся данные для заполнения поля SYS_NUM?

ark6.udb

Возможно ли "исправить" этот источник?

Непосредственно - нет. Можно попробовать взять чистый ark6.udb и перезакрыть в него дни, следующие за проблемным днем. Можно попробовать удалить из старого файла данные начиная с проблемного дня и перезакрыть в него дни, следующие за проблемным днем.

[iArt308]

Благодарю за ответ!
Как только попробую - отпишусь о результатах!

ark6.udb



Непосредственно - нет. Можно попробовать взять чистый ark6.udb и перезакрыть в него дни, следующие за проблемным днем. Можно попробовать удалить из старого файла данные начиная с проблемного дня и перезакрыть в него дни, следующие за проблемным днем.

[PaViS]

И до определенного момента так и было.
Сейчас же поле SYS_NUM для всех записей содержит исключительно одно значение 2120000000

Проверьте с какого дня это началось.
Как уже сказал okis, это поле из таблицы ACheck файла ark6.udb.
Найти проблемный день, удалить его и последующие, перезакрыть проблемный, проверить, перезакрыть последующие, проверить.
ЗЫ.
2 120 000 000 - два миллиарда сто двадцать миллионов чеков !!! Это просто не реально столько продать! Даже если это касс.сервер фаст-фуда на 10 касс, то при проведении даже 1 000 чеков в день на каждой (10 000 чеков) за год получим 3 650 000. У вас сервер работает уже 580 лет?

[iArt308]

Конечно же 580 лет сервер у нас не работает)))
Последний день с нормальным полем SYS_NUM имел значение порядка 1670000.
Я попробую использовать чистый ark6.udb, т.к., насколько я понял, обычными средствами этот файл не отредактировать ввиду его закрытости.

Но вот возник вопрос - удаляя период с данными с помощью ресторанного редактора (rest editor) - я удаляю данные как раз из ark6.udb?
Т.е., по сути, найдя проблемный день, я могу удалить период начиная с этого дня и по текущий и закрыть дни заново?

Проверьте с какого дня это началось.
Как уже сказал okis, это поле из таблицы ACheck файла ark6.udb.
Найти проблемный день, удалить его и последующие, перезакрыть проблемный, проверить, перезакрыть последующие, проверить.
ЗЫ.
2 120 000 000 - два миллиарда сто двадцать миллионов чеков !!! Это просто не реально столько продать! Даже если это касс.сервер фаст-фуда на 10 касс, то при проведении даже 1 000 чеков в день на каждой (10 000 чеков) за год получим 3 650 000. У вас сервер работает уже 580 лет?

[SH]

удаляя период с данными с помощью ресторанного редактора (rest editor) - я удаляю данные как раз из ark6.udb?

Да.

найдя проблемный день, я могу удалить период начиная с этого дня и по текущий и закрыть дни заново?

Да.

А переиндексацию делали?

[PaViS]

удаляя период с данными с помощью ресторанного редактора (rest editor) - я удаляю данные как раз из ark6.udb?
Т.е., по сути, найдя проблемный день, я могу удалить период начиная с этого дня и по текущий и закрыть дни заново?

Только не RestEditor а Report. А потом можно еще воспользоваться Ark6pack.exe для сжатия базы.
Об этом написал okis в первом же ответе.

[iArt308]

Добрый день еще раз!
Наконец добрался до объекта и попробовал предложенные варианты.
А именно: удалил весь период данных, обработал утилитой a6pack, закрыл заново день (взял для начала, для проверки, 1 день из олдрезов).
Сделал выгрузку с помощью data transport. Результат тот же...

Теперь возник вопрос - я нашел чистый ark6.udb.
Насколько я понял в нем хранятся многие данные в т.ч. данные о пользователях и паролях.
Завести пользователей можно через модуль disp32.
Но изначального пароля я не знаю.
Может есть некий универсальный?

---------- Добавлено в 14:58 ---------- Предыдущее сообщение было размещено в 14:16 ----------

Всё, вопрос снят, проблема решена!

Взял ark6.ubd за дату до возникновения проблемы (не стирал период, а именно старый файл).
Прогнал upgrade32 и a6pack.
Прокачал данные из олдрез.
Поле SYS_NUM теперь содержит корректные данные.
Видимо проблема была с ark6 на уровне "физики".

Благодарю всех кто откликнулся!!!!!!

[SH]

Поздравляю!

Завести пользователей можно через модуль disp32.
Но изначального пароля я не знаю.
Может есть некий универсальный?

Для udb - нет.
На Диспетчер пароль назначается дилером, в свою очередь, через DealRK, а туда дилер входит через свой дилерский пароль.

[PaViS]

Взял ark6.ubd за дату до возникновения проблемы (не стирал период, а именно старый файл).

Хорошо иметь резервные копии по дням!