Subject | Re: [firebird-support] using embedded SQL with embedded server |
---|---|
Author | Helen Borrie |
Post date | 2004-02-11T10:05:54Z |
At 05:37 AM 11/02/2004 +0000, you wrote:
of client you want to use. And gpre has to *find* the security
database...etc,. etc., pieces that *it* needs to find in the RootDirectory.
But the main problem here seems to be (totally forgiveable) confusion about
what "embedded" means. In short, you are using a mix-and-match that
doesn't work.
Embedded SERVER
The Embedded Server on Windows merges the API library with a single
Superserver instance. It's for use with front-ends that use DSQL (dynamic
SQL) and API functions. Superserver needs the API client that is embedded
in fbembed.dll. The API client doesn't support ESQL.
The front-end client application for the Windows embedded *Server* is just
any ordinary client application that uses API calls - either direct calls
to the isc_ functions, or class implementations like IBO or Zeos or FIBPlus
for Delphi and C++B or API wrappers such as IBPP. The application is
"embedded" only insofar as it dynamically loads API functions - which it
can equally do from the remote client when connecting to a full server.
Embedded APPLICATIONS
When you write an embedded *application* you effectively create your own
client layer: your application *is* the client. ESQL provides the
language interface for connectivity. The gpre precompiler parses your ESQL
blocks and generates source code that calls macro functions that are the
embedded equivalent of the API functions. Embedded apps can only connect
to a Classic server instance, AFAIK. I simply don't know whether Classic on
Windows supports precompiled SQL but I don't see why it wouldn't.
--------------------------
If you want to use Windows Embedded Server (in contrast to writing apps
that are embedded clients) take a look at wrappers that encapsulate the API
for C++ - esp. IBPP and maybe SQLAPI++ (more generic and low-end) -- links
to both can be found at
http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_dev_comps
/heLen
>I'm trying to get embedded SQL to work against the embedded server onWell, you *do* need a full path to the database (or an alias) whatever kind
>Windows XP, using the examples that come with Firebird (stat2.e in
>particular). I tried this:
>
>[bin]$ ./gpre.exe -c -d employee.fdb stat2.e
>Your user name and password are not defined. Ask your database
>administrator to set up a Firebird login.
>
>Then I tried putting the following at the top of the file:
>
>EXEC SQL
> BEGIN DECLARE SECTION;
>EXEC SQL
> SET DATABASE DB1 = 'employee.fdb';
>EXEC SQL
> CONNECT DB1 USER 'SYSDBA' PASSWORD 'masterkey';
>EXEC SQL
> END DECLARE SECTION;
>
>
>And got:
>[[bin]$ ./gpre.exe -c stat2-mod.e
>Your user name and password are not defined. Ask your database
>administrator to set up a Firebird login.
>(E) stat2-mod.e:42: Couldn't access database DB1 = 'employee.fdb'
>(E) stat2-mod.e:49: No database specified
>
>
>Can anybody help?
>
>Note: the employee.fdb database is in the bin directory, as is my
>source file, so everything is in the same place.
>And I can connect fine to employee.fdb as SYSDBA using isql.
>
>Thanks in advance.
of client you want to use. And gpre has to *find* the security
database...etc,. etc., pieces that *it* needs to find in the RootDirectory.
But the main problem here seems to be (totally forgiveable) confusion about
what "embedded" means. In short, you are using a mix-and-match that
doesn't work.
Embedded SERVER
The Embedded Server on Windows merges the API library with a single
Superserver instance. It's for use with front-ends that use DSQL (dynamic
SQL) and API functions. Superserver needs the API client that is embedded
in fbembed.dll. The API client doesn't support ESQL.
The front-end client application for the Windows embedded *Server* is just
any ordinary client application that uses API calls - either direct calls
to the isc_ functions, or class implementations like IBO or Zeos or FIBPlus
for Delphi and C++B or API wrappers such as IBPP. The application is
"embedded" only insofar as it dynamically loads API functions - which it
can equally do from the remote client when connecting to a full server.
Embedded APPLICATIONS
When you write an embedded *application* you effectively create your own
client layer: your application *is* the client. ESQL provides the
language interface for connectivity. The gpre precompiler parses your ESQL
blocks and generates source code that calls macro functions that are the
embedded equivalent of the API functions. Embedded apps can only connect
to a Classic server instance, AFAIK. I simply don't know whether Classic on
Windows supports precompiled SQL but I don't see why it wouldn't.
--------------------------
If you want to use Windows Embedded Server (in contrast to writing apps
that are embedded clients) take a look at wrappers that encapsulate the API
for C++ - esp. IBPP and maybe SQLAPI++ (more generic and low-end) -- links
to both can be found at
http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_dev_comps
/heLen