>>> On Nov 23, 3:33 am, vomari...@yahoo.com wrote:
>>>> i'm trying to convert old dat/idx files made with sqlexec 2.10 (18
[quoted text clipped - 33 lines]
>> database directory? What is the value of DBPATH? Can you use the 7.25
>> DB-Access to get at other, not so ancient databases?
> hi Jonathan,
> the sqlexec 2.10 is running on a dpx 2 (system B.O.S.). the filesystem
> free space is really small so i'm trying to save and restore DAT files
> on an x86 with SE 7.25.
DPX2 - That was a Bull machine, IIRC. Haven't seen one in a *long*
time! What I don't remember is the CPU chip family - Motorola, Intel,
something else... Hmmm; a quick Google search on 'dpx2 bull' suggests
it was a Motorola 68K machine. That may cause some problems.
> This SE 7.25 on linux is running fine. i have created the table on SE
> 7 (fortunally sqlexec 2.10 has a dbschema) then copy the DAT on it
> then secheck and select but it gives fancy records. xxd on the
> sqlexec 2.10 DAT show 0xd 0xa as a mark for the record's end.
You are switching between two hardware architectures with different
formats for the C float and double types. All other types in C-ISAM
(and hence SE) files are stored in a platform independent format, but
the C float and double (SQL SMALLFLOAT and FLOAT respectively) are not.
And, working from memory of transferring data between NCR Tower
machines with 68K and x86 architectures, what looks like a sensible
float on one looks like a ridiculous value on the other.
I'm puzzled about the end of record markers. C-ISAM uses ^J (\n, 0x0A)
as the end of record marker (for live records; NUL 0x00 for deleted
records). Did the .dat file get copied by FTP to a Windows machine at
some point? Without setting the binary mode? That would explain the
CRLF record endings - and the fix is to redo the transfer using binary
mode in FTP.
In general, if you get the data across reliably, then creating the file
with the new SE on Linux, then copying the old (transferred) .dat file
over the new empty .dat file, and then running secheck to rebuild the
index file correctly normally works. If you don't have C float/double
values to worry about, then that should be all you have to do. If you
do have C float/double values to deal with, someone is going to have to
research the Motorola and Intel floating point formats. It might be as
simple as big-endian vs little-endian -- all that is needed is to
reorder the bytes for the float and double values. It might be more
complex than that. You may be able to use the IBM PowerPC architecture
as an approximation to M68K.

Signature
Jonathan Leffler #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2007.0914 -- http://dbi.perl.org/
publictimestamp.org/ptb/PTB-1885 whirlpool 2007-11-27 03:00:04
347DEF08371622A6F8B0C7BC800A79511AF2A0097C681B5123D87780228F271EC9E5D6
81EC2118AF0E5B756D99B9868114C47B2BD4C7ED06723AC93D6B137FC
vomaringo@yahoo.com - 27 Nov 2007 09:12 GMT
> vomari...@yahoo.com wrote:
> >>> On Nov 23, 3:33 am, vomari...@yahoo.com wrote:
[quoted text clipped - 85 lines]
> 347DEF08371622A6F8B0C7BC800A79511AF2A0097C681B5123D87780228F271EC9E5D6
> 81EC2118AF0E5B756D99B9868114C47B2BD4C7ED06723AC93D6B137FC
thanks for your informations.
you should be right with the end of record markers. someone send me
the files from a windows system.
regards,