Hi Oliver, Oliver Pick [mailto:[EMAIL PROTECTED] wrote: > > I've got a problem loading some data into a table using the > loadercli.exe on a W2K-machine. >
[snipped table def with prim key] > > To load data into this table, I created a loader-file which > is defined as: > FASTLOAD TABLE TEST > A 1 > B 2 > C 3 > D 4 > E 5 DEFAULT NULL > F 6 DEFAULT NULL > G 7 > H 8 > INFILE 'c:\in.data' COMPRESSED > DELIMITER '' > SEPARATOR '|' > NULL '' > > A typical data-line from the infile is: > xxxx|yyy|zzz|1|||tt|1 > which means, that columns E and F are null in most cases. > > When I try to load this file I get every time the following error: > Error during execution > -->-25303 > Input value does not match key order or range specification. > Did you have a look into loader.prt? The message given here is surely only the output of loadercli, right? Ok, the protocol file should actually point to the record that failed to load. > When I first tried a loader-file without defining "Default null" I got > Error during execution > -->-25319 > Missing data for specified column F. > > That's why I started to use "Default null" options. > > Has anybody a clue, how to configure the loader-file for the > given data? > Well, yes ;-) I can't see anything wrong in the stmt you sent. The error message above points to some problems in your data not in the syntax/semantics of the statement. > Once a simple loader test was successfull, but after the > load, the table was > set to "read only". I read somewhere that a database-backup > will solve this > issue and set the table status back. But is this the only way > to reset the > "read only"-flag for a table after a load?` > Read only is set ONLY if the table was loaded using the TABLELOAD ... PAGES command (you either run a TABLELOAD directly or a DBLOAD that itself issues a TABLELOAD). All other command do not set the processed table into the read-only state. You can reset the read-only state of all tables at once using the utility statement SET NOLOG OFF. But, especially in a productive db you should handle this situation with care because the TABLELOAD...PAGES loads data bypassing the log. So if your db crashes after a successful TABLELOAD...PAGES but before you made a backup you're in trouble. HTH. Regards, Steffen -- Steffen Schildberg SAP DB Team SAP Labs Berlin _______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general
