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