Port SE2.1 -> SE7.23 Questions

Hallo! We have to port a very old application running under SE 2.1 NSC-procesor to an intel P3 SE7.23 version. Because there are esc-sequences (and other bineries) stored in char-fields we can not use the unload from 2.1, there is also no -X option available. Who can give us a few tips? Thank a lot!

Peter wrote: > We have to port a very old application running under > SE 2.1 NSC-procesor to an intel P3 SE7.23 version. > Because there are esc-sequences (and other bineries) stored > in char-fields we can not use the unload from 2.1, there is also > no -X option available. > Who can give us a few tips? Thank a lot! Don't do it? A bit late for that, though. Are there FLOAT or SMALLFLOAT fields in the data? If not, you can probably simply copy the date files from the old machine to the new. You might need to do some juggling with bcheck or secheck to sort things out, and you might find yourself having to create empty tables on the Pentium and then copying the data files over the corresponding empty data files, and then running bcheck. If you have FLOAT or SMALLFLOAT data, then life gets harder, unless the NSC processor happens to use the same binary format for floating point data as an Intel does. If NSC and Intel floats are compatible, you can copy the raw data as before. Assuming that won't work, you start having to get tricky. You can still move the data files and fettle them with bcheck. But you need to unload the primary key fields (you do have primary keys, don't you, even though you couldn't explicitly declare them), plus the FLOAT and SMALLFLOAT fields. You can then write some code on the Pentium which selectively updates the data from the load file -- or you could think about using SQLUPLOAD which comes with SQLCMD (available in the IIUG archives) which is intended to be able to handle such partial updates. Be aware: SQLUPLOAD is still in alpha stage of development. It is probably going to be tricky to get right, but it might actually do the job you need. Of course, if your primary keys all contain binary data, then we still have an unload problem. Your best bet might be to add a SERIAL column to the tables in the database. Of course, that isn't trivial; you have to do something like: ALTER TABLE tabname ADD (serial_col INTEGER); UPDATE tabname SET serial_col = ROWID; ALTER TABLE tabname MODIFY (serial_col SERIAL NOT NULL); Then you can unload using the serial_col as your primary key. I haven't verified that the above sequence works. You certainly can't do it in one shot, and you have to find a way of generating a unique integer for each column in the table (which is what the ROWID should do). You will be getting rid of the binary data, won't you? -- Jonathan Leffler (jleffler@informix.com, jleffler@earthlink.net) Guardian of DBD::Informix v0.60 -- see http://www.perl.com/CPAN #include <disclaimer.h>