My first guess would be a TCL DELETE command that was expecting a hightly restrictive select list active, but instead had the whole file. Or instead of TCL delete, it could be a basic program that did the same inside a readnext loop. Or what about an SQL DELETE? I think the defualt there clears a file, i.e., there is no WHERE clause. One way the TCL DELETE (or loop-readnext) scenario could happen would be if there were a 2-stage select, and the second did NOT use REQUIRE.SELECT (aka SELECT.ONLY ) keyword. A simple example: SELECT MASTERf WITH AGE > TWO.YEARS SAVING LINEITEM.IDS SELECT LINEITEM ( <---- you _n_e_e_d_ REQUIRE.SELECT here !!!! ) DELETE LINEITEM Suppose the 1st select comes up blank. Then the second will be a select list of all LINEITEM ids. Then the DELETE effectively clears the LINEITEM file. That's where I would look first. cds ________________________________
From: Patricia Wilson ... an incident last week were one of more heavily used files, the LINEITEM file, all of the sudden go to 0 bytes. Normally, this file has over 46K records. It wasn't a peak load time, and there haven't been any recent changes to any BP's. We had it happen again on another system, to the same file, LINEITEM. 2 Different boxes, 2 different files (same name) @ 2 different times.... [demime 1.01d removed an attachment of type application/ms-tnef which had a name of winmail.dat] ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
