>>Sybase had a booth at the SW Fox (great conference BTW), where they were talking about working on support the foxpro DML, things like seek, scan, recno(), etc. Does this seem to people like it would be doable? It seems to me like it help greatly in the transition to C/S and the maintenance of a code base that talks to both a C/S backend and native foxpro. Any thoughts?
>
>I wonder what they are up to. Are they looking to map VFP commands (SCAN/SEEK/LOCATE/FIND...) to Sybase backend somehow, and if they are, they would need to tweak the VFP binaries, which they really can't (practically or even legally) do. If they are looking to do these things through Sybase specific function calls, that might be interesting, at least in the "academic" sense.
>
>In the meanwhile, and maybe regardless, using VFP remote views against a Sybase backend should accomplish the same thing with no add-ons and no backend-lock-in -worries (once you start down a Sybase -function call route, you are tied to their backend, unless of course you write another itermediate tier of some sort which can talk to Sybase but also to other backends without having to change code all over the place).
>
>To me this seems like a somewhat useless excercise, but I may not grasp fully what they are trying to accomplish here.
>
>IMO your best bet in moving your VFP apps to C/S is to simply start using remote views. It is the most "natural" and backend-independent way of doing things C/S.

I agree there's no way they'd do anything with the VFP executable/runtime. What they might be contemplating is supporting VFP-style table operations that use/require a record/row pointer. These might be accessed through new commands in ODBC/SPT or an OLEDB provider. They'd probably have to do a fair amount of work to make these easy to use e.g. via wrapper classes, or providing an intermediate server tier with some sort of API.

It's my impression that most VFPers these days use VFP's built-in SQL as much as possible. No-one wants to use SCAN etc. where SELECT - SQL will do. I suspect that use of pointer-based DML implies data munging. So, maybe SyBase is looking to support data munging within their server. I can see a few possible advantages:

- data munging when there is a low connection speed between client and server (call it "true client-server munging" :)) The client wouldn't have to pull (and maybe push, too) a lot of data across the slow link to create and process local cursors, the munging would be local to the server

- the SyBase back end might break the 2GB table limit, with or without 64-bit support

- the SyBase back end might support multithreading/SMP and/or clustering

I agree that anyone using something like this would be tied to SyBase, unless they could implement a server tier that can attach to multiple backends. No doubt the product wouldn't be free, and who knows what its market would be ...