At 09:19 PM 27/12/2004 +0000, you wrote:

>We may be off topic, Doug, but we're the only ones posting this
>afternoon.
>
> > I don't think the app server is an ASP.NET app. It is a service
>which runs
> > alongside the DB and interfaces with ASP.NET apps. No user interface
>at all.
>
>This is a valid Firebird support issue, I should think.

No, it's not. Firebird provides the data storage layer of a properly
layered system. Above that is the data access layer, which Firebird
provides by way of the API. That is Firebird's window to whatever the
upper layers throw at it. The language that the upper layers talk to the
database engine is SQL.

Above that (usually) is the data access interface, which can be as OO as
you like (and the best ones are highly OO). Above that are application
layers...somewhere between this point and the endpoint are the input/output
layers - the client application, including web browsers.

>Externalizing some of the Firebird database activity in the form of an app
>server
>must be a frequently discussed topic.

Sure, application layers are what rule most of our lives here. But they
aren't the business of a database engine. Its business is to manage
abstract structures called databases and to process requests from
application layers. The database engine is neutral about where requests
come from.

Firebird injects its own layer - stored procedures and triggers - to give
you the option of internalising some data operations that must rule the
data layer regardless of the application layers. PSQL supports the
objective of making the data layer independent of the application
layer. It makes the business of data operations more efficient,
predictable and faster. It reduces the amount of activity that has to
cross the wire. It provides a way to centralise the behaviour of
data. The cost is loss of genericity - you can't depend on all these good
things if you want to have application layers capable of commanding any ol'
database layer.

>So, if there is anybody still reading our thread, then I ask if there are
>app server tools available for Firebirders?

Of course - there's a whole industry devoted to app server tools. All are
programming language-specific and operating system-specific. A few
languages - such as Java and Python frameworks - inject an extra layer or
two to bypass (to some extent) developing or a specific OS or even a
specific database engine. Many - like .NET, Java, ODBC - limit to some
extent what your applications can realise of the data storage layer's
capabilities, in the interest of presenting a generic interface to database
engines - "the tail wagging the dog".

Firebird has strong language support for your beloved .NET - join the
firebird-net-provider list and ask there about the .NET or Mono frameworks
that you are particularly interested in. The .NET providers are your
window to application frameworks like ASP.NET. Likewise, Java - Firebird's
Jaybird provides interfaces for two JDBC standards and, behind those, is a
world of application frameworks. The forum for Jaybird is the
firebird-java list. Likewise ODBC - see the firebird-odbc-devel list -
Python, PHP, Perl....

Because Firebird emerged from the Borland stable, there are also many OO
data access layers available for Delphi and Kylix and, beyond those,
excellent ObjectPascal OO frameworks for n-tier applications. There are
forums for all of these layers.

>I sure wouldn't want to create one from scratch - instructive as it might be.

It gets down to what language you are developing applications in. Within
that scope, you design your application layers to suit requirements. So,
your mission, should you decide to accept it, is to decide where you are,
where you want to go and to work out where you need to be to develop the
layering you need.

Firebird doesn't care what you do. It listens to SQL because it's the
lingua franca of mainstream database application development. Internally,
it does what it's designed to do - store and retirieve data, manage client
requests and keep the house in order.

./heLen