>If by fast, you mean the speed of the query, then it doesn't matter. Several years ago I did speed tests to SQL Server comparing RV, SPT, and CA. The speed difference for almost everything was negligible between the three options. The only real difference was inserting lots of records, where SPT easily won. However, if that's what you're doing, Bulk Insert will be faster.

I sort of expected this, thanks for confirming my hunch.

>As for ease of implementation, I don't find SPT any more or less easy than CA and RV is easier than either of them.

RVs are easy to do the first time. Maintenance, however, is close to a nightmare. First off, to even try to implement them, you need a DSN, which is relative to the machine on which they were made. On any other machine, you need to recreate the connection - can't use sqlstringconnect() to edit the views, only to open them.

Second, they are in a dbc, where each field in each view takes up one record, with properties set in binary format - IOW you can't write your own tools, unless you want to mess with the binaries (and we had what, two or three guys total on UT who wrote editors). Then this dbc needs to be distributed (ok, can include in the exe, therefore it bloats if you don't watch). And, on top of it, it doesn't allow for flexible where clauses (that I know of). IIRC, you can select from a view, but only after the view is already requeried, with all the records you don't need.

Sure, you can use views for data entry and SPT for everything else, but my bet is that you run into a situation where you need something that's almost the same as what you have in a view, but needs an extra field or a different parameter - and needs to be updatable. Do you make yet another remote view, or roll your own SPT, or...? With an adapter, it's a few lines of code (provided you have something that would fill the key, table, update list properties for you - but you write that once and you're done - and you'd have to do that for SPT anyway, in a different form).

I agree with what Rick Strahl said when CA came up - "nice, but if you already have a solution, you don't need CAs". It just came to "I did have a solution and didn't like it - so a new one was built". And that's exactly what Rick said next: "if you're building data handling from scratch, CA is the right thing to use".