good morning.
excuse me for my poor english.
i have informix rapid on sco unix, some days ago, a dat file was near of 2
gb and i deleted some records and after i alter table (a decimal (3,0) to
(4,0) and after another time to (3,0)) to compact the dat file.
that was right.
when i was doing the alter table, i saw that the filesystem was near of 98%
and i pass 3 dat files of the database directory to may computer and when
the alter table was made i put the dat files in the database directoy.
After that one of the tables (an important table) does not work well, there
are records that the query instructions not found. i have made a bcheck -y
but it doesnt work well.
can anybody help me.
thanks a lot.
> good morning.
> excuse me for my poor english.
[quoted text clipped - 10 lines]
> can anybody help me.
> thanks a lot.
Interpreting a bit...
You have an SCO system that is running Informix SE in some version older
than 7.25, and you might also be using Informix-4GL Rapid Development
System, I4GL-RDS.
You had some data files that grew close to the old 2GB file size limit.
So, to rebuild the table, you did a pair of ALTER TABLE operations.
After doing this, you have some problems, and bcheck (predecessor to
secheck - it sounds like a rather old version of SE) is not able to fix
the issues.
This is going to be painful to sort out. However, the first question
is: do you have a good backup? If so, keep it carefully. If not, now
is a good time to remind yourself why backups are recommended.
How much space do you have on your disk? Make a copy of the database if
you've got the space. Work on the copy - not the original. Or work on
the original and not the copy. Don't work on both.
When you say bcheck doesn't work well, what happens? Do you know if the
index file is more or less OK, or is it corrupted? Do you have the
database schema? How many indexes are on that table?
If the index is corrupted, then the best thing may be to create a new
table with the same structure as the old, then copy the new index file
over the old. Then run bcheck on that. It will say there are a
gazillion records not in the index - that's correct. But it might be
able to rebuild the index(es).
Is the data corrupted? We might need to analyze the data file, using
the record size plus one, looking at the last byte. That should be
either '\n' for a current record, or '\0' for a deleted record. If you
see other values, your file is either corrupt or you've got the wrong
record size. If you find the file is looking semi-decent, then the data
can probably be recovered. If you find some inconsistency - the first
half of the file is OK and the second is not, for example - then we
probably need to go to the backup. If you don't have a backup, then
we'll have to salvage what there is, piecemeal if necessary. You do
have the schema - that should make it possible to resolve the issues,
but it might take some inventiveness.
It would be easier to go to the backup.
And maybe upgrae to a platform that supports files bigger than 2 GB, so
you can upgrade to a version of SE that supports files bigger than 2 GB,
so you don't have to panic about it again.

Signature
Jonathan Leffler #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2008.0513 -- http://dbi.perl.org/
publictimestamp.org/ptb/PTB-3781 whirlpool 2008-07-21 03:00:04
DEC8C3320912C407966BD402FCB444B762BD4A30D242434B6683A62ECBEB473903EB84
2F933D04D6D5A5CA6FC5272C7BB9477E2EF8248B9D76BD892FFBCA07D
Juanito - 21 Jul 2008 09:34 GMT
i have the .dat file of a backup. can i do something with that?
>> good morning.
>> excuse me for my poor english.
[quoted text clipped - 59 lines]
> you can upgrade to a version of SE that supports files bigger than 2 GB,
> so you don't have to panic about it again.