Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
DataSession troubles.
Message
From
31/12/2000 11:02:22
Dragan Nedeljkovich (Online)
Now officially retired
Zrenjanin, Serbia
 
 
To
29/12/2000 20:59:50
Charlie Schreiner
Myers and Stauffer Consulting
Topeka, Kansas, United States
General information
Forum:
Visual FoxPro
Category:
Coding, syntax & commands
Miscellaneous
Thread ID:
00457954
Message ID:
00458189
Views:
18
>Hi Doru,
>I don't ever to SET DATASESSION TO because of the disruption of the controlsources in the current form, or maybe 'cause I just don't like it. I do everything IN the session, so I don't have to do switch anything. I have a special session class that I pass other classes and it instantiates them in it. My point is this: If a class is created while in a private session, it just works in that session and is completely unaffected by everything else and doesn't affect anything else. The following isn't that class, but should work for you.

One thing which may be happening is that a .prg called from a form is switching to the default datasession. I'm not sure of this, though I've observed it often while debugging. Still, can't say what would be the rule.

I'd propose using the table again, read only, and closing it afterwards. This should work regardless of datasessions, and shouldn't move the record pointer anywhere. So
lnWa=select()
select 0
use [table to look into] again alias lookat noupdate
if seek(tcKey, 'lookat', 'tagname')
...[build lcName here]...
endif
select (lnWa)
return lcName

back to same old

the first online autobiography, unfinished by design
What, me reckless? I'm full of recks!
Balkans, eh? Count them.
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform