Ken Levy - First look at Visual FoxPro 9 | TheChannel9Team

SarekOfVulcan
If the answer is 42, what's the question?

Neat video, Ken. Just one thing: I created the Slashpane, to view http://slashdot.org in the Taskpane. Michael Henstock modified it to create the MSDN feed, and then Stuart Dunkeld modified the MSDN feed to create the VFP feed you actually demoed.

These and others are listed at http://taskpane.com, for anyone who didn't catch the URL the first time around.

Alexf
AlexF

Great news Ken. As many of us, I am excited about the features of the new product and can't wait for its imminent release!

Alex Feldstein - Miami, FL, USA

Minh
WOOH! WOOH!

Best version since Visual FoxPro 3.0? VFP 3.0 was dog slow, compared to FoxPro for Windows. I didn't know ANYONE who used VFP 3.0 because it was SO different than FP 2.x. I haven't used FP since FPW but I hope it's MUCH MUCH better than VFP 3.0.

rasx
Programmer/Analyst III, Emperor of String.Empty

I guess the C# team does not find it cool to credit or refer to the VFP designers for inspiring the new push toward making .NET languages more data-centric.

The human history behind the technology is more educational than what appears to be inspiration out of thin air.

maxharris

FoxPro does not have support for files larger than 2GB.

I would gladly trade all of the new features from version 6 on for large file support.

Am I the only user that cares about large file support?

I think I've emailed Ken about this, and he said it's too difficult to do, and to use SQL Server instead. (Which doesn't work, because I use FoxPro interactively to manage mailing lists, which differ very widely in layout.)

NeilT

Good job Ken and VFPT - VFP9 is awesome and its great to see it influencing some of the new and future VS/.Net features.

Rossj

maxharris wrote:
FoxPro does not have support for files larger than 2GB.

I know virtually nothing about FoxPro (yet - but I'll be checking it out now) but I heard mention of xbase formats in the video, is it not the header of that format which restricts the size of the file?

maxharris

Yes, but there are obvious approaches to getting around that.

See http://www.clicketyclick.dk/databases/xbase/format/dbf.html#DBF_STRUCT for information about DBF format.

One way is to simply use 8 bytes of data in the header to describe the number of records, stretching the header by four bytes. This would be OK, because the version number would be changed for this format, and old programs (that are written properly) would not try to read it.

If this approach is taken, it would be very wise to also lift the 10-character limit on field names. Padding the new format with extra reserved space would be a good idea.

I imagine that so many users want large file support that they're willing to buy a new copy of FoxPro, and new copies of any programs they use that read/write DBF format. The alternative is the giant, never-ending hassle of chopped-up data files that we have now.

Other ideas aren't so good:

A 'clever' approach would be to hide the extra 4 needed bytes somewhere else in the header. Compatability is hard to ensure here, so it really doesn't help all that much.

Another idea is to produce a standard header, but to pack extended 64-bit specific info into a special field definition. Compatability still breaks, and this one is just as ugly as the last idea.

CindyWinegarden

Hi Max,

Just in case you're not familiar with Val Matison's solution to the large file problem: http://advisor.com/Articles.nsf/aid/MATIV02.