>Hi Al,
>
>while I think I can almost agree totally
>>
>>1. A "compatible" product is created.
>>1a. Commercial product. etecnologia's offerings, and guineu from Christof.
>>
>>1b. Open-source product... BDFL ... there are clearly some "firsts among equals" but I'm not sure the community would be willing or able to appoint a BDFL.
>
>I'ld probably formulate that more cynical.

I thought about this a little, since posting yesterday. A couple of obvious candidates for BDFL would be Calvin Hsia or Ken Levy, but they're both at MS for the forseeable future and are no doubt prevented from helping out any open-source enhancement to the core product. But, I'm wondering what Dr. Dave Fulton is up to these days ... :)

>
>>2. VFP users migrate to other products. ... Sometimes, that isn't VFP in its current form.
>>
>>Finally, as a corollary to 2 above, I'd argue that it actually isn't imperative that the core product evolve. It can be left as a niche product in its current (if possibly shrinking) market, while new projects move on to something else. An interesting, and timely parallel is the current conflict between Microsoft and Mozilla over JavaScript: http://developers.slashdot.org/article.pl?sid=07/11/02/1748244
>
>Here I follow the argument of the corollary, but for me that translates as: I am hard pressed to argue for any new *commercial app* dev in vfp. There are special cases (vfp based shops drawing on their accumulated expirience, enhancements/new modules to existing apps reusing other parts) but even for connecting vfp to other software I now sometimes create a large part of the wrapping in the other language. Much of that might change if either commercial approach of running vfp in .Net was really painless. Simple truth: using Etec's approach I'ld probably code in vfp and if really needed translate the compile back into another language. After 2 or 3 cycles I'ld KNOW what to watch out for and would adapt my writing style. Using cursors as *part* of an array of local data structures instead of the swiss army knife used for hash tables also would feel better<bg>. Breaking the *dependancy* on vfp as the language is accomplished to a greater degree by that approach IMHO, but I'll watch
>Christoph's session in a few days on german DEVCON very carefully<g>.
>
>Also much of my hesitation stems from the non-evolution of the base table layer. When I started with the dBase file format, 2 Gig HD's were SF. During the heydays of FoxPro each part of the table (dbf, cdx, fpt) could be as large as the largest [Fat16, not counting Foxpro for Unix] partition. Then came Fat32: ok, tables could only be half the size of the maximum table size - not really a show stopper. Then I moved to 64-Bit file system in NTFS with NT4 and vfp's table layer (even as intermediate cursor between C/S databases) suddenly morphed into a very gifted half-toy (consciously left half crippled<g>) - you can get real work done with "toys", but for some tasks you are just not fit or have to add at least more effort. Remember arguing that Access might be good enough for a record collection, but even there Foxpro might be better, as nearly the same effort gives you relatively unlimited data sizes ? We switched from having Oktoberfest bier steins for drinking tiny tequila shots to
>drinking tiny sips with tequila tumblers from a very large beer tank.
>
>Disclaimer: I get called sometimes when "normal" vfp cannot continue, so I might have a distorted view of current problems, as I see more special cases. I might be off to a degree, but not in the trend.

etec seems to be specifically addressing the current VFP table size limit, so that might be helpful for you and others in the enterprise space. I like your beer analogy; it's true that FP/VFP offers for free, data handling that used to be expensive and complicated in both hardware and software if done almost any other way. But these days there are low- or no-cost alternatives, some with features native .DBFs/.DBCs can't match.

I think there are still some places where native VFP data handling could make sense. One might be where absolute rock-bottom lowest cost is important, e.g. for widespread use in developing countries. Another might be anywhere ease of deployment/maintenance is paramount, and it would be considered undesirable to require installation of a C/S backend, maintain its logs etc.

Other things to look at could be:

- Mission-critical data vs. non mission-critical
- Small vs. large data, where small fits comfortably in the current VFP 2GB limit and large won't

Most would agree that free C/S backends like SQL Express, MySQL or PostgreSQL offer better security and integrity than native VFP, so if data are mission-critical one of these, or some other non-free commercial product should probably be used.

But there are circumstances where data storage is not mission-critical, and forcing the use of a C/S backend might be unnecessarily resource-intensive or slow; setting up, populating and knocking down temporary tables/cursors/indexes, which may affect DB logs, triggers etc. This is the classic argument for local data munging using products like VFP. There are obvious applications such as off-loading reporting to workstations. Others that may not be as obvious might be spam filtering, real time monitoring of network traffic and firewall/router logs, voice or other digital signal processing etc. There really are few limits to the types of applications for which you might want temporary local data storage and processing.

Yet another category might be prototyping. With VFP and one of the current RAD frameworks you can quickly put together a sample app which will usually easily fit as an e-mail attachment. Send it to a client, point them to ftp.prolib.de/public for the runtime installer and away they go. Although Remote Desktop or NetMeeting approaches are becoming more popular, an actual installation of a sample app lets them play with it after the meeting is over.