0

Our current system database system is a clipper DOS application. The database inside its folder is fragmented/divided into many parts. I want to decrypt the database so that I will have only one database in all and avoid reshuffling of data. I'll attached the file folder Screenshot.. the database is on .DBF format

VScreenshot of files

  • 1
    DBF files are separate files, not a single database. Each DBF file is one table, and the entire collection of files is the database. They're not encrypted; they're binary files, and the file format is well-documented. There are one or more index files, which typically have the extension .NTX (although third party drivers may cause others to exist such as CDX or SDX). You can't decrypt and convert the files to a single database, because that's not what they are at all. Google can explain how DBASE III databases worked (which is what Clipper used, with the proprietary index format). – Ken White Sep 06 '18 at 01:20
  • (continued) There is no *fragmented* database. There's also no *reshuffling of data* happening. the application opens the files individually, establishes any linkage between them in code (not via SQL), and performs standard I/O operations on them via a library designed to do so. Again, research into DBase III Plus will explain how all of this works. Until you understand that, I'd advise you not to touch anything, because you can corrupt indexes or data very easily if you don't know what you're doing. – Ken White Sep 06 '18 at 01:27
  • Thanks for the advice, RIght now I am working on a duplicate application, to avoid corrupting it. How do I know which table is connected to another one. Cant seem to figure it out. – Dan Matthew Aranas Sep 06 '18 at 02:05
  • 1
    There isn't any way to do so. It's all done in code. Unless you can examine the columns in each table and figure out how they link to other tables, you're out of luck. There is no system table in Clipper/DBase that will provide that linkage. That's one of the difficulties of dealing with old style ISAM databases, I'm afraid. – Ken White Sep 06 '18 at 02:09
  • Thanks Man @KenWhite. Last question is there a way that I can see the code or view the code for this DOS Clipper app? – Dan Matthew Aranas Sep 06 '18 at 02:43
  • Not unless you have the source files (they end in .prg). A decompiler won't provide you with much useful information, especially if it was compiled without debug information, and a large part of the functionality was in C or assembler code that was linked in from external libraries that didn't have source available.. – Ken White Sep 06 '18 at 02:45
  • LOL @KenWhite theres no .prg file. Gonna do this the hardway then – Dan Matthew Aranas Sep 06 '18 at 02:57
  • **Thanks!** I appreciate it man – Dan Matthew Aranas Sep 06 '18 at 02:57

5 Answers5

0

Often you can decompile the CLIPPER exe file to source code and work from the .prg I've done it many times. The program to use is called WALKYRIE.

BobRun
  • 756
  • 5
  • 12
0

In Clipper and Fox Pro for DOS .dbf file is a simple table file. If You want to use as data base with many tables in one unit. You can import these tables in MS SQL data base and/or part of a MS Access database.

Oskars
  • 64
  • 3
0

I see that you got several answers. Most are partially right. Let's address these one at a time:

All those files essentially comprise the "database" for the application you're using. They could be used by other applications as well. Besides having a lot of files, what is the problem you're trying to solve?

People mentioned indexes. You can generally ignore these. There are there primarily to make access to the data files faster. Any properly written clipper application will recreate these if they're missing or corrupted. You could test this by renaming one, running the app, and seeing what happens. If it doesn't recreate it you can name it back. Not replacing missing index files would be unusual behavior.

The DBF file format is binary, but barely. Most of what's in a DBF is text and is readable with an editor. But there's no reason to do so - I'm sure there are several free DBF utilities out there to to read DBF files. Getting the structure of the files could be very helpful.

Getting the data out of the files would also be fairly simple with a utility. If you look up the DBF format you could even write one fairly easily in Clipper, any other language that uses DBF files, or in something like Python. Any language that can open and write files, really. It's not hard - any competent developer could do this in a matter of hours. Must less if you're using Clipper or another language that natively reads DBX files.

Most people create dBase/Clipper programs with relational data, like SQL Server. Where SQL Server has tables that relate to each other dBase/Clipper has a file for each "table." This isn't a requirement, but it was almost certainly done this way.

Given that, if you get the table structures through a utility or by reading the headers in an editor (don't save them from an editor!) you could quite likely recreate the database schema (i.e. the map of the data). Once you have that it's fairly trivial to get the data into another type of database (SQL Sever, Access, or whatever you like to use.) If non of the files are too large it's conceivable to put all the files into Excel sheets. It really depends on what you want to do with it.

As others have said, you may be able to get the code by Valkyrie. Some people have used it very successfully. I don't know where you get it and I've never used it. Why do you not have the code? If this is a commercial application you likely should not have it. If it's a custom app who ever wrote it or paid to have it written should have the code.

Again, it's not clear to me what problem you're trying to solve. But there are many options for doing something with those DBF files. Fortunately they are one of the easier to read data formats you could be working with.

Let me know if you have any questions. Apologies for the typos that are no doubt scattered throughout this reply.

David Richardson
  • 123
  • 1
  • 1
  • 8
0

You sort of can get an idea of how they relate to each other by opening the index files they use (.NTX files). If you have the DBU utility (executable) around, you can open the DBF and load the index (NTX). LibreOffice Calc is also able to open DBFs (haven't tested .NTX). If you open the .NTX on a text editor you will see the indexes in the beginning.

Eduardo
  • 7,631
  • 2
  • 30
  • 31
-1

I open with Access, but I can save the data using a PrintFill Program.