Subject | Re: [firebird-support] Re: Validate and backup ok, but restore with errors |
---|---|
Author | Helen Borrie |
Post date | 2006-02-19T23:56:54Z |
At 09:30 AM 20/02/2006, you wrote:
switch that enables you to restore tables...well....one at at
time. :-) So it will stop during the restoration of a table with
metadata errors (unlikely) or error-prone data.
A propos your (Adam's) comments are talking about RI constraints
(which get created *after* all the tables are restored, anyway...),
whereas the reported problem is occurring during population of a
table with data.
"Arithmetic overflow or division by zero has occurred.
arithmetic exception, numeric overflow, or string truncation."
It could be an error in calculating a CHECK constraint or Before
Insert trigger that involves a string concatenation or some other
calculation. I think I'd first want to look at the check constraints
and triggers on the offending table and see whether I needed to fix
up a calculation so that it takes account of potential exception conditions.
As to how this situation might have arisen: a Before Insert trigger
or check constraint added to an existing table doesn't go through and
verify that existing data is consistent with it.
If you do this sort of thing without, yourself, manually, "fixing up"
existing data to be consistent with new data, then it won't show up
until the first time you insert "bad" data. A record, once inserted,
won't get inserted again *except* in a restore. It's well on the
cards that this is the first time the database has been restored
since the metadata change was done.
./heLen
>To FB Gurus, is there a way of doing a metadata only restore from aNot clear what you mean by this. There is the -o[ne_at_a_time]
>database that contains data as well? This would be a useful feature
>for data pumping if you had to restore one at a time, then correct,
>then pump.
switch that enables you to restore tables...well....one at at
time. :-) So it will stop during the restoration of a table with
metadata errors (unlikely) or error-prone data.
A propos your (Adam's) comments are talking about RI constraints
(which get created *after* all the tables are restored, anyway...),
whereas the reported problem is occurring during population of a
table with data.
"Arithmetic overflow or division by zero has occurred.
arithmetic exception, numeric overflow, or string truncation."
It could be an error in calculating a CHECK constraint or Before
Insert trigger that involves a string concatenation or some other
calculation. I think I'd first want to look at the check constraints
and triggers on the offending table and see whether I needed to fix
up a calculation so that it takes account of potential exception conditions.
As to how this situation might have arisen: a Before Insert trigger
or check constraint added to an existing table doesn't go through and
verify that existing data is consistent with it.
If you do this sort of thing without, yourself, manually, "fixing up"
existing data to be consistent with new data, then it won't show up
until the first time you insert "bad" data. A record, once inserted,
won't get inserted again *except* in a restore. It's well on the
cards that this is the first time the database has been restored
since the metadata change was done.
./heLen