I'm deleting this row from a table and it has a bunch of cascades on the FKs and eventually it gives me this error:
ERROR: insert or update on table "foo_route" violates foreign key constraint "foo_route_bar_fk"
SQL state: 23503
Detail: Key (bar_key)=(2176) is not present in table "bar".
foo_route_bar_fk is defined like this:
ALTER TABLE foo_route
ADD CONSTRAINT foo_route_bar_fk FOREIGN KEY (bar_key) REFERENCES bar (bar_key)
MATCH SIMPLE ON UPDATE NO ACTION ON DELETE CASCADE;
I'm getting this error by deleting a table unrelated to both of these. I think what's happening is a trigger or a cascade is causing this error, but it's difficult to find out why.
My question is, how do you debug issues like this in postgresql? What are the series of steps that caused this error? Postgresql only tells me the result of the last thing it did before it failed. If this were code the error would give an extremely helpful stack trace. Is there a way to see something like that in Postgresql?
Typically your postgresql log will include the statement which triggered the error. That should allow you to follow the chains of cascading events.
One thing I would suggest however is that you might want to draw out a map of fkeys and look at the mappings of ON events on foreign keys. If it were me I would start with a schema only dump or pg_autodoc output, and go from there. The obvious problem is that you have deletes cascading in cases where it can't so you need to take a look and rethink things here.
Related
I was querying against SQL Server to get all columns, that are referenced to other columns. By accident I saw, that the column "tenantId" (table "AbpUsers") is not referenced to AbpTenants.Id.
I asked some of my collegues, that are "used" to know aspnetboilerplate, just to clarify. Everyone was surprised, as I am.
Just for testing purposes I created a new database by "Update-database". Before running the application, I added the "missing" foreign-Key-reference manually. And? Nothing happened. Nothing bad happened. Everything works, as it did without the foreign-key-reference...
ALTER TABLE [dbo].[AbpUsers] WITH CHECK ADD CONSTRAINT [FK_AbpUsers_AbpTenants_TenantId] FOREIGN KEY([TenantId])
REFERENCES [dbo].[AbpTenants] ([Id])
GO
ALTER TABLE [dbo].[AbpUsers] CHECK CONSTRAINT [FK_AbpUsers_AbpTenants_TenantId]
GO
As expected my whole application works fine, even when the initial content builder is running.
Keys exist mainly to protect referential integrity of the database. If you have no Cascade Update or Cascade Delete options on, then maybe this key was removed to make deleting things easier for someone who did not know what they were doing.
I recently received a case which my client came across the ORA-00001: unique constraint violated error. This happened when a program tried to truncate two tables and then insert data into them.
From the error-log file, the truncate step was completed,
delete from INTERNET_GROUP
delete from INTERNET_ITEM
BUT right after this, the insertion to the Internet_group table triggered the ORA-00001 error. I am wondering if there is any database settings related to this error? I never used Oracle and am wondering if Oracle puts a lock on a row with SELECT statement, in which case the row is locked and not deleted somehow? Any help is appreciated.
Please know that there is a difference between truncate and delete. You say you truncated the table, but you mention "delete from" . That is entirely different.
If you're sure you want to empty the tables, try replacing with
truncate table internet_group reuse storage;
Mind you that a commit is not necessary with the truncate statement as this is considered a DDL (data definition language) statement and not a DML (Data modification language) statement like updates and deletes.
Also, there is no row locking on selects. But changes are only applied and visible for other sessions in the database when commit-ed.
I guess that is wat happened; you deleted the records but did not execute a commit (yet) and subsequently inserted new records.
edit:
I now realize you're probably inserting multiple records....
The other option might be, that the data itself causes a violation. Can you please provide the constraints on the table? There must be a primary key or unique constraint. You might want to hold that against your dataset.
This error: Message: oci_execute (): ORA-00001: unique constraint (SCHEMA_NAME.NAME CONSTRAINT) violated
I wonder if I do not how to handle the error more simply, more generic.
Because otherwise I will have to work on each function of the models to check the data before adding, for no duplications and not give the error noted above.
Does anyone know a simple way to solve this?
Thanks.
There is a hint that can be specified that will allow the statement to succeed without inserting the duplicated data. It can be useful for replication or bulk data loading where the job may attempt to insert the same data multiple times. I wouldn't recommend it as part of a user application.
"The IGNORE_ROW_ON_DUPKEY_INDEX hint applies only to single-table INSERT operations. It is not supported for UPDATE, DELETE, MERGE, or multitable insert operations. IGNORE_ROW_ON_DUPKEY_INDEX causes the statement to ignore a unique key violation for a specified set of columns or for a specified index. When a unique key violation is encountered, a row-level rollback occurs and execution resumes with the next input row."
The diagram has over 40 tables, most of them have a primary key defined.
For some reason there is this one table, which has a primary key defined, but that's being ignored when I export the model to a DDL script.
This is the "offending" key (even though it's checked it is nowhere to be found on the generated DDL script):
Has anybody had the same problem? Any ideas on how to solve it?
[EDIT] This is where the key is defined:
And this is the DDL preview (yes, the primary key shows up there):
This is what happens if I try to generate the DDL for just that table (primary key still not generated):
I was finally able to identify and reproduce the problem.
It was a simple conflict of constraints.
Table MIEMBROS had a mandatory 1 to n relationship (foreign key) from another table on its primary key column and vice-versa (there was a foreign key on MIEMBROS against the other table's primary key).
This kind of relationship between two tables makes it impossible to add a record to any of them: The insert operation will return an error complaining about the foreign key restriction pointing the other table.
Anyway I realized that one of the relationships was 0 to n so I simply unchecked the "mandatory" checkbox on the foreign key definition and everything went fine.
So, in a nutshell: The Data Modeler "fails" silently if you are defining a mutual relationship (two foreign keys, one on each table against the other table) on non nullable unique columns, by not generating the primary key of one of the tables.
Such an odd behavior, if you ask me!
"This kind of relationship between two tables makes it impossible to add a record to any of them: The insert operation will return an error complaining about the foreign key restriction pointing the other table."
Actually, if you have deferred constraints, this is not impossible. The constraints can be enforced, for example, at commit time rather than immediately at insert time.
From the Data Modeler menu under File, I used Export -> DDL File. The keys appeared in the DDL, then when I went back to the diagram and did DDL Preview, it showed all the missing stuff.
We have a table TRANSMISSIONS(ID, NAME) which behaves funny in the following ways:
The statement to add a foreign key in another table referencing TRANSMISSIONS.ID won't finish
The statement to add a column to TRANSMISSIONS won't finish
The statement to disable/drop a unique constraint won't finish
The statement to disable/drop a trigger won't finish
TRANSMISSION's primary key is ID, there is also a unique constraint on NAME - therefore there are indexes on ID and NAME. We also have a trigger which creates values for column ID using a sequence, so that INSERT statements do not need to provide a value for ID.
Besides TRANSMISSIONS, there are two more tables behaving like this. For other tables, the above-mentioned statements work fine.
The database is used in an application with Hibernate and due to an incorrect JPA configuration we produced high values for ID during a time. Note that we use the trigger only for "manual" INSERT statements and that Hibernate produces ID values itself, also using the sequence.
The first thought was that the problems were due to the high IDs but we have the problems also with tables that never had such high IDs.
Anyways we suspected that the indexes might be fragmented somehow and called ALTER INDEX TRANSMISSIONS_PK SHRINK SPACE COMPACT, which ran through but showed no effect.
Also, we wanted to call ALTER TABLE TRANSMISSIONS SHRINK SPACE COMPACT which didn't work because we needed to call first ALTER TABLE TRANSMISSIONS ENABLE ROW MOVEMENT which never finished.
We have another instance of the database which does not behave in such a funny way. So we think it might be that in the course of running the application the database got somehow into an inconsistent state.
Does someone have any suggestions what might have gone out of control/into an inconsitent state?
More hints:
There are no locks present on any objects in the database (according to information in v$lock and v$locked_object)
We tried all these statements in SQL Developer and also using SQLPlus (command-line tool).