[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 4834
  • Last Modified:

Cannot connect ODBC for a new user SQLSTATE HYT00

I have a problem I have never had.  I have a MS Sever 2008 running  MSSQL 2008.  I have installed 35 computers with Windows 7 and added ODBCs for all my users before.   I have 2 AD goups that have the SQL rights and everything is working fine for them.

I just purchased a new PC for a new user.  It also is Win7.  I can add ODBCs (Via System DSN) as an administrator to this machine without any problem.  However, when I attempt to add the ODBC's as a specific user (Under User DSN) it tries to connect to the database and then times out saying:  "Connection failed:  SQLState: 'HYT00' SQL Server Error: 0 [Microsoft][ODBC SQL Server Driver]Login timeout expired".

Anyone have any thought on how to rectify this?

Thanks ahead of time!
0
Callenr41
Asked:
Callenr41
  • 11
  • 11
1 Solution
 
regevhaCommented:
Please refer to EE solution 20686994 (use named pipes protocol instead of TCP/IP)
0
 
Callenr41Author Commented:
regevha -

I have changed the system dsn to named pipes under our admin account, however when i log in as the user the system dsn still shows them being a tcp/ip connection.  If I try to adjust it as the standard user then I will get a dialogue box saying I don't have sufficient privileges.    If I try to adjust the file dsn I get the same error.

What I don't understand is happening is if I change the system dsn as the admin, I thought that it retains the changes made no matter what user is logged in.  It doesn't appear that the ODBC has done this and it keeps reverting back to the tcp/ip setting instead.
0
 
regevhaCommented:
Please check that named pipes protocol is enabled on server side and that TCP/IP is disabled on client side
0
Nothing ever in the clear!

This technical paper will help you implement VMware’s VM encryption as well as implement Veeam encryption which together will achieve the nothing ever in the clear goal. If a bad guy steals VMs, backups or traffic they get nothing.

 
Callenr41Author Commented:
regevha -

I will check this on Monday and follow up with you.
0
 
Callenr41Author Commented:
regevha -

I wanted to let you know that I have spoken with our systems administrator and we have never used named pipes on our server.  We had never had any problems up until now and were only having issues with this one user.

I was wondering if there are any other solutions that we might want to try or suggestions that you might be able to offer.

Thanks ahead of time!
0
 
regevhaCommented:
I recommend to try and enable ODBC tracing for this specific Win 7 PC (look for the tracing tab). The information in the trace file following connection failure might shed some light and help us find the source of the problem.
0
 
Callenr41Author Commented:
regevha -

I ran the trace through the ODBC as you suggested and this is what I came up with (the log was quite long so I only inserted the errors that I thought would be relevant).  Here they are:

 
VicinityMfg.Vic 5d8-794	EXIT  SQLDriverConnectW  with return code -1 (SQL_ERROR)
		HDBC                0x052ADAD8
		HWND                0x00000000
		WCHAR *             0x678C8B34 [      -3] "******\ 0"
		SWORD                       -3 
		WCHAR *             0x678C8B34 
		SWORD                       -3 
		SWORD *             0x00000000
		UWORD                        0 <SQL_DRIVER_NOPROMPT>

		DIAG [IM014] [Microsoft][ODBC Driver Manager] The specified DSN contains an architecture mismatch between the Driver and Application (0)

Open in new window

If I am reading this correctly, it looks like there might be some sort of communication issue but I am not sure.


I found this additional error code as well:
 
VicinityMfg.Vic 5d8-794	EXIT  SQLGetDiagRecW  with return code 100 (SQL_NO_DATA_FOUND)
		SQLSMALLINT                  2 <SQL_HANDLE_DBC>
		SQLHANDLE           0x052ADAD8
		SQLSMALLINT                  2 
		SQLWCHAR *          0x0B24EFE4
		SQLINTEGER *        0x0B24F460
		SQLWCHAR *          0x0B24EFF0 
		SQLSMALLINT                512 
		SQLSMALLINT *       0x0B24EFDC

Open in new window

0
 
regevhaCommented:
Would you please attach the trace file ? (with txt extension)
0
 
Callenr41Author Commented:
Here is the attached Log file.  Thanks again for helping me out with this!
SQL.LOG
0
 
regevhaCommented:
Thanks for the trace log. I think the problem is well understood now. You are using Windows 7 64-bit with a 32-bit ODBC driver.
Please use the 32-bit ODBC manager in order to define the DSN: C:\Windows\SysWOW64\odbcad32.exe

The information is based on MSDN SQL Server forum
0
 
Callenr41Author Commented:
Regevha -

I will try this first thing tomorrow morning and report back on the results.
0
 
Callenr41Author Commented:
Regevha -

Unfortunately, this fix did not work.  I am still seeing the same error occur.  I have read through the MSDN SQL Server Forum that you have linked to and didn't really find any additional answers.  I will keep trying to research the problem and try to find a solution.
0
 
regevhaCommented:
Sorry.
Does it works fine if you login as another user on the same Win 7?
0
 
Callenr41Author Commented:
Regevha -

I tried to log-in as another standard user and I ended up getting the same result.  However if I log-in as the administrator I am able to communicate with the SQL server with no problems (and no errors/time-outs).  I am beginning to think that this might be tied to a permissions issue.  We additionally upgraded one of our software suites (MS Dynamics SL 6.5 to MS Dynamics 7.0), maybe it might be tied to that?

This issue may be a little bigger than I initially anticipated.
0
 
regevhaCommented:
You may try connecting using named pipes protocol, as described above and generate new trace file
0
 
Callenr41Author Commented:
Hmmm,  I had to reboot the Domain Controler (Different Sever from the SQL) and now all seems to be fine.  Not sure why this happened but it seems fixed now.

Thanks
0
 
regevhaCommented:
I am glad the issue is solved (you may check the current trace file)
0
 
Callenr41Author Commented:
I've requested that this question be closed as follows:

Accepted answer: 0 points for Callenr41's comment http:/Q_27409096.html#37058374

for the following reason:

The reboot of the DC corrected everything. &nbsp;Not sure what happend but this seemed to be releated to alll SQL rights not being assigned by the DC on login until after the reboot.
0
 
regevhaCommented:
This question should be closed as answered, based on the time and efforts helping the customer in sorting out the problem he was facing.
0
 
regevhaCommented:
This question should be closed as answered, based on the time and efforts helping the customer in sorting out the problem he was facing.
0
 
Callenr41Author Commented:
No disrepect was intended.  I greatly appreciate your help in resolving this problem.  I was was only accepting the solution to the problem as being the reboot for future viewers.  Your assistance in getting me there was highly appreciated and I have no problem with you getting the points.  

Thanks again for your help
0
 
regevhaCommented:
Thank you. We all know that many software related issues "disappear" after reboot.
0

Featured Post

Microsoft Certification Exam 74-409

Veeam® is happy to provide the Microsoft community with a study guide prepared by MVP and MCT, Orin Thomas. This guide will take you through each of the exam objectives, helping you to prepare for and pass the examination.

  • 11
  • 11
Tackle projects and never again get stuck behind a technical roadblock.
Join Now