Thanks for your response, it was very helpful.

I understand the difference between Embedded SQL and the embedded server --
what I did not realize was that they could not be used together (because
embedded SQL is only for the Classic Server and the embedded server is a
Superserver).

I am wondering if I am missing some key piece of documentation, because I
did not see this mentioned anywhere, and the examples that are part of the
Firebird 1.5 download for Windows include embedded sql files. Perhaps this
is just an oversight.

In any case, thanks again.

----- Original Message -----
From: "Helen Borrie" <helebor@...>
To: <firebird-support@yahoogroups.com>
Sent: Wednesday, February 11, 2004 2:05 AM
Subject: Re: [firebird-support] using embedded SQL with embedded server


> At 05:37 AM 11/02/2004 +0000, you wrote:
> >I'm trying to get embedded SQL to work against the embedded server on
> >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.
>
> Well, you *do* need a full path to the database (or an alias) whatever
kind
> 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
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>