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."

Umm, no.

[dudeman2]

See first comment in the article by a Microsoftie:

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 .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.
 

Re:Umm, yes

[morgan_greywolf]

Where does it say that in TFA? This is what I see:

Instead of releasing new versions of FoxPro, Microsoft will release core portions of the FoxPro software to its CodePlex community development site, said Alan Griver, a group manager within the Microsoft Visual Studio team, which leads the FoxPro team.

and then, later:

Meanwhile, Microsoft has been working on "Sedna," which is the code name for the project that takes advantage of enhancements in Visual FoxPro 9.0. The primary goal of Sedna is to expand on the ability of Visual FoxPro-based solutions to better integrate with other Microsoft products and technologies, such as Visual Studio 2005, SQL Server 2005 and Windows Vista.

No, it really looks like Microsoft is open-sourcing VFP, or at least its core components.

Re:How's that relate to Jet?

[Volante3192]

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.

Shared Source

[argent]

That was the first question that came to mind for me, too.

The relevant part of the actual announcement on Microsoft's site [microsoft.com] 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 [microsoft.com] is not Open Source.

Re:How's that relate to Jet?

[Volante3192]

Further comments, apparently ESE was meant to succeed the Access JET, but that didn't happen.

http://en.wikipedia.org/wiki/Extensible_Storage_En gine [wikipedia.org]

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.

Re:Umm, still no

[sweatyboatman]

The article is vague and misleading. Alan Griver (who heads Microsoft's VFP team has been talking alot on his blog about it). Here's the straight-dope [msdn.com]...

How about open sourcing the core product too?
We've been asked this for years. That's not going to happen. The main reason is that there is too much intellectual property in the VFP core codebase.

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 .NET is still a long way from offering the kind of streamlined data-oriented programming that Foxpro offers.

2 gig tablesize limit

[Anonymous Coward]

One of Foxpro's biggest limitations is the 2 gig limit...
hopefully the open source community will be quick to address this

Re:Rushmore technology anyone?

[jjacksonRIAB]

It seems like flamebait because this is the second time you posted on how horribly slow it is. To me it seems fairly obvious that Microsoft allowed Foxpro to stagnate because they did not want it to compete with their other offerings - typical buy out the operation, take core technologies, and watch it die slowly hitjob. Every limitation of Foxpro is attributable to such stagnation, nevertheless while it may not be suited for enterprise development, I think it is very well suited for small business use. The problem IMO with foxpro is it is a victim of its own success. It worked very well and was very easy for RAD, but it didn't scale well to enterprise level. As far as money is concerned it maps to the curve of "we're beyond Access but can't yet afford SQL Server" fairly well. If you think Foxpro is bad try working for a company that has enterprise level demands on one stage and a fileserver full to the brim with terabytes of uncompacted Access databases on another. At least with foxpro it would be easier for the people who use Access to step away from editing the data by hand like they think they should be doing. I would not venture to compare Foxpro to something like Oracle or SQL Server, but more to Access - against which it wins quite handily feature-wise, and as far as .NET is concerned I often find Foxpro to be the faster at database access.

Re:Umm, still no

[killjoe]

There is an open source project inspired by VFP but based on python. It's called Dabo http://dabodev.com/ [dabodev.com] . Check it out if you are interested in getting on board with something that isn't obselete.

Re:Rushmore technology anyone?

[nogginthenog]

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.

Re:Rushmore technology anyone?

[sutekh137]

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.

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 .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.

Foxpro has a lot of problems, sure, and I am digging .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.

And one more time: FOXPRO DOESN'T PULL DOWN THE WHOLE INDEX FILE WHEN DOING QUERIES! *phew* *smile*

Re:glad to see foxpro dead

[Master of Transhuman]

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.

Re:glad to see foxpro dead

[ggeens]

Didn't MS just buy FoxPro, to steal the 'jet' engine from it to stick into access?

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.