How to convert an informix database?
George Poulson
the informix system I am looking for a bit of advice.. and this seems
like a good place to ask!
I have just been asked "what would be involved in extracting data from
an informix database and in what format(s) can it be extracted".
The client has had a major "difference of opinion" with the supplier /
maintainer of their system and now wishes to move their data over to
another system. Obviously being able to read and/or translate the data
is a fundamental requirement.
The data is currently held on an "Altos" machine running AIX; if possible
they would like to convert the data to an MS Access or dBase format.
Any advice or pointers to other sources of information would be much
appreciated.
Many Thanks!
--
George Poulson GP Designs Limited 01782 815231
geo...@gpdesign.demon.co.uk Computer systems & software
Electronics design & development
email: gpde...@gpdesign.demon.co.uk
Paul McGuire
>Apologies if this seems like a stupid question, but knowing little about
>the informix system I am looking for a bit of advice.. and this seems
>like a good place to ask!
It is the best place to ask!
>I have just been asked "what would be involved in extracting data from
>an informix database and in what format(s) can it be extracted".
The answer varies a little depending on which version and which
particular database (Online or Standard Engine) the client is using.
Generally Informix provides two ways of exporting data.
One is called 'unload' which is an SQL command which outputs data
from an SQL statement to a ascii file which separates columns with a
pipe ( | ) symbol. This command does not give you the database
structure, but this can be obtained as a series of SQL commands in an
ascii file using a command called 'dbschema'.
The second is a utility called 'dbexport' this produces a series of
ascii files containing all the data from the database and a script
file with the data structure.
If the client has ACE reports (part of the Informix SQL development
package for versions below 5.0 ) you could write custom reports to
create 'ascii' files in almost any format, but you would have to write
a report for every table in the database.
>The client has had a major "difference of opinion" with the supplier /
>maintainer of their system and now wishes to move their data over to
>another system. Obviously being able to read and/or translate the data
>is a fundamental requirement.
>The data is currently held on an "Altos" machine running AIX; if possible
>they would like to convert the data to an MS Access or dBase format.
Isn't dBase a step backward?
Basically you can get the data out of Informix no problem, but you
will need to do some file conversion regardless. This could
potentially be automated with some UNIX shell scripts. (For example
to change the file format from Informix unload format to CSV's)
Regards
Paul McGuire
Stan & Jennifer Markham
>One is called 'unload' which is an SQL command which outputs data
>from an SQL statement to a ascii file which separates columns with a
>pipe ( | ) symbol. This command does not give you the database
>structure, but this can be obtained as a series of SQL commands in an
>ascii file using a command called 'dbschema'.
>The second is a utility called 'dbexport' this produces a series of
>ascii files containing all the data from the database and a script
>file with the data structure.
>If the client has ACE reports (part of the Informix SQL development
>package for versions below 5.0 ) you could write custom reports to
>create 'ascii' files in almost any format, but you would have to write
>a report for every table in the database.
>>The client has had a major "difference of opinion" with the supplier /
>>maintainer of their system and now wishes to move their data over to
>>another system. Obviously being able to read and/or translate the data
>>is a fundamental requirement.
>>The data is currently held on an "Altos" machine running AIX; if possible
>>they would like to convert the data to an MS Access or dBase format.
>Isn't dBase a step backward?
>Basically you can get the data out of Informix no problem, but you
>will need to do some file conversion regardless. This could
>potentially be automated with some UNIX shell scripts. (For example
>to change the file format from Informix unload format to CSV's)
Any step away from Altos is a step forward! Somewhat more seriously,
it seems that I wind up converting data several times a week, if not
most of my waking moments. The conversion to CSV isn't always necessary
as many xbase programs permit you to designate the FS as any value and
you can set the FS in Informix to a comma before unloading, if CSVs are
absolutely required.
I usually use sed or awk to finish the transition. (unzip -a does the
cr/lf translations). All in all, not difficult and, if after
considering the ramifications, the client wants it - the client gets
it :-).
Jack Parker
> Any step away from Altos is a step forward!
In the years that I sold, serviced and used Altos HW I found them be
a) VERY reliable, b) inexpensive, c) fast enough d) ahead of their time
in terms of design. In 1983 a company I worked for was supporting 5 users on
an Altos box running Oasis - the cost of that box? Under $10k. I've never
heard of anyone putting AIX on one of them - of course back then (despite
their claim that Kernighan and Ritchie found Unix on a tape they had
thrown into their dumpster) IBM had still not entered the world of
'true' operating systems. I think the biggest problem Altos had (has?) was
/(is?) that all kinds of folks who weren't really qualified could sell Altos.
As a result they got a bad rep a lot because their 'dealers' didn't know
much about what to do after the sale.
cheers
j.
_____________________________________________________________________________
Jack Parker - Hewlett Packard, DMD/IS Boise, Idaho, USA
jpa...@hpbs3645.boi.hp.com
Currently on assignment in Sunny Penang.
_____________________________________________________________________________
If anything can go wrong, fix it. To hell with Murphy.
_____________________________________________________________________________
Any opinions expressed herein are my own and not those of my employers.
_____________________________________________________________________________