Subject | RE: [firebird-php] the "to many savepoints" & other problem |
---|---|
Author | Alan McDonald |
Post date | 2004-10-29T13:39:02Z |
my database every two/three days says:
Database: /guest/XXXX.gdb
internal gds software consistency check (Too many savepoints (287))
or
Database: /guest/XXXX.gdb
internal gds software consistency check (decompression overran
buffer (179))
[Alan McDonald] have you made sure you have the correct client lib version
matched to your server?
1. im my application i don't use any of ADOdb, Pear.
2. no explicit transactions used in php code; no "complex" store procedures
or other operations
3. no difference between persistent/NO persistent connection: the problem is
the same
4. the database in small (100 mb) and with a medium of 1000 connections per
day
5. i think the problem is in the transaction mechanism used by php (maybe a
bug in 4.3.3, but no literature on the internet).
[Alan McDonald] I doubt this - it's simple, every page has an implicit
transaction which commits when the page successfully completes.
6. often i have a this message: deadlock confilct....but i think is not the
problem (or i'm wrong?)
[Alan McDonald] This smells more like revealing the issue. It suggests
something about the SQL statement you might be using on a page - maybe we
should see some code as an example?
7. what happens if a php script goes in "fatal error" to the firebird
connection/trasaction?
[Alan McDonald] The transaction is rolledback.
Any suggestion?
Thanx.
[Alan McDonald] do you have the correct firebird.msg file vailable to the
server?
[Non-text portions of this message have been removed]
Database: /guest/XXXX.gdb
internal gds software consistency check (Too many savepoints (287))
or
Database: /guest/XXXX.gdb
internal gds software consistency check (decompression overran
buffer (179))
[Alan McDonald] have you made sure you have the correct client lib version
matched to your server?
1. im my application i don't use any of ADOdb, Pear.
2. no explicit transactions used in php code; no "complex" store procedures
or other operations
3. no difference between persistent/NO persistent connection: the problem is
the same
4. the database in small (100 mb) and with a medium of 1000 connections per
day
5. i think the problem is in the transaction mechanism used by php (maybe a
bug in 4.3.3, but no literature on the internet).
[Alan McDonald] I doubt this - it's simple, every page has an implicit
transaction which commits when the page successfully completes.
6. often i have a this message: deadlock confilct....but i think is not the
problem (or i'm wrong?)
[Alan McDonald] This smells more like revealing the issue. It suggests
something about the SQL statement you might be using on a page - maybe we
should see some code as an example?
7. what happens if a php script goes in "fatal error" to the firebird
connection/trasaction?
[Alan McDonald] The transaction is rolledback.
Any suggestion?
Thanx.
[Alan McDonald] do you have the correct firebird.msg file vailable to the
server?
[Non-text portions of this message have been removed]