Hi all,

I am now going through and summarizing all the key points from the last thread...my head starts to spin with the number of comments made (and some of them went WAY off topic, which is normal I know). I am going to post some new threads with follow up questions that are specific so a bit easier to follow.

First one: would it be possible to start changing their app by moving some of the more "static" information to SQL while keeping most of the data in the VFP tables? They have a few tables that are relatively static (e.g. life company tables that contain an address etc). Why in the world would I do this you might ask?

- to allow me to learn SQL (MS or PostgreSQL) and the limitations

- I will have to reengineer some forms to just pull down way less data (currently their company table has approx 7000 records and the form allows them to search a browsable list) and this is not a big deal. I understand though that I will most likely need to change something like this to bring down a subset of records; it would give me the possibility to present design concepts to them on a lesser used form to approve and they could see the performance

- rewriting an entire large app myself over a couple of years and then migrating to it in one jump is full of pitfalls - we all know how many bugs can be found even with the best of testing; I could develop my own framework and perfect it before rolling it out to all the screens.

So say I change my app to use the cursoradaptor class - does this allow some calls to be made to the SQL backend and others to just access the local/server VFP tables?

Albert