Hi,

We have last week installed one of our larger clients with our
DBISAM-converted product (from Paradox).  We are getting a number of issues
which werent apparent in Paradox.  We have them on client-server so maybe we
need to understand this better, however, here are some of the following
issues:

DBISAM Engine Error#11279: An unknown error (Access violation at address ###
in module 'dbsrvr' Read of address ###) occurred with the connection to the
database server at ### please check the server log';

What might cause this?

Also, can someone explain what a 'disconnected' session is?  It appears that
when a user has a particular issue, they have every now and then
CTRL-ALT-DEL the application.  Would this be the cause of a 'disconnected'
session.  In these situations sometimes when they log back on it tells them
a record is locked when trying to access it again.

What is the best way to handle these situations.  The one thing we cant do ,
once we release this across our client base is manually attend to these sort
of things, so any advice on this.  We are currently on V3.21 btw

Thanks

Alex

Al

> DBISAM Engine Error#11279: An unknown error (Access violation at address ###
> in module 'dbsrvr' Read of address ###) occurred with the connection to the
> database server at ### please check the server log';
>
> What might cause this?

Incorrectly written server side procedures or custom SQL functions are
the most likely candidate. After that, corrupt data.

> Also, can someone explain what a 'disconnected' session is?#

It is in most cases a connection that has been idling for some time. No
scrolling or other activity - user 'gone to lunch'.

> when a user has a particular issue, they have every now and then
> CTRL-ALT-DEL the application.

That would be a client side bug in your code which you need to fix.

> Would this be the cause of a 'disconnected'
> session.

Yes it would.

> In these situations sometimes when they log back on it tells them
> a record is locked when trying to access it again.

The server does not know the client has crashed, it might just have gone
to lunch.

> What is the best way to handle these situations.

Stop the client application crashing.

> The one thing we cant do ,
> once we release this across our client base is manually attend to these sort
> of things, so any advice on this.

Any client app that ever needs a CTRL-ALT-DEL is broken and needs fixed.

> We are currently on V3.21 btw

Which means you are back in December 2002 ...ten patch revisions away
from the final DBISAM V3.x. ...at the very least you should update to
3.30 before going any further.

Eryk

Hi Eryk,

Have been running 3.21 on our other apps for awhile without too much issue.
The reason we never moved from 3.21 is that we would settle on a release,
then upgrade to a later as suggested, and be hit hard by new bugs.  Once we
got to 3.21 we werent
keen to move off it as it proved stable, and our previous experience made us
very wary of anything later.  Saying that, we probably shoud move onto 3.3
since that is the last version 3 release.  Do you have a list of fixes from
3.21 to 3.3?

I realise that potentially a CTRL-ALT-DEL could be required because of a
bug, although the issues we are now experiencing were not apparent in some
very heavy testing at another client under non client-server mode.  You
would probably also realise that when upteen users are using an application
in an environment that we have no control over ie a client site, then you
are going to get some silly things done by silly users.  Also there are
going to be times where PC or server integrity is compromised and could
cause issues.  In fact there are a multitude reasons why a PC may
disconnect.  Im really after advice on how to best recover from these
situations without remotely having to clear sessions.  Someone in some
previous conversation mentioned setting DeadSessions to zero.  Is that a
good idea?  What other suggestions?  Fixing the application is maybe the
answser for 1 or 2 circumstances but not the answer for a number of
potential circumstances.  Has anyone else overcome these potential issues in
any clever way?

Can you elaborate on incorrectly written server side procedures?  We havent
written any (does V3.x support them).  Also custom SQL functions, do you
mean customising the server engine as we dont do this either.

Thanks for your reply

Alex

"Eryk Bottomley" <no@way.com> wrote in message
news:160EB036-B4D2-4908-A033-35A18CA904B7@news.elevatesoft.com...
> Al
>
>> DBISAM Engine Error#11279: An unknown error (Access violation at address
>> ### in module 'dbsrvr' Read of address ###) occurred with the connection
>> to the database server at ### please check the server log';
>>
>> What might cause this?
>
> Incorrectly written server side procedures or custom SQL functions are the
> most likely candidate. After that, corrupt data.
>
>> Also, can someone explain what a 'disconnected' session is?#
>
> It is in most cases a connection that has been idling for some time. No
> scrolling or other activity - user 'gone to lunch'.
>
>> when a user has a particular issue, they have every now and then
>> CTRL-ALT-DEL the application.
>
> That would be a client side bug in your code which you need to fix.
>
>> Would this be the cause of a 'disconnected' session.
>
> Yes it would.
>
>> In these situations sometimes when they log back on it tells them a
>> record is locked when trying to access it again.
>
> The server does not know the client has crashed, it might just have gone
> to lunch.
>
>> What is the best way to handle these situations.
>
> Stop the client application crashing.
>
>> The one thing we cant do , once we release this across our client base is
>> manually attend to these sort of things, so any advice on this.
>
> Any client app that ever needs a CTRL-ALT-DEL is broken and needs fixed.
>
>> We are currently on V3.21 btw
>
> Which means you are back in December 2002 ...ten patch revisions away from
> the final DBISAM V3.x. ...at the very least you should update to 3.30
> before going any further.
>
> Eryk

Alex,

<< We have last week installed one of our larger clients with our
DBISAM-converted product (from Paradox).  We are getting a number of issues
which werent apparent in Paradox.  We have them on client-server so maybe we
need to understand this better, however, here are some of the following
issues:

DBISAM Engine Error#11279: An unknown error (Access violation at address
### in module 'dbsrvr' Read of address ###) occurred with the connection to
the database server at ### please check the server log';

