при резервировании базы выдается ошибка

← →
stud © (2003-09-23 15:03) [0]

arithmetic overflow or division by zero has occurred.
arirhmetic exception, numeric overflow, or string truncation.
что сие может означать?
создаю новую базу этими же скриптами, переношу данные датапампом - и в новой базе все работате??? что может быть?

← →
kaif © (2003-09-23 15:23) [1]

Когда эта ошибка происходит:
1. При backup?
2. При Restore?

← →
stud © (2003-09-23 15:24) [2]

при backup

← →
kaif © (2003-09-23 15:30) [3]

Есть ли в базе:
1. Вычисляемые поля, в которых могло бы происходить деление на 0?
2. Есть ли поля, объявленные NOT NULL, добавленные в таблицу, в которой уже есть строки, но для которых ты забыл создать все значения и какие-то осталиcь NULL?

← →
kaif © (2003-09-23 15:32) [4]

Сначала сделай на всякий копию файла БД.
Затем попробуй из самых подозрительных таблиц удалить все данные и сделать backup. Так ты узнаешь, которая таблица создает проблему (если их не несколько...).

← →
stud © (2003-09-23 15:33) [5]

нет.

← →
kaif © (2003-09-23 15:53) [6]

В общем, стратегия такая, какую я предложил. Удаляешь последовательно данные из каждой таблицы и пытаешься после этого сделать backup. Как только backup заработает, начинаешь разбираться в причинах (напрягать мозг). Может, ты чего-то не видишь.

← →
stud © (2003-09-23 16:10) [7]

может))

← →
stud © (2003-09-23 16:42) [8]

после перезагрузки появилось следующее сообщение:
unsuccesful execution caused by system error that does not preclude succesful execution of subsequent statments.
message length error (encountered 38, expected 30).
gds_$receive failed.
что в переводе на русский (промпт) значит
неудачное выполнение вызвано системной ошибкой, которая не препятствует успешному выполнению следующего выражения
ошибка длины сообщения ....
только файл бекапа не создается, хотя сервис нормально завершает работу(IBexpert)
IBconsole выдает такое сообщение:
Arithmetic exception, numeric overflow, or string truncation
и что делать?
удалять данные из таблиц слишком муторно, потомучто добавлять их обратно нужно, а там триггеры, генераторы .....
(((((((((((

← →
Johnmen © (2003-09-23 16:59) [9]

Удалять кривые данные все равно придется..:)

← →
stud © (2003-09-23 17:03) [10]

дык а найти их как.
тут косоль выдает сообщения по очереди:
о переполнении
или о длине сообщения
каждый раз по разному
как найти на каком объекте это происходит?

← →
Johnmen © (2003-09-23 17:08) [11]

Так ведь kaif © предложил методику.

← →
kaif © (2003-09-23 19:14) [12]

Ну так чем эпопея-то закончилась?
Не исключена ведь и кривизна сервера...
Народу интересно.
Если что-то удалось раскопать, сообщи на форум. И версию сервера не забудь.

← →
Zacho © (2003-09-23 19:18) [13]

2 stud :
Почитай http://www.ibase.ru/devinfo/db_repair.htm

← →
stud © (2003-09-24 09:22) [14]

вот именно это вчера нашед и изучал, сейчас начну ломать)))

← →
stud © (2003-09-24 09:40) [15]

при проверке базы gfix -validate
выдается следующее сообщение
Summary of validation errors

Number of index page errors : 1
Number of database page errors : 6

← →
Sergey13 © (2003-09-24 09:42) [16]

А может и ломать ничего не надо. У меня были похожие проблемы. Получились из за того что менял типы данных через домены (длины, точность). Все меняется, но старые данные (которые были до замены), видимо хранятся в старом виде. Помогло помнится нечто вроде апдейта с поле=поле+"", или поле=поле*1. Можно попробовать через создание поля "двойника".

← →
stud © (2003-09-24 09:47) [17]

да все бы ничего, только знать бы какое поле))) или хотя бы таблица....

← →
Sergey13 © (2003-09-24 10:02) [18]

Дык скажи гбаку делать подробный вывод. В ИБЭксперте можно вроде (нет под рукой). Там будет писаться имя таблицы, на которой происходит ошибка.

← →
stud © (2003-09-24 10:10) [19]

gbak: writing parameter SPEC for stored procedure
вот тут он и останавливается. с процедурой все в порядке, т.к. бэкап с ней проходил раньше и она не менялась

← →
Sergey13 © (2003-09-24 10:34) [20]

Вот тут не подскажу. Черт его знает че там. Попробуй ее убить/ пересоздать. Или смотри все таблицы, которые там упоминаются.

ЗЫ:Кстати а таблицы уже бекапились по логу или еще нет. Какой там порядок не помню.

← →
stud © (2003-09-24 10:39) [21]

вот последние данные))
gbak: writing data for table PERERYV
gbak: 2 records written
gbak: writing index RDB$PRIMARY28
gbak: writing data for table MKB_10
gbak: 0 records written
gbak: writing index RDB$PRIMARY6
gbak: writing data for table BASE_RASP
gbak: ERROR: message length error (encountered 38, expected 30)
gbak: ERROR: gds_$receive failed
gbak: Exiting before completion due to errors

← →
Sergey13 © (2003-09-24 10:49) [22]

>gbak: writing data for table BASE_RASP
>gbak: ERROR: message length error (encountered 38, expected 30)
ИМХО, тут надо копать. В таблице BASE_RASP.

копал,но текстовых полей в этой таблице нету. только time, smallint,integer и первичный ключ

Так не обязательно текстовые. Например integer на smallint не менял? И как эти типы описывается - "напрямую" для каждого поля или через домены?

нет. похоже дело в ПК, вот как-бы его удалить
в ибэксперте не получается, не отключает индекс и не дает удалить ПК

Ну и не отключай. Создай поле дубликат ПК1. Потом ПК1=ПК, потом ПК=ПК1. Потом удали ПК1.

нашел в чем дело, точнее объекты. две таблицы удалил их - все нормально

Это может быть (и есть)
и название этому только одно:

Убогенькие разработчики убогонького серверка сэкономили,
и объединили несколько сообщений об ошибках в одно сообщение,
специально чтобы пользователям (то бишь нам) их продукта было удобнее работать:

arithmetic overflow or division by zero has occurred.
arirhmetic exception, numeric overflow, or string truncation.

У тебя же имеет место быть последнее (изменил формат поля).

но при удалении данных из таблицы то же самое было

← →
KaRaT (2003-09-24 13:50) [30]

Ключевое поле содержит дубликат (номер одинаковый). Такое происходить не должно, но глюки случаются... удали ключ, найди повторяющееся поле и сделай ему туда что-нибудь другое. Восстанови ключ.

да нет все нормально со значениями, я же писал выше при удалении данных из таблицы и уничтожении первичного ключа тоже самое происходит. к тому же создание копии БД из этих же данных проходит нормально и все бекапится без проблем.

однако сегодня проблема повторилась))
очевидно из-за смены типа полей. поменял timestamp на date.
таблицы известны, какие действия можно предпринять, кроме их удаления?

при резервировании базы выдается ошибка Найти похожие ветки