Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!uunet!mcsun!cernvax!pan!jw
From: jw@pan.UUCP (Jamie Watson)
Newsgroups: comp.databases
Subject: Re: Duplicating Informix SQL Database
Keywords: Informix SQL SCO Xenix ranting raving
Message-ID: <575@pan.UUCP>
Date: 28 Sep 89 18:38:25 GMT
References:  <574@pan.UUCP> <2411@infmx.UUCP>
Reply-To: jw@pan.UUCP (Jamie Watson)
Organization: Adasoft AG, Solothurn, Switzerland
Lines: 47

In article <2411@infmx.UUCP> aland@infmx.UUCP (alan denney) writes:
>EXEC FLAME
>  In other words, you want the product to force all files to be under 
>  the .dbs directory and not allow you to place tables in other
>  directories/file systems if you so choose.  The fact that the product
>  provides you with this capability makes it a "piece of trash."
>  Nice logic.
>END-EXEC.

As usual, you insist on avoiding the issue raised by the original
posting.  The fact that Informix provides this capability is useful,
but certainly not exceptional.  However, the original posting asked
why it was not possible to duplicate the database by copying the db
files; this is a perfectly reasonable thing to want to do, and there
is nothing that I have ever seen in the Informix documentation that
says this cannot or should not be done.  In fact, it should work in
the default situation, when the user has done nothing to explicitly
change the value of systables.dirpath, if it weren't for a serious
bug in some of the Informix utilities.

>As posted earlier, there are normally no explicit pathnames in the 
>catalog entries to cause a problem.  Exceptions are:
>
>   2) If a table was altered from a directory outside of that which
>      contains the database, explicit pathnames can result in the 
>      catalog (Bug 2250)

Here is the real point.  The user hasn't done anything to put explicit
pathnames in dirpath; *most* of the tables have relative paths there;
this makes it appear that copying the database worked; but sometime
later, because of the broken Informix utility programs, something bad
happens.  In the case of the original posting, a "drop table" command
wipes the wrong file.  Good work, Informix.

By the way, I have seen this bug in versions of Informix that are as
much as two years old - 2.10.00 - so Informix is doing their usual
bang-up job of fixing things real quickly...

>Advice:
>When UPDATING system catalogs, always do so within transactions
>and check the results before COMMITting.  If you have made an error,
>just ROLLBACK.

Advice:
Fix your stupid software, in time frames measured in less than years.

jw