2

I've seen many solutions on how to convert DBF files into a SQL database, but is there anyway to convert the tables without re-coding the program that refers to the DBF files?

For example convert the DBF files into SQL tables, then leaving the dbf files in place with only a pointer to the SQL database?

The goal would be to allow the existing application to run (until we migrate the code) but keep the data in SQL?

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
Bradleyo
  • 35
  • 6
  • if you can create the table structure again in the SQL you can use Sql Integration services to migrate the data from your old database. Creating SSIS is simple and easy. – Nichole Grace Oct 09 '12 at 20:38
  • What specific version of SQL and dbf are we talking here?? SQL 2008, FoxPro ??? – RThomas Oct 09 '12 at 21:42
  • The two SQL version is TBD, the current DBF files are in a variant of FoxPro used by Xharbor. – Bradleyo Oct 10 '12 at 12:39

3 Answers3

2

I don't think you're going to find a tool that will link to SQL from within a DBF context and allow your code to flow seamlessly through the DBF to your SQL Server keeping both current along the way.

Depending on how complex or extensive your daily transactions are I would recommend setting up some SSIS packages that run on a regular basis to keep the data from your DBF files flowing to your SQL tables until you are ready to commit to SQL full time.

Another option might be to approach it going the other direction. Set up a linked server or open rowset from within SQL to your DBF files and then build some stored procs on the SQL end that merge the data on a regular basis using tsql merge statements or other queries that you'd have to build.

Community
  • 1
  • 1
RThomas
  • 10,702
  • 2
  • 48
  • 61
  • Thanks, I was afraid this was the option. However I didn't have the details, so thanks for the great pointers!! – Bradleyo Oct 10 '12 at 12:40
0

Applications interact with databases using drivers. Two databases (DBF and any other databse eg MySQL) can not interact with each other without an application in between them which would tell the drivers what to do. So your existing application can interact with DBF as well as SQLDatabase but can not make DBF File to interact with SQL Database.
As others have suggested you can use SSIS for this purpose.

Saurabh R S
  • 3,037
  • 1
  • 34
  • 44
0

The closest thing I think you will find for such is to go with SyBase's iSQLAnywhere. They have specifically picked-up and integrated their SQL database to directly recognize .DBF files. However, as others have mentioned, you'll still need to create connection to the database to get at the data. You can create a "database" in iSQLAnywhere that points to free tables instead of embedding into a single "database" such as other databases...

I've done a few DBF to sql conversions, and one approach I've done to keep the front-end consistent is to create a .PRG based set of procedures. If your app is VFP and you have private vs default data sessions throughout, any classes respect the "data session" of the form, so if you create a class under the "default" data session, then run a form that is private, then call your generic class to query and open a table, the opened table will be recognized in the "default" session and not the one of your form.

Now, that said, one other thing I did was had a single function to open the connection and return true/false respectively and allow central place to debug. If valid connection, run a given sql command. Now, if you are expecting a given "alias" name such as "person" table to be open, use the sqlexec( lcSomeCommand, "AliasYouWant" ) and much of the rest will work for displaying and editing. You would still have to push BACK the changes with SQL Insert/Update, but that is very simple with parametererized SQL pass-through.

DRapp
  • 47,638
  • 12
  • 72
  • 142