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.

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.

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

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?

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.

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.

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?

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.

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.

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.

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.

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.

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.

Remove this comment

Remove this thread

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.