On 3 Feb 2009, at 17:22, Helen Borrie wrote:

> At 11:41 AM 4/02/2009, you wrote:
>
>> On 2 Feb 2009, at 17:01, Helen Borrie wrote:
>>
>>> Please test it. I'd really like to know how you get on with this.
>>
>> I'm happy to report that it works, although it seems that the
>> service
>> API is a lot touchier about the order of parameters in the parameter
>> block.
>
> That's good. :-) Thanks for the tip about the SPB parameter order -
> apart from the compulsory first parameter, the *D*PB doesn't care
> about the order of the params, according to available doc. For the
> *S*PB we don't actually have any doc, so I'll note this observation.

I only found this out because my DPB wrapper just accumulates
parameters in a hash map and builds the DPB when asked - essentially
in random order from the hashing. SPB seems to require the parameters
to be added "in order" from most general to most specific. The order
I used for the mode flag was

isc_action_svc_properties
isc_spb_dbname
<two byte vax length followed by characters>
isc_spb_prp_access_mode
isc_spb_prp_am_readonly/isc_spb_prp_am_readwrite

I had noticed a CORE- issue complaining about the SPB string length
macro not understanding endian-ness, but I used the vax_integer
formatter on Windows and it seemed to work fine.

>> One question: Am I supposed to issue some sort of service query to
>> figure out when it is done, or does this one block?
>
> As the SM routines execute the same code as the corresponding
> command-line utilities, my assumption would be that the same
> routines that are "blocking" when run from the executables are also
> "blocking" when run by the SM. That would necessarily be any
> operation that requires exclusive access, such as changing the mode
> attribute in the DB header.
>
> The command-line utilities (at least) pass a return code back to the
> caller. Best guess is that they derive the return code from the
> Error Status array of the function calls that correspond to the
> isc_service_xxx() function calls. All of those isc_service_
> functions have an Error Status array. What I can't guess is whether
> a Services API call actually returns the SQL completion code (0) on
> database-level operations but you could explore that.

I am using the same error handling system I use for the rest of our
Firebird interface layer and checking the status return seemed to work
fine (and the error messages were actually kind of useful for
debugging!)

> If you wanted to check the current status of the header attributes
> for verification, an isc_database_info() call is cheap.

Yeah, we already had that exposed, so the unit test was pretty easy to
write ;-)

Which reminds me... we were looking around the Firebird source tree
the other day for the automated test code and data, but it was not
obvious. Is there any? And if so, where might one find it? We were
actually looking for the collation test data, but anything that exists
would be of interest.

TIA,
________________________________________________________
Richard Wesley Senior Software Developer Tableau
Software
Visit: http://www.trytableau.com/now.html