From the SQL-99 spec:

> > A temporary table is an SQL-session object that cannot be
> > accessed from any other SQL-session.
> >
> > A global temporary table can be accessed from any associated
> > SQL-client module. A local temporary table can be accessed
> > only from the module to which it is local.
> >
> > A temporary table is empty when an SQL-session is initiated
> > and it isemptied (that is, all its rows are deleted) either
> > when an SQL-transaction is terminated or when an SQL-session
> > is terminated, depending on its descriptor.

At 12:05 PM 11/23/2004, Martijn Tonies wrote:

>Again, it might be me :-) ...
>
>But doesn't this say there's a difference between GLOBAL and
>LOCAL?

Yes. And the difference affects whether data in the
table is accessible through different modules. We don't
implement modules, so by definition all access to firebird
is through a single magic "default SQL-client module whose
existence is not apparent to the user." Since there is only
one default client module, global and local are the same.

>Here:
> >A global temporary table can be accessed from any associated
> >SQL-client module.
>
>"SQL-client module": session/connection.

No. SQL-session is a session/connection. SQL client-module
is another beast entirely.

4.2.3.1 SQL-clients
An SQL-client is a processor, perceived by the SQL-agent
as part of the SQL-implementation, that establishes
SQL-connections between itself and SQL-servers and
maintains a diagnostics area and other state data
relating to interactions between itself, the SQL-agent,
and the SQL-servers.

s) SQL-connection: An association between an SQL-client and
an SQL-server.
...
v) SQL-session: The context within which a single user, from
a single SQL-agent, executes a sequence of consecutive
SQL-statements over a single SQL-connection.


4.2.4 SQL-client modules
An SQL-client module is a module that is explicitly created
and dropped by implementation-defined mechanisms. An SQL-client
module does not necessarily have a name; if it does, the permitted
names are implementation-defined.

An SQL-client module contains zero or more externally-invoked
procedures. Exactly one SQL-client module is associated with an
SQL-agent at any time. However, in the case of either direct
binding style or SQL/CLI, this may be a default SQL-client module
whose existence is not apparent to the user.

Here are some more definitions around the issue...

4.2.2 SQL-agents
An SQL-agent is that which causes the execution of
SQL-statements. In the case of the direct invocation
of SQL (see Subclause 5.6.4, ''Direct invocation of SQL''),
it is implementation defined. Alternatively, it may
consist of one or more compilation units that, when
executed, invoke externally-invoked procedures in an
SQL-client module.

4.2.3 SQL-implementations
An SQL-implementation is a processor that executes
SQL-statements, as required by the SQLagent.
An SQL-implementation, as perceived by the SQL-agent,
includes one SQL-client, to which that SQL-agent is
bound, and one or more SQL-servers. An SQL-implementation
can conform to ISO/IEC 9075 without allowing more than one
SQL-server to exist in an SQL-environment. Because an
SQL-implementation can be specified only in terms of how
it executes SQL-statements, the concept denotes an installed
instance of some software (database management system).
ISO/IEC 9075 does not distinguish between features of the
SQL-implementation that are determined by the software vendor
and those determined by the installer.


Regards,


Ann