> IT is kind of a 99% of the time vs. 1% of the time. 99% of=20
> the time I like
> the behavior, 1% I need it to do something that I, and I=20
> guess the designers
> of VFP-SQL think so also, is odd, that is read from 'dirty'=20
> records, it does
> not work like I want it to. That is why I am thinking that=20
> some sort of
> switch could be added to allow for reading of dirty data. I=20
> have a hunch it
> would not be easy to do, having to force the SQL engine to=20
> read buffered data.
If I select from a cursor, it should return what's in the cursor-- plain =
and simple-- just like a scan/endscan does. I don't expect the table of =
that view to return the dirty records-- but the view of that table =
should. This is not weird, whatsoever.
> As the say, write a function, then to your main line code it=20
> will look like one line.
Yeah. Write a function and add another 100ms or more(possibly) to my =
processing. I dunno about you, but CPU cycles are precious with my =
apps-- I have to optimize the hell out of them to get decent performance =
due to VFP's lack of sufficient speed. Not to mention it's not feasable =
to create a broad enough function to process a SQL Select statement of =
any decent complexity and turn it into a scan/endscan...
> Derek, in the apps you are working with it may be a situation=20
> that you cross
> on a daily bases, in my case it is a once in a year or two=20
> problem. Take my
> idea and send it to MS, then both of us will program happily=20
> every after....
I'm fairly certain I've seen this on the UT wishlist and maybe more-- I =
can't recall. It's obvious to me that the majority of the VFP developers =
out here don't care if their tools work properly or not-- my voice isn't =
going to do much on its own...
--=20
Derek
©2003 Derek J. Kalweit |
