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

Hi...anybody any suggestions ?

Hi Gerard,
Why would the SF used VFP tables?  I am guessing that you or your customer have already a VFP application running and you want to build the SF application with nice GUI while keeping the VFP application running.

In previous experience the above did not work too well for me, even though I did it a long time ago when moving from FP2.6 to VFP5.  At the end you end up maintaining 2 applications and limit the new application to the current VFP table design.

I am more fan of building new application in SF & SQL server with corrected table design and functionality then build a conversion process that will import from VFP (using BOs to connect to the VFP tables) and move on with the new application in SF/SQL.

Of course this is just a general opinion which may not fit your case, but you have to look all aspect of the design process and the goals you want to reach.  It may sound pretty cool to have a SF application with VFP tables but in reality I would not used VFP tables with SF other than for importing/exporting process.

Edhy Rijo

Hi Edhy. Thanks for your feedback

Currently, we are redeveloping a large VFP app in SF/SQL Server, which lets say is being used by 100 customers. We plan to have this ready say in December of this year , and start rolling it out to all 100 customers. 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 maily on the same data.

The preference would be to develop these 'New' forms in SF/VFP (with the main app still running in VFP until December 2011) . This means that this customer gets the 'add' ons immediately , and then we can move them over to the main app in December.

Of course, we could do the Add ons in VFP, but then we will also need to convert these over in December, whcih sounds like a waste of development time. I was thinking that the best approcah would be to develop the new screens in SF/VFP, and yes, while I would expect some changes to these forms to change the backend from VFP to SQl, but these changes should be minimal

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