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

>Peter,
>
>SNIP
>>
>>
>>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.
>
>That document can be changed at any time. I have done so a few times already.
>
>>
>>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 ??
>
>To extend the utility of existing VFP applications.
Thought of this, but can't find the examples (may be important for lateron)
>To extend to longevity of VFP developer skills.
Don't understand; maybe English
>To widen the applicability of VFP as a solution to business problems.
Can't guess how or you mean 2GB (OOPS:) or WAN (see later)
>To significantly improve the security (from corruption) of VFP tables.
Good point (ref. my own on hardware routes)
>. . .all without impairing the ability of VFP developers to adopt all of the alternatives presently available in current and future releases of VFP.
Very true
>
>>
>>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

Jim, you sort of turned around my topics below in negatives opposed to... (yea, what). I just tried to think of possible reasons which I topiced but could answer with No only. Your list above IS a Yes list (hmm, more or less)

>
>- SQL Server isn't faster either, yet it serves its users fine. The item of importance here is that it must not be slow.
>
>>Will it bring over 2GB ? no (wouldn't know why)
>
>- Not as I propose THIS wish. But let's suppose that there is another wish that specifically makes the case for tables bigger than 2gig and that it is so compelling that the MS VFP Team decides to do it. Then this would have it too.
>I simply see this as a separate wish.
>You seem to see that a SQL Server translation feature would intrinsically solve the 2gig problem, and I don't argue with that. The trouble that I have is that it changes the wish to be a SQL translator and that is not what *I* am after. IF the (my) wish is delivered and they happen to do it via SQL translation then I am happy. If they do it some other way then I am still happy.
>I faced the problem of tables over 2gig 6 years ago and splitting the tables horizontally actually turned out to be a good thing. People who need to generally find a solution within the VFP environment and if they can't then they adopt SQL Server (or some other that can).
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 ...
>
>>Will it bring commercial pros ? no (the contrary)
>
>- I don't see it as contrary at all. But since you do, and there are others who have expressed the wish to have an internal SQL Server translator (that is actually what started this whole thing! SET ENGINE TO SQL_SERVER) then I really think that such a wish should be discussed and submitted. I must admit surprise that one hasn't appeared yet.
What I mean by contrary (feeling that expl. was needed) :
I really meet this bigger prospects once in the few months and am very well prepared for the commercial story on why xBase. Well, no matter what, I loose once the other well-educated person (the larger the companies the more chance you meet the well-educated) comes up with Oracle etc., or comes with the "poor guy, we have this as a standard". The chance to meet the big ones is there because of the product : ERP. Now coincidentally I met this coal-trader (180K people only ...) knowing of coal only. So at last I am in luck.
I hope my message is clear (but maybe it is applicable to me only).
>
>>Will it be cheaper ? no (server needs lots of memory now)
>
>- Come on, Peter, RAM is cheap. Drives are cheaper than ever, and very cheap. Even SCSI drives and controllers with RAID 0&1 capability. Processors are faster than ever and very cheap too.
>Sure, it most likely means another configuration and probably some UPS hardware too. But you can be sure that it can be done very nicely for a one-time cost of less than $10,000. (US). Of course you could go over $100,000. too.
You're right Jim; tried to find another topic
>
>>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.
>
>>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 ?
>
>>Will it bring easier install ? no (can't imagine that no OLE-DB or so is needed)
>
>- I don't see a connection with OLEDB. I can only tell you that I envision my wish to be a very simple install indeed, with .INI-type specifications by the developer for all control.
So another new feature ? IMO when MS would like to go for that, wouldn't it be there already ?
Note : I think it is already possible to connect without using the usual ways for it. I don't know where I read that, but it may be worth while to incorporate that in the idea.
>
>>
>>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.
>
>- I believe that the VFP Team can handle these issues. In fact it is possible that this wish could lead to simpler yet more reliable control of concurrent changes, locking, etc.
Don't believe too much and try to reason why I would say. It may help you or all of us. I'm in favor of putting it all in an almost ready form, making the problems left small (downsize a complex to a simple).
>
>>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 ?
>
>I have no idea. You do. I can only suggest that you submit the wish for it. Maybe discuss it here first (as I did (but maybe I was a bit quick on making the wish document)).
I do ? no, I bet. I loose often ...;)
>
>>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 ?
>
>>
>>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.
>
>I believe I understand your proposal as not being simply a SQL translator. I use that as a short-cut name for it. And as I said, if the VFP Team were to implement it that way, I wouldn't care as long as it met my objectives.
>But since you realy really really seem to believe that this approach is essential then I do think that it warrants a wish. I claim ownership of the wish I submitted and I have incorporated a few things that have come up in these discussions. I also clearly rejected others for my wish.
All clear and accepted Jim.
>
>I encourage you to do likewise.
?
>
>Jim (without hard feelings of any kind and hoping for same on your side)
>
>>No offence <s> but then let's work on my app instead of typing in here ... :)