Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Weird SQL select behaviour
Message
From
10/04/1998 11:50:17
 
General information
Forum:
Visual FoxPro
Category:
Other
Miscellaneous
Thread ID:
00090881
Message ID:
00091086
Views:
23
>I have noticed something weird, and to be honest quite scary:
>
>The following code yielded different results:
>
>
>1.
>select Airinfo
>set order to 1
>if seek(this.cMawb)
>    scatter memo name this.Airinfo
>else
>   error ...
>endif
>
>2.
>select *;
>   from airinfo;
>   where mawb= this:cMawb;
>  into cursor crsM1
>if _tally- 1
>  select crsM1
>  scatter memo name this.Airinfo
>else
>  error ...
>endif
>
>
>
>The first version gave correct results.
>The second version stores the correct record, but a version that dates of before an update that occurs during the same session (meaning no open/close took place between the update and the select).
>The only way I could have the sql select statement yield correct results is when I unlocked the record before the select statement, so that the table get flushed.
>The tables are plain dos compatible DBFs, no DBC. The update is executed with an sql update.
>In between, another station "sees" the updated version.
>
>So I conclude that an sql select does not see unflushed buffers, but seek and all the other stations do ...
>
>Is this weird, or is this weird ...
>
>Marc


Not so much weird as annoying.
This caught me a few weeks ago also. I had to completely rewrite the way I was doing things because I needed the data from the dirty buffer, and I didn't want to commit it yet. I am curious to hear if the behavior is by design and why?
Erik Moore
Clientelligence
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform