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