Speaking of Foxpro...



  • Continuing the discussion from Foxy Checksum:

    @DocMonster said:

    Foxpro is one of the worst things ever. It let any idiot who knew a bit of SQL pass them self off as a real developer. Every time I heard a job mention anything about Foxpro, even in the past tense, it was an awful experience.

    Does anybody know enough about Foxpro to reverse-engineer a database? I have a commercial program (i.e., no source) that uses Foxpro as its storage engine1. It will export to various formats such as CSV — one file per table, with no hints at all as to the relations between the tables; in some cases, not even a hint as to what the table itself is. It will export to one interchange format that preserves proper relationships among the data, but this is lossy; the format does not support all of the data in the database. There is a newer version of the program that exports to another format that may (or may not) support all of the data, but I don't have the budget to upgrade (assuming I could find a copy; even the newer version was discontinued a year or so ago — replaced by the company's more popular, consumer-oriented program).

    1Despite this and a terrible GUI, it has features that none of its competitors support, or didn't the last time I seriously looked at any of them.



  • I'm not touching fox pro, but maybe this helps



  • @HardwareGeek said:

    one file per table, with no hints at all as to the relations between the tables; in some cases, not even a hint as to what the table itself is. It will export to one interchange format that preserves proper relationships among the data, but this is lossy; the format does not support all of the data in the database.

    IIRC, that was the standard storage approach for FoxPro (and dBase-derived database systems in general), not just CSV exports. Indexes were stored in another file entirely, with their own format.

    Despite what Fox (and MS, after they bought Fox out) claimed later, FoxPro wasn't really relational at all; while a sub-sub-set of SQL was crudely bolted on to the original dBase III scatter/gather navigational database structure, it didn't really work properly. If memory serves, the 'relations' existed entirely in the code, with no representation in the files at all.



  • @ScholRLEA said:

    Despite what Fox (and MS, after they bought Fox out) claimed later, FoxPro wasn't really relational at all

    FoxPro stores relationship in a separate .dbc file. Many FoxPro programmers refused to make the jump beyond what existed in version 2.6, so they are seldom used. That's not Microsoft's fault.



  • Ah, OK. I was working in 2.5 for MS-DOS (which was already a fossil in 1996), so I didn't know about those.



  • @ScholRLEA said:

    I was working in 2.5 for MS-DOS

    You weren't alone. I was occasionally taught FoxPro 3 and 5 from 1996 through 1999 and most of my students (all of them were professional FoxPro developers) had never used 3 or later before class.



  • My experience of Foxpro is limited to discussions with such developers whilst I was working for the company I created an eCommerce website "framework" for. E-commerce was a sideline (eventually not profitable, hence my redundancy). Their main business was bespoke plugin modules for SME account packages.

    Might be a silly question, but have tried looking for decompilers. There appear to be a lot of them out there, but some appear to be from dubious sources and websites so I'm not going to provide any links etc



  • @Jaime said:

    FoxPro stores relationship in a separate .dbc file. Many FoxPro programmers refused to make the jump beyond what existed in version 2.6, so they are seldom used.

    I have .dbf, .cdx and .fpt files for each table; no .dbc.

    @Jarry said:

    http://www.refox.net/
    It might, but at $400 it's 5 – 6 times the cost of the newer version of the program I'm using (if I can find a copy; no luck yet). ... No, it looks like it would (try to) decompile the program's Foxpro source code, if I can find the right files to feed it, and if they haven't been protected, but AFAICT recovering/extracting the data isn't its intended purpose.

    @loose said:

    have tried looking for decompilers
    See above. I don't want to decompile the program; I just want to get my data in a more useful format, and my need for that isn't sufficient to muck about with Foxpro.

    I did find a competing product that announced around the time my program was discontinued that they were working on a new version that would import my program's files directly, without the data loss of going through an interchange format. However, they did not say they would support all my program's data types; anything they don't support would "probably" be stuffed into generic "note" records. I'll probably follow up on that when I have a job and can afford to spend money on hobbies. (Yes, this whole thing is a hobby project. I probably should have said that up front.)

    Frankly, the existing program does everything I need it to do. Better export and maybe UI improvements (and the possibility that someday it may not work on Windows XVII) are the only reasons for upgrading or moving to a competing program.



  • This might be a bit radical: But what about using the time / breathing space to "develop" a replacement? Because sooner or later you may well have to, at a time when there is "no time"



  • @HardwareGeek said:

    I have .dbf, .cdx and .fpt files for each table; no .dbc.

    In FoxPro terminology, those are called "Free Tables". Basically, the guy who built the system said "Relationships, procedures, views... I don't need those". Unfortunately, most FoxPro developers think that way.



  • @HardwareGeek said:

    I just want to get my data in a more useful format, and my need for that isn't sufficient to muck about with Foxpro

    Try using this OLEDB provider.



  • I had a job in 2006 that had all its data in Foxpro 2.6. It ran off that. Their main program read .dbf files. It was terrible. Total clueless cheapskate morons. Sadly they are still around somehow. They also use Classic ASP written in Notepad with only outputting via Response.Write calls.

    Their website looks like it was made in 1994 (probably was) and they have a 1-star BBB rating lol.



  • @Jaime said:

    Basically, the guy who built the system said "Relationships, procedures, views... I don't need those".

    I've been using this program since the '90s, and it was on V3 or 4 then; it may date all the way back to the '80s. It wouldn't surprise me if they weren't supported when the project was started. Which is ironic, because this database is all about relationships.

    @loose said:

    "develop" a replacement
    I'm neither a DB nor UI programmer; I've done a little of both, but I'm not necessarily good at either. This program has had 20+ years of commercial, revenue-driven development; there's no way I'm going to develop an adequate replacement in my spare time. If it comes to the point I have to change, there are viable — though perhaps less capable — alternatives available.

    @Jaime said:

    Try using this OLEDB provider.
    Thanks. I'll check it out; from a quick glance over that page, it may be just what I was looking for.



  • Well, I was taught Foxpro in my secondary 6-7 and was required to take public exam on it.

    IMO, Foxpro is like VB... it allow people who don't know much about database to build applications on it. Since the data don't actually leave the process's boundary, it allows coding styles that should cause problems in other programming languages to run without any obvious performance issue.

    Maybe you think it's ugly, but it does get the job done and was one of the most favourate choice of programming language at the time (I mean days around 90s). My chemistry teacher had the reputation of Foxpro expert when I was in school and he'd built a few handy tools for school administration.

    Clipper or Foxpro, pick your poison.


Log in to reply