|
You don't need to CLRPFM first - use MBROPT(*REPLACE) on the CPYF. I find CPYF faster than SQL methods, anyway. But I think I have also seen times that SQL will do the job when CPYF is blocked. Can't remember details. You might also consider STRQMQRY OUTPUT(*OUTFILE) OUTMBR (*FIRST *REPLACE). You can even replace the contents of a table in place this way - scary but effective. > I am looking for some words of wisdom here, we have a project that is > building a cross-reference table from several systems. Had I had some > insight into what exactly was being done, I might have prevented the table > from being put into DB2 however what is done is too hard to undo around > here. The problem is that on a periodic basis this table needs to be > replaced. In between, I am updating the table which seems ok. My problem is > that this table is just shy of 4 million rows and because of the way the > table was implemented (not a DB2 issue) I am not permitted to use DDL in the > job stream. My thought is to use CLRPFM to clear the table and reload it > using CPYF however something strange happened in testing the program (before > I decided to use CPYF) it took forever using Exec SQL Insert.... and I > eventually killed the job. > > Is there some reason that I should not use CLRPFM to clean out this table > for a reload? > > ____________________________________________ > Howard Weatherly
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.