Hello Tim,

First of all I want to start out saying that I think DBISAM is a great
product, but.....
Lately we have been have quite a few of our sites having numours
problems, both running in file share mode and in client/server mode,
here are a few of the items we are seeing, I will put a partial stack
track here and post the full but reports in the binaries section.

We are using DBISAM 4.25 build

1) Bug Report #1  (this one is VERY common) and yes we have verified
theat Anti-Virus is turned off

exception message : DBISAM Engine Error # 11013 Access denied to table
or backup file 'query (63920)'.

operating system  : Windows 2003 Service Pack 1 build 3790
program up time   : 24 minutes 36 seconds
processors        : 16x Intel(R) Xeon(TM) CPU 3.00GHz
physical memory   : 13417/16382 MB (free/total)

005f6519 +011 exitcare.exe dbisamtb DBISAMError
0055e6b6 +07e exitcare.exe dbisamen TDataEngine.RaiseError
00565423 +0fb exitcare.exe dbisamen TEngineFile.OpenFile
00566c89 +009 exitcare.exe dbisamen TBufferedFile.OpenFile
005a1849 +00d exitcare.exe dbisamen TDataFile.OpenFile
00570c6e +082 exitcare.exe dbisamen TDataTable.OpenTable
0056cee9 +1e9 exitcare.exe dbisamen TDataDirectory.OpenDataTable
00575f13 +0ab exitcare.exe dbisamen TDataCursor.OpenCursor
005c5b4a +c2e exitcare.exe dbisamsq TDataQuery.CreateResultTable
005b4a40 +23c exitcare.exe dbisamsq TDataQuery.PrepareSelectQuery
005b4765 +0a5 exitcare.exe dbisamsq TDataQuery.PrepareQuery
005ad636 +2c6 exitcare.exe dbisamsq TQueryStatement.PrepareStatement
006070a1 +071 exitcare.exe dbisamtb TDBISAMQuery.GetStatementHandle
00607028 +000 exitcare.exe dbisamtb TDBISAMQuery.PrepareSQL
006064d9 +049 exitcare.exe dbisamtb TDBISAMQuery.SetPrepared
006068c4 +0c0 exitcare.exe dbisamtb TDBISAMQuery.GetQueryCursor
006066bd +029 exitcare.exe dbisamtb TDBISAMQuery.CreateCursor
00606728 +010 exitcare.exe dbisamtb TDBISAMQuery.CreateHandle
005fd96c +020 exitcare.exe dbisamtb TDBISAMDataSet.OpenCursor
006012d1 +019 exitcare.exe dbisamtb TDBISAMDBDataSet.OpenCursor
00527c6d +055 exitcare.exe DB TDataSet.SetActive
00527a65 +009 exitcare.exe DB TDataSet.Open


2) Bug Report #2
exception message : The application seems to be frozen.
operating system  : Windows 2003 Service Pack 1 build 3790
program up time   : 3 hours 54 minutes
processors        : 16x Intel(R) Xeon(TM) CPU 3.00GHz
physical memory   : 5746/16382 MB (free/total)

Call stack
7d61cca4 +000 ntdll.dll
7d4d0ebf +047 kernel32.dll          SleepEx
7d4d14ea +00a kernel32.dll          Sleep
0056bdc6 +02e exitcare.exe dbisamen TDataDirectoryLocks.WriteLock
0056ba9f +053 exitcare.exe dbisamen TDataDirectoryLocks.WriteLockFile
0056bc04 +010 exitcare.exe dbisamen TDataDirectoryLocks.AddDataTable
00570e06 +21a exitcare.exe dbisamen TDataTable.OpenTable
0056cee9 +1e9 exitcare.exe dbisamen TDataDirectory.OpenDataTable
00575f13 +0ab exitcare.exe dbisamen TDataCursor.OpenCursor
005abed8 +160 exitcare.exe dbisamsq TSourceTable.Open
005c40bd +035 exitcare.exe dbisamsq TDataQuery.OpenSourceTables
005b483d +039 exitcare.exe dbisamsq TDataQuery.PrepareSelectQuery
005b4765 +0a5 exitcare.exe dbisamsq TDataQuery.PrepareQuery
005ad636 +2c6 exitcare.exe dbisamsq TQueryStatement.PrepareStatement
006070a1 +071 exitcare.exe dbisamtb TDBISAMQuery.GetStatementHandle
00607028 +000 exitcare.exe dbisamtb TDBISAMQuery.PrepareSQL
006064d9 +049 exitcare.exe dbisamtb TDBISAMQuery.SetPrepared
006068c4 +0c0 exitcare.exe dbisamtb TDBISAMQuery.GetQueryCursor
006066bd +029 exitcare.exe dbisamtb TDBISAMQuery.CreateCursor
00606728 +010 exitcare.exe dbisamtb TDBISAMQuery.CreateHandle
005fd96c +020 exitcare.exe dbisamtb TDBISAMDataSet.OpenCursor
006012d1 +019 exitcare.exe dbisamtb TDBISAMDBDataSet.OpenCursor
00527c6d +055 exitcare.exe DB       TDataSet.SetActive
00527a65 +009 exitcare.exe DB       TDataSet.Open


