CHECK ON COMMIT

[David]

Tyson, thanks for the guidance; this does not appear to be related to my
issue, my foreign key HAS "CHECK ON COMMIT" explicitly coded and it was
inappropriately firing after the update instead of after the commit. I
read about wait_for_commit and if I understand what I read this is a
global override for all foreign keys that in effect places CHECK ON
COMMIT in every foreign key whether it is actually coded there or not.
Per my latest note before this I have reworked my foreign keys reducing
the number of varchars > 128 bytes in each key. This seems to hare
resolved the error in both V11 and V12. So I have a successful
workaround for this issue.

Thanks again for your assistance.

David,
What you may be looking is the wait_for_commit option. You can set this
on a connection basis or for the PUBLIC group. If you turn this option
'On', the foreign keys won't be checked until a COMMIT is issued.
http://dcx.sybase.com/index.html#1101en/dbadmin_en11/wait-for-commit-option.html*d5e32947
-Tyson

Is there something in SQL ANYWHERE that would cause CHECK ON COMMIT when
coded in a foreign key (and it appears in the Sybase Central properties
page as CHECK ON COMMIT : Yes) to fire after the update statement (in a
trigger) instead of after the commit is issued. I have debug messages in
each of the table to table update triggers and I have confirmed this is
happening.
This happens in the current version of SQL Anywhere 11.0.1.2452 as well
as SQL Anywhere 12.0.0.2483 I just downloaded and tested. The problem is
with more than 1 foreign key.
This problem was observed in SQLANYWHERE 11 before version 12 was
downloaded.
Thanks in advance for any ideas.

[David]

On 2010/07/13 17:32, David wrote:


The data was consistent on the reload -- the assertion error appears to
be a software problem not an application problem.

Per my concerns about varchar fields I did some significant rework to my
foreign keys and updates (triggers) reducing the number of varchars >
128 bytes per foreign key. The change was successful therefore this
issue has a successful workaround from my perspective.

I never did explain the trigger firing at the inappropriate time ==
however once I reduced the number of varchar fields that issue just went
away without explanation.


Thanks to those who responded.

[Glenn Paulley [Sybase iAnywhere]]

David - I am very interested in investigating this problem. Do you have
a repro that you would be willing be share?

Glenn

Post by David
The data was consistent on the reload -- the assertion error appears to
be a software problem not an application problem.
Per my concerns about varchar fields I did some significant rework to my
foreign keys and updates (triggers) reducing the number of varchars >
128 bytes per foreign key. The change was successful therefore this
issue has a successful workaround from my perspective.
I never did explain the trigger firing at the inappropriate time ==
however once I reduced the number of varchar fields that issue just went
away without explanation.
Thanks to those who responded.

--
Glenn Paulley
Director, Engineering (Query Processing)
Sybase iAnywhere

Blog: http://iablog.sybase.com/paulley

EBF's and Patches: http://downloads.sybase.com
choose SQL Anywhere Studio >> change 'time frame' to all

To Submit Bug Reports: http://case-express.sybase.com

SQL Anywhere Studio Supported Platforms and Support Status
http://my.sybase.com/detail?id=1002288

Whitepapers, TechDocs, and bug fixes are all available through the
Sybase iAnywhere pages at
http://www.sybase.com/products/databasemanagement/sqlanywhere/technicalsupport

[David]

Post by Glenn Paulley [Sybase iAnywhere]
David - I am very interested in investigating this problem. Do you have
a repro that you would be willing be share?
Glenn

Post by David
The data was consistent on the reload -- the assertion error appears
to be a software problem not an application problem.
Per my concerns about varchar fields I did some significant rework to
my foreign keys and updates (triggers) reducing the number of varchars

128 bytes per foreign key. The change was successful therefore this

issue has a successful workaround from my perspective.
I never did explain the trigger firing at the inappropriate time ==
however once I reduced the number of varchar fields that issue just
went away without explanation.
Thanks to those who responded.

Glenn; I will see what I can do but it may take a day or two and the DB
is sizeable. I left the entries commented in the indicies with the
problem so I should be able to reverse one.