Christof,

>> Other than the Stored Proc that tells how to retrieve data.
>
>Which can be quite difficult. Not all ODBC drivers support returning a result set from a stored procedure. Oracle doesn't with their ODBC drivers.

What about OleDb? I haven't used ODBC in a very long time (never with .NET; it would go back to my VFP days).

you make must be the same for all backends. If you originally write the code for MS SQL server as a single stored procedure call, it must be a single procedure call for other databases, as well. You cannot make one call, process the result on the client side and make another call to the database.

True. You win that point. <g>

For instance, updating a record or inserting one if it doesn't exist. Many databases have a command for that, "INSERT OR REPLACE", "UPSERT", "MERGE". Not so MS SQL where you need a sequence of INSERT followed by UPDATE.

Well, I'm not sure what you mean in the case of MS SQL. I send data (one row of data at a time), to what I call a PUT Stored Proc and depending on the value of the PK parameter that gets passed, the SP knows to do an INSERT (if the PK is < = 0) or an UPDATE for any other PK value. OK, I make an assumption there that an invalid PK won't get passed. So, I'm not sure what you mean by a sequence of INSERT followed by UPDATE.

>Sometimes you need a mixture of client side processing and server side processing (printing thousands of balances as of now and updating them). You can't run one statement against the database for each balance, because that won't meet the condition of "as of now". At the same time getting all balances, then printing them all, then updating them all, is often not the most efficient way to deal with this for a particular back end and might keep records locked for too long.

Could be a valid point ... I haven't had to do that type of processing, so I don't have any real world experience with that scenario ... so, I'd have to give more thought about how I would handle it.

~~Bonnie