3) Bug Report #3
exception message : The application seems to be frozen.
operating system  : Windows 2003 Service Pack 1 build 3790
program up time   : 4 hours 57 minutes
processors        : 16x Intel(R) Xeon(TM) CPU 3.00GHz
physical memory   : 5248/16382 MB (free/total)

7d61cca4 +000 ntdll.dll
00565038 +024 exitcare.exe dbisamen TEngineFile.LockRegion
0056bddc +044 exitcare.exe dbisamen TDataDirectoryLocks.WriteLock
0056ba9f +053 exitcare.exe dbisamen TDataDirectoryLocks.WriteLockFile
0056bc04 +010 exitcare.exe dbisamen TDataDirectoryLocks.AddDataTable
00570e06 +21a exitcare.exe dbisamen TDataTable.OpenTable
0056cee9 +1e9 exitcare.exe dbisamen TDataDirectory.OpenDataTable
00575f13 +0ab exitcare.exe dbisamen TDataCursor.OpenCursor
005abed8 +160 exitcare.exe dbisamsq TSourceTable.Open
005c40bd +035 exitcare.exe dbisamsq TDataQuery.OpenSourceTables
005b483d +039 exitcare.exe dbisamsq TDataQuery.PrepareSelectQuery
005b4765 +0a5 exitcare.exe dbisamsq TDataQuery.PrepareQuery
005ad636 +2c6 exitcare.exe dbisamsq TQueryStatement.PrepareStatement
006070a1 +071 exitcare.exe dbisamtb TDBISAMQuery.GetStatementHandle
00607028 +000 exitcare.exe dbisamtb TDBISAMQuery.PrepareSQL
006064d9 +049 exitcare.exe dbisamtb TDBISAMQuery.SetPrepared
006068c4 +0c0 exitcare.exe dbisamtb TDBISAMQuery.GetQueryCursor
006066bd +029 exitcare.exe dbisamtb TDBISAMQuery.CreateCursor
00606728 +010 exitcare.exe dbisamtb TDBISAMQuery.CreateHandle
005fd96c +020 exitcare.exe dbisamtb TDBISAMDataSet.OpenCursor
006012d1 +019 exitcare.exe dbisamtb TDBISAMDBDataSet.OpenCursor
00527c6d +055 exitcare.exe DB       TDataSet.SetActive
00527a65 +009 exitcare.exe DB       TDataSet.Open

4) Bug Report #4
exception message : The application seems to be frozen.
operating system  : Windows XP Service Pack 2 build 2600
program up time   : 16 minutes 6 seconds
processor         : Intel(R) Pentium(R) 4 CPU 1.70GHz
physical memory   : 92/191 MB (free/total)

0066d5bf +04b ExitCare6Updater.exe dbisamen TDataEngine.Decrypt
00671907 +083 ExitCare6Updater.exe dbisamen
TBufferedFile.ClearLastBuffer
0067186b +01b ExitCare6Updater.exe dbisamen TBufferedFile.GetNewBuffer
00671c19 +249 ExitCare6Updater.exe dbisamen TBufferedFile.ReadBuffers
006717f4 +150 ExitCare6Updater.exe dbisamen TBufferedFile.GetBuffer
0067ea06 +01a ExitCare6Updater.exe dbisamen TDataTable.GetRecord
00682fcb +027 ExitCare6Updater.exe dbisamen TDataCursor.GetRecord
00695fec +294 ExitCare6Updater.exe dbisamen
TDataCursor.AddSecondaryIndex
006c8e50 +0d4 ExitCare6Updater.exe dbisamsq
TDataQuery.ExecuteCreateIndexQuery
006c33b3 +ca3 ExitCare6Updater.exe dbisamsq TDataQuery.ExecuteQuery
006b9183 +2e3 ExitCare6Updater.exe dbisamsq
TQueryStatement.ExecuteStatement
00711151 +4b9 ExitCare6Updater.exe dbisamtb TDBISAMQuery.GetQueryCursor
00710b51 +029 ExitCare6Updater.exe dbisamtb TDBISAMQuery.CreateCursor
00710bf9 +035 ExitCare6Updater.exe dbisamtb TDBISAMQuery.ExecSQL
00721997 +0df ExitCare6Updater.exe frmMainU 873  +9 TfrmMain.CreateIndex


