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

The "cynical" came more from the xBase splinter desease I think is stonger than compared to python for example.
They take off into different projects but still let others play.
And even the BDFL is on Google payroll now - they give him payed half time off time to further python. Somehow I doubt this will happen to a vfp BDFL at MS<g>.

OTOH: Christoph is *very* sharp and I have not seen anything from ETEC where I would have thought "gee, why on earth are they doing this ?" - even if some of their actions/time tables are customer driven into schedules I for technical reasons would have structured otherwise, I actually applaud their decision to sometimes leap their own wishes to increase usage spread.

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

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

For non-trivial data input I recommend a C/S HW setup - *might* be vfp if on Citrix or TS, but the risk/cost factor eliminates most of the traditional LAN based apps. Another nice niche is the road warrior scenario: Always connected won't happen in the next 3 years and vfp's comparably small runtime would have fit nicely on PDA's. Too bad MS went elsewhere - there I see a large part of Christoph's niche.

For me, I am scripting vfp on raw datamining tasks - wonderful because of the tight integration and also the ease of OOP to reuse partial statements, build small tasklets - if I would not scatch the 2 Gig more and more. Here I am waiting for Etec to have a funtional SQL Implementation - we code >90% in SQL with a couple Scan's and Lookup-Seeks in between. If Etec is not the solution we are hoping for, we will move to another SQL Implementation - SQL Server or DB2. At that time the integration of vfp is at least partially gone and we might look at python as the language to build the scripts in. Or feel the need to build a java enabled (might be grasshoppered .net) SQL builder layer.
>
>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.

But would coding for such outfits pay enough for bills "not there" ?
>
>But there are circumstances where data storage is not mission-critical,... There really are few limits to the types of applications for which you might want temporary local data storage and processing.

Agree fully. Adobe's AIR employs SqlLite, PHP does now instead of MySQL, Python has the bindings integrated in the 2.5 Distro: the *are* alternatives for local datamunging now, even from MS in the "portable" Server from PDAa. The integration part (a browse on a relation build of 10 tables is set up in a few dozen seconds just to check the results of a few complex SQL statements) is making me productive in my niche, discovering flaws in my assumptions. But for any unsatisfied need there will we growing local script <g>.

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

Here I think the difference is not significant any more: with todays download speeds you send a link and it only takes a few minutes even to download half a CD. For all others MSTSC though 64kb is good enough for testing until the DVD arrives via mail.

regards

thomas