MySQL cant find my table? [closed] - mysql

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I reformatted my C drive, reinstall mysql for windows then deleted my 2 log files + ibdata1. I set the data path in my config file and was able to connect to my database. I see all my databases however if i try to select any data i get an error
I remembered I needed to set files per table so i wrote
innodb_file_per_table
I restarted mysqld and I still get an error. This is what i get specifically. t is the name of my database (its a test database). I see all the databases i have with show databases. show tables; works as well. But I can't select anything or desc TABLE. My database are 60gb in total so i'm worried i broke it all.
mysql> select * from inc;
ERROR 1146 (42S02): Table 't.inc' doesn't exist

The problem was the fresh my.ini file no longer had the innodb_data_home_dir="c:/path/to". I looked at my ini file from a external HD for a different database. I must have a different version of the installer/mysql (even though its still 5.5)

Related

mySQL workbench- 'SELECT * FROM table' not working [closed]

Closed. This question is not reproducible or was caused by typos. It is not currently accepting answers.
This question was caused by a typo or a problem that can no longer be reproduced. While similar questions may be on-topic here, this one was resolved in a way less likely to help future readers.
Closed 2 years ago.
Improve this question
I don't have much experience with mySQL but I thought I knew the basics. However, I am clearly missing something. I am using a database that has 6 tables, I can look at 5 of them with no problem. I was looking for some values and I wasn't sure which exact table it was in so I typed in my mySQL 101 level statement- 'SELECT * FROM project', received the values, and saw that my target was not in there. So I next ran 'SELECT * FROM release' except that command does not work.
The MySQL Workbench underlines the word 'SELECT' and the tooltip message says- "select" is not valid at this position for this server version
When I attempt to run the command, I get Error Code: 1064. You have an error in your SQL syntax
So I tried deleting and rewriting, thinking it was some sort of bug but restarts and everything else I have tried is not helping and I have been unable to google anything relevant.
full command-
USE scorecarddb;
SHOW TABLES;
SELECT * FROM release;
but I usually just use the 1 line command run (aka I only run line 3 since I am already in the scorecard db). And I don't think it is an actual syntax error because if I change the word 'release' to 'project' or any of the other table names, it works
release might be a reserved keyword. Try using:
SELECT * FROM `release`;

Mysql 8 user length issue in centos 8 [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
I tried the create a mysql user , length of user name 23 . It failed . I am user mysql 8 on centos 8 .
Just I tested my create user script by different user name ( less than 16) . It work .
Can anyone advise How I can increase the default user name length.
As per the manual
MySQL user names are up to 32 characters long. Operating system user names may have a different maximum length
And also:
Warning
The MySQL user name length limit is hardcoded in MySQL servers and clients, and trying to circumvent it by modifying the definitions of the tables in the mysql database does not work.
You should never alter the structure of tables in the mysql database in any manner whatsoever except by means of the procedure that is described in Section 2.11, “Upgrading MySQL”. Attempting to redefine MySQL's system tables in any other fashion results in undefined and unsupported behavior. The server is free to ignore rows that become malformed as a result of such modifications.
Read more here

Where mysql stores the password of users [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 8 years ago.
Improve this question
When we setup a MySQL database system, system automatically create a MySQL databse in which there are multiple tables like db,event,func,host,servers,slow_log,user_info etc.
In user_info table I can get the list of users and their details by executing query like select * from user_info; except password.
But in which table MySQL store the password of every users?
MySQL passwords for users are stored within MySQL itself; they are stored in the mysql.user table. The passwords are hashed by default using the PASSWORD() function.
Source
in the mysql db, user table
SELECT
User,
Password
FROM mysql.user;

Importing .sql file into postgresql or Mysql from Local Machine [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 9 years ago.
Improve this question
I'm trying to import 15GB .sql file in postgreysql or Mysql database. What is the faster way or procedure to import such a big dataset in short time.
Any suggestion will be greatly appreciated ?
To start with, there's really no such thing as a ".sql file". It's like saying a ".dat file", it could be practically anything. A list of INSERTs. A script to create tables. A query that extracts information from an existing database. Etc.
The file might contain table and index definitions (DDL) and other content, or it might just be a list of INSERT statements. It could be written to use custom vendor extensions like PostgreSQL's COPY command for fast data loading, too.
You need to look at the file and see what it is. Determine if you need to create tables to hold the data first. See if you need to change any DDL to be compatible with the target database, since unfortunately the standard names for SQL data types aren't followed all that consistently by database vendors, there are vendor extensions for things like key generation, etc.
If it's plain INSERTs into a single table and the inserts don't depend on each other the fastest way to load it into PostgreSQL is to split it into several chunks and run each chunk with psql -1 -v ON_ERROR_ROLLBACK=1 -f chunk.sql.
Otherwise you'd just have to psql -1 -v ON_ERROR_ROLLBACK=1 -f thefile.sql.
The fastest way to load data into PostgreSQL is to use pg_bulkload, but that's quite disruptive and I don't think it'll take pre-formatted SQL input. The next-best option is the COPY command, but that also works with CSV/TSV, not with SQL formatted data written as INSERTs.

mysql workbench records limit [closed]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I perform an SQL query on a database with MySQL and I get back only the first 1000 rows from 24000 expected. If i export the results to an XML form, I get the first 1000 again.
Is there a way to disable that limit and get back all the rows?
Otherwise, I will have to merge 24 XML files :/
Do these steps:
Go to Edit -> Preferences.
Click on the SQL Editor tab.
Under Query Editor, uncheck Limit Rows.
Edit
Workbench Version 6.12 (Mac OS(10.11.3))
Go to Edit -> Preferences.
Click on the SQL Editor tab.
Under SQL Execution, uncheck Limit Rows.
I would recommend simply clicking the "Toggle limitation of the records number" button located right above the results pane. Turning off the limit is not the best approach since the server will have to send all records with every query. Placing a limit on the rows returned is generally a good idea.