> > a) Is ServicesAPI part of the Firebird API that server implements or

not?

>
> Yes, the server implements it, but the local engine does not. It's a
> separate provider under the dispatch code.
> >
> > b) Are you going to change the API itself by introducing new calls?
>
> No.
> >
> > So far I do not see any problem with the current solution as far as
> > application programmer is concerned:
>
> There are two problems. First is that the Vulcan engine provider does
> not include the services API. That may seem arbitrary and capricious,
> but the services code is designed to be layered on the engine, not
> embedded in it. The current implementation of the services API mixes
> layered code with internal engine calls. That's why it's not currently
> in Vulcan.
>
> The suggestion is to make a separate provider that implements the
> services API. That restores the layering and gives us a chance to
> reduce the amount of conditional code in the utilities.

I would like to see some SQL-derived statements for backup,
create user and the like... How about that?

With regards,

Martijn Tonies
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL
Server
Upscene Productions
http://www.upscene.com