Subject | Error: message length error (encountered 36, expected 32) |
---|---|
Author | Steve Wiser |
Post date | 2007-12-04T15:04:24Z |
Hello,
We are getting a strange error on one of our customer's databases. This
code base is run on about 20 different customer databases, but is only
giving an error on 1 of them...
I have searched the newsgroups (and googled) for the "message length
error" and the 2 reasons that I have seen for it are 1) client to server
version mismatch and 2) calling execute on a stored procedure that has a
suspend. We are getting "Error: message length error (encountered 36,
expected 32)" every time we run a specific stored procedure. We have
tried running it from isql directly on the server, IBEpxert from a
windows client, IBPerl from a different linux client, and java from yet
another linux client. All of them are using the correct client
libraries from what I can tell. We are calling the procedure as a
select statement (it does have a suspend at the end of it).
We have even run IBFirstAid on the physical database file and it tells
us that there is no corruption with the database. Does anyone know what
this particular "message length" error means?
The database does a backup and restore without any errors. The database
has been moved to multiple test servers and always gives the same
error. It doesn't seem to happen when we run the procedure on a single
record at a time, only if we run it as a giant loop through the tables.
Server Info:
Firebird 1.5.3 CS
xinetd
ext3 filesystem
CentOS 4.5
Dual Quad-Core Xeon X5355 (2.66 GHz)
8 GB of RAM
4 GB of swap
400 GB of HDD Space in DB partition
Database is about 20 GB single file FDB
gstat output:
Database header page information:
Flags 0
Checksum 12345
Generation 20160
Page size 8192
ODS version 10.1
Oldest transaction 4379
Oldest active 4380
Oldest snapshot 2907
Next transaction 20153
Bumped transaction 1
Sequence number 0
Next attachment ID 0
Implementation ID 19
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 1
Creation date Dec 3, 2007 22:39:15
Variable header data:
Sweep interval: 0
*END*
Thanks,
Steve
We are getting a strange error on one of our customer's databases. This
code base is run on about 20 different customer databases, but is only
giving an error on 1 of them...
I have searched the newsgroups (and googled) for the "message length
error" and the 2 reasons that I have seen for it are 1) client to server
version mismatch and 2) calling execute on a stored procedure that has a
suspend. We are getting "Error: message length error (encountered 36,
expected 32)" every time we run a specific stored procedure. We have
tried running it from isql directly on the server, IBEpxert from a
windows client, IBPerl from a different linux client, and java from yet
another linux client. All of them are using the correct client
libraries from what I can tell. We are calling the procedure as a
select statement (it does have a suspend at the end of it).
We have even run IBFirstAid on the physical database file and it tells
us that there is no corruption with the database. Does anyone know what
this particular "message length" error means?
The database does a backup and restore without any errors. The database
has been moved to multiple test servers and always gives the same
error. It doesn't seem to happen when we run the procedure on a single
record at a time, only if we run it as a giant loop through the tables.
Server Info:
Firebird 1.5.3 CS
xinetd
ext3 filesystem
CentOS 4.5
Dual Quad-Core Xeon X5355 (2.66 GHz)
8 GB of RAM
4 GB of swap
400 GB of HDD Space in DB partition
Database is about 20 GB single file FDB
gstat output:
Database header page information:
Flags 0
Checksum 12345
Generation 20160
Page size 8192
ODS version 10.1
Oldest transaction 4379
Oldest active 4380
Oldest snapshot 2907
Next transaction 20153
Bumped transaction 1
Sequence number 0
Next attachment ID 0
Implementation ID 19
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 1
Creation date Dec 3, 2007 22:39:15
Variable header data:
Sweep interval: 0
*END*
Thanks,
Steve