Slashdot Mirror


Microsoft to Open Source FoxPro

rah1420 writes "Microsoft has announced that it will open-source the core portions of the Visual FoxPro DBMS software to its CodePlex community development site. At the same time, Microsoft has announced that it will no longer be making new versions of the FoxPro DBMS."

3 of 172 comments (clear)

  1. If only all orphaned software would go this route by davidwr · · Score: 4, Insightful

    I wish all companies would open-source or at least make available free-as-in-beer their obsolete-and-non-competing products. If they can't make it free, then make it $1.

    Except for games, which have a commercial nostalgia market, most software over 10-15 years old wouldn't be commercially viable even if it did run on the latest operating systems.

    I for one would love to fire up Windows 3.1 with a 15 year old copy of Microsoft Word and print to my Postscript printer, just to see how fast it is on my modern PC.

    --
    Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
  2. Re:Rushmore technology anyone? by k12linux · · Score: 4, Insightful

    FoxPro IS fast or at least was when I used it last. BUT only if you are retrieving limited datasets that are indexed correctly. If your query can use indexed columns to limit the number of records returned you are ok.

    I did the programming on a system which resided on a Netware v4.11 server back around 1993 and it had one table with somewhere around 3 million records. Queries were lightning fast if you didn't match too many rows and the query was optimized to work with your indexes. Queries which couldn't utilize indexes, however, were painfully slow.

    Having said all that, however, I can't think of any legitimate reason to use DBASE style databases these days. With free DB servers like MySQL and PostgreSQL why bother?

  3. Re:Rushmore technology anyone? by Just+Some+Guy · · Score: 4, Insightful

    Queries were lightning fast if you didn't match too many rows and the query was optimized to work with your indexes.

    But even indexed queries pale when compared to a "real" database. Since FP is file based - that is, each client has to read the files directly - even the index files have to be transmitted over the network to do those lightning fast queries. At some point you saturate your NIC, and after that all the processing power, RAM, or fast drives in the world won't make it a millisecond faster.

    Compare and contrast with any client/server system, where all those queries are consolidated into one cache shared among all clients, and only the actual requested rows have to be returned. By its inherent architecture, FP simply cannot ever hope to be as fast.

    --
    Dewey, what part of this looks like authorities should be involved?