If you are looking for a 'vfp server' that lets you make SQL queries to it, you would get the same results with SQL Server - i.e. you wind up with a result set as a cursor or cursoradapter which you can treat as any other VFP table (especially the cursoradapter).

>The main reason is time, stability and money. We process data (purging, merging, enriching) here in large quantities, all single user. No transactions needed.
>
>We need a dataserver because of security (data stealing) reasons. So far SQL server would be ok. But now come the limitations:
>
>* All code is written in VFP, with lots of SCANS and SET RELATIONS.
>* No one has experience with SQL server, not in maintenance, nor in coding. (I have, but I'm a freelancer)
>
>So to keep everything running without overhauling the whole system and sending the programmers to a SQL-course and appointing someone as SQL-administrator, we need a VFP-server which you can feed VFP-code, and who just applies the code. That is the main difference with SQL server.
>
>In terms of time,money and stability of the firm, I think it is the best solution. Everything here must be fast, flexible and safe. When you get 142678 different formats from your clients, VFP is very flexible in being an intermediate between those client files and big referential internal tables. When you can't afford to rewrite all the code to work with SQL server as a backend, and you do all your work EXCLUSIVE ON, this VFP-server thing is a quick, cheap solution.
>
>The main reason why I answer in such a verbose way, is that I am open to gaps in my reasoning. So if in this particular situation you would have an other opinion, you're welcome. I can learn from that. I am not interested in a general VFP vs SQL war. I know when SQL-server is a good (or even: the best) solution. But if in this particular case I am overlooking something, please tell me.
>
>There is one better solution, I guess: SQL server with a VFP-Etecnologia-front-end. Because their VFP-flavour allows to handle SQL-server-tables as native VFP-files. But that would have to wait until their compiler is in at least RTM-state.
>
>
>>Just to beat a dead horse apparently, if you are considering a database server or something you can request data from, then why not SQL server? It is free for databases of any VFP size (if you have a lot of concurrent connections then you need to spend some $$). It is rock solid, proven technology. It is lightning fast. It is scalable to sizes unimaginable in VFP, and it is easily integrated into most any development platform including VFP. I'd bet you wouldn't have to do much more to integrate SQL server than to integrate any homegrown 'VFP server'.
>>
>>>The company I'm working for might be helped if there was something like a VFP database server written in the VFP language with source code available. I know, I know, it is a contradictio in terminis, but this server would only have to proces sequential requests, no concurrenct ones. The company needs some kind of single-user VFP database server.
>>>
>>>If someone ever tried but dit not finish the product, I would also be very interested.
>>>
>>>If I would read this message, I'd think: why not use SQL Server, or Advantage? The answer is: For the specific problem, circumstances and company that wouldn't work out well. I know MS Sql Server and I know what it can and I know what this company would have to do if it would use SQL server as a backend, and it is no option.
>>>
>>>So... anybody having a hint or link?
>>>
>>>TIA
>>>
>>>Lennert