Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 9 of 9 total
Thread 11276 Error
Fri, Mar 31 2006 2:17 PMPermanent 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 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 PMPermanent 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 Smiley 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 Smiley  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 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 PMPermanent 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 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 PMPermanent 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 kludgeSmiley.  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 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email 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 kludgeSmiley.  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 PMPermanent 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 kludgeSmiley.  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 Smiley 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  
Image