DB will not disconnect after running some r code which creates a PDF file. The PDF is created by some progress application r code so cannot tell what is running, but I would expect any transactions should be covered by my calling procedure. Any ideas on how to force disconnect. The disconnect statement returns false. Any ideas.
The PDF is created by some progress application r code so cannot tell what is running, but I would expect any transactions should be covered by my calling procedure. Any ideas on how to force disconnect.
Most likely cause are by either persistent procedures running, the procedure doing the DISCONNECT statement itself or dynamic buffers still in memory. Try something like this:
DEFINE VARIABLE hProcedure AS HANDLE NO-UNDO.
ASSIGN hProcedure = SESSION:FIRST-PROCEDURE .
DO WHILE VALID-HANDLE (hProcedure):
MESSAGE hProcedure:FILE-NAME SKIP
hProcedure:DB-REFERENCES.
ASSIGN hProcedure = hProcedure:NEXT-SIBLING.
END.
In a similar fashion you can loop thru dynamic buffer objects in memory.
Are you on 10.1 +? Objects (OOP) can cause the same behavior. When a static class references a DB you won't be able to disconnect at all.
The disconnect statement returns false.
How does the DISCONNECT statement return any value?
Thanks Mike,
I was assuming there was a procedure left running which is not allowing the disconnect. I ran through with "PROGRAM-NAME()" but this only tells me the current and calling procedures.
I shall give what you suggest a try and perhaps it will identify what's left running and maybe I can kill off those procedures, if something is left hanging. As I don't know what the program is doing I can only think there is a persisent procedure running and not destroyed.
Progress Version is 101B - no "OO" stuff going on. Basic .p pumping out some HTML with Webspeed.
"The disconnect statement returns false" Sorry led you on the wrong path here.
After the procedure is run which generates the PDF the db is disconnected with " disconnect ".
If we check "If connected () this returns false. There are multiple db's in the mix with same logical name. When the next connect statment is issued on a db with same logical, but varying physical name the command fails with the error physical db names do not match indicating that the previous db has not really disconnected. Hence my problem.
I am not actually at work today so I can't check immediately - thanks for your help.