Re: Question regarding moving a database

In article <32DC333D.1984@igs.net>, John & Cassy Montgomery <montgomery@igs.net> writes We had this problem with one table and although dbexport couldn't unload the data, the sql unload option could. So we dbexport the whole database and then from the same script follow the dbexport with a single sql unload for the problem table, e.g.: #!/bin/ksh #... set INFORMIX environment variables as appropiate cd /EXPORTS dbexport mydbname -ss 1>exp.log 2>&1 cd mydbname.exp dbaccess mydbname <<EOF unload to "mytab.unl" select * from mytab;EOF exit >Informix-List wrote: >> >> A software package I support uses Informix Online as it DBMS engine. >We >> >> often need to bring back customer databases to the lab to recreate and >> >> debug problems. >> >> >> Our software as it is currently written prohibits the use of dbexport >> >> and import as a way to move the database because certain type of data >> >> are lost. We have been using ontape . . . >> >> >> I was wondering if there is another way to do this? >> >> I have to guess that the "certain type of data" that "are lost" are the >> rowids, since just about everything else of value is saved by dbexport. >> >> If this guess is correct, you have just illustrated why there is the >> rule that you should NEVER join (link) tables by the rowid. > >I said I was an Informix Neophyte - not an Informix Neanderthal! :) > >Anyway, this is not my problem. The original software design embedded >some >"binary" data in some text fields. The problem is of course that >dbexport>sees the ASCII null character as the end of string character and stops >exporting data at that point. > >The design is now changed but I need to support alot of customers with >the >existing design. I am looking for alternatives to using the ontape >utility >and was wondering how onunload differs from ontape? > -- Simon Barber