Sybase NNTP forums - End Of Life (EOL)

The NNTP forums from Sybase - forums.sybase.com - are now closed.

All new questions should be directed to the appropriate forum at the SAP Community Network (SCN).

Individual products have links to the respective forums on SCN, or you can go to SCN and search for your product in the search box (upper right corner) to find your specific developer center.

problem with ref integrity

6 posts in General Discussion Last posting was on 2007-10-18 04:19:48.0Z
Chris Posted on 2007-10-05 05:12:42.0Z
From: "Chris" <Chris@gmail.com>
Newsgroups: ianywhere.public.general
Subject: problem with ref integrity
Lines: 26
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-RFC2646: Format=Flowed; Original
NNTP-Posting-Host: 125.160.232.242
X-Original-NNTP-Posting-Host: 125.160.232.242
Message-ID: <4705c7ca$1@forums-1-dub>
Date: 4 Oct 2007 22:12:42 -0700
X-Trace: forums-1-dub 1191561162 125.160.232.242 (4 Oct 2007 22:12:42 -0700)
X-Original-Trace: 4 Oct 2007 22:12:42 -0700, 125.160.232.242
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub ianywhere.public.general:6340
Article PK: 4711

just found a problem with our ASA 8.0.1.2600 where ref integrity doesn't
behave as it should

the child has the following setting:
ON UPDATE: Cascase Values
ON DELETE: set null
CHECK ON COMMIT: no
ALLOW NULLS: yes

I have made sure that corresponding foreign key column on child table has
ALLOW NULL checked

The problem is it prevents me to **delete* the corresponding row in parent
table with ASA Error -198 Primary key for row in table 'parent' is
referenced by foreign key 'fk_name' in table 'child'
I was expecting the action to be carried out without error and corresponding
foreign key of child table would have NULL value as a result.

It also prevents me to **update* the parent's primary key where the value
should be cascaded in normal behavior

Can you please shed a light on this matter?

Chris


"Nick Elson" < Posted on 2007-10-05 14:58:54.0Z
From: "Nick Elson" <@@@nick@@@.@@@elson@sybase@@@.@@@com@@@>
Newsgroups: ianywhere.public.general
References: <4705c7ca$1@forums-1-dub>
Subject: Re: problem with ref integrity
Lines: 72
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-RFC2646: Format=Flowed; Response
NNTP-Posting-Host: nicelson-d620.sybase.com
X-Original-NNTP-Posting-Host: nicelson-d620.sybase.com
Message-ID: <4706512e$1@forums-1-dub>
Date: 5 Oct 2007 07:58:54 -0700
X-Trace: forums-1-dub 1191596334 10.25.98.247 (5 Oct 2007 07:58:54 -0700)
X-Original-Trace: 5 Oct 2007 07:58:54 -0700, nicelson-d620.sybase.com
X-Authenticated-User: techsupp
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub ianywhere.public.general:6343
Article PK: 2843

If I understood your set up, that behaviour not expected
at all. Further I do not recognize this as a known bug.
Some RI bugs were fixed after your build, but they are
few and are not reported as exhibiting your behaviour.

Is this an issue with all of the following tests:

1 - tested with the latested 8.0.3 EBF
2 - tested using just dbisql
3 - started up with just `dbeng8 <no_switches> dbname.db`

or does fail only happen inside of a specific context?
[as in using SQL Remote or Mobilink synchronization
or within a specific application]

It wouldn't hurt to try validating and/or rebuilding
your database [to eliminate/identify possible index/db
corruption that may affect this], and to also see if
9.0.2 last ebf [just download the eval. copy if you
don't have this already] behaves the same way.
Also make sure your server is an 8.0.x or higher
and not an older 7.0.x version [where there was 1
bug that could have led to this result].

Since you do seem to be able to reproduce this at will,
I would strip this down to just the two tables in questions
and see what else is involved. Things you may want
to check into are defaults, checks, triggers, procedures/
functions involved with any part of this (triggers/checks),
and if you have anything but the defaults for these options:

WAIT_FOR_COMMIT
OPTIMISTIC_WAIT_FOR_COMMIT (if present at all)
RI_TRIGGER_TIME
FIRE_TRIGGERS ( of if you have the -gf switch on your


If after reducing the repro down to a small example, you still
do not have a resolution, you may want to provide the full
schema details and history of when this started to be noticed.
Knowing the exact DELETE/UPDATE statements and rows
present would also help to flesh this out.

"Chris" <Chris@gmail.com> wrote in message news:4705c7ca$1@forums-1-dub...
> just found a problem with our ASA 8.0.1.2600 where ref integrity doesn't
> behave as it should
>
> the child has the following setting:
> ON UPDATE: Cascase Values
> ON DELETE: set null
> CHECK ON COMMIT: no
> ALLOW NULLS: yes
>
> I have made sure that corresponding foreign key column on child table has
> ALLOW NULL checked
>
> The problem is it prevents me to **delete* the corresponding row in parent
> table with ASA Error -198 Primary key for row in table 'parent' is
> referenced by foreign key 'fk_name' in table 'child'
> I was expecting the action to be carried out without error and
> corresponding foreign key of child table would have NULL value as a
> result.
>
> It also prevents me to **update* the parent's primary key where the value
> should be cascaded in normal behavior
>
> Can you please shed a light on this matter?
>
> Chris
>


Chris Posted on 2007-10-08 05:15:51.0Z
From: "Chris" <Chris@gmail.com>
Newsgroups: ianywhere.public.general
References: <4705c7ca$1@forums-1-dub> <4706512e$1@forums-1-dub>
Subject: Re: problem with ref integrity
Lines: 96
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-RFC2646: Format=Flowed; Response
NNTP-Posting-Host: 125.160.239.187
X-Original-NNTP-Posting-Host: 125.160.239.187
Message-ID: <4709bd07@forums-1-dub>
Date: 7 Oct 2007 22:15:51 -0700
X-Trace: forums-1-dub 1191820551 125.160.239.187 (7 Oct 2007 22:15:51 -0700)
X-Original-Trace: 7 Oct 2007 22:15:51 -0700, 125.160.239.187
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub ianywhere.public.general:6350
Article PK: 2848

I have checked under the following scenario but problem persist:

1. dbisql
2. dbsrv8

within the same database, I created two new tables namely HEADER and DETAIL
but problem persist
Curious, I created a fresh new database to test the RI and to my confusion
the RI behaves normally.

One thing noteworthy is whilst dbsrv8 and dbeng8 running, a list of messages
appear in the small window and there was a line that says
**Database was created using older software and may benefit from being
rebuilt**

I tried to upgrade the database using sybase central and the process
completed successfuly but dbsrv still reports my db as older version

"Nick Elson" <@@@nick@@@.@@@elson@sybase@@@.@@@com@@@> wrote in message
news:4706512e$1@forums-1-dub...
> If I understood your set up, that behaviour not expected
> at all. Further I do not recognize this as a known bug.
> Some RI bugs were fixed after your build, but they are
> few and are not reported as exhibiting your behaviour.
>
> Is this an issue with all of the following tests:
>
> 1 - tested with the latested 8.0.3 EBF
> 2 - tested using just dbisql
> 3 - started up with just `dbeng8 <no_switches> dbname.db`
>
> or does fail only happen inside of a specific context?
> [as in using SQL Remote or Mobilink synchronization
> or within a specific application]
>
> It wouldn't hurt to try validating and/or rebuilding
> your database [to eliminate/identify possible index/db
> corruption that may affect this], and to also see if
> 9.0.2 last ebf [just download the eval. copy if you
> don't have this already] behaves the same way.
> Also make sure your server is an 8.0.x or higher
> and not an older 7.0.x version [where there was 1
> bug that could have led to this result].
>
> Since you do seem to be able to reproduce this at will,
> I would strip this down to just the two tables in questions
> and see what else is involved. Things you may want
> to check into are defaults, checks, triggers, procedures/
> functions involved with any part of this (triggers/checks),
> and if you have anything but the defaults for these options:
>
> WAIT_FOR_COMMIT
> OPTIMISTIC_WAIT_FOR_COMMIT (if present at all)
> RI_TRIGGER_TIME
> FIRE_TRIGGERS ( of if you have the -gf switch on your
>
>
> If after reducing the repro down to a small example, you still
> do not have a resolution, you may want to provide the full
> schema details and history of when this started to be noticed.
> Knowing the exact DELETE/UPDATE statements and rows
> present would also help to flesh this out.
>
> "Chris" <Chris@gmail.com> wrote in message news:4705c7ca$1@forums-1-dub...
>> just found a problem with our ASA 8.0.1.2600 where ref integrity doesn't
>> behave as it should
>>
>> the child has the following setting:
>> ON UPDATE: Cascase Values
>> ON DELETE: set null
>> CHECK ON COMMIT: no
>> ALLOW NULLS: yes
>>
>> I have made sure that corresponding foreign key column on child table has
>> ALLOW NULL checked
>>
>> The problem is it prevents me to **delete* the corresponding row in
>> parent table with ASA Error -198 Primary key for row in table 'parent' is
>> referenced by foreign key 'fk_name' in table 'child'
>> I was expecting the action to be carried out without error and
>> corresponding foreign key of child table would have NULL value as a
>> result.
>>
>> It also prevents me to **update* the parent's primary key where the value
>> should be cascaded in normal behavior
>>
>> Can you please shed a light on this matter?
>>
>> Chris
>>
>
>


Chris Posted on 2007-10-08 07:35:38.0Z
From: "Chris" <Chris@gmail.com>
Newsgroups: ianywhere.public.general
References: <4705c7ca$1@forums-1-dub> <4706512e$1@forums-1-dub> <4709bd07@forums-1-dub>
Subject: Re: problem with ref integrity
Lines: 105
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-RFC2646: Format=Flowed; Response
NNTP-Posting-Host: 125.160.239.187
X-Original-NNTP-Posting-Host: 125.160.239.187
Message-ID: <4709ddca@forums-1-dub>
Date: 8 Oct 2007 00:35:38 -0700
X-Trace: forums-1-dub 1191828938 125.160.239.187 (8 Oct 2007 00:35:38 -0700)
X-Original-Trace: 8 Oct 2007 00:35:38 -0700, 125.160.239.187
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub ianywhere.public.general:6352
Article PK: 2851

Voila just found the culprit (maybe)

the db version is 7.0 but somehow I couldn't upgrade the db using sybase
central

"Chris" <Chris@gmail.com> wrote in message news:4709bd07@forums-1-dub...
>I have checked under the following scenario but problem persist:
>
> 1. dbisql
> 2. dbsrv8
>
> within the same database, I created two new tables namely HEADER and
> DETAIL but problem persist
> Curious, I created a fresh new database to test the RI and to my confusion
> the RI behaves normally.
>
> One thing noteworthy is whilst dbsrv8 and dbeng8 running, a list of
> messages appear in the small window and there was a line that says
> **Database was created using older software and may benefit from being
> rebuilt**
>
> I tried to upgrade the database using sybase central and the process
> completed successfuly but dbsrv still reports my db as older version
>
>
>
> "Nick Elson" <@@@nick@@@.@@@elson@sybase@@@.@@@com@@@> wrote in message
> news:4706512e$1@forums-1-dub...
>> If I understood your set up, that behaviour not expected
>> at all. Further I do not recognize this as a known bug.
>> Some RI bugs were fixed after your build, but they are
>> few and are not reported as exhibiting your behaviour.
>>
>> Is this an issue with all of the following tests:
>>
>> 1 - tested with the latested 8.0.3 EBF
>> 2 - tested using just dbisql
>> 3 - started up with just `dbeng8 <no_switches> dbname.db`
>>
>> or does fail only happen inside of a specific context?
>> [as in using SQL Remote or Mobilink synchronization
>> or within a specific application]
>>
>> It wouldn't hurt to try validating and/or rebuilding
>> your database [to eliminate/identify possible index/db
>> corruption that may affect this], and to also see if
>> 9.0.2 last ebf [just download the eval. copy if you
>> don't have this already] behaves the same way.
>> Also make sure your server is an 8.0.x or higher
>> and not an older 7.0.x version [where there was 1
>> bug that could have led to this result].
>>
>> Since you do seem to be able to reproduce this at will,
>> I would strip this down to just the two tables in questions
>> and see what else is involved. Things you may want
>> to check into are defaults, checks, triggers, procedures/
>> functions involved with any part of this (triggers/checks),
>> and if you have anything but the defaults for these options:
>>
>> WAIT_FOR_COMMIT
>> OPTIMISTIC_WAIT_FOR_COMMIT (if present at all)
>> RI_TRIGGER_TIME
>> FIRE_TRIGGERS ( of if you have the -gf switch on your
>>
>>
>> If after reducing the repro down to a small example, you still
>> do not have a resolution, you may want to provide the full
>> schema details and history of when this started to be noticed.
>> Knowing the exact DELETE/UPDATE statements and rows
>> present would also help to flesh this out.
>>
>> "Chris" <Chris@gmail.com> wrote in message
>> news:4705c7ca$1@forums-1-dub...
>>> just found a problem with our ASA 8.0.1.2600 where ref integrity doesn't
>>> behave as it should
>>>
>>> the child has the following setting:
>>> ON UPDATE: Cascase Values
>>> ON DELETE: set null
>>> CHECK ON COMMIT: no
>>> ALLOW NULLS: yes
>>>
>>> I have made sure that corresponding foreign key column on child table
>>> has ALLOW NULL checked
>>>
>>> The problem is it prevents me to **delete* the corresponding row in
>>> parent table with ASA Error -198 Primary key for row in table 'parent'
>>> is referenced by foreign key 'fk_name' in table 'child'
>>> I was expecting the action to be carried out without error and
>>> corresponding foreign key of child table would have NULL value as a
>>> result.
>>>
>>> It also prevents me to **update* the parent's primary key where the
>>> value should be cascaded in normal behavior
>>>
>>> Can you please shed a light on this matter?
>>>
>>> Chris
>>>
>>
>>
>
>


"Nick Elson" < Posted on 2007-10-09 13:36:29.0Z
From: "Nick Elson" <@@@nick@@@.@@@elson@sybase@@@.@@@com@@@>
Newsgroups: ianywhere.public.general
References: <4705c7ca$1@forums-1-dub> <4706512e$1@forums-1-dub> <4709bd07@forums-1-dub> <4709ddca@forums-1-dub>
Subject: Re: problem with ref integrity
Lines: 140
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2869
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962
X-RFC2646: Format=Flowed; Response
NNTP-Posting-Host: nicelson-d620.sybase.com
X-Original-NNTP-Posting-Host: nicelson-d620.sybase.com
Message-ID: <470b83dd$1@forums-1-dub>
Date: 9 Oct 2007 06:36:29 -0700
X-Trace: forums-1-dub 1191936989 10.25.98.247 (9 Oct 2007 06:36:29 -0700)
X-Original-Trace: 9 Oct 2007 06:36:29 -0700, nicelson-d620.sybase.com
X-Authenticated-User: techsupp
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub ianywhere.public.general:6365
Article PK: 4722

Did the problem go away after the rebuild? For the
rest of this posting I am assuming it did not clear
it up. [Just an FYI. An upgrade is not a rebuild and
in your case that is especially true of the way that
indexes and foreign keys are implemented.]

It is even more confusing that new tables would also
behave this way. I am suspicious there is a more
fundamental problem with that file than just being a V7
format. [it may be even older than that but the behaviour
you are seeing is just wrong].

I would take a copy of the original first, and then try rebuilding
the database using

dbunload -ar

Watch out for probable corruption during your rebuild.

Even if a rebuild seems to work for you, I am suspicious that the
problem is also tied to the old version of the Version 8 software
you are running. Definitely consider to get to latest 8.0.3 ebf.

I do suspect your upgrade attempt simply failed silently. If that
is your case you may even find .dbR and .logR files hanging
around now.

"Chris" <Chris@gmail.com> wrote in message news:4709ddca@forums-1-dub...
> Voila just found the culprit (maybe)
>
> the db version is 7.0 but somehow I couldn't upgrade the db using sybase
> central
>
> "Chris" <Chris@gmail.com> wrote in message news:4709bd07@forums-1-dub...
>>I have checked under the following scenario but problem persist:
>>
>> 1. dbisql
>> 2. dbsrv8
>>
>> within the same database, I created two new tables namely HEADER and
>> DETAIL but problem persist
>> Curious, I created a fresh new database to test the RI and to my
>> confusion the RI behaves normally.
>>
>> One thing noteworthy is whilst dbsrv8 and dbeng8 running, a list of
>> messages appear in the small window and there was a line that says
>> **Database was created using older software and may benefit from being
>> rebuilt**
>>
>> I tried to upgrade the database using sybase central and the process
>> completed successfuly but dbsrv still reports my db as older version
>>
>>
>>
>> "Nick Elson" <@@@nick@@@.@@@elson@sybase@@@.@@@com@@@> wrote in message
>> news:4706512e$1@forums-1-dub...
>>> If I understood your set up, that behaviour not expected
>>> at all. Further I do not recognize this as a known bug.
>>> Some RI bugs were fixed after your build, but they are
>>> few and are not reported as exhibiting your behaviour.
>>>
>>> Is this an issue with all of the following tests:
>>>
>>> 1 - tested with the latested 8.0.3 EBF
>>> 2 - tested using just dbisql
>>> 3 - started up with just `dbeng8 <no_switches> dbname.db`
>>>
>>> or does fail only happen inside of a specific context?
>>> [as in using SQL Remote or Mobilink synchronization
>>> or within a specific application]
>>>
>>> It wouldn't hurt to try validating and/or rebuilding
>>> your database [to eliminate/identify possible index/db
>>> corruption that may affect this], and to also see if
>>> 9.0.2 last ebf [just download the eval. copy if you
>>> don't have this already] behaves the same way.
>>> Also make sure your server is an 8.0.x or higher
>>> and not an older 7.0.x version [where there was 1
>>> bug that could have led to this result].
>>>
>>> Since you do seem to be able to reproduce this at will,
>>> I would strip this down to just the two tables in questions
>>> and see what else is involved. Things you may want
>>> to check into are defaults, checks, triggers, procedures/
>>> functions involved with any part of this (triggers/checks),
>>> and if you have anything but the defaults for these options:
>>>
>>> WAIT_FOR_COMMIT
>>> OPTIMISTIC_WAIT_FOR_COMMIT (if present at all)
>>> RI_TRIGGER_TIME
>>> FIRE_TRIGGERS ( of if you have the -gf switch on your
>>>
>>>
>>> If after reducing the repro down to a small example, you still
>>> do not have a resolution, you may want to provide the full
>>> schema details and history of when this started to be noticed.
>>> Knowing the exact DELETE/UPDATE statements and rows
>>> present would also help to flesh this out.
>>>
>>> "Chris" <Chris@gmail.com> wrote in message
>>> news:4705c7ca$1@forums-1-dub...
>>>> just found a problem with our ASA 8.0.1.2600 where ref integrity
>>>> doesn't behave as it should
>>>>
>>>> the child has the following setting:
>>>> ON UPDATE: Cascase Values
>>>> ON DELETE: set null
>>>> CHECK ON COMMIT: no
>>>> ALLOW NULLS: yes
>>>>
>>>> I have made sure that corresponding foreign key column on child table
>>>> has ALLOW NULL checked
>>>>
>>>> The problem is it prevents me to **delete* the corresponding row in
>>>> parent table with ASA Error -198 Primary key for row in table 'parent'
>>>> is referenced by foreign key 'fk_name' in table 'child'
>>>> I was expecting the action to be carried out without error and
>>>> corresponding foreign key of child table would have NULL value as a
>>>> result.
>>>>
>>>> It also prevents me to **update* the parent's primary key where the
>>>> value should be cascaded in normal behavior
>>>>
>>>> Can you please shed a light on this matter?
>>>>
>>>> Chris
>>>>
>>>
>>>
>>
>>
>
>


Chris Posted on 2007-10-18 04:19:48.0Z
From: "Chris" <Chris@gmail.com>
Newsgroups: ianywhere.public.general
References: <4705c7ca$1@forums-1-dub> <4706512e$1@forums-1-dub> <4709bd07@forums-1-dub> <4709ddca@forums-1-dub> <470b83dd$1@forums-1-dub>
Subject: Re: problem with ref integrity
Lines: 146
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-RFC2646: Format=Flowed; Response
NNTP-Posting-Host: 125.160.233.20
X-Original-NNTP-Posting-Host: 125.160.233.20
Message-ID: <4716dee4@forums-1-dub>
Date: 17 Oct 2007 21:19:48 -0700
X-Trace: forums-1-dub 1192681188 125.160.233.20 (17 Oct 2007 21:19:48 -0700)
X-Original-Trace: 17 Oct 2007 21:19:48 -0700, 125.160.233.20
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub ianywhere.public.general:6431
Article PK: 2890

yes it now worked thanks nick, dbunload did the trick

"Nick Elson" <@@@nick@@@.@@@elson@sybase@@@.@@@com@@@> wrote in message
news:470b83dd$1@forums-1-dub...
> Did the problem go away after the rebuild? For the
> rest of this posting I am assuming it did not clear
> it up. [Just an FYI. An upgrade is not a rebuild and
> in your case that is especially true of the way that
> indexes and foreign keys are implemented.]
>
> It is even more confusing that new tables would also
> behave this way. I am suspicious there is a more
> fundamental problem with that file than just being a V7
> format. [it may be even older than that but the behaviour
> you are seeing is just wrong].
>
> I would take a copy of the original first, and then try rebuilding
> the database using
>
> dbunload -ar
>
> Watch out for probable corruption during your rebuild.
>
> Even if a rebuild seems to work for you, I am suspicious that the
> problem is also tied to the old version of the Version 8 software
> you are running. Definitely consider to get to latest 8.0.3 ebf.
>
> I do suspect your upgrade attempt simply failed silently. If that
> is your case you may even find .dbR and .logR files hanging
> around now.
>
>
>
>
>
>
> "Chris" <Chris@gmail.com> wrote in message news:4709ddca@forums-1-dub...
>> Voila just found the culprit (maybe)
>>
>> the db version is 7.0 but somehow I couldn't upgrade the db using sybase
>> central
>>
>> "Chris" <Chris@gmail.com> wrote in message news:4709bd07@forums-1-dub...
>>>I have checked under the following scenario but problem persist:
>>>
>>> 1. dbisql
>>> 2. dbsrv8
>>>
>>> within the same database, I created two new tables namely HEADER and
>>> DETAIL but problem persist
>>> Curious, I created a fresh new database to test the RI and to my
>>> confusion the RI behaves normally.
>>>
>>> One thing noteworthy is whilst dbsrv8 and dbeng8 running, a list of
>>> messages appear in the small window and there was a line that says
>>> **Database was created using older software and may benefit from being
>>> rebuilt**
>>>
>>> I tried to upgrade the database using sybase central and the process
>>> completed successfuly but dbsrv still reports my db as older version
>>>
>>>
>>>
>>> "Nick Elson" <@@@nick@@@.@@@elson@sybase@@@.@@@com@@@> wrote in message
>>> news:4706512e$1@forums-1-dub...
>>>> If I understood your set up, that behaviour not expected
>>>> at all. Further I do not recognize this as a known bug.
>>>> Some RI bugs were fixed after your build, but they are
>>>> few and are not reported as exhibiting your behaviour.
>>>>
>>>> Is this an issue with all of the following tests:
>>>>
>>>> 1 - tested with the latested 8.0.3 EBF
>>>> 2 - tested using just dbisql
>>>> 3 - started up with just `dbeng8 <no_switches> dbname.db`
>>>>
>>>> or does fail only happen inside of a specific context?
>>>> [as in using SQL Remote or Mobilink synchronization
>>>> or within a specific application]
>>>>
>>>> It wouldn't hurt to try validating and/or rebuilding
>>>> your database [to eliminate/identify possible index/db
>>>> corruption that may affect this], and to also see if
>>>> 9.0.2 last ebf [just download the eval. copy if you
>>>> don't have this already] behaves the same way.
>>>> Also make sure your server is an 8.0.x or higher
>>>> and not an older 7.0.x version [where there was 1
>>>> bug that could have led to this result].
>>>>
>>>> Since you do seem to be able to reproduce this at will,
>>>> I would strip this down to just the two tables in questions
>>>> and see what else is involved. Things you may want
>>>> to check into are defaults, checks, triggers, procedures/
>>>> functions involved with any part of this (triggers/checks),
>>>> and if you have anything but the defaults for these options:
>>>>
>>>> WAIT_FOR_COMMIT
>>>> OPTIMISTIC_WAIT_FOR_COMMIT (if present at all)
>>>> RI_TRIGGER_TIME
>>>> FIRE_TRIGGERS ( of if you have the -gf switch on your
>>>>
>>>>
>>>> If after reducing the repro down to a small example, you still
>>>> do not have a resolution, you may want to provide the full
>>>> schema details and history of when this started to be noticed.
>>>> Knowing the exact DELETE/UPDATE statements and rows
>>>> present would also help to flesh this out.
>>>>
>>>> "Chris" <Chris@gmail.com> wrote in message
>>>> news:4705c7ca$1@forums-1-dub...
>>>>> just found a problem with our ASA 8.0.1.2600 where ref integrity
>>>>> doesn't behave as it should
>>>>>
>>>>> the child has the following setting:
>>>>> ON UPDATE: Cascase Values
>>>>> ON DELETE: set null
>>>>> CHECK ON COMMIT: no
>>>>> ALLOW NULLS: yes
>>>>>
>>>>> I have made sure that corresponding foreign key column on child table
>>>>> has ALLOW NULL checked
>>>>>
>>>>> The problem is it prevents me to **delete* the corresponding row in
>>>>> parent table with ASA Error -198 Primary key for row in table 'parent'
>>>>> is referenced by foreign key 'fk_name' in table 'child'
>>>>> I was expecting the action to be carried out without error and
>>>>> corresponding foreign key of child table would have NULL value as a
>>>>> result.
>>>>>
>>>>> It also prevents me to **update* the parent's primary key where the
>>>>> value should be cascaded in normal behavior
>>>>>
>>>>> Can you please shed a light on this matter?
>>>>>
>>>>> Chris
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>