2.5b upgrade roadmap? 1

[ZTrue]

Does anyone have a roadmap that I could use to help direct me on getting an old FoxPro 2.5b DB brought into the current age?

Background:
We used FoxPro as an MRP system for 13 years (92-05)and still need to be able to access and reference the data in it from time to time (5-10 times per year). The actual data has been jumbled and moved several times. As a consequence, I believe that several of the file links are now broken. Also, the number of staff memebers who actually know how to use it and find what they are looking for is dwindling quickly.

As a hedge to (1) make the data easier to access and (2) make it easier to maintain, I think that I would like to either move the data to a system that I am familiar with (SQL perhaps), or at least update the DB to VFP 9. At least then, I could get help with maintenance for it.

I appreciate any help that you can give.

Thank you.

 

[DSummZZZ]

There are quite a few posts on migration already, so I won't rehash that. Just poke around this forum and the Visual Foxpro forum and you will get a good idea of what path to take.

You can however, read Foxpro 2.x tables with VFP 9 without converting them.



-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[JRB-Bldr]

brought into the current age

I guess that my first question would be:
Are you trying to migrate the entire MRP applcation and its data?
Or just migrate the old data and abandon the original MRP?

If the former, then you have to set your priorities first which would be used to evaluate the best 'road' to take.

If the later, then you have to consider how will this migrated data be accessed?

Will you write a totally new, different application to access it?
Or will you merely use Queries within an existing application to access it?

The road you are on is a very good one, but there is no single answer (a.k.a. 'roadmap') to EVERYONE's needs.

While we most like will not be able to give you a EXACT approach to use, with more clarification on your goals, we might be able to offer more advice.

Good Luck,
JRB-Bldr

 

[ZTrue]

I think what I need is to migrate the data and build a rudimentary system to search through it. Generally, the info we need out of it is an answer to something like "What contract # required the purchase of material X, and on what PO# was the purchase made?"

Part of the struggles that our newer users have had is with the old interface anyway. If I can dump the tables to SQL and build an Access front end for queries, then that is what I will do. If, on the other hand, I can pick up a copy of VFP9 and it comes with some easy to learn tools for building a competent front-end, then that is a path I am open to as well.

I guess that I basically just need someone who knows FoxPro to give me their best idea for gaining access to these tables and the data therein.

Thank you guys for the replies, they are much appreciated.

 

[JRB-Bldr]

You will not be able to 'dump' the FP dbf data tables into MS SQL.

One approach you could use would be to write a very simple FP program to USE each and every data table and then use the COPY TO command to write it out to another file type - such as TXT or CSV (even Excel - I shudder!!) which can then be imported into MS SQL using the SQL tools.

NOTE - Memo field data would present a problem since it is typically not output with the COPY TO command.

Obviously you would lose any relationships between the various data tables and their associated indicies, but you should be able to determine these for yourself and set them up in your rudimentary system.

There are also 3rd party commercial programs to assist you.
dbConvert -

http://dbconvert.com/convert-foxpro-to-mssql-pro.php?DB=7

Also a Google search for: dbf2sql will turn up some more.

Note - I have not used any of these products, but I'd guess that at least one of them might work for a one-time conversion.

HOWEVER - Since this forum is regarding the Foxpro language I might be a touch biased.
If you already know the Foxpro language, then getting around in Visual Foxpro (VFP9) would be pretty easy. Most (if not all) of the FP syntax is still supported in addition to a lot of new commands/functions/etc.

Also there would be a BIG plus in regards to the data. You could use it 'as is' where it already 'lives' or you could migrate it to SQL and use it from there via ODBC connections.

The biggest difference in VFP from FP that you most likely would encounter would be in the GUI Forms (a.k.a. 'Screens' in FP). While there is a lot of similarity, the Screen Snippet code goes into Form Methods. That takes a little getting used to, but it comes pretty fast.

If you wanted to consider using VFP9, you might want to look over the free on-line tutorial videos at:

http://www.garfieldhudson.com/FreeVideos.aspx

Good Luck,
JRB-Bldr

 

[TamarGranor]

The difficulty of migrating your data or of building a new front end depends very much on the quality of the data structures you already have. If the set of tables follows best practice (like using normalized tables), then your task is a lot easier.

Chances are good, though, that your tables don't follow best practice, particularly, since you mention that some things seem to be broken.

