Please see my response at the end.

>>... And that is exactly why the approach should be more general (read : just have a SQL-based solution), because THEN the problem will be desappeared by itself and there is just nothing to solve. Okay, unless we wish for xBase tables explicitly at the DB-server.
>
>Well 'my' wish does include xBase tables (and only xBase tables) and I intend to keep it that way. It includes xBase and (VFP) SQL I/O commands.
>I take your "SQL-based solution" to mean SQL Server based. Assuming that this is correct then I leave that for others to submit as a wish. (still didn't see one as of last night).
>
>>Now let's turn things around :
>>
>>I take myself as an example, having commercial problems with Fortune 500 possible customers. They KNOW they have to pay for licences, and have the budget for it in advance. Now MS starts to deal with this wishlist topic, KNOWING that if your wish will be met litterally (xBase tables, noting more for now), Fortune 500 companies won't buy SQL-server for sure. So what should MS do ? all BUT allowing for xBase tables.
>
>Nah, it won't happen like that. Look, there are no doubt many even smaller businesses where they do buy SQL Server just because they like to have the "latest and greatest" and because they fall for all the hype in its advertising. Or they fell for the rumour of VFP being a 'dead product'. But had this happened at a fast enough rate then I bet that MS would truly have shelfed VFP by now.
>But more importantly MS retains 2 products to help to maintain shop loyalty to Win OS, even with the possibility (maybe small now, but who can see the future) of developing a Linux version for VFP (and SQL Server?).
>MS' marketing likely knows the size of the markets involved and there is plenty of room for both for years to come.
>
>>
>>What about that huh ?
>>And okay, of course it is not allowed to respond to this like "yea, but now my selling would be more expensive and hence I'll sell less ...". Agreed ?
>>
>SNIP
>>>I have no problem at all with someone else proposing a similar capability for SQL Server or Oracle or whatever. I limit it to VFP specifically to keep the wish small(?), clear and focused and because I believe that there would be a very big market for a VFP-only feature of this kind.
>>>
>>
>>I am not sure (and not sure what you say);
>>It looks like you're saying that the proposed possibilities (by Bob Lee too) should not be handed to MS in order to have them objective and find the best solution ?
>
>Well keep in mind that VFP Team members have probably read what you and Bob have written. And if they haven't then they have to opportunity any time in the future because I made a direct reference to this thread in the wish content.
>
>My "problem" with 'telling' them ways to solve the problem is that it is done totally in the context of the unknown. It is based solely on how each of us imagines the VFP internals are constructed. We simply don't know. But I guess that it is constructed far differently than any of us surmise.
>Also, remembering that there was once going to be a server version of FP, I am confident that they have their own good ideas as to how to achieve it. Hell, there may even be code in there already toward the objective.
>
>>If that is what you are saying, I don't know whether that is the best idea. Suppose, just suppose they don't come up with these ideas taking (possibly) far less time than any normal way of thinking, the task may be too large to begin with, or, just costs to much without real revenues.
>>IMO it can't harm to feed them with a few brief lines on f.e. changing the "compiler" from native xBase commands to SQL commands (higher level commands where possible). Just to indicate the direction.
>
>I agree that it can't harm. My only point is that I do not want to put these ideas into the actual wish document. The single example that I did include in the document was deliberately very general in nature, to give the VFP Team maximum flexibility in their design and also to give minimum possibility of rejection because some specific thing is 'impossible'.
>But I think that, if nothing else, it would make for very interesting material to discuss this heavily right here in this thread.
>
>>I think we all know this thing is more heavy and of more general interest than a wish for another kind of treeview or whatever; this allows for -IMO- some more lines. With focus of course.
>
>So let's discuss various ways of solving the problem in this thread!
>
>I'll start with yours - to turn all commands against remote tables into SQL commands for the 'server'.
>I think this is oversimplified. More importantly, I think that this eliminates the probable advantage of being able to use much of the existing VFP I/O internals right inside the 'server' component. To me this is a key to making this job much smaller than it appears. As I said earlier, it may even be so that much of the required code is already there. And I doubt that it would be in the form of SQL commands. But if it is, then so be it. I guess we would never know, though < s >.
>In another message of this thread you elaborated on xBase constructs that can slow things down dramatically if a SQL translation is used. I agree, but say that this need not be so using other possibilities. And the construct you use is a very common one. Remember, the objective is to have all old code work just fine, still with very good performance. If rewriting becomes required for different pieces of code then the advantage is seriously diminished.
>I'll agree that your solution would make it much easier for the VFP Team to then adapt the same for a SQL Server interface and/or an Oracle interface, etc.
>But that is not what *I* am after.
>
>Jim


Yeah, well ... I think (!) I'm out of here ...

If you say that you don't intend to put this wish as a wish for SQL-DBMS i.e. no DB-independency, what am I doing in this thread. BTW, I see you writing that the document already has been processed (like you promised on 23-09 or so). Okay.

Just one more thing (for now ?) :
You think that it will be more easy to have the xBase-server on the assumption that there may already be code in there (and you may be right on the latter); Maybe the "more easy" isn't your one argument only, but anyhow you want this. But why ??

Suppose I was given this solution; I perfectly fit the person (company) needing the DB-server with native xBase commands. But it still wouldn't help me because my real purpose -the big customers- are not helped at all, and the existing customers still run out of the 2GB. Let's turn this around :
(please, I don't have the beginning of this thread in mind anymore)

What would I - or anyone gain by the xBase DB-server ?
Will it be faster ? no
Will it bring over 2GB ? no (wouldn't know why)
Will it bring commercial pros ? no (the contrary)
Will it be cheaper ? no (server needs lots of memory now)
Will it bring more security ? no (not by itself)
Will it bring additional user-functionality ? no (same SQL-set)
Will it bring easier install ? no (can't imagine that no OLE-DB or so is needed)

I even can imagine that for MS this will be the hardest thing to do out of all, because it will go against all logic being there right now. Think of locking, cacheing, transactions from both the view of xBase and SQL. Both exist, and what you wish for would be completely new AND probably interfering with the existing stuff.
SQL (DMBS) is SQL, and therefore 100 % existing, via ODBC, OLE-DB or whatever connection method existing, all covered in the client as well. So *my* solution-direction only needs adjustments in the interpreter (runtime) and/or compiler (to create the runtime). This is 1,000 times easier. Bet ?
But hey, where is this MS-expert ? is it that hard to give a small response on this ?

Last one (to be sure on what I originally said) :
I didn't propose to translate native commands 1 to 1 to SQL-commands; that was just my explanation on why there will be a loss on performance when that is done.
My proposal was to put SQL on top of things and to output the according results in cursors, where the further program-logic can remain the same, using native commands as ever, physically (!). This design I have in complete, and this can be worked out by myself within the app (system-level). If my $50,000 offer must be in a different thread, well *I* won't type it again.
No offence <s> but then let's work on my app instead of typing in here ... :)