Edward A. Feustel wrote: > I could separate the deposit/expense transactions for each separate > account, make records, do a case insensitive > multi-phase sort so that date order, check order, and payee order are > preserved, eliminate duplicates, and write each > record out as text items. Then I would need to go through and clean up.
How duplicate is "duplicate"? If the duplicated records are identical (through all fields) then could you read them in sequentially, keep an internal set() of the records you've read in, and only output a record (and add it to the set) if it hasn't been seen already? That way's there's no sorting or rearrangement of the records, and the problem reduces to (a) determining what a record is (with luck, there's one per line...) (b) testing for set membership. If they're not that duplicated, but may only have a few fields duplicated, then you could use a table() instead of a set and construct the key from those fields. Anyway, a thought. -- -- Steve Wampler [EMAIL PROTECTED] The gods that smiled upon your birth are laughing now. -- fortune cookie ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Unicon-group mailing list Unicon-group@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/unicon-group