Hi Georg, Georg Schoepe [mailto:[EMAIL PROTECTED] wrote: > > I executed the following loadercli-command with the //-separator: > [...] > User TEST connected to database GS on local host. > CATALOGEXTRACT > TABLE TEST.books2 > OUTSTREAM FILE 'c:\programme\sapdb\export\books2_cat.data' PAGES > Successfully executed > > TABLEEXTRACT > TABLE TEST.books2 > DATA OUTSTREAM FILE 'c:\programme\sapdb\export\books2.data' PAGES > Successfully executed > > As a result I get the following books2_cat.data-file > > SQLMODE INTERNAL > // > CREATE TABLE "BOOKS2" > ( > "ID" Integer, > "TITLE" Varchar (100) ASCII, > "AUTHOR" Varchar (100) ASCII, > "YEAR" Varchar (25) ASCII > ) > // > CREATE TABLE "TEMP_BOOKS" > ( > "ID" Integer, > "TITLE" Varchar (100) ASCII, > "AUTHOR" Varchar (100) ASCII, > "YEAR" Varchar (25) ASCII > ) > // > > As you see, there are 2!!! create table-statements in it - > and I don't know, > where the second statement comes from. > I made an catalogexport for temp_books before, but as you can > see in the > cmdline-messages, there is no catalogextract-statement for > table temp_books in the last command. > > It's no problem for me to delete the second create > table-statement from > books2_cat.data - than everthing works fine- but it's an interesting > feature. > Well, you see, we do even more than you would expect ;-))
Ok, getting serious: It's of course not a feature. The loader works in case of CATALOGEXTRACT and TABLEEXTRACT with a system table called TRANSFORMATIONMODEL. The Loader logs here names of tables that need to be processed, and should delete those that have been successfully processed. It might be that we have here still a problem in that way that the cleaning of the entries after successfully running a command like TABLEEXTRACT/ CATALOGEXTRACT is not properly done. Then, an entry that 'survived' is used for CATALOGEXTRACTing again (even if another table is processed). If this happens again you could simply delete all entries in TRANSFORMATIONMODEL. But we'll correct it asap. Sorry for any inconvenience. Regards, Steffen -- Steffen Schildberg SAP DB Team SAP Labs Berlin _______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general
