More on Data Sessions for a Function

Josh, Thanks.

I've been playing and it seems that the following are true:

CLOSE DATABASE will close table in the current session
RELEASING a session will close the tables in that session
DISPLAY STATUS will show you open tables in the current session
DISPLAY OBJECTS will show you sessions (and other objects)

Do I seem to have it correct?

My functions that want private data should simply save the session coming
in, create a new one, release the created session, and then restore the
saved one prior to returning. I don't need to close tables. Releasing the
session does it for me. Correct?

Also, my SET EXCLUSIVE and SET DELETED seem to be preserved across
datasessions created in code as you outlined so they do not need to be coded
again when a new session object is created. Is that correct?

Thanks again.

Jeff
"Josh Assing" <XjoshX@jassing.com> wrote in message
news:cvksj2teihmhvc5kirr1avc3gr197kkuvb@4ax.com...
> >Is there an easy way to do the same thing for a function?
>
> yes.
>
> it's called a (ready?) data session
>
>
> Here's how to do it in code.
>
> lnCurrentSession = SET("datasession")
> loSession=CREATEOBJECT("session")
> SET DATASESSION TO losession.DataSessionId
>
> * do your stuff here
>
> set datasession to lnCurrentSession
>
> * Back to where you were.
>
>
>
> --- AntiSpam/harvest ---
> Remove X's to send email to me.

Dan
Tue Oct 31 10:37:15 CST 2006

You've pretty much got it. But CLOSE DATABASE will close tables in the
*CURRENT DATABASE* in the current session. If you have five databases open,
this is important to know. <s>

There's a help topic that lists all of the SETs that are scoped to the data
session. Most of us have a class that handles SETting and later restoring
those that's instantiated in our own datasession subclasses.

Dan

Jeff Grippe wrote:
> Josh, Thanks.
>
> I've been playing and it seems that the following are true:
>
> CLOSE DATABASE will close table in the current session
> RELEASING a session will close the tables in that session
> DISPLAY STATUS will show you open tables in the current session
> DISPLAY OBJECTS will show you sessions (and other objects)
>
> Do I seem to have it correct?
>
> My functions that want private data should simply save the session
> coming in, create a new one, release the created session, and then
> restore the saved one prior to returning. I don't need to close
> tables. Releasing the session does it for me. Correct?
>
> Also, my SET EXCLUSIVE and SET DELETED seem to be preserved across
> datasessions created in code as you outlined so they do not need to
> be coded again when a new session object is created. Is that correct?
>
> Thanks again.
>
> Jeff
> "Josh Assing" <XjoshX@jassing.com> wrote in message
> news:cvksj2teihmhvc5kirr1avc3gr197kkuvb@4ax.com...
>>> Is there an easy way to do the same thing for a function?
>>
>> yes.
>>
>> it's called a (ready?) data session
>>
>>
>> Here's how to do it in code.
>>
>> lnCurrentSession = SET("datasession")
>> loSession=CREATEOBJECT("session")
>> SET DATASESSION TO losession.DataSessionId
>>
>> * do your stuff here
>>
>> set datasession to lnCurrentSession
>>
>> * Back to where you were.
>>
>>
>>
>> --- AntiSpam/harvest ---
>> Remove X's to send email to me.

Jeff
Tue Oct 31 12:53:00 CST 2006

Thanks Dan,

I feel like I'm confessing something since I have many years of Fox but the
truth is, I don't use the DBC. I've just never gotten comfortable with it. I
realize that I'm missing something but I just haven't been able to make the
leap.

It doesn't help that most of the apps I'm working with have had to be
incrementally converted from FPD 2.6. For years, I had to maintain some
portion of the apps in FPD 2.6 as the VFP re-writes were done. We've been
pure VFP for a long time now so I really have no excuse except that I'm used
to working the way I do.

Anyway thanks for the clarification about CLOSE DATABASE.

