In December, 2007, I posted about a bug in VFP 9 that causes a dangling datasession after running a report from form with a private datasession and using report listeners chained together as successors. Microsoft still hasn't fixed the problem, but I now have a workaround for the bug.
First of all ... I have to give credit where credit is due. I didn't come up with the solution. It was given to me by Rick Hawkins ... so thanks Rick!! But now that I have the solution, I want to share it with everyone who follows my blog (all three of you.)
The solution is actually quite simple ... just before you instantiate any report listener object, switch to datasession 1, instantiate the object, then switch back to the previous datasession.
LOCAL lnDataSession, loListener, loListener2
lnDataSession = SET('DataSession')
SET DATASESSION TO 1
loListener = CREATEOBJECT('ReportListener')
loListener.ListenerType = 1
loListener2 = CREATEOBJECT('ReportListener')
loListener.Successor = m.loListener2
SET DATASESSION TO (m.lnDatSession)
REPORT FORM Whatever OBJECT m.loListener
I'd rather Microsoft fix the bug, but I guess a workaround is the next best thing!
Showing posts with label datasession. Show all posts
Showing posts with label datasession. Show all posts
Monday, September 8, 2008
Friday, December 7, 2007
Gotcha: Dangling Datasession Left After Running Report
If you run a report using a ReportListener from the FFC directory, and you're using a successor listener, and that report is run from a form with a private datasession, you end up with a dangling datasession after the report completes. If you keeping running reports in this manner, you keep building up more dangling datasessions. I don't think I have to tell you the consequences of a long day of running reports like this!
I posted this on Microsoft's Connect site so anyone who wants to confirm, vote, comment, etc. about this bug, the ID number is 316134.
Here are the steps to reproduce the problem:
1. Create a form
2. Set the datasession to private
3. Add a button with the following code in the click
lcReport = SYS(2015)
CREATE CURSOR junk (test I)
FOR ln = 1 TO 10
INSERT INTO Junk VALUES (ln)
ENDFOR
CREATE REPORT &lcReport FROM Junk
ThisForm.AddProperty('oListener', null)
SET CLASSLIB TO 'C:\Program Files\Microsoft Visual FoxPro
9\Ffc\_reportlistener'
ThisForm.oListener = CREATEOBJECT('_ReportLIstener')
ThisForm.olistener.listenertype = 1
THisForm.AddProperty('o2', null)
ThisForm.o2 = CREATEOBJECT('ReportListener')
ThisForm.oListener.Successor = ThisForm.o2
REPORT FORM &lcReport OBJECT ThisForm.olistener
4. Run the form
5. Click the button
6. Close the report
7. Close the form
8. Open the data session window
9. Notice an Unknown(#) session.
I posted this on Microsoft's Connect site so anyone who wants to confirm, vote, comment, etc. about this bug, the ID number is 316134.
Here are the steps to reproduce the problem:
1. Create a form
2. Set the datasession to private
3. Add a button with the following code in the click
lcReport = SYS(2015)
CREATE CURSOR junk (test I)
FOR ln = 1 TO 10
INSERT INTO Junk VALUES (ln)
ENDFOR
CREATE REPORT &lcReport FROM Junk
ThisForm.AddProperty('oListener', null)
SET CLASSLIB TO 'C:\Program Files\Microsoft Visual FoxPro
9\Ffc\_reportlistener'
ThisForm.oListener = CREATEOBJECT('_ReportLIstener')
ThisForm.olistener.listenertype = 1
THisForm.AddProperty('o2', null)
ThisForm.o2 = CREATEOBJECT('ReportListener')
ThisForm.oListener.Successor = ThisForm.o2
REPORT FORM &lcReport OBJECT ThisForm.olistener
4. Run the form
5. Click the button
6. Close the report
7. Close the form
8. Open the data session window
9. Notice an Unknown(#) session.
Subscribe to:
Posts (Atom)
