Converting old Fox Pro Files to something readable/useful

Question

0.00/5 (No votes)

See more:

Hi there,
I am working with a client to revive his old software which was developed around 14 years ago using Foxpro2.6.
My problem is that client just have the source code (in the form of .prg files)and database files with him but there is neither any documentation nor comments in source code to guide me what does what...even the database files are not correctly named.
My only option in this scenario seems to go through the .prg files and understand which command updates which database and how....but there are around 150 .prg files and I don't know Fox Pro at all (I mean I was in 9th standard when this thing became obsolete!!).

Any suggestion or idea to make this work easy, perhaps a .prg to C converter which can help me a lot.

Please help....it is becoming a nightmare

PS : I dont have problem with the database conversion but the front end and functional source code which too is written in the FoxPro2.6 and saved as .prg extension is the problem as I dont know the language and there is no documentation.

Posted 10-Jul-11 9:43am

nautiyal.sudhanshu

Updated 10-Jul-11 10:17am

v3

Add a Solution

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Espen Harlinn · Answer 1 · 2011-07-10T10:09:00

Solution 1

As usual google is your friend[^]

Are they any good - I don't know, but the important part is probably the data and structure.

Maybe you'll like XAF[^] - if it fits the requirements, it will allow you to spend more time on "saving the data".

[Update 1]
There are a few tools
http://www.vfpconversion.com/products.aspx[^]

http://foxcentral.net/microsoft/VFPToolkitNET.htm[^]

Again I've no idea about how well they works

Best regards
Espen Harlinn

Posted 10-Jul-11 10:09am

Espen Harlinn

Updated 10-Jul-11 10:34am

v2

Comments

nautiyal.sudhanshu 10-Jul-11 16:15pm

Thanx for the reply but I think you misunderstood my point...I finished converting the Data Base, my problem is command files written in foxpro, This particular application is entirely written in FoxPro (front end as well as backend), my nightmare is the front end and functional code written in the form of .prg files, I need something to convert them to C/C# or something else...

Mycroft Holmes 10-Jul-11 19:05pm

I'd be astonished if there was a converter from foxpro programming to anything. I would expect you to have to rewrite the application from scratch. At least you have the working apop to reverse engineer.

nautiyal.sudhanshu 12-Jul-11 6:21am

The problem is client doesn't now anything about the database records, i.e which is where, and what means what; There is no documentation; No proper naming of variables as well as database columns; I am supposed to finish it within 3 months, any idea how to start????....

Espen Harlinn 12-Jul-11 7:31am

If you are lucky the database is reasonably normalized, but I somehow doubt that that will be the case as denormalization often was considered a "performance trick" among foxpro developers.

So wellcome to the wonderfull world of software archeology, if the existing design is reasonably sane, you can start looking for patterns - I'd start by moving the existing data into oracle as I find that pl/sql is somewhat more expressive than TSQL, but SQL Server and TSQL will do too.

Hopefully there are indexes - that may narrow down the number of columns that have to examined. This will at least provide a starting point, even if tablenames are complete gibberish - normally the table names will provide at least some hint about their purpose.

If you can't make any headway, tell your boss and/or the client. They may not be happy about it, but they will be even less happy in three month time - if it becomes obvious that this was something that was likely to fail at the outset.

Good luck :)