From: | Paul Thomas <paul(at)tmsl(dot)demon(dot)co(dot)uk> |
---|---|
To: | "Nigel J (dot) Andrews" <nandrews(at)investsystems(dot)co(dot)uk> |
Cc: | "pgsql-general (at) postgresql (dot) org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Incomprehensible behaviour of a foreign key. |
Date: | 2003-07-20 13:55:21 |
Message-ID: | 20030720145521.C5293@bacon |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 20/07/2003 14:15 Nigel J. Andrews wrote:
>
> As usual I forgot to include the version number. It's 7.3.3
> >
> > I'd really appreciate an explanation, since this test is based on
> queries
> > extracted from the db log, is only one specific example of this sort of
> > operation from many in the driving program and most significantly it
> seems I
> > can't even write sql statments hardcoding these values as the test
> script shows
> > they still get the ref. int. error.
A bit more detail about the tables might be helpful, constraints, triggers
etc... How about doing a select of site_membership immediately before the
delete. What does that show? Have you got a trigger somewhere that would
insert a record into site_membership? This could cause the RI failure but,
without the transaction being committed, the inserted record could be
discarded and the table would still appear empty after the error. I'm very
much clutching at straws here and am probably way off but without more
details, wild guesses are the best I can do.
HTH
--
Paul Thomas
+------------------------------+---------------------------------------------+
| Thomas Micro Systems Limited | Software Solutions for the Smaller
Business |
| Computer Consultants |
http://www.thomas-micro-systems-ltd.co.uk |
+------------------------------+---------------------------------------------+
From | Date | Subject | |
---|---|---|---|
Next Message | Nigel J. Andrews | 2003-07-20 14:10:09 | Re: Incomprehensible behaviour of a foreign key. |
Previous Message | Nigel J. Andrews | 2003-07-20 13:52:44 | Re: Incomprehensible behaviour of a foreign key. |