Strange issue with table in PHPMyadmin - mysql

I am having an issue with a table within my database whereas I cannot execute any queries against it.
I checked my syntax multiplie times and after discovering there was no problem with it I went into PHPMyadmin and have uncovered the following issue which I have not come across before.
When I try to browse the rows in my table (of which there are over 2000) it won't let me browse and comes up with the following error. This is even when I click the table name in the list in the left menu.
As you can see it is trying to organise the rows using an ORDER BY whenever I try and access the table and I don't know why it is trying to do this.
Can anybody shed any light on this?
Thanks

Your order by clause does not contain column name

I managed to sort this issue by deleting and re-creating the table but am still unsure as to why it was adding a default ORDER BY whenever I was trying to access the table.
If anybody could shed any light on this it would be very helpful if it were to happen again!
Thanks

Related

How to execute actions without deleting the previous ones in MySQL?

every time I try to execute a new action I get an error. I guess it's because some of the previuos actions can't be executed twice, but in the tutorial I'm watching, the guy can do it without problems. How can I fix this?
Thanks in advance!
If the error you are referring to is the 'Table...already exists', it looks like you may want to start your script with:
drop database if exists ContactMe;
That will remove all tables and data in that database.
"action" is some concept invented by the UI you are using, by the way, not something that has any specific meaning in mysql.

in popsql when i try to run multiple times it says - table already exists

I have created a table named dbms
it runs once well but when I try to run again, it shows an error that dbms table already exists.
I don't understand what is the problem
can anyone help me, please?
thank you.
when working with databases, you only need to run the script once to create it. Otherwise it will not show until you place data into it.
thank you, everyone.
but I found my mistake.
I was running the whole code again and again.
I just need to run a single line of code or a particular set of lines that need to be excecuted.

phpMyAdmin table search returning empty result but SQL select works for specific table

It is very strange what is happening, I have never seen this before and I am pretty familiar with mysql.
When searching a table using the phpMyAdmin table search feature, the result is empty no matter what I put. For example, searching 77 in the ID column returns empty result. However if I run an SQL query also in phpMyAdmin, and then there is the result. For example, select * from table1 where id = ‘77’;
What is even more strange is this only happens on one table, all other tables the search feature is working fine.
I tried repairing the table but empty result still occurs.
I couldn’t find this happening anywhere to any one online…..
Also restarted sql server.
Are you using cPanel - if yes I just described how to fix the problem on cPanel forums:
http://forums.cpanel.net/f5/unable-use-phpmyadmin-search-users-table-313381.html
If your table has a large number of fields an update via the phpMyAdmin interface can exceed the value for the PHP setting 'max_input_vars'. When this happens some of the internal form fields that phpMyAdmin is expecting to receive on the page your update is being posted to are truncated which causes phpMyAdmin to fail, unfortunately silently, and the page redirects with no warnings back to the blank search form. The default for 'max_input_vars' is 1000. I upped mine in my php.ini file to 5000 with no negative side affects and it solved this problem for me.
The setting 'max_input_vars' has a mode of PHP_INI_PERDIR so if you don't have access to your php.ini file then you may be able to set it in an .htaccess file, your httpd.conf file or your .user.ini (since PHP 5.3) file if you have one. I'm not sure exactly what code you would need for an htaccess file but the PHP code to do it is below.
ini_set('max_input_vars', '5000');
Hopefully that should get you started in the right direction.
Very easy. Go to the table and expose max number of rows as much as is showed in the dropdown. Then you are able to search per big pages. It doesnt fetch text through all the table. It plays only with a page of the table.

MySQL Error 2013 after a failed attempt to import

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

mysql export loses AutoIncrement

When I export a table through SQLYog, the CREATE statement in the exported file lacks AutoIncrement on its primary key, even though the original table contained AutoIncrement.
Is this a bug (in Yog or in mysql?)? Should I report it?
How can I export the table with the AutoIncrement in place?
This happened to us also when using mysql from the command line. It turned out this happened because we added "skip opt" flag. The way to resolve is to either drop "skip opt" or add "--create-options" (Thanks Shlomo)
I just tried to reproduce this via SQLYog, and failed - so the problem must have only been presented in our custom dump scripts.
You should report it whether you think it's a bug or not. A cursory browse through online info gives no indication as to whether the loss of auto-incrementing columns is intentional or not.
And, if it's not specified one way or the other, I would be inclined to think that it should re-create the tables exactly as they were. This would be no different than if the export created a create table statement that left off columns starting with the letter X :-)
Raise it as a bug. If this is a genuine, documented restriction of the product, they will tell you, and hopefully point you to the documentation that details this. They'll probably also be able to tell you any workarounds that may fix it. They may state that it's because of some bone-headed decision from the MySQL people in which case you can then hit them with a bug report :-)
If it's actually a bug, good developers will be glad to hear about it so they can improve their product.