DBase III import to Access

[BGJR]

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]

if you can use a dBase ODBC driver , then you can import your tables directly into Access.

 

[Minty]

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]

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]

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]

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]

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]

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!

 

[Yochiver]

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.

 

[Cotswold]

@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.

 

[BGJR]

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]

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?

 

[theDBguy]

Hi @Nedclack. Welcome to AWF!

 

[SHANEMAC51]

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,

*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]

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]

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.