Re: sqlexec 2.10

On Nov 24, 3:24 am, Jonathan Leffler <jleff...@earthlink.net> wrote: > Art S. Kagel wrote: > > 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 > >> 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. > > > Those files are from the Informix SE engine not IDS. Dbaccess cannot > > 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 1 is correct. > > 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, IIRC, and probably was not > available with 2.10.00. That is a hazy recollection (we are talking > about 1987 vintage code, though). Hmmm, some documentation I wrote back > in Feb 1990 shows some output from DB-Schema 2.10.03F and that includes > the copyright date 1988. The earliest version of the code that is > documented is a year earlier - Feb 1989. So, depending on which 2.10 > version the OP (Vomaringo) actually has, there may or may not be a > DB-Access to use. > > 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? > > -- > Jonathan Leffler #include <disclaimer.h> > Email: jleff...@earthlink.net, jleff...@us.ibm.com > Guardian of DBD::Informix v2007.0914 --http://dbi.perl.org/ > > publictimestamp.org/ptb/PTB-1860 tiger160 2007-11-24 00:00:06 > 85AE2B8A910813198E727ABA815C05D5985492E3 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. 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. thanks jack

vomaringo@yahoo.com wrote: > On Nov 24, 3:24 am, Jonathan Leffler <jleff...@earthlink.net> wrote: >> Art S. Kagel wrote: >>> 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 >>>> 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. >>> Those files are from the Informix SE engine not IDS. Dbaccess cannot >>> 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 1 is correct. >> >> 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: 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

On Nov 27, 6:54 am, Jonathan Leffler <jleff...@earthlink.net> wrote: > vomari...@yahoo.com wrote: > > On Nov 24, 3:24 am, Jonathan Leffler <jleff...@earthlink.net> wrote: > >> Art S. Kagel wrote: > >>> 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 > >>>> 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. > >>> Those files are from the Informix SE engine not IDS. Dbaccess cannot > >>> 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 1 is correct. > > >> 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...@earthlink.net, jleff...@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 thanks for your informations. you should be right with the end of record markers. someone send me the files from a windows system. regards,