Last night I witnessed something rather peculiar! I'd post a number of records like this one - with no problems at all; but suddenly my Rails app refused to INSERT a particular record into a particular table.
This gist details the result. You may learn that the abstract_mysql_adapter.rb does not allow the insert whereas the Rails dbconsole (really the mysql client) does indeed allow the insert?
Does anyone know what goes on? I for one is stumped :(
Related
I truncated 2 tables in my database in MySQL (for a Rails project) so that I could repopulated it with test data. But for some reason the application is still counting how many entries there used to be (250), even though there is only 9 entries now.
I even went into the ruby console using (ruby script/rails console), then truncated using:
ActiveRecord::Base.connection.execute("TRUNCATE TABLE bars;")
but that didn't do anything different then running the query through MySQL. I am pretty confused, the only thing I can think of doing is restarting the server. I am just wondering if there is maybe another way to do this without having to reboot everything.
Printing the search to the logger I can see that the results for the bars are a bunch of nil values for where there used to be a bar_profile, but I have truncated the tables that referenced bars or bar_profiles.
So I don't get why it would just be returning what the results would have been before the tables were truncated. Except now now instead of returning actual results they are just nil.
I was importing one table in a MySQL Server when the power went down. After this event I tried to query the table I was importing, but got the error 2013, only when I'm querying this table (the others work just fine).
I have physical access to the server, tried to execute any query from there (tried to SELECT, and even DROP TABLE) but still got the same error.
Does anybody know a solution where I can re-build only the table (without building the whole schema from scratch?)
I'm adding this as an answer rather than having lots of comments underneath. I must state in advance that I've not used MySQL but I have used SQL server a lot so I'm hoping that something I say may help.
You say the table is still there. Was it created as part of the operation you were doing or had it been there for a while?
What happens if someone else or a different account tries to access this table?
Is there anything on this page that is relevant to your problem?
http://dev.mysql.com/doc/refman/5.0/en/gone-away.html
I've got a legacy database that was running on CakePHP and MySQL that's being migrated to a new Rails App on a Postgres database with a wildly different structure. I have one small piece of migration that's giving me fits, and I'm hoping someone here can point me in the right direction.
Essentially, there are date columns (of MySQL type Date) that contain malformed dates. Most of the malformed dates are of the form '2012-08-00', and the MySQL2 adapter chokes on these (as obviously 00 is not a valid day of the month). If I could just get them into the model I could do the necessary conversions to turn them into the much more complete new format. Even getting them out of the Database as a string would be sufficient, I could do the necessary manipulation that way.
I get the following error:
Mysql2::Error: Invalid date: 2011-12-00
whenever I try to select one of the invalid dates from the system. There are 3800 rows in the table, I would estimate that about half are so attempting to go through and modify them all by hand would take a great deal (but not inordinate, if that's the way it needs to be done) amount of time.
Any suggestions would be highly appreciated!
Something like this should work (not tested):
update [table] set [field] = DATE_ADD([field],INTERVAL 1 day) where day([field]) = '0'
I've got a user model for my app, and it has effectively used has_secure_password up til this point. has_secure_password necessitates a password_digest column, and herein lies my recent problem.
I wanted to create a "role" column of type string that separates admins from users - but after migrating, my password_digest got corrupted so that I get an invalid hash error whenever I try to use it in my app. In mysql everything is fine (the password_digest values haven't changed) but in rails console the value returned by User.first.password_digest is something along the lines of:
\#BigDecimal:59d0c60,'0.0',9(18)
Furthermore, unless I change the type of role from string, it gets similarly messed up (although like password_digest, it's totally fine in mysql regardless). Rolling back the migration and getting rid of the "role" column causes password_digest to go back to normal as far as rails console is concerned.
What is going on here?
Here's my database schema:
Here's the result of a sql query fed directly to mysql:
Here's the result of the same query through rails (first time):
Here's the result of the same query through rails (after first time):
Looks like your query is getting auto-explained. See the documentation here http://guides.rubyonrails.org/active_record_querying.html#automatic-explain
I developed a ruby on rails 3 web app, and i had originally depended on a sqlite3 database that was locally stored in my computer before deploying it. I stored certain information in the sessions to get certain part of my web app to work.
However after deploying, i decided to use a mysql2 database from xeround.com and my website broke down. At first I had gotten an error message saying that i did not have a sessions table in the database. So I created a sessions table. And now it says
ActiveRecord::StatementInvalid in ClientController#index
Mysql2::Error: Unknown column 'sessions.session_id' in 'where clause': SELECT `sessions`.* FROM `sessions` WHERE `sessions`.`session_id` = '................' LIMIT 1
Would i have to create the appropriate columns manually in the new sessions table that I made in the mysql2 database? Or is there another way to get around it?
What seems to be missing is session_id do check in your table sessions does it have column named session_id in it? if it is not there then create it through a migration. According to me, you should not do anything manually cause, in future if you wants to make some changes or rollback the tables you might face some issues.