Peter,

I will comment on only a few points, in-line as usual. . .

>Fair and useful responses Jim.
>If I still may (o yeah, I was the one sneaking out) I interspersed another few (in blue this time (not indicating any feeling ...)) :
>
SNIP
>>To extend the utility of existing VFP applications.
> Thought of this, but can't find the examples (may be important for lateron)
A few short possible examples:
1) A shop with high turnover gets lots of corruptions because staff reboots or powers off randomly, so they are looking for something more "secure". This delivers protection from such events without (virtually) change of any kind.
2) A shop is doing (internally) lots of SQLs that are taking longer and longer, both from sheer size of data involved and heavy network traffic.. Serious improvements with (virtually) no change.
3) A small shop with peer-to-peer is finding things taking longer and longer because of network traffic, lots of locking, much other work going on on PCs, etc. With (virtually) no change they solve the problem and love their VFP app. again.

>>To extend to longevity of VFP developer skills.
>Don't understand; maybe English
There are lots of VFP programmers out there who do not use views or the internet or VFP COM processes. These programmers can keep doing what they are doing yet deploy new applications and in different ways. There are lots of FP programmers out there who can transition easier to VFP if they know that all these other things are not 'mandatory' but can be learned slowly over time as they may identify use cases.

SNIP
>Okay okay, your wish is and remains different. I accept, though :(
>Let me tell you this one (it is somewhere in my credentials) : I have this assignment for running out of the 2GB limit in two weeks or so (sales order line table etc.). So what to do ? horizontally, vertically, diagonally or time-wise <bg> I can't cope with this anyway. The only luck I have is that the customer postponed the live-date of this because of stock-values dropped a little ...

Well yes you *DO* have a problem then, and you surely have my sympathy. I hope that you do find a way to satisfy the customer(s). I didn't check, but I seem to remember that there is a wish document for a bigger than 2gig limit.

>>
SNIP
>>
>>>Will it bring more security ? no (not by itself)
>>
>>- Come on again, Peter. It would take a moron to implement this without making sure that the additional security afforded is not realized.
>Then I don't know what you mean. I think of the other main commercial problem which is the unability to restrict at data-level (so, first key-level (data), then field-level, then field-data, anyway, the usual possibilities). So, when *this* would be possible, yep, that's a real benefit. Only, I won't believe that will be in there (without additional effort) because it will still be xBase.

You are correct here Peter. I don't know if the new DBCEvents offers any possible relief here.
I was referring to better security in terms of less corruption only (which is important, but only a small part of "SECURITY" for sure.

>>
>>>Will it bring additional user-functionality ? no (same SQL-set)
>>
>>- It will bring the possibility of extending VFP applications over a wider area, like WAN applications currently impractical.
>Okay, *very* good point (I think it was said earlier).
>>But how would a SQL translator do this for you if its purpose is to translate VFP commands to SQL Server (or similar)?
>Hmmm, do I understand ? why wouldn't it ? once the app looks like normal SQL coded (remote tables, SQL or not) this facility just is there because the tables are remote. What do I or you miss here ?

Yes, I was very unclear in the position of my statements. I meant that if 'yours' too was simply a question of same capabilities as today but in a SQL-Server compatible translation then I didn't see additional usewr functionality there either.

SNIP

>>>But hey, where is this MS-expert ? is it that hard to give a small response on this ?
>>
>>I have no idea. But we get no responses on wishes ever. And we get no responses on problems submitted through the recommended channel (but *do* get responses on problems submitted here!!!!)
>Small suggestion : address a wish (or question) directly to a member-id ? or would that be too harsh ?

You devil you! (that is a 'saying' used to communicate that you have a "dangerous" or troublesome idea here). I wouldn't know who to address it to, to start. But I would also like the benefit of deep and thoughtful consideration by the whole VFP Team. It sure would be helpful to have some kind of feedback for wishes generally. Particularly through their discussion/development, to help keep things within the realm of the possible. I don't know how to go about making that happen though. Some might say it never will, but I say never say never.
>>
SNIP

Jim