Hey Jim,

>I like the way you're treating data as an object. That is exactly what we do with our DataClas/VFP product (www.redmatrix.com). You'd be surprised how many people still haven't seen the light in regards to that.

You know what they say... great minds think alike. Plus I did take the full two weeks of Visual FoxPro 5.0 training in North Carolina from a great instructor back in 1997. <vbg>

Seriously, it's the only way to build applications to run against different data sources as far as I am concerned. Trying to do it any other way would lead to clucky code (IF ELSE DO CASE statements everywhere) and certainly unreliable, unstable applications.

>The primary difference between our two approaches is that we're SQL Server exclusive right now. Therefore we can adopt the "best practice" of coding all data access and manipulations (SELECT, INSERT, UPDATE, DELETE) inside of pre-compiled and optimized stored procs on the server instead of using SQL Passthrough.

A beautiful thing about using abstract business and data classes is you can mix and match direct SQL Passthrough and calling stored procedures as required by the application. For example, I developed a labor tracking application that updates 5 tables when adding certain labor reason code transactions. Initially the logic code was in the business object's UpdateRecord method. The method consisted of calls to several protected methods and the five data objects wrapped in a transaction. At a later date I wrote the logic as an Oracle stored procedure. The interface layer code didn't change at all:

loBusiness.UpdateRecord()

The UpdateRecord method now calls an Oracle Stored procedure that does all the work. The performance did not improve much if at all (maybe noticeable run in a batch process) but it did allow us to add transactions using ADO and ASP technology. The downside of moving the business logic to the Oracle stored procedure is the application now will not run against SQL Server. Of course, that wasn't a problem because it wasn't a client requirement.

My point is well defined layers are flexible and once understood, very powerful. If you can't or don’t have the time to build them consider buying them.

>For the lurkers reading this, I'll be covering how to actually code all of this in the SQL Server Development for VFP Developers pre-con at DevCon this Sunday.

I'll add to that... if you haven't had the pleasure of attending one of Jim's classes or lectures go the his pre-con. He’s has exceptional talent for explaining and demonstrating technology in a very entertaining way.