I'm trying to re-index the category flat data, but I am always met with the same error:
There was a problem with reindexing process. Error Message: SQLSTATE[HY000]: General error: 1005 Can't create table 'xxx.catalog_category_flat_store_6' (errno: 121)
The table doesn't exist, there is a 1 and a 7. Not sure if that makes a difference?
After running the query manually through phpMyAdmin, I am met with the MySQL error 121. I've checked around and this would suggest the names of the foreign keys trying to be created already exist. I've listed all foreign keys in the DB right now, and they don't exist at all.
I've also tried running SHOW ENGINE INNODB STATUS on the DB for more information, but we don't have the rights to view that apparently.
After getting the priv's updated so we could run SHOW INNODB STATUS, we discovered that we already had an existing index that was attempting to be duplicated with this new table. This stemmed from us backing up an older version of the table that was trying to be created. Deleting that copy of the table enabled Magento to re-index properly and solved our problem.
Try logging the sql commands and debug what its trying to do by executing them manually. On the index process, normally there is a command that clears a table, and another to recreate it.
Edit /magentoRoot/lib/Varien/Db/Adapter/Pdo/Mysql.php and change $_debug to true and note the $_debugFile location (should be var/debug/pdo_mysql.log)
Its best to edit the file in vi, have a browser open to reindex JUST the category data, save the file in vi :w! and then run the indexer then change the debug back to false.
Then go read the log. It may help.
Related
i want to know if it's possible to drop a table fragment that is not letting me perform a restore with the NDB_RESTORE tool.
When i run the restore, it throws the following error:
Create table db_died_maestro/def/NDB$FKM_3194_0_mae_tipo_reg_evaluacion failed: 721: Schema object with given name already exists
Restore: Failed to restore table: db_died_maestro/def/NDB$FKM_3194_0_mae_tipo_reg_evaluacion ... Exiting
NDBT_ProgramExit: 1 - Failed
I have already drop the DB_DIED_MAESTRO database previous to run the restore, but this fragment is not being dropped along with the database.
I have check that the fragment is in the database catalog using this querys:
*select * from ndbinfo.operations_per_fragment
where fq_name like 'db_died_maestro%'*
query result
And this query:
*select * from ndbinfo.memory_per_fragment
where fq_name like '%FKM_3194_0_mae_tipo_reg_evaluacion'*
query 2 result
This fragment was created on a previous run of the NDB_RESTORE tool. Please help me.
The table is a foreign key 'mock' table (indicated by the name NDB$FKM prefix).
Foreign key mock tables are created transiently in some cases to implement the foreign_key_checks = 0 feature of MySQL. This feature requires storage engines to support unordered creation of tables with partially defined foreign key constraints which can be abritrarily enabled (without revalidation) at a later time.
Foreign key mock tables are normally entirely managed by the Ndb storage engine component of MySQL, and so should not be visible unless there has been a failure or bug of some kind.
If you can share information about activities occurring before this problem then that would help us understand how this happened and whether it can be avoided.
As a workaround it should be possible for you to use the ndb_drop_table utility to drop this table, before re-attempting the failing restore. You may have to escape the $ in the name passed as a command line argument from a shell. Probably you should check for any other NDB$FKM tables in a similar situation.
I use code first convention and mysql database in asp.net application. First I created a data model. Second I created database using add-migration and update database. I see in MySQLWorkbench that my database was created.
After that I run my app to see how database work. Before one of views is created I 'ask' database for a list of users. The problem is that during linq query to get list of users there is thrown an exception. Message is Table 'Events' already exists. I do not understand this error. Yes, all tables in the database exits. There is not direct relation between these to tables.
I have stared looking for the answer in the Internet. I found only one solution. I droped database, deleted all migrations, created new migration and update-database, but the this solutions does not solve the problem.
Any ideas?
This problem have number 1050 in MySQL.
In my Seed method I can insert objects into database, and it works. But during app is running the exception is thrown. I try:
DROP TABLE IF EXISTS Events;
REPAIR TABLE Events;
I execute this queries in MySQLWorkbench and restart the application. Then I have "new" exception that: "Table 'Documents' already exists". When I try
DROP TABLE IF EXISTS Documents;
REPAIR TABLE Documents;
MySQLWorkbench: Error Code: 1217. Cannot delete or update a parent row: a foreign key constraint fails. So the problem still exists. Now I have exception "Table 'Documents' already exists". I check my Up method in migration class the first table which is created is Events, the second Documents. So I think that I should repair all tables, becouse in database-update command must create wrong database. But why it earlier works(?) I still do not know.
I am running a simple update statement:
UPDATE sometab
SET `somefield1` = '19',
`somefield2` = '3734941'
WHERE somefield3 = '1234';
and I am getting the error:
ERROR 1146 (42S02): Table 'prod._sometab_new' doesn't exist
I can successfully select from the table where somefield3 is 1234.
Why am I getting a table doesn't exist error for a table that exists? And why does the error message refer to a different table? I don't see any triggers associated with the table.
Additional information: A colleague just noticed that it is referring to a prod scheme, but the statement is running in a dev schema built from prod. The update statement works in DBs that were built a few days ago using the same method, but all of the DBs built after some, as of yet, unknown time exhibit the error.
The current theory is that a conversion script to move us to UTF-8 is currently running and creating tables like _ORIG_new as part of its conversion. We are going to wait for the conversion script to finish and then rebuild the dev databases and see if the error still persists.
Does this happen if you also try Insert into or Delete statements ?
Insert INTO sometab(somefield1, somefield2) VALUES (a, b).
If that works you should not have problems probably, otherwise you have problems accessing your database.
Second, are you sure you are using the correct database file and that are you connected to it properly. If you are using it in external application (c#), check your connection strings.
Also check how are you executing the query. I cant think of other more specific solution to your problem
I have a mysql table y in database xxx which I attempted to change compression type before using
alter table y row_format=compressed key_block_size=8
the process stopped half way. I removed temp file '#sql-ib265.frm and #sql-ib265' in mysql lib directory and restarted the server. However
Now when I attempt the alter table y (with the same command above) again I get error.
ERROR 1050 (42S01) at line 1: Table 'xxx/#sql-ib265' already exists
I can't drop table 'xxx/#sql-ib265' because it can't be found.
what should I do?
Edit
Solution:
I ended up dropping the old database and recreate the database.
Try to restart mysql client with the --skip-auto-rehash option and try DROP TABLE again.
If above does not work, try this from MySQL Manual:
You have a corrupt innodb data dictionary..
https://dev.mysql.com/doc/refman/5.0/en/innodb-troubleshooting-datadict.html
Problem with Temporary Table
If MySQL crashes in the middle of an ALTER TABLE operation, you may end up with an orphaned temporary table inside the InnoDB tablespace. Using the Table Monitor, you can see listed a table with a name that begins with #sql-. You can perform SQL statements on tables whose name contains the character “#” if you enclose the name within backticks. Thus, you can drop such an orphaned table like any other orphaned table using the method described earlier. To copy or rename a file in the Unix shell, you need to put the file name in double quotation marks if the file name contains “#”.
There are two ways to fix this problem.
As other answer suggests, official MySQL documentation suggests to drop a specially crafted table. But please note in versions >= 5.1 you need to prefix table name with #mysql50#.
Move (use RENAME TO) all good tables to a temporary database, drop&recreate the original one and then move the tables back. See a blog post for details.
in additional I'm loging in with root to do the recover job but failed. then i chown the .frm file to meet the owner of mysql service and succeed.
For anyone still facing this problem, I have just followed the following steps to solve it, which (to me at least) seem far less daunting than other solutions:
Use mysqldump to back up the database with all its data.
Drop and recreate the database.
Reload the database and all its schema from the file generated in (1).
Because the orphaned tables are hidden anyway, they don't get backed up, so you end up with a database without them. I had all my procedures/functions scripted out anyway, so was able to restore them easily - if you don't, make sure you use the --routines parameter to dump those too.
My dump file was around 1.5GB for the database in question (so it's not small), and the whole thing was completed in a few minutes.
I had the same error. I fixed it by switching the order in which I dropped the tables at the beginning of the file:
DROP TABLE IF EXISTS table_name;
This line is repeated for each table. Tables with foreign keys need to be deleted before the tables with the primary keys to which they point.
When I run Reindex from Index Management it gives error "Cannot initialize the indexer process."
So based on following article here
http://jasonehmke.com/ecommerce/cannot-initialize-the-indexer-process-in-magento/
I ran
php -f indexer.php reindexall
Which gave following output:
Product Prices index was rebuilt successfully
Catalog URL Rewrites index was rebuilt successfully
Product Flat Data index was rebuilt successfully
Category Flat Data index was rebuilt successfully
Category Products index was rebuilt successfully
Catalog Search Index index was rebuilt successfully
Stock Status index was rebuilt successfully
Tag Aggregation Data index was rebuilt successfully
Product Attributes index process unknown error:
exception 'PDOException' with message 'SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '65-542-1-65' for key 'PRIMARY'' in /home/bizzosph/public_html/lib/Zend/Db/Statement/Pdo.php:228
Next exception 'Zend_Db_Statement_Exception' with message 'SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '65-542-1-65' for key 'PRIMARY'' in /home/bizzosph/public_html/lib/Zend/Db/Statement/Pdo.php:234
Any idea how do I fix this? It does not tell me what table has duplicate entry.
Thanks
I'm sure you've moved on since posting this question, but since it has ~2500 views (and having this answer here would have helped me), I'll add the resolution I found. This does not require truncating any database tables or even any direct SQL queries:
Last night, I was having the same problem. My error was the same as yours (except for the numbers which refer to the product and attribute causing the problem). If you go and re-save that product in the Manage Products section of the admin (no need to change it, just open it to edit and click save), it will solve the problem - but you very likely have more products that will bring additional similar errors.
In my case, it wasn't just a problem with 1 product there were several hundred products causing errors (each one saved brought up a new one). And it wasn't all with the same attribute (I'd updated multiple attributes across a database of over 4,000 products in my last import).
Since everything seemed to actually be in the database correctly (since re-saving seemed to be fixing it and giving the proper data to the final saved product), I had an idea.
Why not export all 4k products, and then re-import the same file without modification and see if that clears it.
It worked!
tl;dr: If you're having this problem with multiple products needing to be re-saved, export your whole inventory (or the relevant section if you can segment in a useful way), and re-import the same file with no modifications.
I'm using Magento v 1.9.0.1
Try first to clean Magento cache. If no success, run official DB repair tool
The solution is to run the following MySQL queries:
TRUNCATE TABLE `catalog_product_flat_1`;
TRUNCATE TABLE `catalog_product_flat_2`;
TRUNCATE TABLE `catalog_product_flat_3`;