Jason Dodson wrote:

> Adam,
>
> This is obviously a "clean" test case. Likely in a clean database, but more importantly, with table definitions that
> were put into play. Just because the clean test fails is no justification to drop it as -irreproducible-

Helen asked - What version of Firebird. That would be a good starting point.
*I* would assume that there was data in the field before making the
change? So we probably need to know the range of values previously stored.
*LIKE* the NULL problem, making changes to the metadata without checking
the data can be a source of problems. I prefer the much more secure 'new
field', pump data from old, drop old, rename field. The way you HAD to
do it in Interbase. If there is anything in the data at least it will be
checked and perhaps the update script could just create a dummy new
field and pump prior to applying the ALTER to the old field. ( Then you
would see how much time is needed to check the data and find any 'funny'
data ;) )

> I will track down when I made made these changes, and restore the backup from before I made the type change. So long as
> it breaks again, I will file a bug report, with a test case.

It is amazing just how much 'funny' data gets into a live database, even
with input checking and the database checks themselves. Personally I
will not be surprised if you find something in the data that is 'adding
to the test case' which we don't know about yet :)

--
Lester Caine - G8HFL
-----------------------------
L.S.Caine Electronic Services
Treasurer - Firebird Foundation Inc.