My Problem is that I cannot connect to an SQL Server Express 2008 64bit Database via an Access Runtime 32bit, neither by Windows authentification nor by SQL auth.
On the Windows 2011 Small Business Server runs a Virtual machine with Windows 7 Prof. 32 bit. From this Windows I tested my Access App. using a (32bit) SQL Driver 11, which works fine.
The same Access App used from a 64 bit Windows 7 Prof. Client using a 64bit SQL Driver 11 fails with SQLState 08001 error.
The Thing which I do not understand is, that ODBC Connection test is successful, a data link (UDL) is successful, but not my Access App.
When starting the app, the first Thing is to run a stored procedure through a passthrougquery and grab data from a certain tbl in the SQL-Database. This SP brings the Connection error, but not an runtime error from Access (I removed even an error handler!).
So, how can I find the reason or any error in the Access app (if there is one)?
I am helpless as anything I know to test or to do I already tried out to make the app run. As I cannot even install the SQL Driver 11 in 32bit, it should not be a Driver related error.
Does anyone know a test-app, where I cannot only connect but retrieve data from an SQL-Database or any other tricks to check the Access to the database?
Thanks your help!
Access usually is installed as a 32bit Application. So on 64bit computers it will use the 32bit subsystem. On Windows 7 all the default shortcuts to the ODBC Data Source Administrator utility will lead to the 64bit version of it. Whatever you see or configure there is completely irrelevant, as your 32bit Access is not going to see it.
Solution:
You need to explicitely open the 32bit version of the ODBC Admin utility and configure the data source there.
To make sure you get the right version, use Windows Explorer and open this file: C:\WINDOWS\syswow64\odbcad32.exe
Well, what I found out meanwhile is, that the Connection Fails when trying to use a Connection like this "ODBC; DSN=MyDSN;....." but it works, when I make a Connection DNS-less, by connecting with "ODBC;DRIVER=SQL Server Native Client 11; SErver=myServer;....".
Maybe this is exactly that what you are talking aout. When I just use a DSN it takes the wrong bit Version.
So I will try this: delete the DSN I have, open odbcad32.exe and create the same DSN again.
If I understand you correct, then Win 7 provides the correct Driver and stores it in the DSN. Calling this DSN by Access would lead to the correct Settings.
Further Problem is, that my SSQL-Server instance is not at port 1434, and the SQL Server Native Client 11 Driver has no more Clientconfiguartion to set the static port. So I found a string solution for that "MyServer\Myinstance, 15999".
I hope that this port Setting will be accepted in the DSN, otherwise I really have to Change to DSN-less which is more complicated due to different Servers for the development and the production.
Thanks yr. reply.
Related
First time ever using ColdFusion.
We have a website that uses ColdFusion 9 on our live server. It calls a COM DLL to encrypt certain things. The code on our live server works fine.
Since I may be taking over the project I installed ColdFusion 10 Developer edition on my local machine and copied all the source code and DLL's down to my local machine for testing.
I am getting an error that it can't instantiate the COM object because it is not registered but I KNOW it is registered because the DLL works on other parts of our website that are still in Classic ASP and will run on my local machine. I actually wrote a ASP script inside the the ColdFusion test site on my machine to test the DLL and everything works fine so it IS registered (via regsvr32.exe).
The ColdFusion page was done by an outside company that we are going to be breaking ties with and I don't have the password to their ColdFusion control panel even though it is on one of our servers. I wanted to look at their settings. Is there some setting that I need to set in the control panel on my machine? If there is I haven't found it yet.
Any ideas?
EDIT:
Here is the code:
<cfscript>
objEnc = CreateObject("com", "mycom.myclass");
</cfscript>
Also, I am running the 32-bit version of CF on a Windows 7 Pro 64-bit OS.
EDIT:
Another edit just for some more info:
The Windows 2008R2 server that it runs successfully on is a 64-bit server. So OS shouldn't have anything to do with it.
Should I try to find Version 9 developer edition on adobe's site and see if it works since it matches the CF version on the server? Haven't been able to find that yet and now Adobe just released 11.
After downgrading my local machine to ColdFusion 9 I can now access the COM DLL perfectly. Which is probably for the best since our server is running CF9. My testing will be with same version. Thanks for all you guy's input.
Randy
I have a problem connection to a SQL Server 2012 instance running on Windows Server 2012. I have a .NET 4.5 windows forms application installed on a client machine running Windows 7. The error I get is this:
A connection was successfully established with the server, but then an error
occurred during the pre-login handshake. (provider: SSL Provider, error: 0 -
The wait operation timed out.)
My connection string looks like this:
server=SERVERNAME;database=DATABASENAME;User Id=someuser;password=somepassword;Timeout=60;app=LabelMaker
I tried connecting to the SQL Server from the client machine using QueryExpress
and that worked! My app is 64-bit if that is of any help. I've checked every setting I can think of in SQL Server. No force encryptions are enabled on the protocols (shared memory and tcp/ip), the domain firewall is open on the server. I've tried various connection strings with all kinds of unheard off parameters, always the same result, failure.
I'm really confused about why it works with QueryExpress? My app works when connected to a remote instance of SQL SERVER Express on another machine, it also works if I run it on the SQL Server 2012 machine.
I've also tried connecting to the server from the client machine with LinqPad and this is also really weird, with the new version based on net4/4.5 (Version: 4.43.06) it fails but when I use the old version of Linqpad (2.x) based on net3.5 it works!
It seems like Panda Security is causing the problem, I ran
netsh winsock show catalog
and found a few panda entries, I then did a reset
netsh winsock reset
now my application works fine, I then rebooted the machine, ran the catalog command again,
the panda entries were back and my app is having the same problem as before.
Here are the Panda entries in the winsock catalogue: https://gist.github.com/pellehenriksson/5159883
All ideas and suggestions are appreciated.
UPDATE
Panda Security v5 is the cause of this problem, this has been confirmed by Panda support.
The root cause of the problem is explained by Alex below. The customer will do an upgrade to v6 of Panda Security, I will test again after the upgrade.
CONCLUSION
Moving to Panda Security v6.0 fixed this issue.
This seems to be a non-Microsoft related issue: Visual Studio 11 beta installation disabled my abillity to connect remote MS SQL Server but not local databases.
The ticket has been closed as external.
The only workaround available at this time on Microsoft Connect is:
Posted by Lars Joakim Nilsson on 5/4/2012 at 5:03 AM
My machine had this problem. The work around for me was to remove non-IFS LSP installed Winsock Catalog Provider. Se
http://support.microsoft.com/kb/2568167
/Lars Nilsson
The SetFileCompletionNotificationModes API causes an IO completion port not work correctly with a non-IFS LSP installed link gives the resolution:
Not specifying the FILE_SKIP_COMPLETION_PORT_ON_SUCCESS flag or
removing any non-IFS Winsock LSPs installed. Also moving from a
non-IFS LSP to Windows Filter Platform (WFP) can resolve this issue.
So, you should remove Panda Security or, as an alternative, you may try to execute netsh winsock reset as a pre-build command (although I'm not sure if this is effective without a reboot), which would let you develop/debug your application.
[UPDATE]
More information about application compatibility is given here: Application Compatibility in the .NET Framework 4.5:
Data
SQLClient
Feature
Ability to connect to a SQL Server database from managed code that
runs under the .NET Framework 4.5.
Change
The existing synchronous API code path was modified to add
asynchronous support.
Impact
The presence of non-IFS Winsock Base Service Providers (BSPs) or Layered Service Providers (LSPs) may interfere with the ability to
connect to SQL Server. For more information, see
SetFileCompletionNotificationModes API causes an IO completion port
not work correctly with a non-IFS LSP installed on the Microsoft
Support website.
I hate to say it, but restarting Visual Studio and my Microsoft SQL Server Management Studio solved this problem.
I have a web server (Coldfusion) and 2 remote networks that have SQL servers. For both remote offices/networks I query for data every 10 minutes. It has been working for some time now. In one of the offices/networks, AT&T dumped our public static IP address. They assigned a new one and I have made the appropriate changes to the firewall. Now I can use the Windows ODBC manager and test the connection from the web server and it passes just fine. But, when I try to verify the Coldfusion data source, it fails, "timed out trying to establish connection".
ColdFusion 9 doesn't use the Windows ODBC drivers; it uses JDBC drivers. Changing the Windows ODBC drivers and testing them will have no affect on your CF sites.
Update your DSNs in ColdFusion Administrator. Remember, you access your CFAdmin via:
http://localhost/CFIDE/Administrator
unless you've specifically changed it during install. Obviously, replace "localhost" with the server's IP or hostname if it is externally hosted.
ADDENDUM
The exception to the above rule is when you are using the ODBC-JDBC Bridge (CF DSN type = "ODBC Socket"), in which case, you need to verify that:
a) The Windows ODBC Driver (System) is set up, tested, and working, and
b) The CF DSN is pointing to the correct Windows ODBC Driver.
If you are using Windows Server 2008 64-bit, then you may be having trouble with your ODBC because you could be looking at the 64-bit connection list, rather than the 32-bit. In this case, you will have to open up c:\windows\syswow64\odbcinst.exe to access the 32-bit ODBC manager (yes, you read that right; the 32-bit version is under a folder named syswow64).
It sounds to me like there is a good chance that the driver settings you need to update are there, instead of those found registered under the 64-bit ODBC manager (which is the default ODBC manager under control panel). You may have actually had duplicate ODBC entries, one under the 64-bit list and one under the 32-bit list, and this could be the source of the confusion - CF could be using the 32-bit version. In any case - this would be a good thing to check.
Good day StackOverFlowlers,
I´m a little stuck (really stuck) with an issue with a legacy application on my organization.
I have a Windows 7 Enterprise 64 Bit machine, Access 2000 Installed and the Legacy App (Is built with something like VB but older) The App uses System ODBC in order to connect to a SQL 2000 DataBase on a Remote Server.
I created the ODCB using C:\Windows\SysWOW64\odbcad32.exe app in order to create a System DSN. I did not use the Windows 7 because it is not visible to the Legacy App.
I tested the ODBC connection with Access and worked ok, I can access the remote database.
Then I run the legacy App as Administrator and the App can see the ODBC, but I´m getting errors on credential validation and I´m getting this error:
DIAG [08001] [Microsoft][ODBC SQL Server Driver][Multi-Protocol]SQL Server does not exist or access denied. (17)
DIAG [01000] [Microsoft][ODBC SQL Server Driver][Multi-Protocol]ConnectionOpen (Connect()). (53)
DIAG [IM006] [Microsoft][ODBC Driver Manager] Driver's SQLSetConnectAttr failed (0)
I use Trusted Connection on the ODBC in order to validate the user by Domain Controller.
I think that the credentials are not being sent by the Legacy App to the ODBC, or something like that. I don´t have the source code of the Legacy App in order to debug the connection.
Also, I turned off the Firewall.
Any ideas??
Thanks in advance!
When you run it as administrator is it your same account elevated or is it a second account all together?
Try running Access 2000 under that same method and see if it can still access the database. You can also check the SQL server logs to see who the app is trying to authenticate as. This should help you identity where to start looking.
I recently installed SQL Server 2008 Express on my Windows 7 Ultimate x64 home machine. I also have IIS 7.5 with PHP 5.3, and I was trying to connect to SQL via ADODB, but kept getting this error:
[Microsoft][ODBC Driver Manager] The specified DSN contains an
architecture mismatch between the Driver and Application
After doing a small amount of digging on the internet, I think this is because the SQL Server ODBC driver is meant for 32-bit operating systems, and mine's 64. First of all, am I correct? Is this the reason I'm running into trouble? Secondly, if so, how do I fix this? Are there any updated ODBC drivers that work with 64-bit operating systems? I looked but was unable to find any...
You're right in that it has to do with the bits.
Hope this helps:
--From MSDN --
To manage a data source that connects to a 32-bit driver under 64-bit
platform, use c:\windows\sysWOW64\odbcad32.exe. To manage a data
source that connects to a 64-bit driver, use
c:\windows\system32\odbcad32.exe. If you use the 64-bit odbcad32.exe
to configure or remove a DSN that connects to a 32-bit driver you will
receive this message.
I've been having the same problem trying to link a 64 bit SQL 2012 server to 'Sage Timberline' using Pervasive ODBC Client Interface.
I can set up the 32 bit DSN, but SQL Server keeps giving me the "architecture mismatch" error when trying to create a linked server using the 32 bit DSN.
I tried the C:\Windows\SysWOW64\odbcad32.exe to add the driver. But when I set up a linked server between MAS90 and SQL Server 2008 R2 I still get the architecture mismatch error. Just spoke to a guy from Sage and he says it won't work with 64-bit edition of Sql Server. The linked server works with MAS90 only if the edition of Sql Server is 32-bit.
I'm betting you are working with User DSNs.
Depending on your perspective, there's a "feature" or "bug" in the 64-bit Windows environment --
32-bit User DSNs show up in the 64-bit Administrator and when 64-bit client applications ask for all available DSNs -- even though the 32-bit DSNs cannot be used by the 64-bit client app and Adminstrator.
64-bit User DSNs show up in the 32-bit Administrator and when 32-bit client applications ask for all available DSNs -- even though the 64-bit DSNs cannot be used by the 32-bit client app and Adminstrator.
The error message you describe comes up anytime there's such a bitness mismatch between the DSN and the client trying to work with it.
Microsoft's recommendation is to name your User DSNs with _32 or _64, depending on the bitness of the driver on which they're based ... or stick with System DSNs.
There are 32-bit and 64-bit solutions for the connection you want. The bitness of your client application(s) -- IIS & PHP, in this case -- dictate the bitness of the solution you require.
if 32 bit application on 64 bit operating system (the application you are installed under [program files (X86)] use the following
C:\Windows\SysWOW64\odbcad32.exe
otherwise 64 bit application and 64 bit operating system use the following
C:\Windows\System32\odbcad32.exe
otherwise you will get a error like "Architectural mismatch"
Hope this will save someone's day :)
This worked for me:
Updated solution, make sure the IIS application is NOT set to 32-bit on x64 Windows. More info:
http://forum.gpsgate.com/topic.asp?TOPIC_ID=13711
from:
http://forum.gpsgate.com/topic.asp?TOPIC_ID=13622