Just a note: I'm not sure if you are a COM+/Just-In-Time-Activation fan (I know that many are not) but the set/get approach won't work with components making use of JITA.

Like you, I can't stand "percolating ADO recordset up the chain" (great phrase, btw). As a result, I make pretty extensive use of the ado recordset's GetString method, which generates the data as a delimited string. This makes it easier to pass the data around (including by value), and will work for multi-record sets. (Unfortunately, you also need to tag on field names and types, which GetString doesn't do -- I throw 'em onto the end as a "last row.")

Once you've bubbled the string up the point where you want to use it, you can rebuild a recordset and populate it with the data, or even just throw it into an array to access it. (In fact, you could also use GetRows() to start out with an array -- I don't do that because I prefer to pass by value since I tend to work in multi-server environments).

It's not pretty, but if you've encapsulated the messiness of the rebuild in an inherited method, it ain't so bad. GetString itself is really quick, which is nice when you are passing 20 or 30 rows of data.



>>>
>>>Not if the data object constructs the properties on demand, and the interface provide a set/get. Then you get an object-object independent of any data standard.
>>
>>Yes, I agree. However, if you're returning large amounts of data, it could get messy.
>
>Well, not really. How the data object maintains data sets is up to it. So, it might well keep an ado recordset. I just find percolating ADO recordsets up the chain to be awkward. That's purely personal preference, though, and as I think I mentioned elsewhere, one needs to know just what sort of ship one is building.
>
>I'm not a fan of building every app for every scalability. The overhead exceeds practical project limits for enough apps that I think one can go overboard.