We have a foxpro 2.5 application and we want to migrate the backend, all the dbf files over to a sql server. Then somehow build a bridge between the frontend application and the sql server. is this possible to do? and how difficult would it be? also any tips oh how to start this process would be helpful. Thankx
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Migrating to SQL server
- Thread starter AldenWang
- Start date
Alden,
As Mike suggests - FoxPro DOS or FP Windows has no way to access SQL server data - VFP does. Depending on how your application is written, you may be able to use some of it VFP, but most would suggest a complete rewrite. The biggest problem you'll face (once you get past the whole new VFP OOP paradigm), is that you don't process data the same way in a client-server environment as you do in a "desktop" application. For some useful background information, go to this thread - I believe you'll find it has some useful links. thread184-258863
Rick
As Mike suggests - FoxPro DOS or FP Windows has no way to access SQL server data - VFP does. Depending on how your application is written, you may be able to use some of it VFP, but most would suggest a complete rewrite. The biggest problem you'll face (once you get past the whole new VFP OOP paradigm), is that you don't process data the same way in a client-server environment as you do in a "desktop" application. For some useful background information, go to this thread - I believe you'll find it has some useful links. thread184-258863
Rick
I disagree with my fellow FP developers on this.
Years ago, MS sold a seperate "Connectivity Kit" that thru the use of ODBC, FP26 was able to get data from a SQL table.
The speed of it was not that great. But it could be done.
For more info try...
HTH - Wayne
Years ago, MS sold a seperate "Connectivity Kit" that thru the use of ODBC, FP26 was able to get data from a SQL table.
The speed of it was not that great. But it could be done.
For more info try...
HTH - Wayne
Wayne,
Wow, what a trip down memory lane - 1994! Unfortunately, this only worked with the 16-bit ODBC SQL Server Drivers. None of the "current" SQL servers can be accessed with 16-bit ODBC - only 32-bit. Now if you are running SQL Server 1.0 on Win NT 3.51, maybe you'll be alright.
Rick
Wow, what a trip down memory lane - 1994! Unfortunately, this only worked with the 16-bit ODBC SQL Server Drivers. None of the "current" SQL servers can be accessed with 16-bit ODBC - only 32-bit. Now if you are running SQL Server 1.0 on Win NT 3.51, maybe you'll be alright.
Rick
Rick;
Sorry, once again I beg to disagree. re: 16 bit vs 32 bit,
I believe (and I might be full of beans on this one), we were able to access an MSSQL50 table from 26.
We did have a devil of a time with the ODBC connection, I had to get the assistance of my supervisor to help me with the link-up, and he was one of those guys who was reluctant to share his knowledge. But I think the end result was to use the VFP ODBC connection instead of the 26 vers. But I was able to query the sql 50 table and store the results in a 26 dbf through the use of the 26 "Connectivity Kit". Of course then you have the curse of having to maintain *2* data sets. Our particular dbf requirements, allowed us the luxury of being able to purge all the data, and start fresh each time. We did have a lot of 26 apps so it was worthwhile for us to pursue this option.
...I found a place on the web that is currently offering the "Connectivity Kit" try...
Rick...memory lane...I first learned dBase 3+ on a C/PM 80, using 2-5.25 floppies and no HD. I was also one of the early members of the FoxForum on CI$ under the moniker was.not.was Yea, I'm an old tart, but please don't call me sir.[g]
Regards - Wayne
Sorry, once again I beg to disagree. re: 16 bit vs 32 bit,
I believe (and I might be full of beans on this one), we were able to access an MSSQL50 table from 26.
We did have a devil of a time with the ODBC connection, I had to get the assistance of my supervisor to help me with the link-up, and he was one of those guys who was reluctant to share his knowledge. But I think the end result was to use the VFP ODBC connection instead of the 26 vers. But I was able to query the sql 50 table and store the results in a 26 dbf through the use of the 26 "Connectivity Kit". Of course then you have the curse of having to maintain *2* data sets. Our particular dbf requirements, allowed us the luxury of being able to purge all the data, and start fresh each time. We did have a lot of 26 apps so it was worthwhile for us to pursue this option.
...I found a place on the web that is currently offering the "Connectivity Kit" try...
Rick...memory lane...I first learned dBase 3+ on a C/PM 80, using 2-5.25 floppies and no HD. I was also one of the early members of the FoxForum on CI$ under the moniker was.not.was Yea, I'm an old tart, but please don't call me sir.[g]
Regards - Wayne
Wayne,
Got you beat, dBase II (which as we know was the first version) on C/PM with 1-8" floppy, and I remember "upgrading" to a 300 baud modem to get faster access on the local BBS. <vbg>
Bottomline on the SQL Server access - best to upgrade to VFP if you don't want a lot of heartache. Just because something can be done doesn't make it worthwhile to try sometimes.
Rick
Got you beat, dBase II (which as we know was the first version) on C/PM with 1-8" floppy, and I remember "upgrading" to a 300 baud modem to get faster access on the local BBS. <vbg>
Bottomline on the SQL Server access - best to upgrade to VFP if you don't want a lot of heartache. Just because something can be done doesn't make it worthwhile to try sometimes.
Rick
fp26guylearningvfp60
Programmer
Rick;
"Just because something can be done doesn't make it worthwhile to try sometimes."
Amen. I agree whole heartedly! Admittedly this is a kludge way of doing things compared to the tools we have today, VB, VFP, COM OBJ, SP etc. etc.
But if someone has invested thousands of dollars or hours in coding, I would want to maximize that investment. Now having said that, this solution that I proposed must be viewed as a short term option. But not necessarily bad one. The client moves forward into the wonderful world of sql,
and two data sets can be run in parallel to validate new code as it's being developed.
The hardest part of this process is getting the correct ODBC drivers installed on a box. The calls to run DBCONNECT are simple, and you have to learn maybe 10 new error codes if your "bridge" fails to connect.
But definately start planing now for your IT moves down the road. VFP - VB - Java - MacDougel whatever (anything but 26[g])
Regards - Wayne
"Just because something can be done doesn't make it worthwhile to try sometimes."
Amen. I agree whole heartedly! Admittedly this is a kludge way of doing things compared to the tools we have today, VB, VFP, COM OBJ, SP etc. etc.
But if someone has invested thousands of dollars or hours in coding, I would want to maximize that investment. Now having said that, this solution that I proposed must be viewed as a short term option. But not necessarily bad one. The client moves forward into the wonderful world of sql,
and two data sets can be run in parallel to validate new code as it's being developed.
The hardest part of this process is getting the correct ODBC drivers installed on a box. The calls to run DBCONNECT are simple, and you have to learn maybe 10 new error codes if your "bridge" fails to connect.
But definately start planing now for your IT moves down the road. VFP - VB - Java - MacDougel whatever (anything but 26[g])
Regards - Wayne
- Thread starter
- #9
- Status
Similar threads
