On 1/15/2015 3:25 PM, Mark Rotteveel wrote: > On 15-1-2015 15:50, Dimitry Sibiryakov wrote: >> 15.01.2015 15:38, James Starkey wrote: >>> Surely there is a transaction id info clumplet that will need to be >>> finessed... >> Fortunately, you made info block's structure expandable and every info >> item is >> accompanied with its length, so nothing have to be changed in the API >> itself, only >> programs that use this API have to accept big values. > Unfortunately, that is not how it works. For example to quote from the > API Guide, table 12.8 "Services API limbo transaction arguments": > isc_spb_tra_id, Precedes a transaction ID number, 4 bytes, Unsigned long > > The value is defined as 4 bytes, it doesn't have a length prefix. > > I am not entirely sure, but I believe there is a similar restriction > elsewhere. > >
Well, yes and no. Transaction info items are self-describing by length. So I take credit for doing it right. The services interface, which I had nothing to do with, seems to make the length implicit. Shame on whoever invented the services interface. The clumplet structure used in all info calls was intended to provide for upwards compatibility. In specific, any layer that didn't understand a particular info item could safely skip over it. ------------------------------------------------------------------------------ New Year. New Location. New Benefits. New Data Center in Ashburn, VA. GigeNET is offering a free month of service with a new server in Ashburn. Choose from 2 high performing configs, both with 100TB of bandwidth. Higher redundancy.Lower latency.Increased capacity.Completely compliant. http://p.sf.net/sfu/gigenet Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
