Derek,
<<
I'm surprised someone with your experience didn't know about this
<<
Probably not a necesary comment on your part - but... I don't use remote
views and further, I don't use buffers. In apps I write - I make local
changes all the time - and issue sql against that. Because I don't use
buffers - SQL returns the expected results. I expected buffers to operate
the same way.
For the record, I gave Rod a call and he thought SQL would work against the
buffer as well... < s >...
Chock this up to yet another reason why RV's are a bad idea - because you
are forced to have them buffered. As for LV's - since I don't work with
native Fox data - I could care less.
I am not ignorant enough to not admit that I don't know every quirk in Fox.
<<
one of VFP's biggest shortfalls
<<
Well...not so big because you can work around it. VFP has shortfalls that
are a lot bigger than this...
Just so you know - there is a KB article about a bug that exists with
table-buffered data and the fact that seeks using old data can return .T..
IMO, this is a bug since SQL is a way of locating and working with a set of
records. In the example, if I did a locate for - using a new value that is
in the buffer - the locate would succeed. The same is true if you had an
index and seek'd. Given that, a SQL statement IMO - should render the same
results.
The buffered data is my current data-set. It represents the current state of
data on my client - and if I issue a sql statement against that cursor - I
should get back the buffered data - not the original values.
Addressing Anthony Testi's comment on why you would want to issue sql
against a view - in which you have local changes - in this case - the
developer who brought this to my attention wants to affect data in a
buffered view - issue a sql statements to show filtered lists.
The botom line - SQL would make for a more elegant solution. Instead - the
developer has to rely on old XBase constructs. We solved the problem -just
not in a way we would like... The operation has to do with reording a list
of data. The goal was to issue a sql statement with an order by clause. Does
not do much good if you get the original data on disk...< s >
Yes Derek - it is a bummer of sorts - but we worked around it....
<<
-- one =
of VFP's biggest shortfalls-- SQL SELECT commands do not work with =
buffered data! A SQL Select will ALWAYS read from disk. This means if =
you have views, or updateable cursors, you can't use SQL commands to =
read the data from them for any purpose. Bummer, eh?
<<
< JVP >
john.v.petersen .at. comcast D.OT net
©2003 john.v.petersen |
