Thanks to everyone who answered me.

I didn't mean to imply that I have doubts about avoiding cursors and loops. I do avoid them whenever possible because I respect the advice of the people who say it's good practice. I will certainly read the recommended articles.

But I'm still learning where to draw the line. Here's my current requirement, where I found that only a cursor provided the control I needed, given my skill set:

I have a CSV of invoice information coming in from a vendor, and it gets moved into a temporary table in the d/b for the following steps:.

1. I have to create and save to disk an RTF exception report which I create using the FSO.

2. I have to examine every field in every row and print the row number and field name of any data that's invalid or missing on the exception report.

3. If the file passes the validation phase, then I rewind the cursor and begin the update phase.

4. If the account has been put on hold or closed out, print a message on the exception report.

5. I write the invoice information to one table and four other values to two other tables.

6. The names and addresses on the invoices may have changed from the information we sent the vendor, so changes must be identified and updated to the tables, and printed on the exception report.

7. In one case, a decision on what to update is based on inspection of multiple interrelated fields. For all of these 'evaluated' updates, I have to print an explanatory message to the exception report.

Doing all of that within one SQL statement or a With block is beyond me, so I used a cursor. But like I said, I'm always willing to learn.

Thanks again,