30.04.2016 18:47, Mark Rotteveel wrote: > Is the limit now 2^32 or 2^48?
2^48 internally, represented as 2^64 for the external world. > Also what is the effect of this change (and the change "Limits Raised > for Attachment and Statement IDs" below that) for the wire protocol? > Does this affect the handle id of statements and transactions (if so > how, as those are int32 in the protocol), or does this only affect the > transaction id in a service request (eg isc_spb_rpr_list_limbo_trans), > if so how, because transaction ids are always length 4 VAX encoded > integers (without length prefix) in the response? Handles are not affected. In isc_database_info(), it affects isc_info_active_transactions, isc_info_limbo, isc_info_oldest_transaction, isc_info_oldest_active, isc_info_oldest_snapshot, isc_info_next_transaction. In isc_transaction_info(), it affects isc_info_tra_id, isc_info_tra_oldest_interesting, isc_info_tra_oldest_snapshot, isc_info_tra_oldest_active. In all these cases, value is length-prefixed. 8 bytes are transmitted only if the value overflows 2^32. In service requests, new info tags are introduced for 64-bit values: isc_spb_tra_id_64, isc_spb_single_tra_id_64, isc_spb_multi_tra_id_64. They are used only of the value overflows 2^32. 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_recover_two_phase. Please file a ticket. Dmitry ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel