Anthony:
Are you saying you never have a need to get small amounts of =
information from a temporary cursor being built? Say you're using a SQL =
Server with an invoice/item type of app. You create an invoice =
item(single-record remote-view, updateable cursor, whatever). You then =
create items for this invoice(another remote view/updateable cursor, =
with numerous items). Now, if you want to issue a select statement such =
as "SELECT SUM(nPrice) FROM rv_Items", you'll get incorrect data. This =
is even worse, when you load an old invoice, add a couple items, and the =
SUM() only sums the old items and not the new. This isn't just a =
problem with table buffering on DBFs, but rather buffering of any sorts =
on cursors.
--=20
Derek
> I do not understand, why is that a shortfall? If the data is=20
> buffered, it
> means that the user/program has not decided if the changes=20
> are 'worthy' of
> being really saved. Why would I want a SQL to return 'not=20
> approved' data?
> Seems like it works exactly as it should, at least in my little world.
> Anthony
>=20
> -----Original Message-----
> From: Derek J. Kalweit [mailto:dkalweit /AT/ sensiblesoftware DOT com]=20
>=20
> I'm surprised someone with your experience didn't know about=20
> this-- one of
> VFP's biggest shortfalls-- SQL SELECT commands do not work=20
> with buffered
> data! A SQL Select will ALWAYS read from disk. This means if=20
> you have views,
> or updateable cursors, you can't use SQL commands to read the=20
> data from them
> for any purpose. Bummer, eh?
>=20
>=20
> --=20
>=20
[excessive quoting removed by server]
©2003 Derek J. Kalweit |
