Re: sqlexec 2.10
- From: vomaringo@xxxxxxxxx
- Date: Tue, 27 Nov 2007 01:12:29 -0800 (PST)
On Nov 27, 6:54 am, Jonathan Leffler <jleff...@xxxxxxxxxxxxx> wrote:
vomari...@xxxxxxxxx wrote:
On Nov 24, 3:24 am, Jonathan Leffler <jleff...@xxxxxxxxxxxxx> wrote:
Art S. Kagel wrote:
On Nov 23, 3:33 am, vomari...@xxxxxxxxx wrote:Sentence 1 is correct.
i'm trying to convert old dat/idx files made with sqlexec 2.10 (18Those files are from the Informix SE engine not IDS. Dbaccess cannot
years old!). it seems that quering with dbaccess 7.25
doesn't work. Does it exists a way to convert it or do i need to
install a previous version ?
thanks for your help.
access that engine unless you have a network product running (iNet).
You can probably export the data using the dbexport module included in
your 2.10 software and then import it into a more recent Informix DB
engine (SE 7.2, Online 5.20, or IDS 11.10).
Sentence 2 is not - you could use the DB-Access distributed with SE 5.x
or 7.x to access the SE database via the corresponding (newer) sqlexec
(though DB-Access itself never directly accesses any database, of
course). Moreover, the conversion from 2.10 to 5.x would pretty much
occur automatically; I'm 95% sure it would work with 7.x as well, but it
is a decade and more since I had a copy of 2.10 to play with, so I can't
be absolutely certain.
DB-Export arrived on the scene with 2.10.03x, [...]
Since Vomaringo mentions DB-Access 7.25, it should mean he or she has SE
7.25 on hand; there never was an IDS 7.25.
Vomaringo,
Was the data produced on the same machine as where you are running SE
7.25? Or was the old machine a PC (Intel x86) machine and is the new
machine also x86? If so, you are far from irrecoverable - as long as
you've been messing with a copy of the database and not the only copy of
the data. When you say "querying with DB-Access doesn't work", what
error message do you get? What have you got set in the environment?
Which directory is your current directory; which directory contains the
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.
--
Jonathan Leffler #include <disclaimer.h>
Email: jleff...@xxxxxxxxxxxxx, jleff...@xxxxxxxxxx
Guardian of DBD::Informix v2007.0914 --http://dbi.perl.org/
publictimestamp.org/ptb/PTB-1885 whirlpool 2007-11-27 03:00:04
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,
.
- References:
- sqlexec 2.10
- From: vomaringo
- Re: sqlexec 2.10
- From: Art S. Kagel
- Re: sqlexec 2.10
- From: Jonathan Leffler
- Re: sqlexec 2.10
- From: vomaringo
- Re: sqlexec 2.10
- From: Jonathan Leffler
- sqlexec 2.10
- Prev by Date: Re: sqlexec 2.10
- Next by Date: informix.com
- Previous by thread: Re: sqlexec 2.10
- Next by thread: IDS 11 archecker ignores AC_RESTORE_FILTER
- Index(es):
Relevant Pages
|
|
