Disconnect DB is not working

kasundha

New Member
Hi all,

I have scheduled an automated process to generate a system report. after the process completed it needs to disconnect the DB connection and close the program. the problem is, the program(Screen) is closing properly but the session in the DB server is still in the active mode and I have to log in to the DB server to disconnect the session.

DISCONNECT abfhero NO-ERROR.

QUIT.

Openedge Version:- 10.2B
Server : Sun (Oracle)

Do you have any idea or experience regarding this kind of situation?
 

RealHeavyDude

Well-Known Member
What proof do you have that the session is still actively connected to the database server?
 

kasundha

New Member
The session is still shown as an active session in PROMON.
 

Patrice Perrot

New Member
Hi
It could be several reasons.
One of them is "a transaction is open"
If you want to know what is the Reason you can modify your source to have the error .
Patrice
Code:
DISCONNECT abfhero NO-ERROR.

   DEF VAR v-c-error AS CHAR  NO-UNDO.
   DEF VAR ixerr     AS INT    NO-UNDO.
   IF ERROR-STATUS:ERROR OR ERROR-STATUS:NUM-MESSAGES > 0 THEN DO :
           v-c-error = "" .
            DO ixerr = 1 TO ERROR-STATUS:NUM-MESSAGES:
                v-c-error = v-c-error + CHR(10) +  String(ERROR-STATUS:GET-NUMBER(ixerr)) + " " + ERROR-STATUS:GET-MESSAGE(ixerr)  .
            END.
            /*MESSAGE or what you want*/
           MESSAGE "DISCONNECT abfhero ERROR : " SKIP
               v-c-error SKIP
               VIEW-AS ALERT-BOX INFO BUTTONS OK.
   END.
QUIT.
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
I have scheduled an automated process to generate a system report. after the process completed it needs to disconnect the DB connection and close the program.
Why does the client "need" to disconnect from the database? If you have described its purpose accurately, it should just end the program and exit after it generates the system report. That doesn't require a DISCONNECT statement.

the problem is, the program(Screen) is closing properly
What "screen"? You said this is an automated process. Does it not run in batch mode?
 

kasundha

New Member
Why does the client "need" to disconnect from the database? If you have described its purpose accurately, it should just end the program and exit after it generates the system report. That doesn't require a DISCONNECT statement.

We have limited user license.

What "screen"? You said this is an automated process. Does it not run in batch mode?

This is the code.

DEFINE NEW GLOBAL SHARED VARIABLE mBNAME AS CHAR.
DEFINE NEW GLOBAL SHARED VARIABLE mSYSDATE AS DATE.
DEFINE NEW GLOBAL SHARED VARIABLE loginname AS CHAR.

DEFINE VARIABLE vConFlag AS LOGICAL NO-UNDO.
SESSION:MULTITASKING-INTERVAL = 100.
DO WHILE NOT (CONNECTED ("gl")
AND CONNECTED ("corpdata")
AND CONNECTED ("cdsysad")
AND CONNECTED ("lessor")
AND CONNECTED ("bd")
AND CONNECTED ("loantrk")
AND CONNECTED ("ople")
AND CONNECTED ("fixdepo")
AND CONNECTED ("reims")):

CONNECT gl -H 192.168.1.2 -S 12440 -N tcp NO-ERROR.
CONNECT corpdata -H 192.168.1.2 -S 12445 -N tcp NO-ERROR.
CONNECT cdsysad -H 192.168.1.2 -S 12446 -N tcp NO-ERROR.
CONNECT lessor -H 192.168.1.2 -S 12448 -N tcp NO-ERROR.
CONNECT bd -H 192.168.1.2 -S 12447 -N tcp NO-ERROR.
CONNECT loantrk -H 192.168.1.2 -S 12441 -N tcp NO-ERROR.
CONNECT ople -H 192.168.1.2 -S 12444 -N tcp NO-ERROR.
CONNECT fixdepo -H 192.168.1.2 -S 12442 -N tcp NO-ERROR.
CONNECT reims -H 192.168.1.2 -S 12443 -N tcp NO-ERROR.

vConFlag = YES.

END.

RUN setpropath("OL,FD,RE,LT,LE,CD,GL").

RUN MIS2-MARKETING.w.


DISCONNECT gl NO-ERROR.
DISCONNECT lessor NO-ERROR.
DISCONNECT corpdata NO-ERROR.
DISCONNECT cdsysad NO-ERROR.
DISCONNECT bd NO-ERROR.
DISCONNECT loantrk NO-ERROR.
DISCONNECT ople NO-ERROR.
DISCONNECT fixdepo NO-ERROR.
DISCONNECT reims NO-ERROR.

QUIT.
 

RealHeavyDude

Well-Known Member
  1. You don't need to disconnect from the databases - on quitting the session they are automatically disconnected gracefully. But, if you really want to use the disconnect and use the no-error option you should check if there were any errors. Otherwise any error encountered will be eaten and you will never know that something went wrong.
  2. If you use the no-error option on the connect statement you should check for any errors instead of looping until all connections are established. If there was any problem the logic will loop endlessly until somehow the problem goes away automagically ...

Please don't get me wrong but this code is NOT good practice. Whenever I see code that, not only, does not handle any errors, but even suppresses them in the way that you do - it hurts my eyes. No matter which programming language or technology - this bad practice.
 

kasundha

New Member
  1. You don't need to disconnect from the databases - on quitting the session they are automatically disconnected gracefully. But, if you really want to use the disconnect and use the no-error option you should check if there were any errors. Otherwise any error encountered will be eaten and you will never know that something went wrong.
  2. If you use the no-error option on the connect statement you should check for any errors instead of looping until all connections are established. If there was any problem the logic will loop endlessly until somehow the problem goes away automagically ...

Please don't get me wrong but this code is NOT good practice. Whenever I see code that, not only, does not handle any errors, but even suppresses them in the way that you do - it hurts my eyes. No matter which programming language or technology - this bad practice.

we have limited user licence and that is why i'm suffering about this issue. these days our network is a little bit slower than other days, is it effects to occur this issue.?
 

Cringer

ProgressTalk.com Moderator
Staff member
Take off the NO-ERROR as has been suggested a number of times. Do you get errors?

The point is, the DISCONNECT is superfluous though. QUIT will disconnect the session also. So if you're seeing the sessions still connected then something else is up.
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
these days our network is a little bit slower than other days, is it effects to occur this issue.?
I doubt it. OpenEdge clients are not very robust in the face of network degradation like packet loss and TCP retransmissions. If a "slow network" was affecting your client in some way that altered its behaviour, I would expect you to see (778) and (735) errors and your client disconnecting from its databases.
 

RealHeavyDude

Well-Known Member
For the record: The number of licenses you have bought is not enforced by an server-side product of Progress in OE10 and OE11, and, I doubt that it is in OE12.
That means that either you are using a workgroup database ( if I remember correctly the maximum value -n is 63 or something like that ) or, if you have an enterprise licences, your broker and remote server parameters are not configured correctly.

Nevertheless - you might be in a situation where the number of users you have licensed is ridiculously low - but that we don't know as you don't reveal much information about your environment.

What I have seen so many times, is, that the -n parameter is set to the number of users that are licensed. But, -n is the number of processes NOT USERS, that can technically connect to a database. It is not violating any license if -n is significantly higher that the number of licensed users - for example if you have, per user, an ABL client session connected to the database and additionally connecting a reporting tool via SQL to the database on behalf of the same user. Additionally you might have batch processing and other stuff running on the server like the database backup.

Hope this helps.
 
Top