Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
DataSession troubles.
Message
De
31/12/2000 11:02:22
Dragan Nedeljkovich (En ligne)
Now officially retired
Zrenjanin, Serbia
 
 
À
29/12/2000 20:59:50
Charlie Schreiner
Myers and Stauffer Consulting
Topeka, Kansas, États-Unis
Information générale
Forum:
Visual FoxPro
Catégorie:
Codage, syntaxe et commandes
Divers
Thread ID:
00457954
Message ID:
00458189
Vues:
19
>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.
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform