DBase III import to Access (2 Viewers)

BGJR

New member
Local time
Today, 10:01
Joined
Jun 23, 2021
Messages
3
Hello forum. I apologize for what is likely to be a common question, but it is important to me. In the mid to late 1980's, we had a fairly robust and complex Dbase program customized for my company. The programmer is LONG gone, and I personally have no DBase or Access skills. I have milked this DOS program for a long time now, and simply cannot get it to run on anything above XP, and even then printing is a hassle, as I have to redirect LPT1 output to a USB port, it is not networkable, etc.

All I know is that to run the program (on an XP computer), I start Dbase with the DOS command "dbase app" (in a desktop icon these days), where "app" is the sole application we use, but we use it all day long, every day. I am a real estate appraiser, so "app" actually stands for "appraisal program", not "application", though I guess it really is an application...

Currently in my Dbase directory, there are hundreds of .DBF files (one for each month back to the '80's), quite a few .PRG and .TBK files, and handful of misc files like .FRM, .FMT, .NDX, and .OVL.

My question is: How difficult will it be for me to convert all of this mess into a working Access program (recognizing that I know NOTHING about DBase III or Access, but am fairly computer knowledgeable otherwise)? If not me, is it reasonably simple for an Access savvy individual to do? Con you recommend a BASIC book or article which would illustrate how to, IF it is simple? Will an entire new access program need to be written to duplicate the functionality of the old one? (hope not). In the end, if it is not VERY simple, I will be looking for someone to do this for us. Any clues on where to start looking if help is needed?

I am very thankful for your input and help on this!
 

Ranman256

Well-known member
Local time
Today, 10:01
Joined
Apr 9, 2015
Messages
3,915
if you can use a dBase ODBC driver , then you can import your tables directly into Access.
 

Minty

AWF VIP
Local time
Today, 15:01
Joined
Jul 26, 2013
Messages
8,760
I suspect you would be better off getting somebody to do a migration for you.
The time you spend learning and creating the same database processes in Access or another DBMS will far exceed your expectations if you are not experienced. (Whatever you think it will take you, in hours, multiply by 10, at least, probably more like 25.)

Depending on the complexity of the data entry and business rules, after moving the tables into Access (which is probably the easy bit), you then have to replicate the functionality in a completely different environment.

If your business process is simple this could be 10 days of work for an experienced developer.
If you are NASA and it's slightly more complex and involves space flight modelling and rocket science it could be a couple of months ;)
 

BGJR

New member
Local time
Today, 10:01
Joined
Jun 23, 2021
Messages
3
I suspect you would be better off getting somebody to do a migration for you.
The time you spend learning and creating the same database processes in Access or another DBMS will far exceed your expectations if you are not experienced. (Whatever you think it will take you, in hours, multiply by 10, at least, probably more like 25.)

Depending on the complexity of the data entry and business rules, after moving the tables into Access (which is probably the easy bit), you then have to replicate the functionality in a completely different environment.

If your business process is simple this could be 10 days of work for an experienced developer.
If you are NASA and it's slightly more complex and involves space flight modelling and rocket science it could be a couple of months ;)
 

BGJR

New member
Local time
Today, 10:01
Joined
Jun 23, 2021
Messages
3
Though NASA is right down the street, I suspect my needs are a bit less demanding! Thank you for your frank and honest response. I am realizing that I may have exaggerated when I called our program "complex", as I imagine in reality it is a good, thorough, but not necessarily complex program. I am thinking I will wait for some other responses, but I am seeing that it is NOT a simple process.
 

Uncle Gizmo

Nifty Access Guy
Staff member
Local time
Today, 15:01
Joined
Jul 9, 2003
Messages
13,359
One way to approach the problem is to pick off the most useful process that the database provides, the bit that saves you in the most work, the bit that you need the most.

Move this process and corresponding tables etc, into MS Access first and get that working then add the rest as you go.
 

Cronk

Registered User.
Local time
Tomorrow, 00:01
Joined
Jul 4, 2013
Messages
2,532
I developed a number of systems in dBase before switching to Access in the mid 1990's.

IMO, Access is completely different. For a start everything is within the one file, data tables, indicies, queries, forms, reports and modules (although common practice is to split out the data tables into another linked file). In the dBase, there are separate files for each table, another for each table index, each form etc.

It's easy to import tables into Access and recreate the indicies but nothing else can be imported. You'll have to create the forms, reports and functionality.

Either you have to learn how to use Access or pay someone to do the development. If the latter, check the abilities of the developer by seeking a demonstration of something else they have done. Also check whether that developer relies mostly on macros rather than code as code provides more flexibility and error handling.
 

Cotswold

Member
Local time
Today, 15:01
Joined
Dec 31, 2020
Messages
39
Hi BGJR
I did a huge amount of database work using dBASE as a backend and programming using Clipper87 as the frontend. It is not a trivial operation to convert a dBASE system into Access as it is a real paradigm shift between the two. Not only that, you'll need to redesign all of the screens and print routines for Windows.

Recently I was messing about and wanted to convert and import some of my old 1980s dBASE tables into Access2019 and fortunately had a copy of FoxPro8. I had to pull the dBASE tables into Foxpro8 first and then import those into Access. This was because Access just didn't want to recognise the older dBASE tables. Also, when Access imports it sets field sizes to defaults and you'll need to maybe trawl through amending nearly every one.

You could I suppose convert your system into FoxPro8 but it is not anything like the same as dBASE. Also, it is no longer supported and with a new version of Windows soon to arrive, it is just possible FoxPro will not run on it. Plus, in a few years Microsoft will stop supporting Windows10, maybe as soon as 2025.

If you aren't experienced in writing software it will probably take you six to nine months to learn Access and start to create something sound.

I think where you are now, Minty and Cronk gave the best advice to employ a developer. Or alternatively, look around and see if a similar application is sold that would do the job. You may think it not to be the case, but it is unlikely that your business type is unique. After all you've used this software for 40 years so all the money you've saved you can now blow on a new system for the next 40!

For the time being, keep your copies of XP safe so you can at least add new PCs until the switch. Good luck!:)
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 10:01
Joined
Feb 19, 2002
Messages
32,787
The best use of your skills will be to document the existing app and to decide how you want the new app to work. Think of this as an opportunity to get new features and fix things that never quite worked.

Converting the data will be the easiest part. I think Access can import .dbf's again. If you want to post one of the old files, we can try to import it for you to see how that will work. In the new database, you will NOT have separate files for each month. All the historical data will be converted into a single table. This dramatically reduces the complexity of working with old data. All you need is to provide criteria for your queries to pick the data you want from the table.

Any developer you hire will almost certainly not be able to run the dBase app and that will be problematic since he won't have the ability to look at the code or compare results so you are going to have to explain all calculations and validation rules. You might as well start documenting now.

I did a search just to see what is out there. If one of the products will work for you, I wouldn't bother with rolling your own. You can still record the history and use that in an Access database for reference.

Real Estate Appraisal Software (homeputer.com)
Top 5 Real Estate Appraisal Software for Enhanced Transparency | Wondershare PDFelement
Real Estate Appraisal Software | GandySoft
a la mode | Trusted by more appraisers than all others combined


I didn't look closely at any of them since I don't know enough about the process to evaluate them but what I will do is to warn you about losing control over your data. When you use a cloud based service, your data is now in someone elses custody and you will be hard pressed to ever get it back in a computer readable format. So if you pick a product and six months later decide you don't like it. Good luck getting anything except printed reports of what you put in. So, my advice before you commit to a cloud service is to start with a good understanding of how you can get your data out should you decide to move on. If you can't get your data out, I would move on and try a different product. If the product is something you install on your LAN and includes a database such as SQL Server, you are in a much better position regarding your old data. If you can have direct access to the database that powers the app, you can extract your data and import it int a new app or at least load it into a historical database for reference.
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 10:01
Joined
Feb 19, 2002
Messages
32,787
Have we depressed you? Did you take a look at any of the current software offerings?
 

Users who are viewing this thread

Top Bottom