SQLBase 12.2.1 : 09024 GCI SEA Session ended abnormally

[svit]

We just migrated from " 8.5 --> 12.2.1.12624 (x64) "

On some SELECT, we have the "09024 GCI SEA Session ended abnormally" error that happens every time...

To make it "normal" we have to change our equi-join to outer-join '(+)'.

Before in SQLBase 8.5 this was not a problem ...

Help, What to do ?


Thank's

[monchotgu]

Does your database Crashes? or it is just in the client side?

[svit]

Yes, every time (database + client).

I thought I figured out why, but I didn't.

When loading the database from sql (unload database f:\data.sql / load sql f:\data.sql), he had not created the foreign keys correctly.

[monchotgu]

Have you try running a check database command to see if there is a corrupt index?
If ithe same select command causes the error, check the indexes on the tables involved in the select.
This has happen to me with corrupt indexes. The "session ended abnormaly" is because the database crashes.
You can also check in the folder where the database is installed there is a file called fail.sql that should record the error that crashes the database.

Hope this helps

[Igor Ivanovic]

FYI, "check database" doesn't always catch all of the errors/corruptions.
Long time ago I was suggested by support to use "UNLOAD DATABASE NUL;" as it touches every single part of the database, and I'm still using it.
The single "l" in nul in the command is on purpose.
If you write null it will actually write to the file, nul doesn't, so it's quick.

You can add a log to the command so you can check where the problem was.
Once you have it found out, if it's an index, just drop it and recreate, the same goes for referential integrity.

If it's a table, you can copy the content with the "insert into select from order by index" command.
It will stop on the corrupt page (or row), but you can continue from the next record using the next value of the index, so you loose a minimal amount of data.
Using this method I was able to get almost 99.9% of data from a badly corrupted database in the past.
It's manual work but worth trying.

[monchotgu]

Thanks Igor for that tip on the unload command! I will definately take it into account if I run into trouble with the database again.!