Getting cracy here... SQL Error (1045) ...user @localhost. WHY?!

I am not used to cry for help, actually I am getting along with alot of reading... and thats what I did the whole night long!

I had to newly setup my windows machine and I am trying to re-establish Heidi Sql with plink / putty. That worked flawlessly before and on the serverside nothing has changed.

As I recall I did a console connection with putty to store the Server Key, what I did again. Througg the putty.exe I got shell access on the server and I did save this session. It seems to work correctly with the information given.

Heading over to Heidi, filling the settings as follows:

Settings:
- Network Type: SSH tunnel
- Hostname / IP : MyDomain.com
- User: MyDatabaseUser
- Password: MyDatabasePassword
- Port: 3306
- Databases: MyDatabaseName

SSH Tunnel:
Plink.exe location: C:\Programm Files\puttz\plink.exe
SSH host + port: MyDomain.com
Username: MySSH-Username
Password: MySSH-Password
plink.exe timeout: 15
Private key file: nothing
Local port: 3307

...I may do what I want, I ALWAYS got the following error, trying to connect with Heidi:

SQL Error (1045): Access denied for user 'MyDatabaseUser'@'localhost' (using password: YES)

I actually tried everthing I could find on the net. I deleted the registry key and downloaded the last nightly build of Heidi just to be sure it wasn´t the programms fault.

PLEASE I have to rebuild a database and I am lost without all my snipets and the wonderful tools of Heidi!

Thanks alot considering giving some assistance.

It seems I have the same problem like described HERE. Manually, without the -N parameter plink.exe connects to the server. I as well did not found any documentation on this parameter as per Plink.exe Doku.

Somebody knows more?

The original plink docs are here: http://the.earth.li/~sgtatham/putty/0.62/htmldoc/Chapter7.html#plink-usage - -N means ssh will not start a shell on the server after connecting; must be used with -L or -R to establich a tunnel, or connection is a no-op

The above seems to indicate that SSH connected Ok, 1045 is coming from the mysql server. Have you tried to connect without a mysql password this way ? The default mysql configuration (mysql.user table) often defines different access rules for remote and local access, and sometimes local access has no password. Accessing the mysql server via a tunnel looks like a local access to the server (eg coming from 127.0.0.1 or localhost, not from your ip)

Hi jfalch! Thanks for helping!

I just tried it out... with the same result!

Tried as well server backend password, no joy.

Ahhhh... halleluja!

Your hint gave me some energy and I tried to change the Hostname under the settings tab to the IP! As it seems, remote access on this particular hoster does not follow the hostname for the site, it is some encrypted url with the used MySql version in it!

It works finally! So I may go an work...

Thanks for coaching me, jfalch!

Yes, as jfalch said, the error message indicates this is a password problem, or your mysql username on the server is configured not to allow connections from your ip. This is nothing someone in this forum could help you.

if you habe shell access to mysql via ssh (without -N), try

mysql -u MyDatabaseUser -p

and enter your MyDatabasePassword when requested. if this fails, the password for localhost / 127.0.0.1 access is not what yout think it to be.

if you can access the mysql server by any method (other than heidi, eg a web interface like phpmyadmin), try

select Host,User,Password from mysql.user

to show what users mysql has defined and wether they have a password. the password is shown encrypted, ie you can only see a) if there is a non-empty password, and b) if the passwords for two users are identical.
The interesting result lines are those for localhost and 127.0.0.1 - do these lines show a non-empty password ?

jfalch and anse... it wasn´t a password problem. It seems, that I managed to connect using shell access, but I did not connect to the database, I didn´t checked that

So connecting to the server, using the regular hostname worked and I supposed it should work for
the database as well... this was wrong.

The database has a different hostname, I figured that out using the IP instead the url. As Heidi wanted to connect to a not existing (i.e. wrong) hostname for the database, acessing with the correct password, it throw this error which was in my comon sense somekind of missleading (after a night without sleep, such things may happen).

So problem solved and heidi is still my top tool.

Thanks a bunch for your assistance!

Good news - glad to hear that!