Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 5 of 5 total |
Sessions staying in ServerSessions... |
Mon, Aug 16 2021 6:51 PM | Permanent Link |
Ian Branch | HI Team,
D10.4.2, latest EDB, 32 bit Apps. I am not sure what is going on here, nor am I sure I can adequately describe it.. As part of the Application's start up, in the project file I have something like.. {code} ... if TLogInForm.Execute('MyAppName', BinToInt('1')) then begin // SplashScreen := TSplashScreen.Create(nil); // try SplashScreen.Show; SplashScreen.Update; Sleep(4000); finally FreeAndNil(SplashScreen); end; // Application.Title := 'MyAppName'; Application.MainFormOnTaskbar := True; Application.CreateForm(TMainForm, MainForm); Application.Run; // end; ... .... {code} This executes the LogInForm before I get to the main application code. In the Login Form is its own EDBEngine, EDBSession, EDBDatabase and EDBTable. All self contained. The form offers a log in dialog and if the user logs in successfully the routine returns True and the main App continues. If the form returns False the App closes. Inside the Log in form the Close contains the following code.. {code} procedure TLogInForm.FormClose(Sender: TObject; var Action: TCloseAction); begin // DBC1.CloseDataSets; // DBC1.Close; DBSLogin.Close; DBE1.Close; // Action := caFree; // end; {code} So, to the issue. It seems the Login Form Sessions are staying in the Server sessions as disconnected, even though, ostensibly, the form's table, database, session & engine have been closed. The Log in sessions hang around until the actual App closes. This happens to all the Apps. Their presence doesn't seem to cause any issues but I would rather they weren't there. Appreciate understanding why this happens and what I may be able to do to eliminate these 'phantom' sessions. Regards & TIA, Ian |
Tue, Aug 17 2021 2:40 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Ian
Different to the way I do it so I'm guessing here. I'd suggest capture the result from your login form as a variable and as soon as the login form has returned explicitly free it. I have had mixed results with caFree so I decided that a lot of the time I'll do it myself. I'd also explicitly (in the logon form's close event) close and free the Elevate components in reverse order (table, queries, database, session, engine) Roy Lambert |
Tue, Aug 17 2021 7:02 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Ian,
<< So, to the issue. It seems the Login Form Sessions are staying in the Server sessions as disconnected, even though, ostensibly, the form's table, database, session & engine have been closed. >> How are you confirming this, through the EDB Manager or through the EDB Server application's interface ? If you can email me an example of this that reproduces the problem, I can take a look and see what's going on. Tim Young Elevate Software www.elevatesoft.com |
Tue, Aug 17 2021 7:10 PM | Permanent Link |
Ian Branch | HI All,
Rest. Stand down. Don't panic. I had a brain wave. The Customer uses ThinFinity by Cybele to give their Customers and their on-line Staff (read CV-19 home bound) access to their Apps/operations. I noticed that all of the lingering sessions were seemingly related this interface. I say seemingly because it is very hard to get this Customer to co-operate with testing like this. So, based on almost all of the lingering sessions being the App login session, I reasoned that something was happening there. I looked at all the App suite various logs, there are many, and determined that there were no actual Application logins related to the lingering login sessions. n.b. Once the user has successfully logged in, the log in session is closed and the Application logs in. Me thinks, Ah Ha! Knowing the nature of the on-line Users there (Fiji), it could be that they are opening the login but not completing the process or it times out (the log in dialog has a time out) being thrown off, or being disconnected due to their poor internet. So, I put in detection of loss of connection, it's actually browser disconnection functionality that ThinFinity has, into the Login form/routine. I already have this functionality built into the actual Apps that are used on-line but hadn't put it into the Log In. Bingo! No hung/lingering sessions since. Sorry for the long tale but I thought you might be interested. Tim, To answer your question on how I was confirming this.. {sql} SELECT runsum(1), * FROM Configuration.ServerSessions Group by ID order by ID {sql} Regards, Ian |
Thu, Aug 19 2021 6:26 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Ian,
<< Me thinks, Ah Ha! Knowing the nature of the on-line Users there (Fiji), it could be that they are opening the login but not completing the process or it times out (the log in dialog has a time out) being thrown off, or being disconnected due to their poor internet. >> Yes, that would result in sessions showing up in the server UI without a remote address first, followed by an (eventual) disconnect and then they would sit there as dead sessions until the EDB Server removed them. Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Friday, May 3, 2024 at 06:06 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |