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."
See first comment in the article by a Microsoftie:
.NET framework, wrappers for Vista APIs to make it easier to write applications that run on Vista machines, as well as better support for VFP data in Visual Studio.
NOTE that the released part is Sedna and NOT VFP nor VFP core elements!
Sedna is a project Microsoft has been working on for the past year or so. Sedna is built using the extensibility model of VFP9 and provides features like better connectivity to SQL Server, integration with parts of the
I know Access uses JET, but I haven't run across anything saying Exchange uses it... If they did, I could use eseutil to fix this stupid broken Access mdb I was just told about today instead of the not-working jetcomp.exe tool.
Apparently ESE stands for Extensible Storage Engine as well...so I'm gonna have to say Exchange doesn't use JET.
That was the first question that came to mind for me, too.
The relevant part of the actual announcement on Microsoft's site reads "To reiterate, today we are announcing that we are not planning on releasing a VFP 10 and will be releasing the completed Sedna work on CodePlex at no charge. The components written as part of Sedna will be placed in the community for further enhancement as part of our shared source initiative. You can expect to see the Sedna code on CodePlex sometime before the end of summer 2007."
Shared Source is not Open Source.
Further comments, apparently ESE was meant to succeed the Access JET, but that didn't happen.
n gine
http://en.wikipedia.org/wiki/Extensible_Storage_E
So it's apparently a flavor of JET...but different.
I could "see" them opening JET Red (Access) in about 10 years, because there are no plans to make it 64 bit, but not JET Blue (ESE/Exchange). That'd open up Exchange and MS wouldn't want to do that.
That seems pretty definitive to me.
For clarification: Sedna (the stuff that's going into CodePlex) is not now (nor was it ever intended to be) the next version of Visual Foxpro. It's just a set of VFP-based tools intended to help current VFP developers to make better use of new features in Vista/SQL Server/etc...
Meanwhile, VFP 9 is getting a final service pack and then that's it as far as Microsoft is concerned. There's certainly no plans to open-source the IDE or the VFP engine because, frankly, Microsoft would never do that. Some of the technology (and people) from VFP is going towards the LINQ project, but
It breaks my pluginses, my precious!
There is an open source project inspired by VFP but based on python. It's called Dabo http://dabodev.com/ . Check it out if you are interested in getting on board with something that isn't obselete.
evil is as evil does
If you want to query it, your machine has to read to entire file, throw out the lines it doesn't want, and present the results
That is incorrect. FoxPro only reads only the data it needs.
I know this will come across as flamebait, and I'd normally not say this, but anyone who claims that FoxPro is fast is a hobbyist programmer. It's simply not fast by any imaginable standard other than the trivial case of small files on a single user's drive.
Another lie. I've written FoxPro apps that are used in 100+ multiuser environments with multi gigabytes of data. Fast as hell.
I'm not saying it's better that client-server but to say FoxPro is slow is wrong. You can write crap applications in any language you know.
Let's see... I just did a query against a 1.5 GB table (DBF) that has an index file (CDX) of 240 MB. I did an indexed query that returned 435 records or so, and it did it in 1.11 seconds.
.NET. It's called LINQ, and it isn't out yet. Foxpro has been doing this stuff for more than 15 years. I've accessed text files, Excel spreadsheets, AS/400 DB2 data, and SQL Server data all at one time and generated reports that can be viewed, printed, and/or exported back to Excel. All coming from million+ row data sources, all heterogenous.
.NET. But I have never seen anything do what Foxpro can do with varied data sources and local cursor speed in 15+ years of business database programming.
So, you are mistaken. Either that, or my machine downloaded 240 MB in under a second. Sorry, our network isn't that fast. *smile*
I don't know much about file servers, but the entire index file does not need to come down. Not sure if that is a boon of the file server or of Foxpro, but I have been fighting that myth for ten years -- Foxpro does NOT pull entire files down...neither the index files nor the data file.
Let's get some other "duh" stuff taken care of. ANY system will be slow if you pull down a lot of data. That's because the data is coming down. It has to traverse the network to become truly local. If it isn't coming down, like some sort of DataReader thingamabob, then OK, it isn't down. But then don't try joiing that table to another local one, because then you'll just have to wait _then_.
Foxpro is incredibly fast. We have custom applications totalling more than 600,000 lines of code. Everything from old DOS-based input screen to an imaging system (scan, classify, viewing) housing more than 5 million images/files across 2 SQL Server databases (yes, VFP does wonders with SQL Server databases as well). The file-based DBF problems arise as they would with any file-based solution: size limits, contention issues, corruption, etc. But we have over 50-60 users regularly pounding our system, a mix of DBF data and SQL Server data, and it works pretty darn well.
Foxpro's other advantage is what it does with client side data. I can read in an XLS file (one line of code), bring in data via a SQL Server query (3 lines of code), and query a local DBF file (one line of code). Each query will reside in it's own local cursor which can then be indexed, browsed etc. Even better, those cursors can then be joined, filtered, and queried to build another cursor with all of that data brought together. I hear Microsoft is still working on a local engine with that kind of power for
Foxpro has a lot of problems, sure, and I am digging
And one more time: FOXPRO DOESN'T PULL DOWN THE WHOLE INDEX FILE WHEN DOING QUERIES! *phew* *smile*
What Would Sutekh Do?
Yes, I used FoxPro back in the early nineties. It was a great product under Fox, but when Microsoft purchased it, they supported it only for a while, then let it languish while they pushed Access (an UTTER POS with all the "reliability" and brain-dead design decisions Microsoft is known for).
I was at a computer show in San Francisco standing at the FoxPro booth actually when I heard that Microsoft had bought them.
But I don't think the "Jet" engine came from Foxpro. I might be wrong about that. I think the Access engine and the FoxPro engines were separate for a long time. A quick Google indicates that Microsoft bought Fox for their "Rushmore" database technology which ended up being included in Jet.
Richard Steven Hack - This sig is TOO GODDAMN SHORT TO DO ANYTHING USEFUL WITH! MORONS!
A few years ago, I ran into a couple of FoxPro-based applications and I learned a little about the history of the product.
FoxPro was rather popular with application writers and there are still a lot of small business applications based on it. Apart from the technical merits, it had one big advantage over MS Access: you could bundle FoxPro with your application for free, while Access required an Office license for each PC.
Microsoft bought the company mainly to destroy a competitor. They ended up supporting the product for a long time, probably due to support contracts.
WWTTD?