Ken Levy - First look at Visual FoxPro 9

Download this episode

Download Video


Visual FoxPro 9 is here. Ken Levy chats with us about its development and gives us a demo.



Available formats for this video:

Actual format may change based on video formats available and browser capability.

    The Discussion

    • SarekOf​Vulcan
      Neat video, Ken. Just one thing: I created the Slashpane, to view 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, for anyone who didn't catch the URL the first time around.
    • 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
      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
      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 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.
    • Cindy​Winegarden
      Hi Max,

      Just in case you're not familiar with Val Matison's solution to the large file problem:
    • VBmaniac
      alright enough video's i'm now addicted to Visual FoxPro! Oh and when some of the features come to Visual Studio.NET!!!! Big Smile Big Smile Big Smile
    • ValMatison

      FoxPro is fine as it is without support for files larger than 2 gig. Someone stated that all that would be needed is to change the header and you're basically done. Well, it isn't that simple. VFP would have to change quite a bit to support larger tables. Concurrency issues would have to be looked at; we'd have to get some kind of DBCC for VFP; indexing would have to be reworked as would transaction management.

      So just being able to work with a larer table does not give you much, there's so much more that would be required. Got large files? Use SQL Express or SQL Server. They're ideally suited for that purpose.

    • maxharris
      I don't use indexes, transactions, or concurrent processes on the same table.

      I do use foxpro to interactively manipulate large tables filled with text, though.

      Sometimes I still use foxplus for DOS! The main thing that sucks is the 2GB limit.
    • Taskerr

      Ken - your an unsung hero!

      Its been a long, long time since I worked with Foxpro or was it FoxBase+ back in 1988.

      At the time it was the fastest thing around with version 2.x coming on five 1.44Mb diskettes.

      We won't talk about the Rushmore heist! 

      Given that type of foot print, have you considered re-issuing a cut-down version at a similar size as part of the Express range of products. It would be a cool way to introduce a new generation of programmer/hobbyist to an xbase legacy. 

      I'd like to see some benchmarks that compare Foxpro with other MS database technologies - anybody up for the the challenge?

    • ShadowWulf
      Just for those who are dwelling on the 2 GB limit and aren't familiar with VFP.  The 2 GB support is per table, not per database.  You can have a database with twenty 1+ GB tables.  This is much different from MSDE or SQL Express where the limit is 2 GB and 4 GB per database respectively.

      Depending on the type of system you're writing, you may never reach that limit due to various data separation methods (see the article mentioned by Cindy). And even if you need more, you can still migrate to SQL Server or Oracle, etc., with very little trouble... if you designed your app with that possibility in mind.  Wink
    • maxharris

      But I don't use FoxPro to write applications.

      A typical FoxPro session (for me) looks like this (The commands I use are not predictable, and change as often as the data does.):

      <start FoxPro>
      COUN FOR FRSTNAME <> ' '
      CLOS ALL

      Frequently, I have to send files to other people. Many of these files are very large, which forces me to keep multiple tables lying around:

      TABLE.DBF (2GB)
      TABLE1.DBF (2GB)
      TABLE2.DBF (2GB)
      TABLE3.DBF (312MB)

      On the first three tables, I can't use MODIFY STRU to add a field to them, because they're too large. I have to waste time splitting the table up, giving me:

      TABLEA.DBF (1GB)
      TABLEB.DBF (1GB)
      TABLE1A.DBF (1GB)
      TABLE1B.DBF (1GB)
      TABLE2A.DBF (1GB)
      TABLE2B.DBF (1GB)
      TABLE3.DBF (312MB)

      So now, I have to take the small number of commands I would have just typed once, and run them seven times! And I have to waste even more time compressing the files with a ZIP utility, etc.

      Since I only need to manipulate the files for a day or two (and then they're not on my computer anymore), it makes no sense to try importing to SQL.

      This is a horrible thing, and would be much easier to deal with if FoxPro were fixed!

    • Chanmy8
      Why do you want to send many 2GB table to ppls? Is it possible to get only those required fields/records which new/updated into free table and then only send?

      How do you solve it using SQL server?
    • maxharris
      I need to all the 2GB tables because the list that's stored in the tables would be incomplete if I didn't send them.

      It's not possible to change individual fields/recs for many reasons:

      * the tables don't always exist on the recieving end
      * on many tables, every record is changed significantly
      * some recipients of the tables don't know how to merge records into an existing table
      * others don't want to go through the hassle of merging records in their databases - they just want the changed files

      SQL server can't do this because it's a huge hassle (SLOW) to import DBF files into SQL.
    • SteveC-A9
      Great stuff. 

      But a decent amount of functionality is still missing from the OLEDB driver.  This makes VFP less-than-optimal for reading/writing data from ADO.NET and other platforms. 

      One example is VFP stored procedures cannot return full result sets, they can only return a single value (default boolean).  That hurts.  If the OLEDB driver at least supported CursorToXml(), then the "single string" values could at least be results that could be converted into ADO.NET DataSets easily. 
    • yag
      Actually, in VFP9, we allow you to return result sets from stored procs.

    • SarekOf​Vulcan
      maxharris wrote:

      So now, I have to take the small number of commands I would have just typed once, and run them seven times! And I have to waste even more time compressing the files with a ZIP utility, etc.

      Or, you could write a program that used, for example, ADIR() to get the filenames of those tables, and then use Fox's Macro Substitution to perform the functions on each of those tables without having to type the specific names of the tables over and over.
    • erictn

      Is Fox still limited to 10-character table field names?  They really ought to do something about that.

    • yag
      Actually, that went away around 7 years ago with the database container.

    • SteveC-A9
      If that's the case, then would it be possible for the VFP team to publish an example or two on the official VFP MSDN home?  It would be really nice to show VFP SP's really performing (passing DataSets) with ADO.NET.

    • flerlerp
      Check out Anders ideas about the types of problems C# v3 should solve...

      With a few minor tweaks to VFP v9 it may be a good candidate to replace C# v3 Smiley
    • Fieldpro
      I would also like to agree that the 2GB maximum file size is rapidly becoming a major issue with our company. We have been developing our applications in Foxpro since the days of FoxBase.  However, we are frustrated at time by this significant limitation.
    • Speaking 2x4
      10 character limit is for FREE tables (those tables not part of a database), and 32 characters for tables within a database.  At least with VFP 8.0

      It works, but you have to love a language that says "SYNTAX ERROR" on "CREATE TABLE mytab (field_name c(32) NOT NULL)" and that is as smart as it gets.  It's COBOL for the 1990s!

    Comments closed

    Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation, please create a new thread in our Forums, or Contact Us and let us know.