0

I have run an old (1996) Windows program that accesses DBF files. If I run with an old copy of the database it works fine. But if I run with my current copy of the database, I get the GP Fault when I take a certain action.

I conclude from the above that there's something in the current database that the program does not like, but when I take the action I just get the name of the DLL that caused the fault, and a hex location (0001:0F7F).

Is there any way, any tool, any process that would let me see what the program is trying to do when it bombs? This might give me insight into fixing the database. For instance, if the process before the bomb is joining of two tables, then I'd know which two tables to clean-up.

Journeyman Geek
  • 127,463
  • 52
  • 260
  • 430
Dale
  • 483
  • 3
  • 15
  • Without access to the original source code, you're basically reverse-engineering it. Unless you have a lot of time, you're out of luck - a high-level operation like joining two tables could easily be thousands of assembly instructions. You'd be better off restoring from backup and/or contacting the original author. – Bob Apr 24 '15 at 03:17
  • DBFs are quite standard. You may use something like MSO or LibreOffice to read/modify them (in both Spreadsheet/Excel and Database/Access modes). – LogicDaemon Apr 24 '15 at 10:27
  • LogicDaemon, access to the data isn't the problem, its something in the content that is unknown that the program objects to. Although using one of your suggestions might allow me to incrementally delete data until the error goes away. There are foreign keys and many tables, so I'd need to understand the schema well before trying that. – Dale May 20 '15 at 16:00

0 Answers0