Jeff
"Dan Freeman" <spam@microsoft.com> wrote in message
news:%23kQuTrQ$GHA.3344@TK2MSFTNGP03.phx.gbl...
> You've pretty much got it. But CLOSE DATABASE will close tables in the
> *CURRENT DATABASE* in the current session. If you have five databases
> open,
> this is important to know. <s>
>
> There's a help topic that lists all of the SETs that are scoped to the
> data
> session. Most of us have a class that handles SETting and later restoring
> those that's instantiated in our own datasession subclasses.
>
> Dan
>
> Jeff Grippe wrote:
>> Josh, Thanks.
>>
>> I've been playing and it seems that the following are true:
>>
>> CLOSE DATABASE will close table in the current session
>> RELEASING a session will close the tables in that session
>> DISPLAY STATUS will show you open tables in the current session
>> DISPLAY OBJECTS will show you sessions (and other objects)
>>
>> Do I seem to have it correct?
>>
>> My functions that want private data should simply save the session
>> coming in, create a new one, release the created session, and then
>> restore the saved one prior to returning. I don't need to close
>> tables. Releasing the session does it for me. Correct?
>>
>> Also, my SET EXCLUSIVE and SET DELETED seem to be preserved across
>> datasessions created in code as you outlined so they do not need to
>> be coded again when a new session object is created. Is that correct?
>>
>> Thanks again.
>>
>> Jeff
>> "Josh Assing" <XjoshX@jassing.com> wrote in message
>> news:cvksj2teihmhvc5kirr1avc3gr197kkuvb@4ax.com...
>>>> Is there an easy way to do the same thing for a function?
>>>
>>> yes.
>>>
>>> it's called a (ready?) data session
>>>
>>>
>>> Here's how to do it in code.
>>>
>>> lnCurrentSession = SET("datasession")
>>> loSession=CREATEOBJECT("session")
>>> SET DATASESSION TO losession.DataSessionId
>>>
>>> * do your stuff here
>>>
>>> set datasession to lnCurrentSession
>>>
>>> * Back to where you were.
>>>
>>>
>>>
>>> --- AntiSpam/harvest ---
>>> Remove X's to send email to me.
>
>

Gene
Tue Oct 31 14:59:25 CST 2006

"Jeff Grippe" <jgrippe@hilldun.com> wrote:

>Thanks Dan,
>
>I feel like I'm confessing something since I have many years of Fox but the
>truth is, I don't use the DBC. I've just never gotten comfortable with it. I
>realize that I'm missing something but I just haven't been able to make the
>leap.

Likewise. That VFP SQL does not support FKs is where I have been
stopped.

I would love to do it, but it would be a big job to retrofit the
existing app I maintain. Somehow, more immediate things take
priority.

There is still code in some of my basic classes that shows a
fundamental misunderstanding of OOP. I read the documentation, and
either misinterpreted something or it was poorly-written. My code
works, but if only I had the time to rewrite it.

Then, there are the deficiencies in VFP. I would like to see a
control that allows numeric entry right to left, but until the other
things are dealt with, that is lipstick on a pig.

>It doesn't help that most of the apps I'm working with have had to be
>incrementally converted from FPD 2.6. For years, I had to maintain some
>portion of the apps in FPD 2.6 as the VFP re-writes were done. We've been
>pure VFP for a long time now so I really have no excuse except that I'm used
>to working the way I do.

And you have a codebase to maintain.

When I started with VFP, my boss wanted the new version quickly.
Trade-offs were made. <sob, sob>

[snip]

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

Dan
Tue Oct 31 15:33:02 CST 2006

Nothing wrong with that! If you don't need it, don't use it. Just be aware
of the behavior differences should you ever decide to take the plunge. <s>

Dan


Jeff Grippe wrote:
> Thanks Dan,
>
> I feel like I'm confessing something since I have many years of Fox
> but the truth is, I don't use the DBC. I've just never gotten
> comfortable with it. I realize that I'm missing something but I just
> haven't been able to make the leap.
>
> It doesn't help that most of the apps I'm working with have had to be
> incrementally converted from FPD 2.6. For years, I had to maintain
> some portion of the apps in FPD 2.6 as the VFP re-writes were done.
> We've been pure VFP for a long time now so I really have no excuse
> except that I'm used to working the way I do.
>
> Anyway thanks for the clarification about CLOSE DATABASE.
>
> Jeff
> "Dan Freeman" <spam@microsoft.com> wrote in message
> news:%23kQuTrQ$GHA.3344@TK2MSFTNGP03.phx.gbl...
>> You've pretty much got it. But CLOSE DATABASE will close tables in
>> the *CURRENT DATABASE* in the current session. If you have five
>> databases open,
>> this is important to know. <s>
>>
>> There's a help topic that lists all of the SETs that are scoped to
>> the data
>> session. Most of us have a class that handles SETting and later
>> restoring those that's instantiated in our own datasession
>> subclasses.
>>
>> Dan
>>
>> Jeff Grippe wrote:
>>> Josh, Thanks.
>>>
>>> I've been playing and it seems that the following are true:
>>>
>>> CLOSE DATABASE will close table in the current session
>>> RELEASING a session will close the tables in that session
>>> DISPLAY STATUS will show you open tables in the current session
>>> DISPLAY OBJECTS will show you sessions (and other objects)
>>>
>>> Do I seem to have it correct?
>>>
>>> My functions that want private data should simply save the session
>>> coming in, create a new one, release the created session, and then
>>> restore the saved one prior to returning. I don't need to close
>>> tables. Releasing the session does it for me. Correct?
>>>
>>> Also, my SET EXCLUSIVE and SET DELETED seem to be preserved across
>>> datasessions created in code as you outlined so they do not need to
>>> be coded again when a new session object is created. Is that
>>> correct?
>>>
>>> Thanks again.
>>>
>>> Jeff
>>> "Josh Assing" <XjoshX@jassing.com> wrote in message
>>> news:cvksj2teihmhvc5kirr1avc3gr197kkuvb@4ax.com...
>>>>> Is there an easy way to do the same thing for a function?
>>>>
>>>> yes.
>>>>
>>>> it's called a (ready?) data session
>>>>
>>>>
>>>> Here's how to do it in code.
>>>>
>>>> lnCurrentSession = SET("datasession")
>>>> loSession=CREATEOBJECT("session")
>>>> SET DATASESSION TO losession.DataSessionId
>>>>
>>>> * do your stuff here
>>>>
>>>> set datasession to lnCurrentSession
>>>>
>>>> * Back to where you were.
>>>>
>>>>
>>>>
>>>> --- AntiSpam/harvest ---
>>>> Remove X's to send email to me.

