Jim: Good point. That Deposit table had been pretty stable, although I made a major change on Saturday, adding a column.
I'll think on that tonight. Thanks Bruce -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of James Bentley Sent: Monday, October 14, 2013 4:49 PM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: Ref Integrity Violation?: Solved 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! --
