Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
How to answer negative VFP attitude? Help...
Message
 
To
24/10/2000 06:36:29
John Ryan
Captain-Cooker Appreciation Society
Taumata Whakatangi ..., New Zealand
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
00427554
Message ID:
00433402
Views:
20
John:

>>IMHO this is a severely circular argument. People apparently don't like RVs >>because on the "read" side, a RV "might" send an entire SQL command that may >>be pretty big, across the wire. That's assuming you don't use select *.

Here are some things I don't like most about RV's. What you just mentioned is very far down on my list.

(1) Ya can't change the SQL property without first dropping, rebuilding, then adding VIEW back to database. Parameterized Views offer a little help, but doesn't come near the the flexibility of SPT cursors in this regard.

(2) Gotta store connection handle in a database. I pefer the flexibility of SQLSTRINGCONNECT() and ya don't need a DSN on the client.

(3) View designer sucks. Ya can't do complex joins and other weird stuff.

(4) Views can break when underlying table changes.

>>Then on update the same people are willing to send each and every field back- >>hardly an advertisement for efficient use of bandwith and unnecessary extra >>work for the server that has to update every single field even when only one >>has changed.

You don't have to do it that way. When designing my data classes, I felt that any gains to be realized from minimizing your parameter list on an update would be offset by the additional overhead of checking for changes. I could easily add that in if I thought it was worthwhile.

>>What about field-level contentions? Modern (for example) operating theatre >>apps rely on multiple users updating same-row fields every few seconds and >>not overwriting each others' work with stale material.

My data classes have built-in conflict resolution. If someone commits a change while you were editing, your gonna know about it.

Regards,
Charlie



This seems fair- after all, VFP's own execution of macro-substituted SQL is fast+++ once the parsing engine has loaded. SQL just isn't that complicated, if that's all you're doing.

So: at least some effort to determine the "facts" rather than "slogans" is urgently needed IMHO. The "obvious" principle that I was always prepared to accept, that SP is faster, may no longer be so "obvious" in every case- an argument for the "why?" that is supposed to characterise a practical profession. We need to ask it.

As for the "Emperor's clothes"... if the Emperor is naked, or turns out to be wearing only a loin-cloth rather than the sumptuous robe others describe, I claim credit for noticing!

Regards

JR
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform