Mark,

Sorry for being SQL centric - I just reread your original post and will restate.

For Key -I would NOT incumber myself with the overhead of a view. Keep in mind that a view is nothing but a wrapper around an SPT cursor that "automatically" sets a bunch of CursorGetProp() properties for you among other things.

As for the gerneal idea - I suggest you build a middle tier (virtual if not physical) where all database access and bus. rules are managed. Your forms/front end will talk to the middle tier and then when you want to upsize to SQL - all you have to modify is the middle tier components. Even with this approach, I prefer SPT (SQL Pass Through) cursors with stored procs over views, although in my pre-SQL app, I did use views quite succesfully.

Also - though I haven't used them - I believe several commercial frameworks have support for both VFP and SQL data sources. PErhaps soemone with that expereince could jump in and give you more advice on specifics.

Ken

>Thanks Ken

>The SQL identity solution would be ideal when when (and if) we do upsize the proposed app to SQL. However in the mean time the App will be in plain old vanilla VFP >and we were planning that the keytable would be accessed using a surrogate key function we found called GETKEY(), which is usually called from the valid condition >on the primary key field.

>Would acessing and updating this keytable as a view be worthwile at all since nobody elsewhere in the enterprise will ever want to see the contents of this table and it >s is never going to be more than 20 small records long so there is unlikely to be any network overhead involved.