5) In client/server we are getting a lot of "Re-connection rejected,
session not found" errors, which is weird since we have our session set
to keep alive. We have also increased the timeout on the server to keep
sessions for 6 hours. Even restarting the client does not fix the
problem, the only way to fix the problem is a restart of the server.


6) We also seem to getting a lot of AVs in the server, but I have not
been able to get a copy of one from the clients yet.
--


Thanks for any help
Bern

Bern


The first one has a numeric table name which probably means a temporary table. From other posts the most likely culprit is privileges for the temporary directory.

Looking at the error logs I see a computer name containing CITRIX. Are they running under that?

It might be worth posting the environment(s) for Tim to consider eg wireless networks.

Roy Lambert

Roy Lambert wrote:

> Bern
>
>
> The first one has a numeric table name which probably means a
> temporary table. From other posts the most likely culprit is
> privileges for the temporary directory.
>
> Looking at the error logs I see a computer name containing CITRIX.
> Are they running under that?
>
> It might be worth posting the environment(s) for Tim to consider eg
> wireless networks.
>
> Roy Lambert

I would agree but the problem is this is a random error, as for the
enviroments, I would I could tell you but to be honest I just picked a
few samples from the numorous bug reports we get, so for these I don't
know the enviroments.

Bern

--

Bern,

<< 1) Bug Report #1  (this one is VERY common) and yes we have verified
theat Anti-Virus is turned off >>

It's an AV or other type of active file-scanning issue.  Double-check to
make sure that the AV, etc. software is not scanning the temporary tables
when they are created and opened.

<< 2) Bug Report #2
exception message : The application seems to be frozen. >>

<< 3) Bug Report #3
exception message : The application seems to be frozen. >>

These are very odd errors - DBISAM is not able to get a lock on the lock
file in order to add a table to the lock file.  Are you creating a lot of
named temporary tables that you delete later ?  These errors are occurring
during the opening of the source tables referenced in a query, so they
should have already been added to the lock file a while ago if a) they are
static tables in the database and b) the database has been accessed at least
once.

<< 4) Bug Report #4
exception message : The application seems to be frozen. >>

Did someone kill the application in this instance ?  This bug report simply
appears to be a CREATE INDEX statement that is taking a very long while to
execute because encryption is being used on the table.

<< 5) In client/server we are getting a lot of "Re-connection rejected,
session not found" errors, which is weird since we have our session set to
keep alive. >>

Is this compiled into the application this way, or is it configurable ?  If
you want to send me a server log, I can look at it to see what I can find
out.

<< We have also increased the timeout on the server to keep sessions for 6
hours. Even restarting the client does not fix the problem, the only way to
fix the problem is a restart of the server. >>

So, you're saying that a restart of the database server corrects the dropped
connections issue ?

<< 6) We also seem to getting a lot of AVs in the server, but I have not
been able to get a copy of one from the clients yet. >>

Are any of the client applications multi-threaded ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> Bern,
>
> << 1) Bug Report #1  (this one is VERY common) and yes we have
> verified theat Anti-Virus is turned off >>
>
> It's an AV or other type of active file-scanning issue.  Double-check
> to make sure that the AV, etc. software is not scanning the temporary
> tables when they are created and opened.

   We have verified that AV etc is not running, this has even happen on
clean systems with only the OS and the APP installed.
>
> << 2) Bug Report #2
> exception message : The application seems to be frozen. >>
>
> << 3) Bug Report #3
> exception message : The application seems to be frozen. >>
>
> These are very odd errors - DBISAM is not able to get a lock on the
> lock file in order to add a table to the lock file.  Are you creating
> a lot of named temporary tables that you delete later ?  These errors
> are occurring during the opening of the source tables referenced in a
> query, so they should have already been added to the lock file a
> while ago if a) they are static tables in the database and b) the
> database has been accessed at least once.

