I am evaluating a Laravel/PHP component meant to manage tree data in a SQL database using the "closure Table" design pattern. Code repository: https://github.com/franzose/ClosureTable
Oh my, this component gives me endless headaches. After some installation hickups (Lifetime cost: 2 days ...) I got one little step forward, and ran into what seems to be a really serious compatibility problem with the Microsoft SQL server. When the database ist created through the migration provided by the component, I get the following fatal SQL error:
[Illuminate\Database\QueryException]
SQLSTATE[42000]: [Microsoft][ODBC Driver 11 for SQL Server][SQL
Server]Introducing FOREIGN KEY constraint 'pages_parent_id_foreign' on
table 'pages' may cause cycles or multiple cascade paths. Specify ON
DELETE NO ACTION or ON UPDATE NO ACTION, or modify other FOREIGN KEY
constraints. (SQL: alter table "pages" add constraint
"pages_parent_id_foreign" foreign key ("parent_id") references "pages"
("id") on delete set null)
A similar problem has been described here:
Foreign key constraint may cause cycles or multiple cascade paths?
Anyone having an idea how I can fix this, without breaking the component?
Thnx, Armin.
P.S. I also filed an issue hoping to get teh developer's attraction: Link to Git issue
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.
When I tries to add the simple product to configurable product I am getting the below error
SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or
update a child row: a foreign key constraint fails
(db_mydb.catalog_product_super_link, CONSTRAINT
FK_CAT_PRD_SPR_LNK_PRD_ID_CAT_PRD_ENTT_ENTT_ID FOREIGN KEY
(product_id) REFERENCES catalog_product_entity (entity_id) ON DELE)
But this was working perfectly before. Anyone has idea, What could be the reason.?
Much appreciated your help.
But this was working perfectly before
Step one would be "what have you changed since before"? Installing custom extensions may change system behavior, so if you've installed anything recently (or even if you haven't, it's possible the bug's been lurking but you hadn't tried the specific save code path before) try disabling extensions in a development environment until the error doesn't happen anymore.
It's also worth checking out your catalog_product_super_link table and the specific query that's running when you get this foreign constraint error. It sounds like Magento tried to remove a product from this table, catalog_product_super_link, but doing do would cause a data integrity violation.
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.
I am attempting to upgrade a clients Magento to v1.7 (from v1.4). I have had a couple of minor blips along the way, but nothing too tragic.... until now.
My upgrade route is to copy the existing v1.4 database and install a fresh version of 1.7. Then running the standard upgrade script, the database should get upgraded to v1.7 (except of course any installed extensions which will need re installing following the upgrade). This is a route I have used before and seems far more reliable that upgrading via magento connect.
However, I have hit a brick wall. I am getting the following error report:
a:5:{i:0;s:464:"Error in file: "/route/to/magento/install/app/code/core/Mage/Cms/data/cms_setup/data-upgrade-1.6.0.0.0-1.6.0.0.1.php" - SQLSTATE[23000]: Integrity constraint violation: 1452 Cannot add or update a child row: a foreign key constraint fails (`magento_1411_1702/cms_page_store`, CONSTRAINT `FK_CMS_PAGE_STORE_STORE_ID_CORE_STORE_STORE_ID` FOREIGN KEY (`store_id`) REFERENCES `core_store` (`store_id`) ON DELETE CASCADE ON UPDATE CASCAD)";i:1;s:1095:"#0 /route/to/magento/install/app/code/core/Mage/Core/Model/Resource/Setup.php(645): Mage::exception('Mage_Core', 'Error in file: ...')
Now this infers to me that there is a record in cms_page_store which has a store_id which cannot be found in the related table (in this case the ONLY related table is core_store). This is not the case. There was a record in core_store with no entries in cms_page_store and even though this did not break the referential integrity, I have removed it in desperation, without success.
I have also checked the records in the other immediately related tables and still cannot find the reason for the error.
Any ideas?
When doing the update from 1.4 to 1.7 I had to empty two tables before succeeding. Before that I got all kinds of weird errors.
The tables I emptied (not deleted, only emptied) are:
report_compared_product_index & report_viewed_product_index
Try if that helps in your case, too.
Oh, I forgot, in case you wonder. The tables are used for non-essential statistical data about compared and viewed products. If you are dependent on accurate store statistics of the past, then you might need to dig deeper into this issue.
Try it
SET FOREIGN_KEY_CHECKS=0;
UPDATE `core_store` SET store_id = 0 WHERE code='admin';
UPDATE `core_store_group` SET group_id = 0 WHERE name='Default';
UPDATE `core_website` SET website_id = 0 WHERE code='admin';
UPDATE `customer_group` SET customer_group_id = 0 WHERE customer_group_code='NOT LOGGED IN';
SET FOREIGN_KEY_CHECKS=1;
Can you verify that you have an admin store in core_store that has store_id 0? I've bumped into similar issues with primary key IDs shifting and some assumptions made during upgrade scripts.
We have a header table which has a primary key and a detail table which references the header table (Foreign key). Both the header and detail tables are monthly partitioned. These tables contain 5 years of data, so when a new month comes the data for the first partition is deleted and so on. So that always only 5 years of data is maintained.
The problem that we are facing is while dropping the partition from the header we are getting the following error:
ORA-02266: unique/primary keys in table referenced by enabled foreign keys
ORA-06512: at "SCH_TEST.DROP_PARTITION", line 51
ORA-06512: at line 16 (DBD ERROR: OCIStmtExecute)
We have deleted the referencing data from the detail table, still the above error is occuring.
One way for solving this error is to disable the constraint, drop the partition and then enable the constraint. Is there any other approach/solution for this issue.
Database is Oracle 11G.
Edit 1: I'm able to drop the partition from header table if i delete the data in the partition first and then drop it. Any idea how this works?
Oracle 11g introduced partition by reference for this. Are you using reference partitioning? If not you need to change your partitioning scheme.
I chose "disable the reference constraint and then drop the partition" approach, as i did not find any other solution for this issue.
Posting this information here and accepting it as answer so that it may help others who search for the same issue.