Startup connection error

Suncatcher's profile image Suncatcher posted 9 years ago in General Permalink
Every time whenever I start Heidi I receive following error

After that, session manager is showed and then the connection process is done successfully exactly to the same connection that buged before.
Connection parameters:

What the matter? What am I doing wrong?
TTSneko's profile image TTSneko posted 9 years ago Permalink
"... What the matter? What am I doing wrong? ..."

If you get this error directly when starting Heidi I would assume that your connection is refused because it is trying to access the server via timed-out session. And to receive a fresh session ID you are of course forced to re-login (hence the connection requester).
Suncatcher's profile image Suncatcher posted 9 years ago Permalink
What do you mean by "time-out"? How did it get "time-out" if I just starting application?
TTSneko's profile image TTSneko posted 9 years ago Permalink
Your database is not local but available online, and most of those connections are session-based. Meaning that you are disconnected from the server either after a certain time of inactivity or after a direct log-off; the session you were working in either "times out" or "expires" (the internal flag used is often the same, "timed out").

If you try to reconnect after an instant reboot or a few hours of sleep is irrelevant here, as your connection cache (or method of opening the db/workplace) still holds an old session ID. The server demands that you verify your connection by (again) providing your credentials as the previous session ID you were working with has "timed out" and has become invalid.

This often happens when people bookmark connections which include session IDs, drop connection/page icons on the desktop (which also stores session info), or try to restart a client which had a running session tied to it.

[Note that the error CODE 18456 is merely a generic "can't connect". It would be easier if we knew the error STATE (e.g. server access failure, login/pw mismatch, etc.) but that is often not directly shown/provided by MS-SQL.]
Suncatcher's profile image Suncatcher posted 9 years ago Permalink


This often happens when people bookmark connections which include session IDs, drop connection/page icons on the desktop (which also stores session info), or try to restart a client which had a running session tied to it.

Okay, this is all very interesting but I didn't find any session IDs in my connection settings or something like that. What could be the solution for this issue?
Suncatcher's profile image Suncatcher posted 9 years ago Permalink
Bump.
Suncatcher's profile image Suncatcher posted 9 years ago Permalink

If you try to reconnect after an instant reboot or a few hours of sleep is irrelevant here, as your connection cache (or method of opening the db/workplace) still holds an old session ID. The server demands that you verify your connection by (again) providing your credentials as the previous session ID you were working with has "timed out" and has become invalid.


Why this issue does not appear with other cpnnections? What setting is responsible for it?

Please login to leave a reply, or register at first.