I have to write an app (Using SF) which right now will link into VFP databases but in a year or so these VFP databases will be upgraded to SQL Server.

I realise I will have to do some changes but want to keep them to a minimum and am planning now . One of the things I've run into with the OleDB driver is if I am  updating or inserting, in VFP , named parameters cannot be used and you end up with about 40 question marks. (All my Apps so far in SF have been with Sql Server so here I am referring to writing an APP not using SF)

I'm looking for pointers in the design, so that when I come to use the APP with SQL Server, my mods will be down to a minimum. I also don't want to necessarily build a whole factory with options for VFP and SQL, i.e. I am happy enough to make hard coded changes as long as they are kept to a minimum

Gerard, thanks for the explanation.

One of these customers wants some 'Special Developments' around the main application, specific only to them, and will consist of say 20/30 forms , but based mainly on the same data.

Does any of the new functionality for this customer depend on what is currently being done in the VFP application?  If that is the case I don't see how you will easily keep controlling the new SF application and the VFP one.  At some point customer may not end up happy having to use 2 applications to do specific things.
The way I have done all my VFP->SF/SQL moved is to keep it simple as follow:

1. Duplicate VFP table structures to MS SQL
2. In MS SQL make all data structure changes needed to properly handle relationships and new functionality for specific customers.
3. In SF create new application which will basically do the same thing as the VFP application but with huge enhancements using SF ListView some other 3rd party controls like Ribbon menu, etc.
4. Create an import routine using SF Business Objects reading the VFP table and making the changes required on the fly.  This is very important since you have several customer, then you can simply upgrade customers at your own pace.
5. Add new functionality to SF application for specific customers.
   

As an independent consultant I have moved several VFP applications to SF using the above guidelines.  I know that in some cases this may not work, but if you control of the customer base and the application, at some point you have to stop new VFP development and move your resources towards the SF application.  I don't know what your VFP application does or how big/complicated it could be, but December 2011 looks to me very far away.

If you need, feel free to contact me directly via email and I will be glad to talk to you about what I have done with StrataFrame and VFP.  Trust me, StrataFrame logic has worked for me on all my VFP conversions.

Edhy Rijo

Hi Edhy. Thanks again for taking the time to response to this thread



I have started to upgrade the exisitng VFP app, and progress is not a fast as I would like, mainly because I have to still earn a crust with other developments and support, but based on progress - to - date, I reckon Dec 2011 is realistic and achievable. The APP is fully functional ERP type app with about 100 forms in total.

The new forms will be self contained but will 90% of the time rely on data in the VFP data. The danger is , that if I say to the customer hold on until Dec 2011 and everything will be ready, he may go looking elsewhere . In fact he has gone looking elsewhere and 'nearly' installed a completely different system a year ago, but the recession here slowed him down a bit)

I think myself that the way to go is to develop the new forms in SF/VFP in tandem with current redevelopment of the Main App that is under way, but wnat to be sure that a)This will work  and b) There is not going to be a huge amount of time spent chnging these specific froms from VFP to SQL come december

That could work, but again, it means that the customer will need to open 2 programs and still you will need to update/modify the VFP tables to accommodate new functionality in SF application. 

Be sure to test the saving functionality with SF/VFP.  Then you may end up having 2 BO, one for the VFP and one for SQL functionality, at least for more complicated process.  Regular maintenance forms, you may get away using a single BO and just changing the DataSourceKey, but for SQL CRUD you may one to use stored procedures and not for VFP, so it may be better just to have a BO for each to keep it clean and easier to maintain while still using VFP.

Edhy Rijo