Subject | Re: [Firebird-Architect] Vulcan services part II |
---|---|
Author | Arno Brinkman |
Post date | 2006-05-11T08:42:49Z |
Hi,
the services provider.
provider.
Regards,
Arno Brinkman
ABVisie
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
General database developer support:
http://www.databasedevelopmentforum.com
Firebird open source database (based on IB-OE) with many SQL-99 features:
http://www.firebirdsql.org
http://www.firebirdsql.info
Support list for Interbase and Firebird users:
firebird-support@yahoogroups.com
Nederlandse firebird nieuwsgroep:
news://newsgroups.firebirdsql.info
>>Yes, a somewhat equal call, but database_info returns only informationLooking up the provider that is bind to the attachment.
>>about the specified database. fb_engine_info returns information over
>>all active databases.
>
> But then why to give it a dbHandle?
>>> For this purpose we already have isc_service_attach() which hasYes, but it finally ends by the provider that correctly validates the isc_service_attach() call and that is currently
>>> "service" param that holds servername (and engine name?).
>>
>>But it attaches to a services provider and not engine.
>
> Wrong. It attaches to Y-valve (as all other calls do). Where it
> will be redirected to is a matter of config and Y-valve logic.
the services provider.
> We are discussing about which provider must provide informationYes, and were discussing which method to use, but for backwards compatibilty this must be supported inside services
> about engine. I think that it must be the engine because only engine
> has all necessary information.
provider.
Regards,
Arno Brinkman
ABVisie
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
General database developer support:
http://www.databasedevelopmentforum.com
Firebird open source database (based on IB-OE) with many SQL-99 features:
http://www.firebirdsql.org
http://www.firebirdsql.info
Support list for Interbase and Firebird users:
firebird-support@yahoogroups.com
Nederlandse firebird nieuwsgroep:
news://newsgroups.firebirdsql.info