Books/Links on VFP to SQL Server

We have new senior management and they want to go away from the VFP and do SQL Server 2008

So I am converting my VFP programs to SQL Server

But trying to figure out how SQL Server will do what VFP does for me

Date Variables, parameters, and so on....

Anyone knows of a reference book or link on this subject?

Who is Participating?
"I am converting my VFP programs to SQL Server"

So the question is....  
  1  Are you keeping the VFP GUI front end and merely changing the backend from VFP data tables/databases to M$ SQL Server?
  2  Or are you planning on abandoning VFP all together and changing to some other GUI front end (VB.NET or something else) with SQL Server as your backend?

"trying to figure out how SQL Server will do what VFP does for me"

Remember that while M$ SQL Server is a very good database and it does indeed have its own T-SQL language, but there is nothing there to build complete 'applications' and their associated GUI front ends -- it is a DATABASE SERVER.  You will need to use another development language to create the 'application' and its front ends.

Personally I'd recommend the first choice since there is MUCH less work to do and this is a Visual Foxpro language-specific forum after all (we're generally prejudiced towards the BEST solution!!!)

But if you are electing the 2nd choice, then you will most likely have a good bit of work ahead of you.   And, depending on your own depth of knowledge of Visual Foxpro to 'understand' what you are beginning with, you might need to hire a VFP contractor/consultant.

Depending on which change path (#1 or #2 above) you are planning to do, it will greatly affect our recommendations.

Good Luck
CaptainCyrilFounder, Software Engineer, Data ScientistCommented:
It seems you are keeping the VFP frontend and moving the data to SQL. For the data it's much more secure and can be used elsewhere like online.

There are a few commands you need to learn really to do the job.


in SQLEXEC you can to the INSERT, DELETE and UPDATE.

What I propose to you it to use Program Objects which you do yourself. This will be helpful when you change the GUI later on.

You should write functions like CreateClient, DeleteClient, UpdateClient, GetClientOrders

Inside each function you will call the SQL.

You need to open the SQL connection once in the application and close it while exiting or you can do that for each module.

It's not hard at all. If you know VFP SQL, you can do MS SQL. You just need to learn how to work with date and time fields.
Kalpesh ChhatralaSoftware ConsultantCommented:
you can use This VFP & SQL - Client-Server Apps Book
Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions

Olaf DoschkeSoftware DeveloperCommented:
Well, kalpesh, the Hentzenwerke Book is about SQL Server 7.0 and - what's more important - isn't covering CursorAdapter.

The most important thing to know about any database Server as a remote backend to VFPis: You are forced into multi tier architecture pattern. You can't simply USE a server table, but you will get cursors/aliases from it and from that point can work with the data as usual.

I assume you're used to using the data environment (DE) of forms, or how are you accessing VFP data?

If that is the case you can replace tables in DEs with cursoradapters, but you will want to add parameterization to limit data retrieval.

The point is, if you USE a table VFP did limit data retrival in a "fetch only what is needed" fashion for you, eg the grid only retrieves data, untill all visible rows are filled. The scrollbar is rendered according to the reccount of a DBF, even if you Set Filter.

If you replace a table in the DE with a cursoradapter based on a simple SELECT * FROM TABLE, the cursoradapter does load all data of a table, which is not recommendable with many thousand records. The more users your app has, the worse the factor get's for LAN bandwidth usge.

That's the main issue you will have.

Bye, Olaf.

jaymz69Author Commented:
Well the person who drove VFP and had me get into it left the company and the new people (since they are not familuar with it) want to do away with it.

They think SQL Server can do everything VFP can do for the queries and reports. Perhaps it can? He suggests all the VFP reoprting I have running will need to convert toe SQL Server, maybe TSQL...?

I was telling him about how in VFP I can take data quickly now with SQLEXEC() and manipulate the data, variables, store DBF for later data compareson.

Only time can tell? I
You might need to have an 'education' session with the individual(s) who wants you to change to SQL Server.

You can 'educate' them that SQL Server, as a SERVER, is a repository for data, not an application builder.  Think of it as a responder to an application.
SQL Server can execute its own T-SQL code to accumulate/insert/update data in its data tables.
And through things like SSI and stored procedures within SQL Server, you 'automate' certain operations, but they typically use 'fixed' parameters or parameters which are passed to them via an 'outside' application.

If you have an APPLICATION today (VFP?) which allows users to make dynamic entries and manipulates data from those pieces of dynamically entered data, SQL Server can work with the data, but it cannot, by itself, get the data into itself.   It will take an APPLICATION to do that.

Good Luck
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.