[#CORE-1693] Error in EXECUTE STATEMENT inside CONNECT / TRANSACTION START triggers

Firebird Core

Error in EXECUTE STATEMENT inside CONNECT / TRANSACTION START triggers

Created: 14/Jan/08 08:45 PM Updated: 20/Apr/11 10:42 AM

Component/s:

Engine

Affects Version/s:

2.1 Alpha 1, 2.1 Beta 1, 2.1 Beta 2, 2.1 RC1

Fix Version/s:

2.5 Alpha 1

Time Tracking:

Not Specified

Issue Links:

Duplicate

This issue is duplicated by:

~~CORE-2178~~ Execute statement in database on connect trigger

Relate

This issue is related to:

~~QA-335~~ Test for CORE-1693

Description

« Hide

By the same reasons already discussed for external languages implementation, EXECUTE STATEMENT doesn't work in CONNECT / TRANSACTION START triggers.

isql -term !
Use CONNECT or CREATE DATABASE to specify a database
SQL> create database 't.fdb'!
SQL> create trigger t_connect on connect as
CON> declare v integer;
CON> begin
CON> execute statement 'select 1 from rdb$database' into v;
CON> end!

isql t.fdb
Statement failed, SQLCODE = -904
invalid database handle (no active connection)
-At trigger 'T_CONNECT' line: 4, col: 3
Use CONNECT or CREATE DATABASE to specify a database

All

Comments

Work Log

Change History

Version Control

Subversion Commits

Sort Order:

[ Permalink | « Hide ]

Alexander Peshkov added a comment - 15/Jan/08 03:29 AM

Adriano, you were telling in Architect that you have an idea how to make it work? Something like creating temporal database handle if permanent is missing - like we do with transactions now?

BTW, TRANSACTION START trigger works except first time when connecting to database. And it makes me wonder - what transaction is started during database attach and is it really worth running TRANSACTION START triggers for it?

[ Permalink | « Hide ]

Adriano dos Santos Fernandes added a comment - 15/Jan/08 03:49 PM

Alex, I was supposing that creating handle in y-valve before calling GDS attach function, and passing direct y-valve handle address to GDS argument handle would be sufficient.

It's not, and reason is related to your question about the first transaction start.

GetWhyAttachment works in DSQL environment, so it don't work correctly if you didn't issued any DSQL command before.

Creating temporal handle solution works, and that completely eliminates GetWhyAttachment function. It would requires we use in the engine the subsystem number 1 to create the handle. Ugly, but not a very big problem for the current code.