What might cause this? >>

There were several issues with 3.21 and higher in reference to AVs:

http://www.elevatesoft.com/scripts/incident.dll?action=search

Search for "av".

Did you check the database server log to see what operation was causing the
AV ?  That should shed some light on the issue.

--
Tim Young
Elevate Software
www.elevatesoft.com

Al,

> Do you have a list of fixes from
> 3.21 to 3.3?

Not in "consolidated" form, but the information for each patch release
is here:

http://www.elevatesoft.com/scripts/incident.dll?action=list

> I realise that potentially a CTRL-ALT-DEL could be required because of a
> bug, although the issues we are now experiencing were not apparent in some
> very heavy testing at another client under non client-server mode.

Naturally it could be a DBISAM bug but, as I said, you are a bit too far
off the current build to be sure one way or another.

> would probably also realise that when upteen users are using an application
> in an environment that we have no control over ie a client site, then you
> are going to get some silly things done by silly users.

Definitely

> Im really after advice on how to best recover from these
> situations without remotely having to clear sessions.

You can control that with the dead session timeout setting and those
associated with it.

> Someone in some
> previous conversation mentioned setting DeadSessions to zero.  Is that a
> good idea?  What other suggestions?

You have a tradeoff to make here. The server doesn't know if a given
user has blown his/her app out of the water or is just sitting there
'thinking'. If you set the dead session settings too aggressively then
you risk booting off a user who was simply taking a long time typing
stuff into a field (or something similar) and trashing their work  ...if
you leave the settings at their defaults you risk ending up with the
problem you are describing (locked records). V4 adds features that make
all this a bit easier to deal with via things like the remote "ping"
functionality.

> Fixing the application is maybe the
> answser for 1 or 2 circumstances but not the answer for a number of
> potential circumstances.  Has anyone else overcome these potential issues in
> any clever way?

You can simulate V4's "ping" functionality by using a timer to
periodically get the current server time or something like that. You
could then set fairly aggressive dead session cleanup parameters.
Personally I would just upgrade to V4.x though.

> Can you elaborate on incorrectly written server side procedures?  We havent
> written any (does V3.x support them).  Also custom SQL functions, do you
> mean customising the server engine as we dont do this either.

Yes, I meant customising the server. I was replying as I read and I
didn't get to the "V3" reference until right at the end - I left the
comment in because even in V3.x it was possible to add custom server
side logic.

Eryk

Hi Eryk (and Tim),

Thanks for your comments.  We will look into some of these for solutions.  I
would love to upgrade to version 4, however, there is alot of testing for us
to do this at this stage.  We stayed with version 3.x as our other apps are
using 3.x and have been very stable.  To move to 4 would require us
upgrading our other products too (as I dont believe you can have 3 and 4 in
the same IDE) and we are not yet big enough to handle this sort of task.
Will be something we can visit when we change Delphi versions (and can have
one product in old, another in new).

Isnt Version 5 out soon anyway

Regards

Alex


"Eryk Bottomley" <no@way.com> wrote in message
news:DAE2A955-5970-420D-8732-41C5BD24DB82@news.elevatesoft.com...
> Al,
>
> > Do you have a list of fixes from
>> 3.21 to 3.3?
>
> Not in "consolidated" form, but the information for each patch release is
> here:
>
> http://www.elevatesoft.com/scripts/incident.dll?action=list
>
>> I realise that potentially a CTRL-ALT-DEL could be required because of a
>> bug, although the issues we are now experiencing were not apparent in
>> some very heavy testing at another client under non client-server mode.
>
> Naturally it could be a DBISAM bug but, as I said, you are a bit too far
> off the current build to be sure one way or another.
>
>> would probably also realise that when upteen users are using an
>> application in an environment that we have no control over ie a client
>> site, then you are going to get some silly things done by silly users.
>
> Definitely
>
>> Im really after advice on how to best recover from these situations
>> without remotely having to clear sessions.
>
> You can control that with the dead session timeout setting and those
> associated with it.
>
>> Someone in some previous conversation mentioned setting DeadSessions to
>> zero.  Is that a good idea?  What other suggestions?
>
> You have a tradeoff to make here. The server doesn't know if a given user
> has blown his/her app out of the water or is just sitting there
> 'thinking'. If you set the dead session settings too aggressively then you
> risk booting off a user who was simply taking a long time typing stuff
> into a field (or something similar) and trashing their work  ...if you
> leave the settings at their defaults you risk ending up with the problem
> you are describing (locked records). V4 adds features that make all this a
> bit easier to deal with via things like the remote "ping" functionality.
>
> > Fixing the application is maybe the
>> answser for 1 or 2 circumstances but not the answer for a number of
>> potential circumstances.  Has anyone else overcome these potential issues
>> in any clever way?
>
> You can simulate V4's "ping" functionality by using a timer to
> periodically get the current server time or something like that. You could
> then set fairly aggressive dead session cleanup parameters.
> Personally I would just upgrade to V4.x though.
>
>> Can you elaborate on incorrectly written server side procedures?  We
>> havent written any (does V3.x support them).  Also custom SQL functions,
>> do you mean customising the server engine as we dont do this either.
>
> Yes, I meant customising the server. I was replying as I read and I didn't
> get to the "V3" reference until right at the end - I left the comment in
> because even in V3.x it was possible to add custom server side logic.
>
> Eryk

Al,

<< Isnt Version 5 out soon anyway >>

Hopefully, yes.

--
Tim Young
Elevate Software
www.elevatesoft.com