Do you have an existing FoxPro 2.5 application to work with this data or have your people simply been working in the Command Window directly?

Tamar

 

[ZTrue]

The users have been using the command window to interact with the DB.

I have found a copy of a VFP6 install disk the piles (literally) of misc. disks left by the previous guy.

I am not totally ignorant to DB or interface design. Hopefully things are not too broken. I will see if I can get this copy of VFP6 to install and whether I can make heads or tails of the interface.

Thank you all for you help and suggestions.

 

[JRB-Bldr]

Look at the on-line tutorial that I referenced above to get some basic understanding of how to 'navigate' through VFP6.

As to Hopefully things are not too broken...

It depends a lot on what might be 'broken'.

If it is only the Indicies which would be used to 'connect' one data table to another, those can (AND MOST LIKELY SHOULD) be re-created.

One piece of knowledge that will be of great benefit to you will be knowing how the data tables work together to achieve the results you want.

Example:
Table: CUSTOMERS has a field CustID
Table CUSTADDR has a field CUSTID
Table SOMASTER has a field CUSTID
Table SODETAIL has a field CUSTID
Table ARMASTER has a field CUSTID
Table ARDETAIL has a field CUSTID
etc.
And the multiple tables can be brought together using the CUSTID as the basis for a SQL Query or to set up table RELATIONS

If you know that you can re-build the indicies (build the new ones as Complex 'CDX' indicies) and you will be off-and-running.

However if the data within the table fields is corrupted, then things can get a whole lot messier.

Good Luck,
JRB-Bldr

 

[JRB-Bldr]

One thing to keep in mind with VFP6...

When you mentioned the variety of disks, it jogged my memory from WAY BACK WHEN...
VFP6 was most often sold as part of Visual Studio 6

It does not need all of that VS 'stuff' to run and or develop in just VFP. Don't get lost in the abundance of VS6.

From the VS6 installation utility, you can install just the VFP6 part of the package and run it without the Visual Studio IDE, etc.

VFP6 should do everything you have described needing, but if you could find VFP7 or VFP9 (skip over VFP8), they would come as single DVD's

Good Luck,
JRB-Bldr

 

[dbMark]

Over 10 years ago I did some conversion from FoxPro tables to SQL. FP doesn't have any way to open a SQL database. So we wrote simple routines in VFP to pick up the data, configure the data to the new destination fields (for example, our new specs for Yes/No changed simple Y/N to Y/N/-/{blank}/etc), open the SQL database and tables, then write it. However, you probably just want a simple port, so you won't have to worry about reconfiguring data.

So Visual FoxPro is an excellent and native way to either handle current tables or transfer the data into SQL. Of course if you have to look for a version, then VFP 9.0 is the way to go. For example, VFP 6 SP5 (the minimum to work with) is at least 10-12 years old. Probably VFP versions older than 9.0 won't be that much cheaper to make it worth whatever savings there might be.

 

[TamarGranor]

FP doesn't have any way to open a SQL database.

FoxPro 2.x by itself doesn't, but with the Connectivity Kit, you can do that.

Tamar

 

[JRB-Bldr]

If you are interested in possibly finding a copy of the FP Connectivity Kit go to:

http://www.emsps.com/oldtools/msfox.htm#foxprodos25

Search the page for: Connectivity Kit

Good Luck,
JRB-Bldr

 

[Olaf Doschke]

I assume that means technical the files are ok but you have some contradcting data or more general the data is wrong subject specific. If you have technically broken files you can fix a bit of that by tools like foxfix, but it can't retreive lost data.

On the other side, if technically the dbfs are ok, you can take the latest ODBC or OLEDB driver and due to the downward compatibility also read 2.5 dbf, both the foxpro data access drivers are also capable to read a bit clipper and dbase, and certainly the whole line of foxpro dbf versions.

Others have suggested to write a migration tool, in the first step I'd take the sql upsizing wizard of codeplex vfpx, that was improved. After you apply that you will have the data in SQL Server at least. The normalisation and other steps to higher the data quality can be done from that point onwards.

http://vfpx.codeplex.com/releases/view/10224

The first step of the wirzard asks for a dbcm which you won't have, but you can create one and simply add all the 2.5 dbfs to it. It just take CREATE DATABASE C:\data\my.dbc and the USE a 2.5 dbf andd COPY TO C:\data\table.dbf DATABASE my for each table.dbf and the wizard can take it from there.

Bye, Olaf.