Bruce,

Still begs the question had did the deposit table record acquire an invalid 
"fymid" record.
Since a PK and FK constraint existed an invalid FK -> PK should not be possible.

Jim Bentley,
American Celiac Society
1-504-737-3293

--------------------------------------------
On Mon, 10/14/13, Bruce A. Chitiea <[email protected]> wrote:

 Subject: [RBASE-L] - Re: Ref Integrity Violation?: Solved
 To: "RBASE-L Mailing List" <[email protected]>
 Date: Monday, October 14, 2013, 5:08 PM
 
 Bill:
  Sure enough ...
  SELECT * FROM deposit +WHERE fymid NOT IN +(SELECT fymid FROM
 fymonth)  ... returns one row from table:
 deposit where FK fymid does indeed have a value not in the
 PK column.  The UPDATE worked down to that
 record, then errored out with the proper message, which I
 assumed implicated the PK value.
  Gotta admit, this was
 yesterday’s careless edit. Today’s R:List
 session results from my assumption that the underlying FK
 data was correct.
  A good education. Thanks everyone,
 sincerely, for your help.
  Bruce
  From: [email protected] [mailto:[email protected]]
 On Behalf Of Bill Downall
 Sent: Monday, October 14, 2013 2:52 PM
 To: RBASE-L Mailing List
 Subject: [RBASE-L] - Re: Ref Integrity
 Violation?
  Bruce,   Try a query, see if you can
 find a row with corrupted data.  SELECT * FROM fktable WHERE
 fkcolumn NOT IN (SELECT pkcolumn FROM
 pktable)
    On Mon, Oct 14, 2013 at 5:47
 PM, Bruce A. Chitiea <[email protected]>
 wrote:Razzak et al:
 
 Yes, there must be other issues.
 
 1. Performed a RELOAD, worked on the reloaded database.
 2. Dropped the FK
 3. Performed the UPDATE, success
 4. Attempted to create the new FK. Trouble.
 
 Will do a full UNLOAD and poke around a bit.
 Thanks very much.
 
 Bruce
 
 -----Original Message-----From: [email protected]
 [mailto:[email protected]]
 On Behalf Of A. Razzak
 MemonSent: Monday, October 14, 2013
 1:52 PM
 To: RBASE-L Mailing List
 Subject: [RBASE-L] - Re: Ref Integrity
 Violation?At 04:47 PM 10/14/2013, Bruce
 A. Chitiea wrote:
 
 >I'm going to do an UNLOAD/RELOAD on the database ...
 way overdue, anyway.
 
 Bruce,
 
 There must be other circumstances to your database as we are
 to perform the
 same update on the foreign key table values as long as the
 new values exist
 in the primary key table.
 
 Perhaps the data needs to be verified.
 
 Hope that provides you with some blue's clues ...
 
 Very Best R:egards,
 
 Razzak.
 
 www.rbase.com
 www.facebook.com/rbase
 --
 30+ years of continuous innovation!
 15 Years of R:BASE Technologies, Inc. making R:BASE what it
 is today!
 --
 
 
  


Reply via email to