Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!uakari.primate.wisc.edu!ginosko!brutus.cs.uiuc.edu!apple!voder!pyramid!infmx!aland
From: aland@infmx.UUCP (Dr. Scump)
Newsgroups: comp.databases
Subject: Re: Duplicating Informix SQL Database
Summary: "there you go again!"
Keywords: Informix SQL SCO Xenix ranting raving
Message-ID: <2411@infmx.UUCP>
Date: 26 Sep 89 02:32:34 GMT
References:  <574@pan.UUCP>
Reply-To: aland@infmx.UUCP (alan denney)
Organization: INFORMIX Professional Services ("Peace thru Normalization")
Lines: 97

In article <574@pan.UUCP> jw@pan.UUCP (Jamie Watson) writes:
|In article  emuleomo@yes.rutgers.edu (Emuleomo) writes:
|>...
|>I tried copying the contents of the ".dbs" directory to another directory
|>and the changing DBPATH so that I pick up the copy.  That seemed to work
|>fine, until I DROPPED the copy, and LO and BEHOLD, it dropped some tables
|>in the original database!. However, the entire 'copy' database was dropped
|>as expected!
|
|This particular crock is caused by the way Informix stores the filename
|for the table in the systables catalog.  In some cases it stores a simple
|filename, while in others it stores an absolute pathname.  In the latter
|case, when you duplicate the database by copying it, the pathname in the
|systables catalog still points at the original file, so everything you
|do still operates on that file, instead of the copy.  This is particularly
|confusing because you will often have some relative and some absolute
|pathnames in the same database, so it appears that copying sometimes works
|and sometimes doesn't.
|
|Yet another piece of trash from Informix...
|jw

Oh, jeez, not this guy again, please!

(Apologies to those who missed the Jamie Watson/Informix flame war
 of several months ago and don't understand my comments here.)

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 posted earlier, there are normally no explicit pathnames in the 
catalog entries to cause a problem.  Exceptions are:

   1) Programmer-chosen externally located tables, as created via 
      CREATE TABLE ... IN  "pathname"
   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)
   3) Standard engine databases created with logging; the log file
      pathname is placed in the SYSLOG entry in systables

The only recommended/supported way to move or copy a database is
using the provided schema generation and table unload/load utilities.
There are no known problems with this method.  Use DBSCHEMA to
generate the needed DDL statements to recreate the database and the
load/unload utilities to move the data.

However...

If the user wants to, and exercises due caution, the files can be
merely copied/moved WITHIN CERTAIN LIMITS.  (listed below)

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

   1) If a table has been created externally by choice, you will need
      to adjust the catalog entry IMMEDIATELY, BEFORE using the table
      in the new database.  For example, if the original "orders" database 
      is located in /db/orders.dbs, a "history" table in the old database
      is in "/usr/bigtables/history"(.dat and .idx), the new database is
      called "/usr/neworders.dbs", and you have copied those
      "bigtables/history" files to "/usr2/bigtab/newhist"(.dat and .idx),
      the first thing to do in the new database is to fix the catalog:
            UPDATE systables SET dirpath = "/usr2/bigtab/newhist"
                   WHERE tabname = "history"

   2) if a *redundant* pathname is present, the "dirpath" column for the
      affected table can be updated by the DBA to omit the path via SQL.
      Example:   if the dirpath is "/db/orders.dbs/prod_103" and the
                 table ID is 103, you can fix it as follows:
            UPDATE systables SET dirpath = "prod_103" WHERE tabid = 103

   3) If logging is in force, logging should be turned off before 
      attempting to migrate using the following SQL statement (for
      current product versions):
            DELETE FROM systables WHERE tabname = "syslog"

      Then, recreate the log for the new database where you want it 
      using the START DATABASE statement, e.g.:
            START DATABASE orders WITH LOG IN "/usr/neworders.log"

My own opinions, etc.   Flame war transcripts available upon request :-].

--
    Alan S. Denney  @  Informix Software, Inc.    
         {pyramid|uunet}!infmx!aland                 "I want to live!
   --------------------------------------------       as an honest man,
    Disclaimer:  These opinions are mine alone.       to get all I deserve
    If I am caught or killed, the secretary           and to give all I can."
    will disavow any knowledge of my actions.             - S. Vega