Редактирование баз

[diz]

Здравствуйте!

Ситауция следующая: полетела база, то есть касса перезагрузилась и при загрузке после переиндексации висла (после Reindex.. переходит на след строку и стоит) случайно подкинул базу с другой станции, которая уже отработала полдня, после чего все заработало и думал что на этом все. Но в конце дня день не закрылся, видимо потому что в системе имеются чеки со второй станции. В данный момент подкинул бэкап базы, все работает. Необходимо выгрузить данные за злополучный день...
Интересует такой вопрос, можно ли из например двух check.db сделать один?
Ну, то есть, имеется две папки database с одной станции: в первой - первая половина дня, во второй - вторая (но в здесь же находятся чеки первой половины дня со второй станции), необходимо их как то объединить их чтобы закрыть корректно день, или же закрыть их по очереди, но при этом возможно ли удалить неверные значения из одного из них (данные со второй станции)?
касса 6.77 мен 6.81

[SH]

случайно подкинул базу с другой станции

O_o ничего себе "случайность".

Но в конце дня день не закрылся, видимо потому что в системе имеются чеки со второй станции.

Вряд ли из-за этого.

при этом возможно ли удалить неверные значения из одного из них (данные со второй станции)?

Это как раз легко, взять да и потереть ненужные строки во всех файлах.

необходимо их как то объединить

Да, а вот это вопрос. Наверное, есть какие-то утилиты по работе с таблицами, которые это позволяют, но вот какие?

[VampireKB]

Вряд ли из-за этого.

из-за этого

Это как раз легко, взять да и потереть ненужные строки во всех файлах.

Ну ка ) Покажи как рядовой системщик будет легко удалять строчки о которых ничего не знает ( ну хот да..спустя неделю мук и страданий..(с) )

Да, а вот это вопрос. Наверное, есть какие-то утилиты по работе с таблицами, которые это позволяют, но вот какие?

[SH]

из-за этого

Ммм... А станции не все равно при закрытии дня, что в базе лежит?

[diz]

видимо нет, пишет что то вроде "не закрыт день второй юнит" (2 юнит - станция с которой копировал базу)

вот щас например отредактировал check.db редактором dbd32 - удалил лишнее, добавил нужное но столбцы cnum и lnum не совсем правильно получаются, то есть 1-18 первая половина дня и следом 1-85 вторая половина дня (LNUM) и 1-18 и 121-205 соответственно CNUM. на что влияют эти значения и влияют ли они вообще на что либо? и какие файлики еще следует отредактировать, которые отвечают за данные для закрытия дня?

[Admin]

А станции не все равно при закрытии дня, что в базе лежит?

нет, в базе есть запись, с какой именно станции был пробит чек, допустим и юнит1 и юнит2. И если в еодее нет отметки, что день закрыт по юнит2, то на юните1 будет упорно твердится, что не закрыт день на втором юните.

---------- Сообщение добавлено в 20:12 ---------- Предыдущее сообщение было в 20:11 ----------

CNUM

это САМАЯ главная сквозная идентификация конкретного чека во всех базах.

[diz]

тогда в данном случае если CNUM 1-18 и с 121-205 то нужно их редактировать или можно оставить как есть?

и как насчет файлов для закрытия дня? помимо check.db какие еще?

[SH]

diz, посмотрите любой OLDRES, увидите полный список.

---------- Сообщение добавлено в 20:25 ---------- Предыдущее сообщение было в 20:24 ----------

И если в еодее нет отметки, что день закрыт по юнит2, то на юните1 будет упорно твердится, что не закрыт день на втором юните.

Правильно, но, я думаю, топикстартер догадался закрыть день на втором юните (и запись в eoday должна была быть), а ошибка похоже все равно была.

---------- Сообщение добавлено в 20:26 ---------- Предыдущее сообщение было в 20:25 ----------

Ну ка ) Покажи как рядовой системщик будет легко удалять строчки о которых ничего не знает

Он уже Зато в базе разберется.

[diz]

ага. сижу ищу файлы в которых данные различаются в обеих папках, потом буду удалять/добавлять..
пока это только check opert rcheck pccheck..
а как же все таки с порядком строк? в каждом файле явно будут отсутствовать с 19 по 120 строки..

[SH]

Ну, можно попробовать проигнорить, закрыть так и посмотреть, что будет.
Если не получится, редактировать CNUM.