Re: Problem about Informix and Xenix
On Tue, 18 Aug 1998, Lau Wai Kwong wrote: > Our system is programmed by Informix Version 1.1 being run on Altos > XENIX. However, the hardware of our Altos Machine was crashed > recently. I guess that makes it about 12 years old. Not bad! Was that ISQL v1.1 or I4GL v1.1 (which would have been equivalent to ISQL v2.1)? There is an important difference. And I'm assuming that you do not have a non-SQL Informix v1.1 (which would presumably be a pre-cursor of Informix 3.30, and would be still older). Do (did) you have xyz.dbs directories or xyx.dbd files defining the database xyz? If they are directories, then it's the SQL product; if they're files, then it's the pre-SQL product and what follows is not very relevant (but contact me again for more ideas about how to deal with your problem). > Could I / How can I migrate my applications on PC or other machine? Hmmm. Well, the obvious question is, do you have a copy of the database on (backup) media that you can read on another system. If not, you're stuck before we even try to get going, so we'll take the optimistic view. Your data might come in either of 2 formats; binary copies of the C-ISAM files or in an ASCII (unload) format. And you might or might not have a complete schema for your database. If the data is in the ASCII format, then life is pretty simple -- you create an SE database using your new software (probably version 5.10 SE and 4.20 ISQL; possibly 7.24 SE and 7.20 ISQL), and then you create the tables using the schema, and then you load them. It might be a bit fiddly if you don't have a pre-made script, but it is completely doable. If you don't have the database schema, life is trickier -- you probably don't have the system catalogue unloaded, so you'll have to reverse engineer the field types from the unloaded data. Messy, but doable. If the data is in the C-ISAM files that constitute the data, then you probably have a complete backup of the database, including the system catalogue. It now becomes rather important to know whether you were using ISQL v1.10 or I4GL v1.10. When ISQL 1.10 was upgraded to ISQL v2.00 and I4GL v1.00, there was a change in the disk representation of the DECIMAL type. Amongst other changes, ISQL v1.10 had no nulls but ISQL v2.00 and I4GL v1.00 added nulls. I don't know what the details of the decimal format change were, nor what aspect of the representation needed to be changed, but there was a special conversion program, decconv, to handle it. This is no longer available. Consequently, if your database was ISQL v1.10 and contained any DECIMAL columns, we could have problems. At the very least, you are going to have to scrutinize any DECIMAL data and validate it. Let's duck the decimal issue and deal with the general process. You should be able to restore the database onto your new machine. Make at least one copy of it. You can then try running the new SE against the old database. It will probably be able to select the data, at least -- I wouldn't try doing updates. I would then immediately run DBEXPORT on it and then create a new database with DBIMPORT. Given that Xenix ran on x86 processors and that you are using a newer x86 architecture machine, you don't have to worry about data formats for FLOAT and SMALLFLOAT changing behind the scenes. If SE can't select the data, then you may be reduced to analysis of the various .dat files. You can determine the schema from an analyis of systables, syscolumns and sysindexes files, and given the schema, it is possible to parse the .dat files with appropriate tools and create unload format files from the files. This would be painful, but doable with a little bit of C-ISAM and/or ESQL/C expertise. Yours, Jonathan Leffler (jleffler@informix.com) #include <witticism.h> Guardian of DBD::Informix v0.60 -- http://www.perl.com/CPAN Informix IDN for D4GL & Linux -- http://www.informix.com/idn