John, you say:
<<... 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.=20
<<
but previously:
<<...put the data in buffer mode 5<<
I don't understand the contradiction: do you use buffers or doesn't it =
use buffers? =20
If you don't use buffers or doesn't know their operation well, leave =
them in their value default (1, buffer inactive). =20
The sentences SQL will return the values that you wait.
Saludos!
-----Mensaje original-----
De: john.v.petersen [mailto:john.v.petersen /AT/ comcast DOT net]
Enviado el: Jueves, 31 de Julio de 2003 16:11
Para: profox@leafe.com
Asunto: RE: Anomaly with buffered data and sql
Derek,=20
<<
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.=20
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.=20
<<
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..=20
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.=20
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 =3D
of VFP's biggest shortfalls-- SQL SELECT commands do not work with =3D
buffered data! A SQL Select will ALWAYS read from disk. This means if =
=3D
you have views, or updateable cursors, you can't use SQL commands to =3D
read the data from them for any purpose. Bummer, eh?
<<
< JVP >
john.v.petersen /AT/ comcast DOT net
[excessive quoting removed by server]
©2003 FAUX CESAR |
