Hi Mike,

After answering another contributor's comments with "web services might let you do that today" (it was a specific thing) I felt the need to get more info on Web Services. So I printed all of the stuff supplied in the VFP7 documentation and read it this very morning. I like what I read and may well have a good case to use it in a specific application.

While it does tell me the basics of using such a service and creating such a service for use by others, there was very little regarding how it works and the performance implications of such (not that VFP docs should tell me, but I still have to find it).

My guess for now is that Web Services used to perform significant I/O for a stateful form(s) application is not practical. Is this incorrect?

I agree that there's lots of stuff to implement here. But the VFP Team can handle lots of stuff, as they've demonstrated in the past.

I don't want to diminish Web Service's momentum. I have no confidence, though, that Web Services could handle the load and give acceptable performance. I'm talking about existing applications and those to be developed yet in the "traditional" manner.
Meanwhile we have a nice wide population of VFP developers who could continue to exploit VFP for more things, and for longer than might otherwise be possible, with a 'server' like component supporting their established coding practises and product knowledge.

Jim


>>The concept is that this feature would let VFP developers design and code programs virtually exactly like they do today but VFP would, internally, pass the actual command to its 'server', perform all of the required I/O processing in that 'server', and return the resulting data to be made available to the program exactly as if the command had executed within the program.
>
>Why not use Web Services to do this? This is exactly what Web Services and .NET are, why should VFP play its own, completely different game, when Web Services already have alot of momentum?
>
>How would you handle transactions on these servers? How would you handle a transaction accross multiple VFP Servers? There's alot of stuff to implement here. Meanwhile, Web Services has this all figured out.
>
>>My hot-button is data security. The 'server' component(s) could be located in a secure room with UPS power and managed by IT professionals, and since it could be arranged that all updating would actually be done on the 'server' then the incidence of damaged or corrupted tables would virtually disappear.
>
>You could also use OLE-DB or maybe a secure DCOM component... or maybe... Soap and Web Services!