The ability of foxpro 2.6 for windows to perform coss tabulastion

#The ability of foxpro 2.6 for windows to perform coss tabulastion mod
#The ability of foxpro 2.6 for windows to perform coss tabulastion code

It was also easy to generate tables programatically. Think of it as Design Patterns where you can easily query, search, and print the patterns rather than dig thru linear code.

#The ability of foxpro 2.6 for windows to perform coss tabulastion code

I used to do all kinds of table-oriented stuff in XBase, like store programming code or expressions in the tables. (However, index dictionaries were never standardized across dialects.) Newer dialects of XBase incorporated SQL to allow one to use whichever is best for a task. Sometimes cursoring around is easier than bulk, declaritive queries that SQL gives you. Xbase allows a more incrimental, integrated approach.ДЄnd unlike SQL, it easily allows one to do cursor-oriented manipulation and see intermediate results. In MS-Access the language world and mouse world are too distinct. Unlike MS-Access, there was an easy path to ad-hoc manipulations and script writing. You can tell it was invented by people who had to deal with data and tables all day long. Just my thoughts anywayДЇoxPro? Who still uses FoxPro?! What ancient MS product is next?.ДЄlthough they never got their GUI conventions right, the XBase language was outstanding for ad-hoc and small-scale data chomping.

#The ability of foxpro 2.6 for windows to perform coss tabulastion mod

Please don't be to harsh when you mod me for this speculation: What if Microsoft open sources this product with a different goal in mind? For instance, maybe M$ is curious to see what new ideas become of their abandonware? Perhaps, the community might give it a new lease on life and re-develop a market for it? Should that happen M$ could close the source again, if the license is not GPL, LGPL, or BSD. But much beyond that, Microsoft is open sourcing FoxPro because there is little or no threat posed as the technology is, as the tag line points out, abandonware. I could see FoxPro being adapted as an LDAP backend or a configuration backend. If the license is GPL or BSD, it could find a new lease on life in UNIX, FreeBSD, and Linux. I am not terribly familiar with FoxPro but I would wager, in its present inception, that it does not scale nearly as well as SQL.

FoxPro was fantastic in its hay day but it is a bygone technology. Unfortunately, I would have to say Microsoft's actions are largely irrelevant. It's simply not fast by any imaginable standard other than the trivial case of small files on a single user's drive. 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. Reports altered to query PostgreSQL instead of FP typically see speedups of several hundred times, multiple users can run the same reports simultaneously, and you can actually run the reports over a slow link since only the query and resultsets have to traverse the network instead of the whole table. This takes about 25 minutes, and we run it hourly - and it's still worth the pain.

Let me put it this way: I wrote a program to export our FP tables to tab-delimited text files and then import those into PostgreSQL. My company has about 40 people using the same legacy FP database from a RAID 1+0 system over gigabit ethernet, and it's still hundreds of times slower than running similar queries via SQL to any 'real' database. 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. FP supports multi-user access by putting the data files on a network drive. It may be quick for the common case of a small table (10K lines) on a local drive, but move outside that and it's horrid. I'm curious because I really want to know what made FoxPro the speed demon it's always purported to be.