At 12:15 AM 31/03/2006, you wrote:

>Thank you, Helen, I'll remake my question with some more details.
>I was using Delphi 7 + SQL Server, now I've changed to Delphi7 +
>FireBird 1.5 + IBO
>1) Using SQL Server
>In Delphi program I have a TADOConnection.
>It's Connection String contains some parameters, like User, Password,
>Initial Catalog, etc, and a particular one that I use for my own
>purposes called Application Name.
>In Delphi program, before opening ADO connection, I set Application
>Name equal to a string containing some variables (not only the
>application name itself).
>In SQL Server, there is a built-in function called APP_NAME() that
>retrieves that string value. When Delphi program changes something in a
>table, SQL Server fires a before update trigger and inside the trigger
>I can use APP_NAME() function to know that string value and this way I
>am able to know change's origin and choose between some alternatives.
>2) Using FireBird 1.5 + IBO
>The question is:
>Has FireBird 1.5 some built-in function that allows me to act the same
>way as with SQL Server ? (it should be a function that retrieves some
>string value that I've setted in a Delphi program using a
>TIB_Connection)

No. A Firebird database is totally independent of the applications
that access it. Actually, it makes my flesh crawl even to consider
that one would put trigger actions on tables that were conditional on
the application that was modifying the tables. It's a terribly
Microsoftish thing to do and makes a joke out of ACID
compliance. It violates both consistency and durability principles
and arguably, atomicity as well.

It would be a far, far better thing to turn the thing around, in the
interests of good database design, and determine behaviour according to ROLE.

./heLen