At 25/05/2002 09:14 PM, you wrote:

>I recall that you have been working with unicode in recent weeks. Is it
>possible that a unicode value was pushed into a charset NONE column at some
>point?

I do have some columns in the table in question that are of type
ASCII. The only problem that I have with this is that the values that go
in those columns are like "360.12" or "V1234". And, my client is in the US
and has no intention of using special characters(he's in the northern part
of the US). Also, the latest upgrade that this client has had was almost 2
months ago and the error only occurred a few days ago. I would've tried to
fix it sooner, but I was at BorCon.

I do appreciate your explanation and that does make a lot of sense. But,
how can I fix this. The only way that I see to fix the situation is to try
to copy as much of the data to a new table, but this means data will be
lost and my client wont accept that, especially it's recent financial data.

>btw, I'm still convinced that this error:
>"internal gds software consistency check (page in use during flush (210))"
>which your client encountered, was caused by something external going on
>when the database cache was flushed to disk. Even if forced writes is on,
>the cache still has to be flushed at the end of a transaction. This error
>would have had its source during a write (i.e. at the customer site),
>rather than during a read (you trying to read a file-copy of the database).
>
>If you are getting your customers to make file copies of the db for
>troubleshooting purposes (e.g. "zip up the database and send it to me")
>then teach them to shut down EVERYTHING (including the server) in an
>orderly fashion before they start zipping.
>
>Likewise, make it totally clear to them that they must not let a system
>backup run over the database directory whilst anyone is logged in. For
>safety, I'd want them to have the server shutdown as well if they *must*
>include the db directories in their system backups.

Explanation accepted. It was my boss that prepared the file to be
transferred. I'll have to make a policy for him to follow to shut-down the
DB server before copying the database file.

>I'd really like to collect together some of these "inconsistency check"
>errors and document them into one paper.

This would be very appreciated, since in the IB 6 beta docs, the error
number is only mentioned and not the list of inconsistency check errors and
possible causes.

Again thank you. I'll think of something to try in the morning(it's 10pm
here right now).


Daniel Rail
Senior System Engineer
ACCRA Group Inc. (www.accra.ca)
ACCRA Med Software Inc. (www.accramed.ca)