I added a simple check constraint to a table that contained some rows violating the constraint; I was expecting to be blocked by the engine due to an integrity check of old data but the schema was saved without warning. The constraint works as expected on new insertions or updates. Is it the expected behavior?
I'm using: XAMPP 3.3 (Windows 10), MariaDB 10.4.21, and SQLYog community edition as frontend
Yes this is expected behaviour as a CHECK constraint will
Before a row is inserted or updated, all constraints are evaluated in the order they are defined.
manual
As the old data are already inserted you will not get a an error message of a violation.
You can run a SELECT to check for all violations and update them accourding to a plan, or or could rename the old table create a new one with the old name and insert all data, this will stop when you hit a constraint, but the forst way is more secure
Related
I imported data into a MariaDB database while foreign key constraint checks were disabled. Those checks were enabled afterwards. However, some data in the database seems to be corrupt in the sense that the foreign key constraints are not satisfied.
I tried to use the mysqlcheck tool to verify all tables, but this does not produce any error output. Also running CHECK TABLE someTable does not show any errors or warnings.
Still I can manually show data not being correct, for example by performing a query:
select count(*) from some_table where id not in (select id from related_table)
where some_table has a foreign key constraint to related_table by id.
How do I fix this?
I have an odd issue with foreign keys. I am trying to perform the following query:
ALTER TABLE [GroupMember] FOREIGN KEY ([Group]) REFERENCES [Group]([GUID])
Which gives me the following error:
The ALTER TABLE statement conflicted with the FOREIGN KEY constraint "FK__GroupMember__Group__0D25C822". The conflict occurred in database "x", table "dbo.Group", column 'GUID'.
I then verified the existing things, which I have confirmed are all ok:
Referenced table (dbo.Group) has a defined PRIMARY KEY on [GUID] column
Referencing table (dbo.GroupMember) has no [Group]-values which do not exist in [GUID]-column of dbo.Group-table
No similarly referencing foreign keys exist already
From here on, I experimented. Taking some rows in and out, wiping the table, truncating the table. What I can conclude so far:
If I wipe the referencing table using DELETE FROM [GroupMember]; then try to apply the FK constraint, I receive the same error message
If I truncate the referencing table using TRUNCATE TABLE [GroupMember];, I can apply the FK constraint without errors. Additionally, I am able to reinsert the exact same data after applying the FK constraint, without problems.
From this I can conclude that the data itself is not the problem. Can anyone make sense of this? Why am I able to apply the constraint after truncating the table, but not after deleting all records?
If you are using Microsoft SSMS check whether unchecking "Prevent saving changes that require table re-creation" solves the problem. You'll find this in Options > Designers > Table and Database Designers.
I have had similar issues that have been resolved by this. Let me know if it works or not.
Good luck.
I'm really stumped on this one. We had a table with a two part primary key. The parts were a review_id (a foreign key from another table) and a time-stamp. Whoever designed this table didn't realize that some situations could result in two entries having identical time-stamps, and I was getting "ORA-00001: unique constraint" errors.
However, as this table was a log, it had no real need to have a primary key in the first place, so I removed the primary key constraint. Despite this constraint no longer existing, I'm still getting the same error.
I've tried adding elements to the PK to prevent the conflict as well as restoring the constraint but disabling it. Oracle SQL Developer insists that the database reflects the changes I've made, but the behavior suggests that it's still using the original PK. I thought it might be a caching problem, but even a complete reboot of my computer doesn't change it.
Any advice is appreciated.
An example of the commands I've run:
alter table "DATABASE"."DB_REVIEW_LOG" drop constraint "DB_REVIEW_LOG_PK";
update database.db_review_log set review_id=17494 where review_id = 17495;
and this is what I get back:
Error starting at line : 2 in command -
update database.db_review_log set review_id=17494 where review_id = 17495
Error report -
SQL Error: ORA-00001: unique constraint (DATABASE.DB_REVIEW_LOG_PK) violated
00001. 00000 - "unique constraint (%s.%s) violated"
*Cause: An UPDATE or INSERT statement attempted to insert a duplicate key.
For Trusted Oracle configured in DBMS MAC mode, you may see
this message if a duplicate entry exists at a different level.
*Action: Either remove the unique restriction or do not insert the key.
Turns out that despite it complaining about a constraint, the problem was a unique index with the same name that was causing the problems.
Thank you, Justin Cave
I have an issue related to data in sql server. In my database some of the constraint were not enabled i.e. they were not checked , After some time working on it we found this issue that a parent rows can be deleted without deleting child, which was an issue. I enabled all the constraint in the database using query
ALTER TABLE tbl_name CHECK CONSTRAINT ALL
above query was executed on all the tables of that database without any error . But my concern is whether it will work or not , if it will work on the existing data then what will happen to that data whose parent table data has been deleted.
I want to know is there any way such that I can validate such data data whose parent record doesn't exist in the entire database. There are about 270 constraint containing FOREIGN KEY AND UNIQUE KEY . I don't want to go for manual option.
Please help me out.
ALTER TABLE tbl_name CHECK CONSTRAINT ALL
only re-enables the constraints. Importantly, the constraints are not checked against the existing data in the database (nor are they trusted by the optimizer). If you want that to occur, you need to specify WITH CHECK as well:
ALTER TABLE tbl_name WITH CHECK CHECK CONSTRAINT ALL
(And yes, the word CHECK appears twice)
If you execute this, and there are orphaned child rows (or other invalid constraints), then the ALTER TABLE will fail with an error message. There's nothing SQL Server can do to fix this issue - it's for you to decide whether to a) remove the orphaned rows, or b) to re-create, in some manner, a suitable parent row for them.
You can also add the 'ON DELETE CASCADE' code to the end of foreign keys to prevent orphaned child rows from persisting.
This is more of a 'better practice' going forward than a solution, but I believe Damien_The_Unbeliever has answered your main question.
Here's a strange one. I'm using SubSonic 2.0.3 to insert a new row into a given table.
The table includes an int identity field that is set up properly in the database (Identity seed = 1, Identity increment = 1). Obviously I do not explicitly set this value before calling .Save().
Ever since I rebuilt my development DB (copying from my prod DB), the .Save() fails with the message:
"The INSERT statement conflicted with the CHECK constraint \"repl_identity_range_tran_661577395\". The conflict occurred in database \"blah\", table \"dbo.ScheduledEmails\", column 'MyIdentity'"
The database is replicated, and I didn't explicitly create that constraint. To be honest, I don't understand the constraint, since the condition is ([MyIdentity]>(7) AND [MyIdentity]<(20000)). The constraint from the Prod DB has different numbers, but it's the same format as this one from my Dev DB.
Any clues about this bizarre issue?