Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 7 of 7 total |
DBISAM Engine Error Issues |
Mon, Jan 30 2006 9:54 PM | Permanent Link |
"Al VAs" | 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 |
Mon, Jan 30 2006 11:02 PM | Permanent Link |
Eryk Bottomley | 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 |
Tue, Jan 31 2006 12:41 AM | Permanent Link |
"Al VAs" | 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 |
Tue, Jan 31 2006 7:44 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Tue, Jan 31 2006 7:02 PM | Permanent Link |
Eryk Bottomley | 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 |
Thu, Feb 2 2006 11:48 PM | Permanent Link |
"Al VAs" | 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 |
Fri, Feb 3 2006 5:29 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Al,
<< Isnt Version 5 out soon anyway >> Hopefully, yes. -- Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Wednesday, April 24, 2024 at 11:07 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |