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!'

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.

(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.

(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.

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

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

(6) In VFP you have macro substition.

and the list goes on...

Charlie