Hi Charlie...

Stored Procedures good.... creating SQL on the client...bad

Glad to see things are working well for you....

>Your right, VIEWS are tired! I was committed to using VIEWS until I started thinking about replacing them with stored procedures. Right now I'm about half way my first application that is completely driven by stored procedures (all updates, inserts and deletes and anything else I might think of). I have also developed cursor classes which contain all the functionality they need to handle the management and parameter passing. The cool thing is most of their functionality is ending up in the base cursor class making them very reuseable. There is hardly any code in the forms at all! I'm sold on this concept. To me, once your base data management classes are developed, application development becomes easier doing it this way because you have more logical seperation between client and server. Bottom line, 'it works like a champ!'
>

I think this is a mistake. Your insert stored procs could store @@Identity to an output variable. Then you get the new key. No need to round trip to the server...

>As for identity keys, I don't use them. What I do is call a stored procedure at the beginning of the application to get the next key. Subsequent keys are generated locally and concatenated with the start up key to create a unique key. This saves round trips to the server.
>

>I got the idea for this framework on an aritcle I read on VB. My impression is it is much better in VFP than ADO\VB. For these reasons.
>
>(1) In VFP it takes less code to pass and recieve parameters to and from stored procedures.
>

Not so.. If you use ADO, the code is the same...


>(2) In VFP you can recieve and output parameter and a cursor back from a stored procedure at the same time. According to the article, you can't do this with ADO.
>

A cursor is a VFP thing... To say that VB does not support is not entirely fair. I could drag a laundry list of items that are not supported in VFP. The fact is, VFP has a langauge geared toward DBF's, VB does not. And, with ADO Recordsets, you can much of the same sorts of operatons.

Trust me,the legion of VB developer's are not banging MS's doors down to get DBF support....


>(3) In VFP you can have a local database for data that doesn't change much (i.e, pick list data) and anything else you want to put in there. Saves round trips to server.
>

Once again, on a decent network with a good box, going back to the server is a trivial matter.... I do this all the time. And, to somebody who did not know better, the look up data is local...


>4) In VFP you can create reauseable data objects that can be subclassed.

In VB, you can create reusable data objects as well. As for the ineritence implication here, I don't find myself taking advantage of that with data objects. So, I see inheritance has irrelevent here,,

>(5) In VFP you have a flexible local data engine at your disposal.

Yes, this is an advantage, and one that I do take advantage of...

>(6) In VFP you have macro substition.

Macro substition is nice. However, not having it in VB has not caused me major problems... You can actually do alot of this by implementing scripting techniques in VB. You can actually do the same thing in VFP. Rod Paddock wrote an article about this some time ago..


For me. the decision to use VFP comes down to 2 basic items:

1. For UI development, VFP still has a more elegant designer than VB.
2. VFP has a local data engine that can vastly improve performance

Personally, I think VB is gaining with respect to advantage 1. As for advantage 2, while nice, as time goes on, the local engine is becomming less and less relevant - as far as multi-tier and C/S development is concerned...