dbase3 conversion

  • Thread starter Thread starter K.taylor
  • Start date Start date
K

K.taylor

Hello,

I am the head of a small non profit (501c3) feline registry that
several years ago had a dbase program created to keep track of members,

cats, registration numbers, etc. The son of the original founder wrote
the program, and ive been trying to convert it to Access. I can get to
all the data, the problem lies in that I cannot access the indexes to
know how all the data fits together as the person who wrote the program

no longer has the original files. the program, in it's entirety,
including all the data, is less than 2 Mb. Would anyone be willing to
point me in the rifght direction to anyone who would be willing to do
the conversion for a nomial fee, or failing that, tell me what tool i
would require in order to do it myself. I have tried a couple of
"freeware" conversion utilities that did not work. there is an .exe
file that would probably need to be decompiled in order to find what im

looking for.
Any help would be greatly appreciated!
Thank You
Ken Taylor
President
AACE Inc.
 
Hi K. Taylor

Not too sure, but an exe file running against a dbase III data probably
indicates that it was a *compiled* dbase application developed using a tool
such as Clipper. The original dbase III index file is .NDX. However, you may
see a .NTX file which would indicate that it was a Clipper application.

There is not a whole lot more you can do to convert to Access than migrating
the data (i.e. from dbf to mdb tables) using a link or import function in
Access. The application itself, the logic, user interface have to be rebuilt
from scratch.

A couple of comments:
all the data, the problem lies in that I cannot access the indexes to
know how all the data fits together as the person who wrote the program
Click to expand...

IMHO, knowing and having access to the indexes are not enough to figure out
how all the data fits together.
"freeware" conversion utilities that did not work. there is an .exe
file that would probably need to be decompiled in order to find what im
Click to expand...

It's practically impossible to try to decompile an .exe in order to
understand an application. You would have a better chance understanding the
application by using it and explore all the menu structures, etc.

I have converted a few *old* dbase systems to Access based systems and the
following have been the norms:
- Only the data is worth anything (i.e. the dbf files)
- The user interface, functionalities, etc. needed to be rebuilt from
scratch because Access is fundamentally a different development tool.
- It's not a bad idea to rebuild the *old* application anyway, since things
(i.e. business requirements) may have changed. There are always things that
could
be done, designed better.. more efficient.. etc etc.



HTH,
Immanuel Sibero
 
I apologize if this is a repeat, but I got an error trying to post earlier.

Decompiling the .exe will be of little or no value if you do not have the
correct version of the correct tool used to build the application.

All that is of any value to you is the data in the .dbf files. All the
Dbase tools (Dbase, Foxbase, early Foxpro, and Quicksilver) held their data
externally in these .dbf files. A .dbf file would be the same as a table in
Access. Depending on the tool used to create the application, there will be
..ndx, .idx, .ntx, or other associated files used as indexes.

The .dbf files can be imported into Access as tables; however, you will need
to create indexes and relationships for them within Access.

If I were doing this, I would first import the .dbf files and analyze their
content to determine the relationships and indexes needed to make it into a
relational database. I would then create the forms, reports, and other
objects necessary to make it a useful application.

If you have a functioning version of the program, you can use that as a
start for defining the business rules for the application; otherwise, you
will have to define the business rules and functionality you desire before
anyone can begin building an application for your.

If you would like to discuss this further, I can be contacted at

dahargisAtVerizonDotNet
 
Thank you all for the quick replies! I was under the impression that
decompiling the .exe file would help in that it would tell me how the
program matched people to the cats they own to the reg number of the
cats etc. I have already imported the dbf files into access, as well as
all the other dbf files, but.... until I can figure out how it matches
the data together then Im kinda stuck, save for using the original
program to try and do it by hand (I hope that makes sense). As for the
other files: there are quite a few .aix files that I found I could
change the extension to .dbf and they would be imported as well. Then
there are alot of .ace files (which leads me to believe the maker of
the program named the extension himself), that no matter what, (with my
limited knowledge) I change the extension to can be imported at all.
Those I believe are the files that I need to help place the data in
some sort of order...

Glad you guys are here
Ken
 
If you could find the correct decompiler, which may be difficult given the
different versions, it might help understand the relationships. In the XBase
languages, there were no set relationships. To relate tables, you used the
SET RELATION TO command to establish relationships for the current process.
You could at least see what fields in what tables the program was setting
relationships.

You may try looking at the field names and values in the tables for things
that make sense. Since there was no Autonumber field, a relationship was
established based on the values in the field. So, for example, if you have a
table that has the Cats in it, you might look for a field named Owner,
Parent, or anything that contains a value you would also find in the owners
table. That is just an example of the kind of detective work you will need
to do.
 
Back
Top