-
-
Notifications
You must be signed in to change notification settings - Fork 3.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
General error: 1005 Can't create table 'snipeit.#sql-70e_cb3' #1430
Comments
I am noticing that the storage engine on the tables appears to be InnoDB on some, and MyISAM on others. |
@chrisrbmn I know the USD to TWD is a known issue based on them both using the $ symbol. See #1383 regarding the duplicate. Did you turn on debugging to see if you can get any other details about the issue you're having otherwise? http://docs.snipeitapp.com/getting-help.html |
I enabled debugging, here's the output:
And the output for the /app/storage/logs
Please let me know if I missed any debug information that will help. |
Can you run |
|
Should I convert all of the tables to InnoDB? |
So, I think the problem is that the migration is trying to assign a foreign key to a table that's MyISAM. What's weird is that your companies table looks to be InnoDB (which is good), though I'm not sure why it is, since I think your default stage engine is MyISAM, since so many of the other tables are MyISAM. In a later migration, we remove the FK constraint, but the table type mismatch is donking up the migration so it can't proceed to even get there. Go ahead and change the table types to InnoDB if you can, and then try running migrations again. I've added engine type to the older migrations to hopefully prevent this issue moving forward with folks who have MyISAM as the default table engine. |
well, we made it a touch further.. Thank you very much for the help! :) I then re-ran migrate, and now get a new error. It looks like in versions 5.1 MySQL, MyISAM was default. So i'm guessing anyone using 5.1, will definately see this. In my case, I'm on CentOS 6.7, and installed via yum. |
I went ahead into /etc/my.cnf This will tell MySQL that InnoDB is the default engine. *Just incase anyone else needs this. |
Seems like you're maybe pulling from develop, instead of a release? Remove the last migration from the migrations directory. Should be |
I'm sorry for the hassle on this. That foreign key constraint has been nothing but problems. It came in through a pull request, and since my default tables are InnoDB, we didn't catch this issue during testing. |
Its only a small hassle, I'm learning so much about snipeit. I can't tell you how invaluable this troubleshooting has been. I admit, I was pulling from dev, and decided today, that this was the day, snipe was gonna be the tool I continue to use, so thought it was a good idea, to pull down release, and migrate into it. I see, that may have been a bad idea on my part. I have to take some responsibility that this is self inflicted, Thank you for the continued help troubleshooting. :) I apologize for the newbie question, but what is the path to the migrations directory? |
It's not self-inflicted. This was a cock-up on our end (and develop is usually pretty stable, so trustworthy for folks with a little risk tolerance, but unfortunately since some people have already run those migrations, fixing it in a way that won't break stuff for others is the challenge. :-/ Migrations are in |
Do you have existing data in the database, or is this more or less a fresh install? I'd be curious to see if you reinstall from the latest on develop if you still run into these issues. |
(This foreign key nonsense is exactly why I never use foreign keys. They always seem like a good idea but always end in tears.) |
I have existing data.. I copied the DB into a backup database, and wiped the tables, and still had the issue on the fresh install.. I removed that |
i'm repulling from dev. just to see what magic I can cause! Whooppeee! |
ok, dev, breaks it. lol |
Breaks it how? |
Okay, the pull from dev probably put that migration file back, that's all. |
removed the file, And on that bombshell, its time to head home for the day.. Thank you again for the help! |
That's what I would expect, since it was just that last migration it's choking on. That's still a weird error to get though. If all of the tables are InnoDB now, the foreign keys should have been able to be added (and then removed in that last migration). :-/ |
Well, I'm happy to try and help out in the future, but you should probably work on that "day drinking".. ;) |
Hi all,
![2015-12-02_10-41-55](https://cloud.githubusercontent.com/assets/5017742/11537166/606306ca-98e1-11e5-8ddb-36724e0d653e.png)
I just tried to run the 2.0.6 upgrade, and ran across this error.
Here are the steps I ran, on my centos 6.7 server.
from /var/www/snipeit
git stash
git pull
php composer.phar install
php composer.phar dump-autoload
php artisan migrate
Did I do the upgrade correctly? or something else?
![2015-12-02_10-45-49](https://cloud.githubusercontent.com/assets/5017742/11537280/ee460a32-98e1-11e5-983f-3694989ee3a8.png)
I don't see any visible issue, unless I go edit something on the settings page.. If I try to change the currency option to US Dollar's, (which is defaulted to TWD - Taiwan New Dollars), I get a 500 error.
Thanks for your help all,
Chris
The text was updated successfully, but these errors were encountered: