Re: dbexport/dbimport problems

If I am not mistaken, the default location for a table is the same dbspace as the database was created it, this is not always the root dbspace. ---- original message from Joe Matuscak ---- ++ ++ On Tue, 24 Jan 1995 serge@perch.inwest.donetsk.ua wrote: ++ ++ > ++ > On Mon, 23 Jan 1995, Joe Matuscak <matuscak@rohrer.com> wrote: ++ > > Message-ID: <3g0ng9$9i7@cssun.mathcs.emory.edu> ++ > [...skipped...] ++ > > Did you use the SQL that dbexport generated directly without editing it? ++ > > Dbexport/dbimport looses all manner of useful information. Including, for ++ > > example, extent sizes, table locations in specific dbspaces and lock mode. ++ > > If you do nothing, the tables all get created in the root dbspace, with ++ > ^^^^^^^^^^^^^^^^^^^ ++ > Sorry, Joe, BUT you can specify dbspace as argument in dbimport comand ++ > line ;) ++ ++ True enough. However, that loads *all* of the tables for that database ++ into the single specified dbspace. In many cases, to optimize performance, ++ you may want to explicitly seperate tables on different devices. For ++ example, if you have master/detail tables you might want to have the ++ master table in one dbspace and the detail table in another. ++ -- Jerry M. Denman -- Director of Special Projects Sherwood Systems (a division of Sherwood Mfg Co. Inc.) jerry@sherwood.com ------------------------------------------------------------------------------ The manner in which one endures what must be endured is more important than the thing that must be endured. - DEAN ACHESON