Hi Tim,

I've been running the old server without trigger for approximately 2 weeks now and there hasn't been a single error, so it looks like the errors were somehow related to the trigger. I have
tried, without success, to duplicate the errors on my own computer as follows:

I ran the server (with trigger) and 10 clients on the same PC. Each client was inserting records at random intervals of between 100ms and 500ms. Each client ran until it had inserted 1,000
records. Thus there were 10,000 records added to the main table. Of these 10,000 records 5,010 satisfied the trigger condition and were posted to a second table by the server. This is a
much higher workload than the real system will ever see. Not a single error occurred.

Can you suggest anything else to try?  

I should point out that in the real system the client applications connect to the server over ADSL and that the clients in my test were not the same applications as the real clients. The test
clients were created solely for the purpose of automatically adding records with random values to one table. So is it possible, that the server errors could have been caused by the real client
applications or by the method of connection to the server (i.e. ADSL).

Tony,

<< I should point out that in the real system the client applications
connect to the server over ADSL and that the clients in my test were not the
same applications as the real clients. The test clients were created solely
for the purpose of automatically adding records with random values to one
table. So is it possible, that the server errors could have been caused by
the real client applications or by the method of connection to the server
(i.e. ADSL). >>

The type of connection won't have any bearing on the functionality in the
database server with respect to the problem that you're seeing.  It may
cause more disconnects/dead sessions, but the database server should be able
to cope with them just fine.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tony,

<< I've been running the old server without trigger for approximately 2
weeks now and there hasn't been a single error, so it looks like the errors
were somehow related to the trigger. I have tried, without success, to
duplicate the errors on my own computer as follows:

I ran the server (with trigger) and 10 clients on the same PC. Each client
was inserting records at random intervals of between 100ms and 500ms. Each
client ran until it had inserted 1,000 records. Thus there were 10,000
records added to the main table. Of these 10,000 records 5,010 satisfied the
trigger condition and were posted to a second table by the server. This is a
much higher workload than the real system will ever see. Not a single error
occurred.

Can you suggest anything else to try? >>

Have you tried using a table component instead of a query for performing the
insert in the after-insert trigger ?  I'm just curious to see if that gives
you any kind of different result.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tony Pomfrett wrote:

> Hi,
>
> I have a DBISAM server running on a Small Business Server 2003 box.
> Approximately 20 clients connect to the DBISAM server, mostly
> external access over the internet. Approximately once a week the
> client applications lose connectivity and report the following error
> in their system error logs:
>
> "The following information is part of the event: DBISAM Engine Error
> # 11279 An unknown error ('Access violation at address 004081F4 in
> module 'dbsrvr.exe'. Read of address 397A1700') occurred with the
> connection to the database server at '127.0.0.1', please check the
> server log."
>
> This behaviour occurs for remote clients and local clients running on
> the server machine. Restarting the DBISAM server fixes the problem.
> Checking the server log doesn't reveal any info because the server
> must be restarted first which seems to clear the log - Any
> suggestions?
>
> Thanks, Tony.

Tony,

any news on this topic?

We still have the same problem...

What I found is, .. it just happens at 2003 Servers.
We have customers running the same app up to 40 clients on w2k servers
24/7 ... they never had these av's.
Just two customer with W2003 (18/23 clients) reported this error. It
happens maybe once a week.. maybe every 10 days... there is absolutely
no system in this behaviour...

First I thought that it could be a trigger or a server proc,.. dead
sessions,...  but I don't think that it's some kind of this..


I tried to reproduce on xp/w2K/... absolutely no chance...
Thinking of replacing the "unknown error" with an madexcept handler..
maybe that would show something whats going on... but at the moment
there is absolutely no time to look into the sources where to hook in..

if you found something... any hint would be appreciated.

< if you didn't found anything.. >
@Tim: any hint where to forward the "unknown" error to madexcept..
file, line number?
</ if you didn't found anything.. >

regards
ralf

Ralf,

<< I tried to reproduce on xp/w2K/... absolutely no chance... Thinking of
replacing the "unknown error" with an madexcept handler.. maybe that would
show something whats going on... but at the moment there is absolutely no
time to look into the sources where to hook in.. >>

MadExcept just goes in as the first line (or second, after the DBISAM memory
manager, check the docs for MadExcept) in the dbsrvr.dpr file.

We use Windows 2003 with our internal database server here, and it works
fine, so I'm not sure what is going on.  If you do get a MadExcept trace,
please forward it to me and I'll see what I can find.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim / Ralf,

I was just wondering if you managed to get to the bottom of this problem.
Recently, I've just moved one of my clients from stLocal to stRemote.
Mostly, it's been running fine, but on some reports they print (larger
queries) we've been having some hit and miss.

The problem is that during the execution of a query, the application just
'locks up'. No error message. They have to task kill the application.

We're running:

DBISam 4.25 b 4
Windows 2003 Standard Server
Clients are running Windows XP
Communication via a 100mb Lan

I have seen some errors in the log such as:

6/4/2007 5:34:32 PM [ERROR] Engine error [Access violation at address
004B3E40 in module 'dbsrvr.exe'. Read of address 00000000] [Client Version:
4.25 User Name: amanda Address: 10.30.11.115 Encrypted: No Request:
REQUEST_FREESTMT Thread: 5388 Session: 45416456]

We aren't using any triggers or stored procedures. Just the bare DBSRVR.exe
installation/file.

Best Regards

Adam.

Adam,

<< I was just wondering if you managed to get to the bottom of this problem.
Recently, I've just moved one of my clients from stLocal to stRemote.
Mostly, it's been running fine, but on some reports they print (larger
queries) we've been having some hit and miss.

The problem is that during the execution of a query, the application just
'locks up'. No error message. They have to task kill the application. >>

Are these queries that normally run slow, or are they normally fast ?

<< I have seen some errors in the log such as: >>

We've had various reports of the same error when freeing SQL statements, but
none have been reproducible.  So, at this point I'm not sure what the issue
is.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim,

> The problem is that during the execution of a query, the application just
> 'locks up'. No error message. They have to task kill the application. >>
>
> Are these queries that normally run slow, or are they normally fast ?

Define slow.  

Most of the queries I have actually have about 4 seperate SQL statements
seperated by the semicolumn all in the one SQL. They can take anything from
5 to 30 seconds to execute.

> << I have seen some errors in the log such as: >>
>
> We've had various reports of the same error when freeing SQL statements,
> but none have been reproducible.  So, at this point I'm not sure what the
> issue is.

I'll keep an eye out to see if I can reproduce it on demand. So far, it
seems to be a hit and miss issue with:

c/s (stremote)
Windows 2003 standard Server (running server application)
Windows XP clients

Cheers

Adam.

Adam,

<< Define slow.  >>

Minutes, at the very least.

<< Most of the queries I have actually have about 4 seperate SQL statements
seperated by the semicolumn all in the one SQL. They can take anything from
5 to 30 seconds to execute. >>

Okay, that shouldn't cause an issue.  Are you using the
TDBISAMSession.OnRemoteSendProgress/OnRemoteReceiveProgress event handler(s)
at all ?

<< I'll keep an eye out to see if I can reproduce it on demand. So far, it
seems to be a hit and miss issue with: >>

Thanks.  The issue is one where every time the actual SQL statement is run
in isolation, it doesn't have an issue.  So, I can't reproduce anything
after the fact, at least not yet.

--
Tim Young
Elevate Software
www.elevatesoft.com