You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Firebird currently uses unsigned 32 bit integers for the update counts returned by the isc_info_req_update_count (and related info items). Can this be extends to unsiged 64 bit integers (which technically is already supported by the code in jrd/inf.cpp). The current code should be compatible with this change because it will return numbers that fit inside a signed 32 bit integer as a 4 byte vax integer, and if the receiving side does not support 8 byte vax integers the client code (also in for example 2.5) will return 0.
Looking at this I also notice a potential bug in the existing code: the update counts (defined as ULONG) don't correctly roundtrip for values larger than MAX_SLONG as those are sent as a vax int64, and a received update count is usually decoded with gds__vax_integer which will return 0 if the length of the vax integer is larger than 4 (see print_counts in qli\exe.cpp, process_record_count in isql\isql.epp)
Submitted by: @mrotteveel
Firebird currently uses unsigned 32 bit integers for the update counts returned by the isc_info_req_update_count (and related info items). Can this be extends to unsiged 64 bit integers (which technically is already supported by the code in jrd/inf.cpp). The current code should be compatible with this change because it will return numbers that fit inside a signed 32 bit integer as a 4 byte vax integer, and if the receiving side does not support 8 byte vax integers the client code (also in for example 2.5) will return 0.
Looking at this I also notice a potential bug in the existing code: the update counts (defined as ULONG) don't correctly roundtrip for values larger than MAX_SLONG as those are sent as a vax int64, and a received update count is usually decoded with gds__vax_integer which will return 0 if the length of the vax integer is larger than 4 (see print_counts in qli\exe.cpp, process_record_count in isql\isql.epp)
Major reason (for me) is the introduction of retrieval of large update counts in the JDBC API with Java 8 / JDBC 4.2 (see http://download.java.net/jdk8/docs/api/java/sql/Statement.html#getLargeUpdateCount() ).
The text was updated successfully, but these errors were encountered: