Printable Version of Topic

Click here to view this topic in its original format

UtterAccess Forums _ Q & A - Software _ Fox Pro Developer Files

Posted by: River59 Oct 20 2018, 11:33 AM

I am at my wits end here. I was asked to 'convert' a FoxPro database into MS Access. The problem is that I have no idea how to get to the 'developer/backend code' files. What should I look for?
We have imported the tables and can see screens, but have no idea of the logic or coding that goes into them.

Please, I am begging!

Posted by: cheekybuddha Oct 20 2018, 02:24 PM

Will your company stump up a grand?

(ps I know nothing of VFP, so would this even be the right software?)

Posted by: nvogel Oct 21 2018, 09:16 AM

If you just want the data and not any screens or reports then look for DBF files.

You can import DBF files directly into an Access database. Click New Data Source > From Database > dBase File and browse to the DBF file(s) you want to import. Selecting the dBase IV option should be compatible with most (possibly not all) FoxPro files. One DBF file corresponds to a table in Access terms so there may be multiple files associated with your FoxPro application.

Posted by: River59 Oct 21 2018, 10:11 AM

I have imported most of the tables. I have seen screenshots of some of the forms. Under normal circumstances I would be prepared to just re-build the application but when I was brought in for this job, the manager said it was a simple 'conversion' and he knew enough about FoxPro to get me what I needed from the program. Come to find out, he knows nothing.

Last week he said he estimated the job to be about 100 hrs of work .... hahaha. We are talking months to build this invoicing application. He then proceeded to invalidate my background (about 22 years) in the program because I spend 40 hours building an application to 'clean' the files.

I was just hoping to see the logic and code that was used in FoxPro to see if I could short cut some of the work and brain power. I am ready to walk out on this insanity if he isn't willing to accept that this is a lot of work and going to take some time.

Posted by: DanielPineault Oct 21 2018, 10:15 AM

From what I know, it's a complete start over from scratch. You can extract the tables/data, but that's about it.

Posted by: River59 Oct 21 2018, 10:27 AM

That is what I thought, Daniel. I did open a couple small code files (one specific query) and can see that the code would need re-writing. I just can't find any of the 'big' functions anywhere to see what tables were temporarily built to create the forms.

It is going to be a complete start over and he needs to understand that or continue to use the FoxPro application.


Posted by: DanielPineault Oct 21 2018, 10:36 AM

Good luck.

Posted by: River59 Oct 21 2018, 10:41 AM

I'm just curious about all the companies on the web who claim to be able to 'convert' a FoxPro database into an Access database. This has him convinced it is an easy task and made me believe that it was possible if I could just find the secret decoder ring. And yes, I've told him to have one of them do the job!

Posted by: AlbertKallal Oct 21 2018, 09:03 PM

Well, just importing the tables from a FoxPro database into an Access database means you “converted” from FoxPro to Access.

However the application part is a VERY different concept.

I mean, for example, one can migrate or convert the Access tables to SQL server. At that point you can continue to use Access as the application side and development tool.

I mean, you can convert an Excel sheet into Access (import it). At that point you converted from Excel to Access.

However, now that you have a table in Access, then the next question and part is going to revolve around building the application part.

So, I am sure that within the first day, you imported and converted the FoxPro database to Access.

However, the term database means the tables – not the application part.

So many a company will say offer to convert a Oracle database to say SQL server database, or even say to a Access database. At that point, you converted the database.

However converting from one database to another has VERY LITTLE to do with NOW building an application to work with that database.

So a database is just a collection of tables. To interact with a SQL database, Oracle database, or an Access database you THEN have to build an application.

I mean, there nothing that will say convert a Delphi application you build to FoxPro, or Access or say

And there nothing that will say convert an Access application in VBA to c#, or say to VB6, or even

So, converting from one database to another is a common task, usually rather automated, or will be a series of importing of data from the older system to the newer system. At that point you converted the database, but that concept and process has VERY little to do with converting a application.

A database is a VERY separate concept from that of a application.

So, there is no more chance of converting a program written in c++ to Access VBA, then converting FoxPro applications to, c# or say Access.

So the developer tools you choose to build an application with are VERY separate then the database system you going to use to “house” the data tables.

A database is not an application – it is a collection of tables and data – big difference.

As for looking at the code? Well, all of the FoxPro programs (thankfully) are not in binary format. So you can open up the folder where the application resides, and open any file with a “.prg” extension with notepad.

So the program code should be easy to look at, and view with notepad. However, you be reading + learning a new programming language if you going to “read” that code and figure out what it does.

As for the screens? Well, again, no development tools I am aware of could say take Delphi code and forms can convert them say into VB6, or say Visual Studio and

So, the most fundamental task is getting the database (data) over into a set of tables, and then establishing how the tables are related to each other.

In any project, even a large Access one? Well even without ANY documentation, or reading ugly code?

The #1 thing I would want?

A good relationship diagram of the tables. You give me that, and I am really quite much off to the races.

You cannot really work on any application until such time you have a “spatial” concept and view of the tables involved.

Unless you have somewhat decent FoxPro skills, then I would simply get the FoxPro database transferred over to Access.

Once you converted the database, then the REAL work starts.

You need a functional spec (this is simply a written document as to what the application does, and all of its features).

You can simply reverse engineer what each screen does, and use that as you design guide, or simply write out in a word doc what the features you plan to have and duplicate in your new application.

I mean, you have to “gain” familiarly with the existing program, get the feel and run it. Without a good solid knowledge of the existing application, then you have no means to re-build it in Access.

So either the existing application is your functional spec, or you write out a functional spec as to what features and how your new application will work. Such functional specs are not technical in nature – just a outlie of all the features.

That “function” spec is THEN converted into what we call a “technical” spec. (how the Access code, forms etc. will work). Often the developer just reads and uses the functional spec and then works directly in Access.

However, if you have a “team” of developers, then a lead developer will write out the technical spec that is then handed over to the programmers to actually code and build.

So you can open the “code” files with notepad, but even for me to start say reading some Access VBA code, and figure out what is going on, I tend to need:

A good grasp of what the application does. (Functional spec).

A good ER diagram of the database (tables). (Start of technical spec)

Without above two parts, then it really hard to do any work on an existing Access application, let alone create a new application.

So, that existing FoxPro application is your “design” or “functional” specification. You simply have to look at it, and reproduce the same functionally. However, you can’t reproduce the same features until you know what the features are!! Just reading code usually will not “give” you an overall picture of the features.

You have to bring up the old application, open up the first part (say searching for customers, editing customers), and simply now re-produce that part of the application in your new platform.

Then you might open up the second part – say the reporting part, and start looking at the list of reports, and then start re-producing them one by one.

And if some “tricky” part that processes some data on say a click of a button? Well then now you certainly may well open the FoxPro code to see what is does, or you have to figure out what is required. However just opening a bunch of code files and reading FoxPro code is of LITTLE use until such time you “know” what the context of the code running is used for.

So while moving the database is mostly a automated process (imports of data), the application part is a manual labour part.

And software is VERY labour intensive – that’s why it rather costly to develop.

Albert D. Kallal (Access MVP, 2003-2017)
Edmonton, Alberta Canada

Posted by: AlbertKallal Oct 21 2018, 09:18 PM

For some tips, read this article of mine:

The above was a complex conversion of a mainframe project to Access, but "most" of what applies in the above article would in fact apply to if using FoxPro to Access.

Note how in the article I stress how important it is to get a NICE laid out ER diagram of the tables, and how they are related. This should be your #1 priority here.

Enjoy the article - it should give you some ideas on how I went about converting the application to Access. More amazing? I wrote that article 17 years ago!!!

Albert D. Kallal (Access MVP, 2003-2017)
Edmonton, Alberta Canada

Posted by: JonSmith Oct 22 2018, 05:06 AM

So Albert, I asked this before as I find your posts extremely hard to read these days since each sentence is a paragraph but you didn't answer me. So to check again, is this posting style a personal choice (if so I'll say no more as I don't want to argue with personal preference) or a change to deal with the UtterAccess line break bug that many users have experienced? If its the latter I discovered the fix for it so line breaks behave as normal and would be happy to share. Let me know.

Sounds like a tough job but this guy isn't holding up his end of the bargain. If they guaranteed he had the knowledge then try to push of that and give him the responsibility of finding the tables and developer view etc?

It sounds like its going quite toxic so it seems like if you don't get on the same page its best to walk away so they'll need to understand if he is lacking the expert knowledge then this is a much much larger task and the time already spent is kind of wasted because of him.


Posted by: River59 Oct 23 2018, 07:56 AM

Thank you very much, Albert. Your post is just what I needed to possibly help convince management what is going to be involved in this project. I appreciate your expertise on the subject and your willingness to share your knowledge.
Again, hats off to the UA team! hat_tip.gif

Posted by: River59 Oct 23 2018, 07:58 AM

Yes, Jon, you are correct. I was mislead when I accepted this job. I will see what I can do to educate them on what will be involved in this project and see if they are willing to invest the time and money. If not, it will be time to move on.

Posted by: nvogel Oct 23 2018, 01:06 PM

Here's another thing to think about. Making a straight port / rewrite of a business application is often said to be something you should never try to do. At the very least it's something you should be quite cautious about. The reason is that to make such a project a success you need to get buy-in from the users / stakeholders who actually use and rely on the application. When you talk to them about the details you will nearly always find that they say "the current application does X but it would be much better if it did Y instead". So it's quite probably a mistake to take the existing application as your starting point. Best talk to the user community first and find out what they really want.

Posted by: andyrice Nov 12 2018, 03:31 PM

I used to do FoxPro. Although this was fifteen years ago. You would need to have access to the source files. Those could be .scx/.sct, .vcx/.vct files. And the FoxPro project that contained those files. The project files have a .pjx/.pjt extension. There also can be .prg files, those are in a text format. To view the code you need to have a copy of Visual FoxPro.
The above is for a Visual FoxPro application. I don't remember the extensions for older versions of FoxPro. And Visual FoxPro works quite differently than Access, especially if the programmer used classes a lot.