>I am starting a project to develop some tools in VFP5 that will utilise tables concurrently used by a FPW2.6a system. Whilst I can access the tables as "free tables", I would like to base the new tools on Views based on the 2.6 tables. The 2.6 tables all have a Codebook 2.6 psuedo-primary key field cID c(9), which has ID's generated by Codebook's NetID() function. Therefore, there is a unique key value in the 2.6 table. Does anyone have any experience with this approach? I have read in the VFP help that views need a "primary key" in the source table to allow accurate/successfull updates. Will the 2.6 cID field value do? Any comments/tips/ideas very much appreciated.

As long as your cid's are really unique, you should have no problem with the update. But there's another concern, it's the relative path from you TEST and PRODUCTION DBC to the data. I've two approaches to this. The first one is to define your views in code. To be honest, I went as far as I could (not real far) with the View Designer, used GENDBCX to generate the view code and started from there. I tuned the code into a SELECT &lcFrom. The variable holds the path and the name of the table(s) involved. Save your view code as a PRG. That's a lot of work, and you need to run you PRG view definitions once at the customer's to update their DBC. I've dropped this solution.

The other approach is to consider your 2.6 data as remote, then build remote views using an ODBC connection. The performance is a little slower, but the implementation is cleaner. VFP ODBC 6.0 has improved a lot compared to older versions.

José