>What I meant to say is that using remote VIEWS, you can work with SQL Server data with less hassel than the way I saw it demonstrated to me at a SQL Server Class using VB. With VIEWS, your update code, conflict resolution, batch processing, ect., is all taken care of for you using low-level VFP functions. You can bind your controls on the property sheet to the DE and off you go. The way they were teaching it in VB included hard coding SQL Updates and Inserts, hardcoding conflict resolution, binding form controls with code on the fly, ect. It was a ton of code! Although it may be more efficent to do it this way using disconnected data because it is less resource intensive on the client and you are not sustaining locks on the server, but isn't that ture only in a very high transaction environment? They also said that the bound control technique was really only good for prototyping. Now, I haven't heard that said about remote Views, which use bound controls.
>

So your issue is with how they taught the class. Fact is, it sounds like a rather bone-headed approach. There is no place for hardcoding. Rather, logic for updates, inserts, and deletes belongs in stored procedures, not as hard-coded update statements in VB.

The negative impression you have is based on how somebody presented the tool to you, not because of the tool itself. I like to tell people that I can write code as inefficiently as anybody else with VFP. i.e, it is the fiddler, not the fiddle...

>Yes, I also think VFP is more flexible than ADO. With VFP you can subclass the cursor class and the DE to create custom data management classes. That opens a whole world of possiblities. Can you do that with ADO?
>

First off, you can do the same thing with ADO by implementing a set of wrapper classes. Trust me, I know because I probably work with the most powerful set of data management classes that tie ADO and SPT together that exists today. If you want more info on that stuff, I would be happy to discuss that in further detail.

As for flexibility, let me ask you this. How could you pass a VFP cursor to a COM Component? Fact is, you cannot. The flexibility argument pretty much dies right there for me. VFP cursors are flexible in VFP, because that is thier native environment. They should be flexible there. Stray beyond that turf however, and they flat out, don't scale....

>When I said native data access I meant that there were features built into the language for client server development. Your not instantiating a COM object for these services.
>

No, but it is not the best way to engage in C/S development either, at least as far as Remote Views goe. If you rely on SPT and classes that encapsulate those features, you are on sounder ground. However, most folks won't take that leap. It is perceived as being far too complicated. In fact, it is not. It's just when you compare the two, Remote Views look too inviting.

It's kind of like that girl you wanted to date. She looks great. Then, you finally get your chance. And when it happens, you find here to be a real whackadoo and she goes mental. I look at Remote Views in much the same way..<bg>.


>Finally, i know VFP is a file server database and not capable of processing data access tasks in a seperate process. You didn't have to acuse me of such ignorance.
>

Sorry, that was a cheap-shot on my part, and I apoligize!! :)
>Charlie