Re: dbimport 9.40 hates tables without owner names?

Madison Pruet wrote: > Well --- I haven't been able to reproduce the problem. > > I guess the main question that I have is where did the dbexport x.sql > script come from? We should be generating the sql script with the > owner in both the schema definition and the table definition. The > only way that I can think of that you would be getting the duplicate > error is for a non-ansi database to have been created without the > table's owner name in one place and the owner in the other? > > When you get a case open on this let us know. > > By the way --- I noticed in your other emails that some of this > involved migration and/or [ANSI?] Yes - export from Pyramid 7.3ish, to Solaris 9 with 9.40.FC4. In brief: No matter where I go, I find random table owners. This place is no exception. If the opportunity arises for an export/import (ie upgrade or something) then I simply run a little scriptlet which removes the owner names from the .sql file in the .exp directory. The dbimport will then load all the tables and objects with an owner that is the userid of the account used to perform the dbimport. This practice has worked for me since the day when OTC was still only a MIME, knee-high to Marcel Marceu. In this instance, I'm doing a dbexport from a 7.3ish engine (running on a Pyramid, but since the export goes to ASCII it barely matters), then applying the usual cleanup of the .sql file and performing an import on a 9.40.FC4 engine into Solaris. At this point it barfed with the error message I mentioned. The source database is not ANSI. The target database is not ANSI. However I do not see anything in the dbexport which would MARK the export as being from an ANSI (oh, ok - unique table names would come from "owner".table) anyway, the source DB is not ANSI so there is no potentially conflicting table names. The dbimport is not performed using the -ansi flag so it it not going to ansi. The table it barfs on is the very first table. Putting a suitable "owner". into the { TABLE part of the .sql file was sufficient to allow the import to proceed. An opportunity to do another export/import is coming soon, so I'll try to build a firmer test case and see what other interesting variations has any effect. As far as I can see, it must be an error in dbimport; if you can't reproduce it then it must be subtle :-)