Hi Peter,

First my apologies for answering others while seeming to ignore yours. Those were simple to answer and I needed to think more before answering this. I had a rehearsal last night so couldn't do so until today.
I have interspersed my comments with yours:
SNIP
>>
>>Please offer your comments, criticism, or variations on the following:
>>
>>I would like to see the next version of VFP endowed with 'server-like' processing capabilities for both xBase (oh, how I hate that term) and SQL-based I/O commands...
>
SNIP
>
>Why this would be needed ?
>
>

Old code
>In general, yes, this is sort of nonsense, because it is not hard to incorporate SQL from the beginning (George). I won’t decide for the fastest way of development, but what I can say is that this shoud be subjective to the quality, openness etc. However :
>Where this may be the general standpoint, there are (quite) a few out there, just not having the possibility to re-write all the code, and where the new code will differ in terms of structure (logic). The structure can remain the same, but performance will (highly) degrade.
>Like you started the thread with some expectations of potential respondents, I can add one : it is no argument at all to say that one should use the latest techniques, and therefore this idea would be stupid.

As regards "one should use the latest techniques", again I don't really think so. Nothing wrong with the idea at all, but I just don't think that the whole VFP world is doing so. Many guru say that remote views are crap. I can't find information on performance expectations when deploying Web Services. SQL Server offers much more powerful SQL than does VFP. Now sure, people use these and many more "latest techniques", but I bet that far more do not. Many of the "latest techniques" have their use in that niche called the Fortune 500, but the small/medium business world, comprising a HUGE market where FP (yes) and VFP is used, have much simpler and straightforward requirements. Old code and old logic works very nicely in those areas and will do so for a long time to come.

>
>

2GB Limit
>Maybe I am surprised that this one is treated more or less as a sub-topic, where this is the most serious thread to us all. Well, if we really like to be ‘big’ or ‘more real’. I think Bob Lee said something about that, but somehow we are forgetting that we can’t be more real at all, limiting tables to 2 GB.
>Please note that this won’t be solved if we keep on having VFP-tables (though remotely). See further down the line.
>Also note that any compression idea is a not thought-over idea, because is just will postpone the problem. Further, I am pretty sure that if MS was asked to solve the 2GB problem in this direction, the answer would be ‘impossible’, because right now this problem is there because of the way of logical locking, and which is at record level, e.g. the mapping of that to an explicit other area (offset). I can’t be clearer on this, but when this mapping should be done on a compressed area, MS will give up on this in advance. Too hard.

In my comments about this I said that I would NOT include it in my wish submission. It's not that I don't think this is an important problem, but rather that it "interferes" with the central theme of the wish.
But I would suggest, just to be difficult, that this needn't be "too hard" within a 'server'-type component. Since a 'server' would/could manage such locks all within itself then various techniques could be employed to achieve the goal. Doesn't answer for a "regular" VFP deployment though.

>
>

Data corruption
>IMO this one is treated not seriously enough;
>We all must realize that without a remote DB (VFP or SQL) all the data where our logical selects are upon, is going through an enormeous bunch of hardware, ready to loose bits at any place. No, I am not saying that this is a serious problem, but chances are there, and the real know-it-alls (read : your customer knowing of Oracle etc.) will know this too, and you won’t have an answer on it. So, no assignment.
>Please note that this seems off topic, but it isn’t, at the moment you have this huge amount of older code, being too much to rewrite. Remember, this is my starting point, and the only argument to make Jim’s idea legitimate IMO.
>Another thing in the same area, is that no one out there is going to tell me that VFP’s xBase (sorry) isn’t ready for corruption. Snakes are around everywhere, and though 99 % of these kind of corruptions can be explained (not counting hardware reasons), everyone is struggeling with this, especially the beginner.
>This too, leads to a rephrase of Jim’s proposal into just opposing a remote SQL DB which Jim did not propose because of expected additional techinical problems, which IMO can be overcome (see later).

We agree on this! You have elaborated with detail that I will include in my wish document.

>
>

