Ahh, looks like I found the problem. The DeflateStream in .NET is
producing really raw deflate, while Firebird want's the zlib header.
--
Mgr. Jiří Činčura
Independent IT Specialist
--
What NetFlow Analyzer can do for yo
OK, I'm successfully writing data to server for op_attach - checked on
network level.
Just "for fun" I tried to write uncompressed data, as it would without
compression. In that case the server closes connection with me during
writing of DPB for op_attach.
--
Mgr. Jiří Činčura
Independent IT Spe
> Do you receive pflag_compress set in accept->p_acpt_type? You should
> check this value to decide use compression later or not.
Yes, I do. I receive 261, which is ptype_lazy_send | pflag_compress, if
I'm not mistaken.
Not sure where to look next.
> As far as I know no such flag exists.
> Try
18.06.2016 16:03, Mark Rotteveel wrote:
> What about op_reconnect? Can I always send an 8 byte VAX 'integer', even
> on older Firebird versions? Or should I only try to send 8 bytes on FB 3?
The latter. Older FB versions are unlikely to crash but won't execute
the request either (VAX integers lo
On 18-6-2016 15:03, Mark Rotteveel wrote:
> Yet another question:
>
> What about op_reconnect? Can I always send an 8 byte VAX 'integer', even
> on older Firebird versions? Or should I only try to send 8 bytes on FB 3?
The same question also applies to isc_reconnect_transaction in fbclient.
Mark
On 17-6-2016 20:23, Mark Rotteveel wrote:
> On 2-5-2016 08:40, Dmitry Yemanov wrote:
>> 01.05.2016 13:01, Mark Rotteveel wrote:
>>>
But it seems that these inputs tags were forgotten re. their longer
counterparts: isc_spb_rpr_commit_trans, isc_spb_rpr_rollback_trans,
isc_spb_rpr_reco
On 06/17/2016 09:23 PM, Mark Rotteveel wrote:
> On 2-5-2016 08:40, Dmitry Yemanov wrote:
>> 01.05.2016 13:01, Mark Rotteveel wrote:
But it seems that these inputs tags were forgotten re. their longer
counterparts: isc_spb_rpr_commit_trans, isc_spb_rpr_rollback_trans,
isc_spb_rpr_reco
On 06/17/2016 07:11 PM, Dimitry Sibiryakov wrote:
> 17.06.2016 17:58, Dmitry Yemanov wrote:
>> Or perhaps do such a check in the remote client, or even better in the
>> Y-valve?
> In this case the test will fail always.
>
>
Tests are also fixed sometimes ;)
--