I am not creating any temp tables, I let DBISAM handle all that. These
errors are random.
>
> << 4) Bug Report #4
> exception message : The application seems to be frozen. >>
>
> Did someone kill the application in this instance ?  This bug report
> simply appears to be a CREATE INDEX statement that is taking a very
> long while to execute because encryption is being used on the table.

   I will have to check.
>
> << 5) In client/server we are getting a lot of "Re-connection
> rejected, session not found" errors, which is weird since we have our
> session set to keep alive. >>
>
> Is this compiled into the application this way, or is it configurable
> ?  If you want to send me a server log, I can look at it to see what
> I can find out.

   It is compiled into the applicaiton. I have posted a log file in
..binaries called "Log fie for Tim"
>
> << We have also increased the timeout on the server to keep sessions
> for 6 hours. Even restarting the client does not fix the problem, the
> only way to fix the problem is a restart of the server. >>
>
> So, you're saying that a restart of the database server corrects the
> dropped connections issue ?

   Yes

>
> << 6) We also seem to getting a lot of AVs in the server, but I have
> not been able to get a copy of one from the clients yet. >>
>
> Are any of the client applications multi-threaded ?

Yes the appliation has 4 threads that load data when it first starts
up, and each uses its own session. All I create all my sessions,
tables, query elements on the fly in code.



--

Bern,

> exception message : The application seems to be frozen.

I experienced the same behaviour using Eurekalog. When I disabled the
possibility to register situations when application does not interact with
display for time longer than xy minutes (it is assumed 'frozen' - this is
normal situation with long queries) the problem was solved.

Iztok Lajovic

Bern,

<< We have verified that AV etc is not running, this has even happen on
clean systems with only the OS and the APP installed. >>

Then the only other thing it could be is that the user account that the
database server process is running under doesn't have the proper rights to
create tables in the temporary tables directory setting on the server.

I think someone else may have the "app is frozen" angle covered already.

<< It is compiled into the applicaiton. I have posted a log file in
..binaries called "Log fie for Tim" >>

The log indicates that you just started the database server, hence the
reason for the "session not found" warnings is because the sessions were all
removed when the database server was shut down and then restarted.

<< Yes the appliation has 4 threads that load data when it first starts up,
and each uses its own session. All I create all my sessions, tables, query
elements on the fly in code. >>

Have I seen this code yet ?  If not, if you could send it to me I can verify
that everything is in order.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> Bern,
>
> << We have verified that AV etc is not running, this has even happen
> on clean systems with only the OS and the APP installed. >>
>
> Then the only other thing it could be is that the user account that
> the database server process is running under doesn't have the proper
> rights to create tables in the temporary tables directory setting on
> the server.

This I don't understand because it is a random error that is happening,
sometimes the program can be running for hours and then they will start
getting this, or it could be after a few seconds. Same User, Same
Machine, Same Login. I have reported this before but lately we are
getting more and more users having this problem.


>
> I think someone else may have the "app is frozen" angle covered
> already.

   This may be, I will disable the frozen application check in my code.

>
> << It is compiled into the applicaiton. I have posted a log file in
> .binaries called "Log fie for Tim" >>
>
> The log indicates that you just started the database server, hence
> the reason for the "session not found" warnings is because the
> sessions were all removed when the database server was shut down and
> then restarted.

That may make sense, Is there a better way to handle this? I would
assume something in a try except that check for the error and
reestablish connection to the server
>
> << Yes the appliation has 4 threads that load data when it first
> starts up, and each uses its own session. All I create all my
> sessions, tables, query elements on the fly in code. >>
>
> Have I seen this code yet ?  If not, if you could send it to me I can
> verify that everything is in order.

A little background on our app may help.
We have a set of tables on the server (either peer-2-peer or
Client/server) and a duplicated set on the local systems. When our
application starts up it compares the two sets of tables and pulls down
any changes to the local system. Our app then only reads data from the
local system (this is done for speed, limit network bandwidth, and so
our app will be avail offline if the server goes down) and all writes
are done to the server (never to the local system)

here are the procedures that create the session, query, or table

 TUseSessionTypes = (usLocal, usServer);

function TDM.CreateSession(var sesTempSession: Tdbisamsession;
WhichSession: TUseSessionTypes = usLocal; ForThread: boolean = False):
string;


var
 strGUID: string;