Transparency
>Native xBase commands are a rather short way to write code, and it will imply good logic as well; Note that once this feature will be there, it may be just the way to go for, instead of having SQL commands in the new app. However, the explicit SQL will be faster (in a lot of occasions). Never mind this for now.
>What IS important, is that we will be forced to have the same DB-commands (so, xBase), which internally may be optimized for the DB-engine applicable (maybe not, see lateron).

I *think* this melds well with my reasoning.

>
>To show how serious I am my self, I would like to pay Microsoft $ 50,000 (US) in order to get this running. And yes, I was this stupid having 5 million lines of ‘old’ code, running into the 2GB problem and running into the customers knowing it better (which sadly is true).
>I too, started this subject about 6 months ago (at FoxWikis), beginning with the question whether a tool exists already doing what Jim wants, knowing pretty sure that it does (for Oracle), but not knowing anymore the how’s and what’s (Randy Rinker).
>
>What do we need ?
>Without wanting to change Jim’s subject, I wouldn’t know why we shouldn’t go for the SQL DBMS (Oracle, SQL-Server, etc. etc.) including remote VFP (xBase).
>In all the thread I missed the technical idea behind it (or any ideas for it), with my conclusion that we all think MS will come with a solution. However, with the lack of these ideas, we created the licency-problem at the same time. My personal ideas (being a bit creative) :
>
>

Program-logic
>The very main problem is how to maintain the program-logic with it’s Do While’s etc., containing the Seek’s and Skip’s; Please note that if these lines are reformatted into SQL commands, responsetimes will be very very bad. So, what in fact will be needed, is changing the logic of these kind of loops into SQL commands, doing all which is performed in the loop. I state this cannot be done at the higher level, e.g. MS won’t be able to handle this.
>
>

The interpreter
>Being a bit creative indeed, I created a design to overcome the problem of the program-logic (see above) by treating the normal tables as cursors. These cursors are to be filled by normal SQL commands, getting active when eof of the cursor is reached.
>Of course I won’t work it all out here, but it is the easiest to see (just a small example !) that all Skip’s will be functions (MySkip(1)) and when eof of the cursor is reached, an SQL command will get the next bunch of pre-defined records (as ususal). The cursor just has the same name as the normal dbf had without this feature, and logic can remain the same AND no serious response penalty will be there.
>Reading this, you already see that we all will be able to do this ourselves, by changing the Skip’s into MySkip’s.
>
>

The licence problem ?
>From the before, of course, can be derived that there is no such thing as a licence-problem for MS, because it will need the SQL-server (etc., okay, too bad for MS but as usual) licences as ever.
>
>

The interpreter revisited
>Where I can do this (knowing that the design for it is complete), MS can do this as well, but better;
>Why couldn’t the compiler (okay Compile command) have an option ‘Create SQL’ ?
>Note that my solution would re-generate all the code with MySkip’s, MySeek’s etc., but that this is not the fastest way (for the interpreter at runtime).
>Note too that in the past I tried to create custom API-commands, leaving me with even worst response in opposite to a normal function call, but that I don’t know about this right today (just didn’t try).
>Anyhow, where the My-functions will contain the necessary SQL commands, these may be optimized for a specific DBMS, but of which I wonder this is the way to go for. I mean, leaving it to MS, we must forget about this, and so general SQL will be used only. And why not. For this matter we may say that it is an emergency solution, though I’m fairly sure it will have many many users.
>
>And yes, one may wonder why MS is needed for this, when I can do it myself, though not with the interpreter-speed they can achieve. I could sell it as a library-kit or so, and anyone needing this can make it available to him/herself.
>For now I would go for the MS-solution, once it is known that it becomes available in due time. A combination might be that I achieve this in advance with the re-generation of code, being a 100 % example of what MS has to do.
>
>So this were my 2c, and the only real thing coming from that, is my being willing to pay MS a certain amount of money for it. Maybe that helps ?

You've given this a lot of thought, Peter, going far deeper into showing that there are ways to accomplish the wish than I did. This is important, I think, in convincing other developers of the viability of the wish. But I do not intend to include these in the wish document, prefering to let the VFP Team come up with the best and most practical design given VFP's existing structure.
You've also given more detail about the real need/value for such a facility as well as the benefits of it.

I really appreciate that. It helps a LOT!

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.

Jim