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.

>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.

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

./heLen