On 10/19/11 8:52 AM, Rick Schummer wrote: > I am not disagreeing with you Paul, but when people start talking in > absolutes like Stephen's post it is like > fingernails on a chalkboard for me.
I dislike absolute thinking too. > It is my opinion though that code that is getting migrated from VFP tables to > a remote back end can be done more easily > with remote views when minimizing code changes is important. Each migration > is subject to a lot of decisions with > respect to retrofitting data, but in my experience you don't rewrite as much > of it when you put in remote views. Same > commands to work with the data. I used the same commands to work with the data, too. Once you have the data in a local cursor, you can choose whatever vfp commands you want, or go with what the app already used. >I have also used SQL Passthrough in some migrations. Naturally, the >architecture of the > apps is going to make a big difference in the decision. There is no perfect > world. > > I did a lot of testing with respect to performance of the various data access > techniques for a remote data session I > gave a couple of years ago. Craig Berntson had a session at the same German > DevCon on the subject of remote data > performance. Our findings were identical, the performance differences for > common CRUD operations was so close it did not > matter what you picked. At this point it becomes a choice of maintainability, > ease of development, developer tools > available to speed up the pace to market, and what you are most comfortable > using. Yes, I don't think there were ever any indications, for me at least, that sql passthrough would give better performance than remote views. >>> parameterized remote views couldn't be shared among multiple users because >>> of 'view definition has been changed'<< > > Odd, I have never been bit by this and I would say that 90% of my views are > parameterized. Are you referring to > development or production users? It was odd. It bit me in production after a certain number of users were hitting the app for a certain length of time. I remember having a hunch that some kind of locking contention was happening. IIRC VFP had to recompile the view in the DBC each time or something. Anyway what I basically did was reimplement remote views outside of the DBC. I'd execute my own parameterized SQL via SQL Passthrough, then run that through MakeUpdatable, and from then on I could treat that cursor as if it were a local view. Paul _______________________________________________ Post Messages to: ProFox@leafe.com Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/4e9f06b6.2050...@ulmcnett.com ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.