begin
 if ForThread then
   EnterCriticalSection(SessionNameSection);
 try
   if ForThread then
     begin
       sesTempSession := tdbisamsession.Create(nil);
       strGUID := GetGUID;
       strGUID := StringReplace(strGUID, '{', '', [rfReplaceAll,
rfIgnoreCase]);
       strGUID := StringReplace(strGUID, '}', '', [rfReplaceAll,
rfIgnoreCase]);
       strGUID := StringReplace(strGUID, '-', '', [rfReplaceAll,
rfIgnoreCase]);

       with sesTempSession do
         begin
           Name := 'ses' + strGUID;
           SessionName := Name;
           case WhichSession of
             usLocal:
               begin
                 LockProtocol := LocalSession.LockProtocol;
                 RemotePassword := LocalSession.RemotePassword;
                 RemotePing := LocalSession.RemotePing;
                 RemoteUser := LocalSession.RemoteUser;
                 RemoteEncryptionPassword :=
LocalSession.RemoteEncryptionPassword;
                 OnPassword := LocalSession.OnPassword;
                 PrivateDir := LocalSession.PrivateDir;
                 SessionType := LocalSession.SessionType;
                 RemoteHost := LocalSession.RemoteHost;
                 //                  RemoteAddress :=
LocalSession.RemoteAddress;
               end;
             usServer:
               begin
                 LockProtocol := ServerSession.LockProtocol;
                 RemotePassword := ServerSession.RemotePassword;
                 RemotePing := ServerSession.RemotePing;
                 RemoteUser := ServerSession.RemoteUser;
                 RemoteEncryptionPassword :=
ServerSession.RemoteEncryptionPassword;
                 OnPassword := ServerSession.OnPassword;
                 PrivateDir := ServerSession.PrivateDir;
                 SessionType := ServerSession.SessionType;
                 RemoteHost := ServerSession.RemoteHost;
                 //                  RemoteAddress :=
