Re: Informix on DOS (was: R: BASE 3.1A)

Path: emory!att!linac!pacific.mps.ohio-state.edu!zaphod.mps.ohio-state.edu!wupost!uunet!lll-winken!cert!netnews.upenn.edu!catone From: catone@wharton.upenn.edu (Tony Catone) Newsgroups: comp.databases Message-ID: <CATONE.91Aug11085601@dmark.wharton.upenn.edu> Date: 11 Aug 91 12:56:01 GMT References: <46341@netnews.upenn.edu> <1991Aug5.081359.27386@informix.com> <CATONE.91Aug8180714@dmark.wharton.upenn.edu> <1991Aug10.063424.26276@informix.com> Sender: news@netnews.upenn.edu Organization: University of Pennsylvania Nntp-Posting-Host: dmark.wharton.upenn.edu In-reply-to: aland@informix.com's message of 10 Aug 91 06:34:24 GMT In article <1991Aug10.063424.26276@informix.com> aland@informix.com (Colonel Panic) writes: > ... > The "so easy to blow away tables" part is utter bullshit, and I defy to > to provide a specific example. > >Fine. Copy tables from one directory to another. See what happens when >you drop a table that is hard linked. Note that hard links are put in >by many of the Informix utilities. Since you posted on this problem over >a year ago, your statement that you have never haeard of problems >is a falsehood. You, sir, are either a liar or very sloppy. Oh, please. If I understand correctly, you are saying that you moved underlying data files around without keeping the catalogs in sync, and you refer to that as "blowing away tables". Uh, right. You don't understand correcty (there's a surprise). So I give you the relevant quote from your original article, dated 26 Sep 89: In article <574@pan.UUCP> jw@pan.UUCP (Jamie Watson) writes: |In article <Sep.22.11.17.54.1989.4802@yes.rutgers.edu> 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! 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. Remember the BUG now? In the past week, you've posted major (and extremely vague) flames about both Informix and Ingres, while your postings about KMan tend to sound like quoted ads (and almost never follow a question about KMan). I still think it warrants raising the question. I question your premise, which seems to be: all critical comments are "flames" and anyone who likes and uses a competing product has ulterior motives. Those "vague" comments of mine were obviously clear enough for everyone else, since no one so much as wrote me privately to ask clarification. And those questions I responded to were asking for recommendations on data base packages to use. Your package is not the best. Full stop. >.... I think I have a broad enough range of technical experience to make >sound evaluations of products. But not the objectivity, perhaps. On what do you base this indepth assessment? It's speciously reasoned remarks like this that make me think comp.databases.informix might not be such a bad idea after all. >Take your follow ups to mail or alt.flame. Sure, now that the facts are somewhat straight... Too right. - Tony catone@dmark.wharton.upenn.edu "Faith is wonderful, but doubt is what gets you an education."