Hello, All.
Must multiple error handlers be allowed for the same block?
I.e. something like this:
BEGIN
WHEN SQLCODE -803 DO
WHEN GDSCODE isc_key_violation DO
WHEN ANY DO .
END
--
WBR, SD.
On Fri, 09 May 2014 11:15:36 +0200, Dimitry Sibiryakov s...@ibphoenix.com
wrote:
Hello, All.
Must multiple error handlers be allowed for the same block?
I.e. something like this:
BEGIN
WHEN SQLCODE -803 DO
WHEN GDSCODE isc_key_violation DO
WHEN ANY DO .
END
09.05.2014 13:52, Mark Rotteveel wrote:
So although multiple WHENs might be handy, they are - afaik - currently
not allowed, and this limitation can be worked around.
Actually, according to my test, they are allowed now, but their behavior
seems strange
to me. That's why I ask.
For
09.05.2014 14:37, Dmitry Yemanov wrote:
They were always allowed, so we cannot even think about breaking this.
The only thing that may be treated like a bug is CORE-3275.
Ok. From your comment in the ticket I conclude that _every_ matching handler
must be
executed. Am I right?
I.e. in
09.05.2014 16:45, Dimitry Sibiryakov wrote:
09.05.2014 14:37, Dmitry Yemanov wrote:
They were always allowed, so we cannot even think about breaking this.
The only thing that may be treated like a bug is CORE-3275.
Ok. From your comment in the ticket I conclude that _every_ matching handler
09.05.2014 15:37, Dmitry Yemanov wrote:
Looking at the code, the problem is that the first successfully matched
WHEN block clears the status vector, so only WHEN ANY can be matched
after that. And this code (inherited from InterBase) seems to be written
intentionally.
BTW, this is not the
Hello, All.
What following asserts are supposed to check? My debug build is falling into
them every
time I try to check (almost fresh) database.
switch (REL.RDB$RELATION_TYPE)
{
case rel_persistent:
break;
case rel_external:
Rollback to wrong savepoint if several exception handlers on the same level are
executed
Key: CORE-4424
URL: http://tracker.firebirdsql.org/browse/CORE-4424
I was referring to cases where the disk controller has ignored the engine
careful write order, by collapsing disk sector writes and applying them in a
sequence optimal for the disk but out of order from a FB perspective (Jim's
comment about micro code optimization).
In that case, the
09.05.2014 20:08, Leyne, Sean wrote:
I was referring to cases where the disk controller has ignored the engine
careful write order, by collapsing disk sector writes and applying them in
a
sequence optimal for the disk but out of order from a FB perspective (Jim's
comment about micro code
09.05.2014 18:13, Dimitry Sibiryakov wrote:
What following asserts are supposed to check?
That the relation type is assigned properly and, additionally, that the
proper flags are already set by the prior MET_lookup_* calls.
My debug build is falling into them every time I try to check
09.05.2014 19:37, Dmitry Yemanov wrote:
What is check database? Validate with gfix?
Yes, gfix -full
case rel_global_temp_delete:
fb_assert(relation-rel_flags REL_temp_tran);
What exactly asserts do you see fired?
This one. I just run isql -i oltp_ddl.sql and then
12 matches
Mail list logo