ServerSession.RemoteAddress;
               end;
           end;
         end;
     end
   else
     begin
       MessageBox(0, 'Error ExitCare is trying to create an invalid
session to the database server.' + #13 + #10 + 'Please contact ExitCare
support.', 'Database error.', MB_ICONSTOP or MB_OK);
       global.ExitCareEnd;
     end;

 finally
   if ForThread then
     LeaveCriticalSection(SessionNameSection);
 end;
end;

=====================================================

procedure TDM.CreateQuery(var Query: TDBISAMQuery; sesTempSession:
TDBISAMSession; UseServer: boolean = False; blnReadOnly: boolean =
True);
begin
 itdProgressPos := 0;
 Query := tdbisamquery.Create(self);
 Query.Sessionname := sesTempSession.sessionName;
 query.OnQueryProgress := QueryProgress;
 query.RequestLive := True;
 if UseServer then
   begin
     case global.ECData.ConnectionType of
       1: query.DatabaseName := global.ECData.LocalDatabaseLocation;
//Local
       2: query.databaseName := 'ExitCare'; // Client/Server
       3: query.DatabaseName := global.ECData.ServerDatabaseLocation;
// Peer to Peer
       4: query.DatabaseName := global.ECData.LocalDatabaseLocation;
// Direct From Server
       5: query.databaseName := 'ExitCare'; // Internet
     end;
   end
 else
   begin
     query.DatabaseName := global.ECData.LocalDatabaseLocation;
     query.ReadOnly := blnReadOnly;
   end;
end;

=================================

procedure TDM.CreateTable(var Table: TDBISAMTable; sesTempSession:
tdbisamsession; UseServer:
 Boolean = False; blnReadOnly: boolean = True);
begin
 table := tdbisamtable.Create(nil);
 table.SessionName := sesTempSession.sessionname;

 if UseServer then
   begin
     //      frmecmain.logfile.add('CreateTable', '  Set to use server
- Connection Type = ' + IntToStr(global.ECData.ConnectionType));
     case global.ECData.ConnectionType of
       1: Table.DatabaseName := global.ECData.LocalDatabaseLocation;
//Local
       2: Table.databaseName := 'ExitCare'; // Client/Server
       3: Table.DatabaseName := global.ECData.ServerDatabaseLocation;
// Peer to Peer
       4: Table.DatabaseName := global.ECData.LocalDatabaseLocation;
// Direct From Server
       5: Table.databaseName := 'ExitCare'; // Internet
     end;
   end
 else
   begin
     table.DatabaseName := global.ECData.LocalDatabaseLocation;
     Table.ReadOnly := blnReadOnly;
   end;
end;


==============================

sample call that needs a query

function TDM.GetCount(strSQL: string; SessionType: TUseSessionTypes;
UseServer: boolean): Integer;
var
 Query: TDBISAMQuery;
 sesTempSession: TDBISAMSession;
begin
 CreateSession(sesTempSession, Sessiontype, true);
 createquery(Query, sesTempSession, UseServer);

 try
   query.SQL.Text := 'SELECT COUNT(*) as mycount FROM ' + strSQL;
   query.open;
   Result := query.FieldByName('mycount').AsInteger;
   query.Close;
 finally
   query.free;
   sesTempSession.Free;
 end;

end;

=======================
Sample call that needs a table

would be the same as for createing a query except I would call
CreateTable instead.


I do also have 2 other set sessions on my datamodule
ServerSession (which points to the server) and LocalSession (which
points to the local databases)
I use these 2 sessions when ever I am not woring in a thread (which is
most of the time) so when I need a query or table that is in the main
thread I pass one of those 2 sessions in instead of the dynamically
created one. Should I just create each session dynamically that way
they always have a new connection? I did not do it that way thinking it
would slow down the app if it had to create a new session each and
every time.





--

Bern,

<< This I don't understand because it is a random error that is happening,
sometimes the program can be running for hours and then they will start
getting this, or it could be after a few seconds. Same User, Same Machine,
Same Login. I have reported this before but lately we are getting more and
more users having this problem. >>

If the issue seems random, then most likely it is the AV issue.  A user
accounts issue or a directory issue would be consistent.  I know that you
don't think it's the AV issue, but you're going to have to trust me on this
one - some external piece of software is interfering with the ability of
DBISAM to create temporary tables properly.

<< That may make sense, Is there a better way to handle this? I would assume
something in a try except that check for the error and reestablish
connection to the server >>

Well, the bigger question is why was the database server restarted ?

<< I do also have 2 other set sessions on my datamodule ServerSession (which
points to the server) and LocalSession (which points to the local databases)
I use these 2 sessions when ever I am not woring in a thread (which is most
of the time) so when I need a query or table that is in the main thread I
pass one of those 2 sessions in instead of the dynamically created one.
Should I just create each session dynamically that way they always have a
new connection? I did not do it that way thinking it would slow down the app
if it had to create a new session each and every time. >>

First of all, the code looks good provided that you're always passing in the
ForThread parameter properly in the calling code.  The only thing I would
change is passing a nil instead of Self when creating the TDBISAMQuery
component dynamically.  So, if you can get a hold of a server log that has
an AV in it, it would help immensely because I can at least see which
request is causing the AV.  As for your question, the way that you're doing
things now is fine.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> Bern,
>
> << This I don't understand because it is a random error that is
> happening, sometimes the program can be running for hours and then
> they will start getting this, or it could be after a few seconds.
> Same User, Same Machine, Same Login. I have reported this before but
> lately we are getting more and more users having this problem. >>
>
> If the issue seems random, then most likely it is the AV issue.  A
> user accounts issue or a directory issue would be consistent.  I know
> that you don't think it's the AV issue, but you're going to have to
> trust me on this one - some external piece of software is interfering
> with the ability of DBISAM to create temporary tables properly.


> << That may make sense, Is there a better way to handle this? I would
> assume something in a try except that check for the error and
> reestablish connection to the server >>
>
> Well, the bigger question is why was the database server restarted ?

One of the reason they are restarting the server is because it keeps
crashing.

I have posted an ecserver.log file on the binaries news group.
This is happing at a number of sites, of which we are getting ready to
loose 2 of them because of this.

>
> << I do also have 2 other set sessions on my datamodule ServerSession
> (which points to the server) and LocalSession (which points to the
> local databases) I use these 2 sessions when ever I am not woring in
> a thread (which is most of the time) so when I need a query or table
> that is in the main thread I pass one of those 2 sessions in instead
> of the dynamically created one. Should I just create each session
> dynamically that way they always have a new connection? I did not do
> it that way thinking it would slow down the app if it had to create a
> new session each and every time. >>
>
> First of all, the code looks good provided that you're always passing
> in the ForThread parameter properly in the calling code.  The only
> thing I would change is passing a nil instead of Self when creating
> the TDBISAMQuery component dynamically.  So, if you can get a hold of
> a server log that has an AV in it, it would help immensely because I
> can at least see which request is causing the AV.  As for your
> question, the way that you're doing things now is fine.



--