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

Reply via email to