Jeff
Wed Nov 01 13:54:28 CST 2006

It isn't that I don't need it. I haven't taken the time to really understand
it. I'm actually somewhat convinced that there are features that I'm not
using that would make my life easier. But like everyone else, there's far
less time to explore the unknown.

"Dan Freeman" <spam@microsoft.com> wrote in message
news:%23cwAmQT$GHA.4376@TK2MSFTNGP03.phx.gbl...
> Nothing wrong with that! If you don't need it, don't use it. Just be aware
> of the behavior differences should you ever decide to take the plunge. <s>
>
> Dan
>
>
> Jeff Grippe wrote:
>> Thanks Dan,
>>
>> I feel like I'm confessing something since I have many years of Fox
>> but the truth is, I don't use the DBC. I've just never gotten
>> comfortable with it. I realize that I'm missing something but I just
>> haven't been able to make the leap.
>>
>> It doesn't help that most of the apps I'm working with have had to be
>> incrementally converted from FPD 2.6. For years, I had to maintain
>> some portion of the apps in FPD 2.6 as the VFP re-writes were done.
>> We've been pure VFP for a long time now so I really have no excuse
>> except that I'm used to working the way I do.
>>
>> Anyway thanks for the clarification about CLOSE DATABASE.
>>
>> Jeff
>> "Dan Freeman" <spam@microsoft.com> wrote in message
>> news:%23kQuTrQ$GHA.3344@TK2MSFTNGP03.phx.gbl...
>>> You've pretty much got it. But CLOSE DATABASE will close tables in
>>> the *CURRENT DATABASE* in the current session. If you have five
>>> databases open,
>>> this is important to know. <s>
>>>
>>> There's a help topic that lists all of the SETs that are scoped to
>>> the data
>>> session. Most of us have a class that handles SETting and later
>>> restoring those that's instantiated in our own datasession
>>> subclasses.
>>>
>>> Dan
>>>
>>> Jeff Grippe wrote:
>>>> Josh, Thanks.
>>>>
>>>> I've been playing and it seems that the following are true:
>>>>
>>>> CLOSE DATABASE will close table in the current session
>>>> RELEASING a session will close the tables in that session
>>>> DISPLAY STATUS will show you open tables in the current session
>>>> DISPLAY OBJECTS will show you sessions (and other objects)
>>>>
>>>> Do I seem to have it correct?
>>>>
>>>> My functions that want private data should simply save the session
>>>> coming in, create a new one, release the created session, and then
>>>> restore the saved one prior to returning. I don't need to close
>>>> tables. Releasing the session does it for me. Correct?
>>>>
>>>> Also, my SET EXCLUSIVE and SET DELETED seem to be preserved across
>>>> datasessions created in code as you outlined so they do not need to
>>>> be coded again when a new session object is created. Is that
>>>> correct?
>>>>
>>>> Thanks again.
>>>>
>>>> Jeff
>>>> "Josh Assing" <XjoshX@jassing.com> wrote in message
>>>> news:cvksj2teihmhvc5kirr1avc3gr197kkuvb@4ax.com...
>>>>>> Is there an easy way to do the same thing for a function?
>>>>>
>>>>> yes.
>>>>>
>>>>> it's called a (ready?) data session
>>>>>
>>>>>
>>>>> Here's how to do it in code.
>>>>>
>>>>> lnCurrentSession = SET("datasession")
>>>>> loSession=CREATEOBJECT("session")
>>>>> SET DATASESSION TO losession.DataSessionId
>>>>>
>>>>> * do your stuff here
>>>>>
>>>>> set datasession to lnCurrentSession
>>>>>
>>>>> * Back to where you were.
>>>>>
>>>>>
>>>>>
>>>>> --- AntiSpam/harvest ---
>>>>> Remove X's to send email to me.
>
>