DBase III import to Access (1 Viewer)

BGJR

New member
Local time
Today, 12:00
Joined
Jun 23, 2021
Messages
4
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, 12:00
Joined
Apr 9, 2015
Messages
4,339
if you can use a dBase ODBC driver , then you can import your tables directly into Access.
 

Minty

AWF VIP
Local time
Today, 16:00
Joined
Jul 26, 2013
Messages
10,354
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, 12:00
Joined
Jun 23, 2021
Messages
4
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, 12:00
Joined
Jun 23, 2021
Messages
4
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, 16:00
Joined
Jul 9, 2003
Messages
16,244
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, 03:00
Joined
Jul 4, 2013
Messages
2,770
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

Active member
Local time
Today, 16:00
Joined
Dec 31, 2020
Messages
521
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, 12:00
Joined
Feb 19, 2002
Messages
42,970
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, 12:00
Joined
Feb 19, 2002
Messages
42,970
Have we depressed you? Did you take a look at any of the current software offerings?
 

Yochiver

New member
Local time
Today, 17:00
Joined
Nov 25, 2021
Messages
8
I still run a very old application with Dbase III files under Windows 10 , thanks to VDOS from Jos Schaars .
Maybe it can help you.
 

Pat Hartman

Super Moderator
Staff member
Local time
Today, 12:00
Joined
Feb 19, 2002
Messages
42,970
I guess the original poster asked his question and then went away:(
 

Cotswold

Active member
Local time
Today, 16:00
Joined
Dec 31, 2020
Messages
521
@Yochiver : I still run a very old application with Dbase III files under Windows 10 , thanks to VDOS from Jos Schaars .
I can confirm this is the case. I've just tested a Clipper87 program that was last compiled into an EXE in 1997
but written some years before and it runs perfectly. However, do think that you maybe should start to have
your programs converted/updated? At least you have some breathing space now. One advantage is that in
a Windows program you aren't restricted to 80 columns and 24 lines, so much more screen for your data.
 
Last edited:

BGJR

New member
Local time
Today, 12:00
Joined
Jun 23, 2021
Messages
4
I still run a very old application with Dbase III files under Windows 10 , thanks to VDOS from Jos Schaars .
Maybe it can help you.
OP Here: Thank you! Over the holiday weekend, I was able to get DBaseIII to run very nicely with VDOS under Windows 7 and 10. I had some printing issues, but I was able to modify the oputput with some switches in the config file, and it prints very nicely. Seems to be a very robust program and has solved much of my problem. Ultimately I would like to run it from a server, and have someone working on the DBASEIII to Access conversion for that. Thanks all!
 

Nedclack

New member
Local time
Today, 16:00
Joined
Jan 31, 2022
Messages
1
I can confirm this is the case. I've just tested a Clipper87 program that was last compiled into an EXE in 1997
but written some years before and it runs perfectly. However, do think that you maybe should start to have
your programs converted/updated? At least you have some breathing space now. One advantage is that in
a Windows program you aren't restricted to 80 columns and 24 lines, so much more screen for your data.
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!
OP Here: Thank you! Over the holiday weekend, I was able to get DBaseIII to run very nicely with VDOS under Windows 7 and 10. I had some printing issues, but I was able to modify the oputput with some switches in the config file, and it prints very nicely. Seems to be a very robust program and has solved much of my problem. Ultimately I would like to run it from a server, and have someone working on the DBASEIII to Access conversion for that. Thanks all!
If you look at dbase.com there's also dbDOSv which claims to be a DOS emulator good for running any DOS app under Windows. I've not used it but it may help in future if VDOS ever falls short.

I've used both DOS and Windows dBASE and would warn that they are very different animals. As long as you can keep limping in DOS I'd do so. Going to retire soon?
 

SHANEMAC51

Active member
Local time
Today, 19:00
Joined
Jan 28, 2022
Messages
310
OP Here: Thank you! Over the holiday weekend, I was able to get DBaseIII to run very nicely with VDOS under Windows 7 and 10. I had some printing issues, but I was able to modify the oputput with some switches in the config file, and it prints very nicely. Seems to be a very robust program and has solved much of my problem. Ultimately I would like to run it from a server, and have someone working on the DBASEIII to Access conversion for that. Thanks all!
I worked with dbase for more than 10 years
, then I transferred tasks to ms access, and for 2 years I worked in parallel with dbase
, during these 2 years I developed reporting forms in ms access, and used the data from DBF

I had a feature in dbase - all reports were written to text files, there was no direct printing
, this technique greatly simplified the report generation programs (the initial/final print sheet and the like were not requested)

when MS WORD appeared,

Code:
*PROG1.PRG
DO START
SET ALTE TO PROG1.DOC
SET ALTE ON
?"<HTML>"
?"<PRE>"
------------ useful content of the report-----------
?"</ PRE>"
?"</HTML>"
SEAT ALTE OFF
SET ALTE TO

the resulting file PROG1.DOC easily printed in MS WORD
 

Cotswold

Active member
Local time
Today, 16:00
Joined
Dec 31, 2020
Messages
521
If you look at dbase.com there's also dbDOSv which claims to be a DOS emulator good for running any DOS app under Windows. I've not used it but it may help in future if VDOS ever falls short.

I've used both DOS and Windows dBASE and would warn that they are very different animals. As long as you can keep limping in DOS I'd do so. Going to retire soon?
Last year I spent a few weeks looking at Visual XHarbour a development from Harbour Clipper and have to say I found it was sound and generally as good as Access. If not better in some aspects. It compiles into a standalone EXE in the same way as Clipper did. ( I'm always on the lookout for an Access alternative, just to be away from MS and their unwanted surprise bugs and the possibility that one day they'll just kill Access )

Really impressed, EXCEPT.......poor to no support, and printing or reports were shall we say challenging. The Forum is on google and it just a pain, bordering on useless, as well as being poorly supported. A really great product just a pity that it didn't come up to the mark overall.
 

GPGeorge

Grover Park George
Local time
Today, 09:00
Joined
Nov 25, 2004
Messages
1,776
Last year I spent a few weeks looking at Visual XHarbour a development from Harbour Clipper and have to say I found it was sound and generally as good as Access. If not better in some aspects. It compiles into a standalone EXE in the same way as Clipper did. ( I'm always on the lookout for an Access alternative, just to be away from MS and their unwanted surprise bugs and the possibility that one day they'll just kill Access )

Really impressed, EXCEPT.......poor to no support, and printing or reports were shall we say challenging. The Forum is on google and it just a pain, bordering on useless, as well as being poorly supported. A really great product just a pity that it didn't come up to the mark overall.
That's probably one of the reasons MS isn't too concerned about Access not being given sufficient resources to keep it bug-free (how's that for a left-handed way of saying, "neglect"). The alternatives may be functionally as good as, or better than, Access, but lack of long-term support makes them unattractive.

BTW: Access can import .dbf's again largely because of the response of the Access community on the now-deprecated UserVoice. I remember the MS people were actually surprised at the vehemence of the demands it be brought back. The dbf user base was small but very vocal about the importance of dbfs to their businesses.
 

Users who are viewing this thread

Top Bottom