Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM Client/Server » View Thread |
Messages 1 to 9 of 9 total |
11276 Error |
Fri, Mar 31 2006 2:17 PM | Permanent Link |
"Jim Gallagher" | Hi,
I'm kind of at my wit's end with this problem. I'm using 3.30. I have a program that runs 24/7 and monitors a directory. When a new file appears in the directory it processes it (loads it into MySQL) and at the end posts a status message to a DBISAM table on another machine. This has all worked perfectly in the past. Now, it also works perfectly except when: The program sits for several days without any file appearing in the directory it is monitoring. When that happens I get: # 11276 The connection to the database server at '192.nn.nn.nn' has been lost" I have tried every way I can think of to get this to work, without success. This is the latest version of the code I'm running: UpdateFailed := False; try RemoteSession.Active := True; except on E: Exception do begin UpdateFailed := True; Loggit('Unable to set session to active'); Loggit('Error Message 1: ' + E.Message); end; end; if UpdateFailed = True then begin UpdateFailed := False; try RemoteSession.Active := False; except on E: Exception do begin Loggit('Unable to set session to Inactive'); Loggit('Error Message 2: ' + E.Message); end; end; try RemoteSession.Active := True; except on E: Exception do begin UpdateFailed := True; Loggit('Unable to set session to active2'); Loggit('Error Message: ' + E.Message); end; end; end; try try ViewTable.Open; ViewTable.Insert; // set some values in the row ViewTable.Post; ViewTable.Close; except on E: Exception do begin Loggit('Unable to update view'); Loggit('Error Message: ' + E.Message); UpdateFailed := True; end; end; finally ViewTable.Close; RemoteSession.Active := False; end; if UpdateFailed = True then // try second time begin try RemoteSession.Active := True; except Loggit('Unable to set session to active3'); end; try try ViewTable.Open; ViewTable.Insert; // set some values in the row ViewTable.Post; ViewTable.Close; except on E: Exception do begin Loggit('2nd attempt: ' + E.Message); RemoteSession.Active := False; end; end; finally RemoteSession.Active := False; end; end; try ViewTable.Close; RemoteSession.Active := False; except end; The log messsages I get are these: 2006-03-30 01:29:50.729 PM,"Unable to set session to active" 2006-03-30 01:29:50.729 PM,"Error Message: DBISAM Engine Error # 11276 The connection to the database server at '192.60.27.152' has been lost" 2006-03-30 01:29:51.932 PM,"Unable to set session to active2" 2006-03-30 01:29:51.932 PM,"Error Message: DBISAM Engine Error # 11276 The connection to the database server at '192.60.27.152' has been lost" 2006-03-30 01:29:53.042 PM,"Unable to update view" 2006-03-30 01:29:53.042 PM,"Error Message: DBISAM Engine Error # 11276 The connection to the database server at '192.60.27.152' has been lost" 2006-03-30 01:29:54.120 PM,"Unable to set session to active3" 2006-03-30 01:29:55.432 PM,"2nd attempt: DBISAM Engine Error # 11276 The connection to the database server at '192.60.27.152' has been lost" ViewTable has a DBISAMsession and a DBISAMDatabase with KeepConnection = False (I've tried True with the same results). The session's active property is set to false on program startup, and is only activated in the above code. ViewTable is the only table using the remote session. There are 2 local DBISAM tables (using a different, local, session), which are not causing a problem (they also are only accessed when the program "comes to life" when a file appears in the directory). There have been several changes to my environment - I've moved this program to my laptop with Delphi 6 instead of Delphi 7 (I'm upgrading the program to use DBISAM V4, among other things, on my development machine). I've also upgraded to 3.30 from an older version of DBISAM. I'm not sure about the timing of any of this, since the problem only occurs in unusual circumstances, and only after several days of inactivity. On the version of the program in development using v 4 of DBISAM, I had the same problem, but was able to resolve it (I think) by keeping the connection open and pinging the server using the session parameter to do that). However, the new version will not be going live for at least several months. I don't think this is a network problem because a) it occurs on 3 different client sites. b) Other programs using DBISAM (and communicating with the same server) continue to work correctly from the same machine at the time of the failure. At this point I just want a way to perform a simple update of a DBISAM table - I'd even be happy with an extremely kludgy way to accomplish this. The clients are getting VERY impatient with me, and I don't blame them. -Jim Gallagher |
Fri, Mar 31 2006 3:31 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Jim,
<< I'm kind of at my wit's end with this problem. I'm using 3.30. I have a program that runs 24/7 and monitors a directory. When a new file appears in the directory it processes it (loads it into MySQL) and at the end posts a status message to a DBISAM table on another machine. This has all worked perfectly in the past. Now, it also works perfectly except when: The program sits for several days without any file appearing in the directory it is monitoring. >> Are you making sure that the RemoteSession is actually deactivated properly after this whole procedure exits ? If the RemoteSession is left active, then the database server will remove it after a while and cause all sorts of problems on the client end. Also, remember that simply shutting down the RemoteSession (Active:=False) will not prevent further connection errors because DBISAM may attempt a reconnection again to satisfy some necessary operation during the shutdown of any attached TDBISAM* components. Such a reconnection may cause another 11276 error and prevent the shutdown from completing for the session. This is why the TDBISAMSession.OnRemoteReconnect event was added in version 4.x. I would suggest that, if all else fails, that you enable the TDBISAMSession.RemoteTrace property and then use the OnRemoteTrace event to trace the remote requests/responses. That will tell you exactly what is going on. Also, simply looking at the database server log will be informative because it will tell you whether the session is actually being logged off properly. -- Tim Young Elevate Software www.elevatesoft.com |
Fri, Mar 31 2006 5:12 PM | Permanent Link |
"Jim Gallagher" | Tim Young [Elevate Software] wrote:
> > Are you making sure that the RemoteSession is actually deactivated > properly after this whole procedure exits ? If the RemoteSession is > left active, then the database server will remove it after a while > and cause all sorts of problems on the client end. Yes, the code I listed is the only place in the program that the table is accessed, and the session is closed (twice, now after. However, I don't think that could be the problem anyway. At your suggestion, I looked at the log on the server. I started up my program on 3/27. The DBISAM server log shows that there was no logged access from that IP until 3/28 at 11:16 am. This implies to me that the session was inactive, as it should be - the program was just monitoring the directory for a new file. However, my program's local log shows that on 3/28 at 10:48 (when a file appeared) it got the 11276 error, before it ever showed up on the server's DBISAM log. The access at 11:16 was my manual update of the table, using dbsys. Since the session is inactive on program initialization, and the server isn't showing any access at all from that IP until *after* the 11276 error, this seems to imply that something is happening to the session's ability to make a connection. What is really strange is that if a file kicks off the procedure (where the DBISAM access is happening) soon after the program starts up, the DBISAM update works fine. It's only when the program sits idle for a long time that this error occurs. > I would suggest that, if all else fails, that you enable the > TDBISAMSession.RemoteTrace property and then use the OnRemoteTrace > event to trace the remote requests/responses. That will tell you > exactly what is going on. Also, simply looking at the database > server log will be informative because it will tell you whether the > session is actually being logged off properly. All else has without any doubt failed at this point I'll investigate the RemoteTrace property (never used it), and see what I get. The worst part of this problem is that trying a new solution takes several days (since the error only happens after a long period of inactivity). Thanks, -Jim Gallagher |
Mon, Apr 3 2006 5:50 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Jim,
<< Since the session is inactive on program initialization, and the server isn't showing any access at all from that IP until *after* the 11276 error, this seems to imply that something is happening to the session's ability to make a connection. What is really strange is that if a file kicks off the procedure (where the DBISAM access is happening) soon after the program starts up, the DBISAM update works fine. It's only when the program sits idle for a long time that this error occurs. >> Two things: 1) Is there possibly a difference in the time setting on either computer that would account for the time difference in the database server log and the client log ? 2) Is the client using a firewall of any sort that might be interfering with the connection ? -- Tim Young Elevate Software www.elevatesoft.com |
Mon, Apr 3 2006 12:50 PM | Permanent Link |
"Jim Gallagher" | Tim,
> Two things: > > 1) Is there possibly a difference in the time setting on either > computer that would account for the time difference in the database > server log and the client log ? No, I did check that - the client machine and the server machine are showing the same time. The first entry after program startup was another program that I used to manually update the entry. The failure just happened again over the weekend (on Saturday). There was no logged entry from the IP of the client machine until Monday morning, when I accessed the server (successfully) with a different program. The client machine writes its own log, and shows a 11276 error on Saturday. This much is pretty clear: the DBISAM server is not being accessed at all when the client program is reporting a 11276 error. > 2) Is the client using a firewall of any sort that might be > interfering with the connection ? We supply the machines in a LAN for the client, and we don't install a firewall. Since dbsys is able to make the connection (and we have other client programs which occasionally run on the same machine, and which communicate constantly with the DBISAM server), that seems unlikely to be the problem. The directory scan uses a TTimer to initiate a scan every minute - is there any way that could be interfering? I know that this sounds like a problem in my program somewhere (and it probably is), but it is essentially a simple program in terms of the DBISAM usage. When a file appears, the program just accesses a local DBISAM table, and then the remote DBISAM table for a simple update of one record. The code that I posted is the only DBISAM access in the program that uses the remote session. I still have some clients with programs compiled with DBISAM 3.28 accessing the server (they are working fine). Is it possible that the 3.28 clients could somehow be affecting the ability of this program (which was compiled with 3.30, the same version as the dbsrvr) to connect? Thanks, Jim Gallagher |
Tue, Apr 4 2006 9:52 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Jim,
<< The failure just happened again over the weekend (on Saturday). There was no logged entry from the IP of the client machine until Monday morning, when I accessed the server (successfully) with a different program. The client machine writes its own log, and shows a 11276 error on Saturday. This much is pretty clear: the DBISAM server is not being accessed at all when the client program is reporting a 11276 error. >> The database server should, at the very least, show a connection by the client if the problem is DBISAM-specific and not a general network connection issue. << We supply the machines in a LAN for the client, and we don't install a firewall. Since dbsys is able to make the connection (and we have other client programs which occasionally run on the same machine, and which communicate constantly with the DBISAM server), that seems unlikely to be the problem. The directory scan uses a TTimer to initiate a scan every minute - is there any way that could be interfering? >> I don't see how it could - a TTimer is simply a means of executing code at a certain interval, it really would have no bearing on a network connection. << I still have some clients with programs compiled with DBISAM 3.28 accessing the server (they are working fine). Is it possible that the 3.28 clients could somehow be affecting the ability of this program (which was compiled with 3.30, the same version as the dbsrvr) to connect? >> No. One more question - is this issue specific to a certain machine or machines ? -- Tim Young Elevate Software www.elevatesoft.com |
Tue, Apr 4 2006 4:15 PM | Permanent Link |
"Jim Gallagher" | Tim,
> One more question - is this issue specific to a certain machine or > machines ? It is happening at 2 different client sites. I can't get it to happen in our test environment. I put an open and close of the table in question every few minutes (in the TTimer event), and the problem has apparently gone away (I told you I'd settle for an ugly kludge. THe program will soon be replaced with one using DBISAM 4.x anyway. I'm sure that it is some obscure problem in my code somewhere, or in the network hardware, not a DBISAM issue at all, since I'm using DBISAM extensively in other programs without any problems. Thanks for your help. -Jim |
Wed, Apr 5 2006 2:14 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Jim,
<< It is happening at 2 different client sites. I can't get it to happen in our test environment. >> Hmmm, anything unique about the two sites at all ? << I put an open and close of the table in question every few minutes (in the TTimer event), and the problem has apparently gone away (I told you I'd settle for an ugly kludge. THe program will soon be replaced with one using DBISAM 4.x anyway. >> It definitely is a timeout issue if an occasional open/close solves the problem. The problem is that it will most likely occur with 4.x also if you don't use pinging. If you want to send me your code, I can take a look and see where the problem is. At this point I don't think it's 3.x or DBISAM, but what I can do is simply run it with 4.x without pinging and see what happens. -- Tim Young Elevate Software www.elevatesoft.com |
Wed, Apr 5 2006 4:45 PM | Permanent Link |
"Jim Gallagher" | Tim,
> Jim, > > << It is happening at 2 different client sites. I can't get it to > happen in our test environment. >> > > Hmmm, anything unique about the two sites at all ? > Not that I know of, but there are a *lot* of variables in our different client sites, so it's possible there is something different about just those two. > << I put an open and close of the table in question every few minutes > (in the TTimer event), and the problem has apparently gone away (I > told you I'd settle for an ugly kludge. THe program will soon be > replaced with one using DBISAM 4.x anyway. >> > > It definitely is a timeout issue if an occasional open/close solves > the problem. The problem is that it will most likely occur with 4.x > also if you don't use pinging. If you want to send me your code, I > can take a look and see where the problem is. At this point I don't > think it's 3.x or DBISAM, but what I can do is simply run it with 4.x > without pinging and see what happens. The test version of the program using 4.x has pinging turned on, and I haven't had any problems yet. If it becomes an issue I'll follow up with more questions but I think that everything is OK, for now. The function that is failing is a tiny cog in a large wheel, so I don't want to spend a lot more time on it. As I said, I'm convinced that it's not a DBISAM issue/bug, or I would try to get together a small reproducible example of it. Thanks for your great support, and for your work on DBISAM - I'm anxious to see the next version. -Jim |
This web page was last updated on Saturday, April 27, 2024 at 08:52 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |