When you prepare a statement the response comes back including an xdr array. If the length of the array is 32767 (0x00007FFF) or below, everything is fine, but firebird 2.5 has a bug where it encodes the lengths above that incorrectly, for instance 32768 (0x00008000) is encoded as 0xFFFF8000. This causes the allocateAndPrepare callback not to be called and the connection to be left in a broken state.
Unfortunately the fix makes array lengths greater than 65535 (0xFFFF) unrepresentable, and I don't know if newer versions of firebird - or other parts of firebird in 2.5 sending xdr arrays - might send arrays longer than that. That means I can't be sure that applying this fix won't create more issues. I'd appreciate your thoughts!
When you prepare a statement the response comes back including an xdr array. If the length of the array is 32767 (
0x00007FFF) or below, everything is fine, but firebird 2.5 has a bug where it encodes the lengths above that incorrectly, for instance 32768 (0x00008000) is encoded as0xFFFF8000. This causes the allocateAndPrepare callback not to be called and the connection to be left in a broken state.The ado.net adapter mitigates this by casting to short. The bug seems to be fixed in firebird 3 - I had to drop back to 2.5 to get this test demonstrating the issue to fail.
It's possible to fix here by dropping the first two bytes of the length, then reading the following two bytes as an unsigned short. Is this fix something you're interested in incorporating?
Unfortunately the fix makes array lengths greater than 65535 (0xFFFF) unrepresentable, and I don't know if newer versions of firebird - or other parts of firebird in 2.5 sending xdr arrays - might send arrays longer than that. That means I can't be sure that applying this fix won't create more issues. I'd appreciate your thoughts!