Scott,

I have run into problems with using SET DATASESSION TO in methods. The problem being a form suddenly loses it's datasession after returning from a App method call.

After spending some time tearing everything apart and searching Universal Thread messages I developed a rule for using SET DATASESSION TO which fixed all my problems. The rule is:

In any method that changes the datasession with SET DATASESSION TO you must first save the current datasession to a holder and set the datasession back to the saved datasession in the SAME METHOD which changed the datasession.

Example:

>********
>********
>LOCAL loReportPreviewForm

*--BDS|WRD
LOCAL lnOldDataSession
lnOldDataSession = SET("DATASESSION")
*--BDS|WRD

>
>wait window 'opentables'
>
>loReportPreviewForm = goApp.GetFormOnTop()
>
>WITH loReportPreviewForm
> SET DATASESSION TO (.DataSessionID)
> WITH .poPrintObject
> SELECT (.pcReportFormCURSOR)
> .PrepareData()
> ENDWITH
>ENDWITH

*--BDS|WRD
SET DATASESSION TO (lnOldDataSession)
*--BDS|WRD

>********
>********

For some reason once you return from a method in another object which changed the datasession without setting it back VFP seams to inconsistently loose track of the datasession.

Bill


>Jeff...
>
> I've followed the steps you've outlined, which were very close to those I'd already tried. I still end up with the "No database is open in the current work area" message. Here's what I'm finding.
>
> I have put the following code in my OpenTables of the DataEnvironment of my report, which *does* use a private data session:
>
>********
>********
>LOCAL loReportPreviewForm
>
>wait window 'opentables'
>
>loReportPreviewForm = goApp.GetFormOnTop()
>
>WITH loReportPreviewForm
> SET DATASESSION TO (.DataSessionID)
> WITH .poPrintObject
> SELECT (.pcReportFormCURSOR)
> .PrepareData()
> ENDWITH
>ENDWITH
>********
>********
>
>The PrepareData method accesses the CURSOR in question, and sets certain flags. It also establishes some global variables used in the report. The strange thing here is that this executes just fine (my WAIT WINDOW tells me it's getting there), and it should blow up on the "SELECT (.pcReportFormCURSOR)" line if there wasn't anything to SELECT. It doesn't blow up (meaning, I assume, it doesn't lose the DataSession) until *after* it's done running whatever methods are used.
>
>I put another WAIT WINDOW in the BeforeOpenTables method, and what's disturbing is that the BeforeOpenTables is run *after* OpenTables. In any event, I still can't get this bad boy to work.
>
>AAAAAAAAAAAAARRRRRRGGGG!!!!
>
>Scott
>
>
>
>>Scott,
>>
>>You are correct with your assumption concerning NOWAIT.
>>
>>With NOWAIT, the OpenTables EventMethod of the report's DataEnvironment fires each time the report redraws (e.g. Zoom). This makes sense because of the fact that with the NOWAIT option, program execution continues after the REPORT FORM blah, blah, blah NOWAIT PREVIEW command.
>>
>>I use the following solution when using NOWAIT:
>>
>>[1] In the report designer, set it to use a Private Data Session.
>>
>>[2] Put the following code in the OpenTables EventMethod of the report's DataEnvironment:
>>
>>LOCAL loActiveForm, lcCursor
>>loActiveForm = whatever
>>lcCursor = whatever
>>
>>SET DATASESSION TO (loActiveForm.DataSessionID)
>>GOTO startpoint IN (lcCursor)
>>
>>Make sure that loActiveForm is referencing the correct form object and not a toolbar - in other words, be careful using _SCREEN.ActiveForm. Also, the record pointer must be repositioned every time the report redraws - even if you are zooming the last page of a 1,000 page report.
>>
>>One real cool benefit to this approach is that you can minimize the report preview, do a requery in loActiveForm, restore the report preview and see a new report (after a redraw, zoom, etc.) without ever closing the preview.
>>
>>Hope this helps.
>>
>>JP
>>
>>
>>>Marty...
>>>
>>> I've tried that, setting the datasession to be the same as the form which called it. I *still* get the same problem. The issue seems to be my use of NOWAIT with the REPORT FORM MyReport PREVIEW: after the report has run, the datasession is somehow being set to the default, instead of the datasession it had when it ran originally.
>>>
>>> I've tried setting the datasession in *every* method that gets called before the report redraws, and it *still* loses the reference. It's something in the guts of the reporting tool itself.
>>>
>>>Scott
>>>
>>>>Are you sure you want the preview form to have a private datasession? Wouldn't you rather set it to 1-Default and allow it to use the datasession that called it?