>The one option you can knock out is VB/SQL. If you are going to consider VB for the first time, VB .NET is the choice to make.

Are there learning resurces such as those found for VFP thru Hentzenwerke?

>At this point, I assume you have a pure VFP solution (VFP App and VFP Data). The easy one to tackle first is the data. If the data requires the services to go to SQL Server, then you should not hessitate to transition your data to SQL Server.

Correct. Its a pure VFP app. Currently no pressure to move towards SQL - but am looking at long term plans for the app.

>Finally, we are left with whether you should stay with VFP or go to .NET. I would not recommend dropping VFP in favor of .NET. If you have an application in VFP and it works, then I would suggest sticking with it if you can, taking this time to learn .NET.

Sounds logical.

>On the other hand, if you need to go to SQL Server, it may necessitate an overhaul of your VFP code. If you need to undertake a re-write of the VFP app, then your decision gets a little more difficult. I think part of the decision turns on whether you are a consultant or an employee. If you are an employee, you need to consider the needs of your company. The sensitivity to the current VFP situation is a little less sensitive. If you are a consultant, then your situation may be little more perilous. Based on your profile, I assume you are an employee. Still, as an employee, you need to be concerned with investing in a skill set that is going to have a long term payoff.

I am owner/employee and all <g>. As athe ownere also - you say it is wise to learning VB.Net?

>If you need to re-write the VFP app to work correctly with SQL Server, your company needs to evalutate that investment in VFP carefully. If your company values the idea of developing in tools that will be supported AND innovated, then you need to consider VB .NET. Finding employees to work on the application is another important consideration. As time goes by, it is getting harder and harder to find VFP developers. As others have said, keeping productive (ringing the register!) is important as well.

If I read this correctly, I take it that pouring resources into VFP is not a viable idea considering long term implications? eg. developing VFP/SQL with VFP as frontend,; acquiring books to learn VFP/SQL; and possibly some other tools that fit in between VFP and SQL? Would these be a waste of resources in the long term?

>1. If you can get SQL Server weaved into your application in the short term (6 months or less), then VFP/SQL may be a good choice.

While my app uses SQL statements all most of the time, I think eventually it will be a re-write. Your opinion?
>
>2. If you find that you need SQL Server, but it will necessitate a complete rewrite of your VFP app, unless you can do it within 6 months, then VS .NET should be considered.

VB.Net or VS.Net?

>
>3. If you don't need to go to SQL Server, stay with VFP but at the same time, invest in your VS .NET learning endeavors.

Sounds logical.

John, thank you for taking the time to respond to this thread.