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.
To extend to longevity of VFP developer skills.
To widen the applicability of VFP as a solution to business problems.
To significantly improve the security (from corruption) of VFP tables.
. . .all without impairing the ability of VFP developers to adopt all of the alternatives presently available in current and future releases of VFP.

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

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

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

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

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

>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.
But how would a SQL translator do this for you if its purpose is to translate VFP commands to SQL Server (or similar)?

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

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

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

>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!!!!)

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

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