ngolem: A SP can write to a dataset and still return a result set within CR, perhaps not with all databases, but it can with Oracle and SQL Server.
The SP could read the counter table, then update it, then return the dataset to Crystal, which would then construct a dataset. To write to the SAME table name as the last time, it must no longer exist (which means an external process, like within the SP or some other code).
Your theory works, but it's less efficient than letting the database do it all, and since the end result is a table, CR is probably just a layer of inefficiency and potential problems. With just an SP, you can have it handle the counter and export to the other database. Consider all of the posts you've read where the final solution was to use an SP to show the data. In this case, there's nothing to show, just populate another database, so why use CR?
Database programming is great fun and expansive, you can D/L both SQL Server and Oracle personal editions if you've ever a hankering to explore SP's more. Properly designed SP's are the fastest way to manipulate data from Crystal (and other tools), and the most flexible, there's no maybe yes or no to it. Plus, rather than a consultant billing themselves as a Crystal Reports consultant/instructor, they can add databa$e programmer...
Chelseatech: Intriguing UFL's... So the idea is to use a text file as the *counter* repository? Perhaps not the best solution to the problem at hand, but workable, and I can see that functionality being VERY useful elsewhere.
I'm interested in your UFL's, please send along info.
-k
kai@informeddatadecisions.com