Subject | Re: [ib-support] Access Violation at address 40560C6F in module 'gds32.dll'. Read address 202020 |
---|---|
Author | Jason Wharton |
Post date | 2001-01-23T05:21:12Z |
> I have a stored procedure that enters values into a couple ofYes. This is a long-standing bug in InterBase itself. It only affects remote
> tables. If I call it once and reboot the server everything is fine.
> If I call it twice in a row without rebooting I get:
>
> "Access Violation at address 40560C6F in module 'gds32.dll'. Read
> address 202020"
>
> Since this DB isn't in production yet, (but we would like it to be by
> the end of the week) we have just been recreating the DB from scratch
> each time we have changes. About two versions ago, I had this
> problem. We just moved the DB to a different box and all went well.
> Now with this build we have the same issue.
>
> Does anyone know what may have caused it?
connections where you are using the singleton isc_dsql_execute() API call
(which is what IBO uses when you call ExecSQL).
The work around is to prepare the statement each time it is executed.
Calling just Prepare doesn't guarantee that you are RE-preparing the
statement. You must call Unprepare and then Prepare.
It was never noticed before because the BDE doesn't keep stored procedures
prepared. It prepared them fresh every time.
You might also be compounding the problem by having an incorrect version of
GDS32.DLL on your client. An AV isn't usually the signature error of this
problem although there does seem to be a certain amount on inconsistency to
the problem.
I have complained of this problem for over 3 years now and it just doesn't
seem to catch anyone's fancy. I sure could use getting it fixed though!!!
HTH,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com