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.
Related
I have the following problem in my current Symfony 6 project. I have a Many to Many Relationship between two tables in my Database. Therefore a third table for the references got created.
Afterwards, I created an Entity for this thie reference table which I needed for a query. However, if I now want to create a new migration with the command php bin/console make:migration.
I always get the error "table with name "database.table" already exists"
I think the problem occurs because, obviously the table for this entity already exists and the migration command wants to create it. But how do I solve this issue?
Thanks for any ideas in advance. :)
Maybe you are trying to build ManyToMany with extra fields?
Then this is not a simple ManyToMany anymore: it's now a OneToMany + the inverse side of the ManyToOne relationship.
More details is here https://symfonycasts.com/screencast/collections/many-to-many-extra-fields
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 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
One part of my application is querying CREATE TEMPORARY TABLE which throws an exception if a current connection already has a temporary table. Ideally, I would just add IF NOT EXISTS, but unfortunately, I can't edit the code at that particular part of the application.
So, what would be the other best way to make sure TMP tables for the current connection are cleared? I tried using
$this->_connection->closeConnection();
but that also throws an exception on the first run.
I managed to flush tmp tables without exceptions by executing the following code:
$this->_connection->commit();
$this->_connection->closeConnection();
$this->_connection->beginTransaction();
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.