| Subject | Re: [ib-support] How to use "Direct File Access" or "Local Access Method" |
|---|---|
| Author | Helen Borrie |
| Post date | 2002-09-26T09:59:59Z |
At 07:56 AM 26-09-02 +0000, you wrote:
database management system. The "management" and "system" things are
totally under the control of the database engine, aka
"server". Applications don't touch physical files at all, except through
the medium of the client library, aka API.
It is possible - and, in the past, very common - to write embedded client
applications, that is, programs where application code and the client
library's functions are ultimately compiled into one executable. Fb/IB has
a special subset of SQL statements and syntax - "static SQL" or "ESQL" -
which can be run through a pre-processor ready for inclusion in the compile.
store the data of a single table. The db engine stores and manages
database pages, and data belonging to a single table may be anywhere on the
disk. Operations occur as the result of instructions passed between the
API and the engine. Applications "talk" to the API via a number of record
structures that are transported by formal function calls.
"remote" (via the network) vs "local" (on a machine where the server and
the client are running on the same hardware). In older evolutions, on
now-obsolete platforms, it was possible to bypass the network layer (now
managed by the client library) and have the client application working in
the server's process space. I can't explain how it was done but there are
others around here who can explain it very well.
superserver, where one and only one instance of the client library (no
threading) can share the same inter-process communication space as the
server on a single machine. Hence it is possible to "connect locally" to
the server - but it is still through the medium of the client library.
will probably be spoiled for choice.
heLen
>Hi,It isn't possible. Fb/IB is not a file-based database: it's a relational
>
>I am trying to evaluate Firebird/Interbase for use in a standalone
>Windows application, but have not been able to firmly establish that
>it is possible to embed the database engine directly in an
>application.
database management system. The "management" and "system" things are
totally under the control of the database engine, aka
"server". Applications don't touch physical files at all, except through
the medium of the client library, aka API.
It is possible - and, in the past, very common - to write embedded client
applications, that is, programs where application code and the client
library's functions are ultimately compiled into one executable. Fb/IB has
a special subset of SQL statements and syntax - "static SQL" or "ESQL" -
which can be run through a pre-processor ready for inclusion in the compile.
>By "embedded" I mean that the database engine executes "in process"No. The database files are not like ISAM files, where one or more files
>with the application. What I am after is that the application be able
>to connect directly to the database files without going through
>ibserver or any other external processes.
store the data of a single table. The db engine stores and manages
database pages, and data belonging to a single table may be anywhere on the
disk. Operations occur as the result of instructions passed between the
API and the engine. Applications "talk" to the API via a number of record
structures that are transported by formal function calls.
>This would be similar to SQLite, but with the advanced features ofLike a bicycle that can go at Mach 2?
>FB/IB.
>The article Securing your Firebird/InterBase Installation"Direct access" is a bit of misnomer. The dichotomy is really closer to
>By Mark O'Donohue 21st January 2001
>(http://www.ibphoenix.com/main.nfs?
>a=ibphoenixApp&l=;IBPHOENIXAPP.PAGES;NAME='art_fb_security')
> mentions that it is possible to perform I/O directly on the database
>files using "Direct File Access" or "Direct Connect Mode".
"remote" (via the network) vs "local" (on a machine where the server and
the client are running on the same hardware). In older evolutions, on
now-obsolete platforms, it was possible to bypass the network layer (now
managed by the client library) and have the client application working in
the server's process space. I can't explain how it was done but there are
others around here who can explain it very well.
>Another hint is in InterBase Architecture: SuperServer vs ClassicWith a classic server on Linux I believe so.
>(http://community.borland.com/article/0,1410,23217,00.html) wherein
>a "Local Access Method" is described for the Classic architecture
>
>Is it possible and how is it done???
>Will it work in Windows for which only the Super Server arch. isNo; although a "fudge" was done in the transition from classic to
>available?
superserver, where one and only one instance of the client library (no
threading) can share the same inter-process communication space as the
server on a single machine. Hence it is possible to "connect locally" to
the server - but it is still through the medium of the client library.
>Is FB/IB overkill for these types of standalone applications?Totally.
>Are there other open source databases that are better suited?Undoubtedly. People love writing databases. Hunt on Sourceforge - you
will probably be spoiled for choice.
heLen