I've got a client that I wrote an asp front end application 2 yrs ago, which connects to a access 2007 database. All the files sat on a windows server 2000 machine 2 yrs ago. They recently upgraded their server to a windows server 2008 machine (64bit). Now the asp can't connect to the Access database via the ODBC connection. I tried using a dsnless connection, as well as, a manually created dsn connection (the manual dsn was created on the server 2008 machine using the 32bit .exe wizard to create dsn connections)...but that didn't work. I get an error that basically says the database odbc couldn't connect.
I've read that this is a problem between a 64bit 2008 server and a 32bit application (access 2007), but I can't seem to find any solutions to fix this problem.
Can anyone point me in the right direction, or offer some help? I'm really clueless how to solve this for them and they really don't have any other people to help.
Thanks for your help.
On a Windows 2008 x64 the following can be done to enable 32 bit applications in IIS:
Open IIS (inetmgr command)
Locate the application pool that your application is using
In the pool's advanced settings, set Enable 32-bit Applications to true
If that doesn't work, try enabling 32 bit compatibility mode by using the following command:
cscript c:\inetpub\adminscripts\adsutil.vbs SET /w3svc/AppPools/Enable32BitAppOnWin64 True
Hope it helps!
Related
We've got some MS Access 2007 apps here. I'm responsible for one. Normally, it never gives any problems. I haven't heard from the users of this app for over a year, until today. It was written years ago by someone (I don't know who) that is long gone, with little documentation. We're in the process of replacing all of our Windows 7 machines with Windows 10 machines. At first I thought that was the issue. However, one of my colleagues, who is responsible for a number of Access 2007 apps, said that his users are able to use their Access apps with no problem.
Looking back at the user's error, it says simply, "ODBC - call failed". No error number; just that. So, my next thought was maybe there was a missing DSN on the new Windows 10 machine. However, I asked the PC tech to check one of the working Windows 7 machines. He told me there were no DSN's in them. I'm not an Access developer, so I asked my colleague, who does do Access development, what he could discover. He found that the tables are all linked tables from a SQL Server database. Looking at what he was referring to (now that I know where to look) I saw what he meant. The connection to each of those tables uses trusted connections. They're all pointing to the correct SQL database server. That server is there. When I got into SSMS I could easily see data in the tables.
So, what could be causing that error to occur, especially since it doesn't look like it needs a DSN to make a connection to the SQL db?
I presume your Windows 10 is 64-bit.
And probably your Access is 32-bit.
Its important to know!
If my assumptions are correct, you need to use the 32-bit version of ODBC admin to setup the DSN.
The 32-bit version is 'C:\Windows\SysWOW64\odbc32.exe'
The 64-bit version is 'C:\Windows\System32\odbc32.exe'
32-bit Access will look for a DSN setup using the 32-bit version of ODBC admin, even on a 64-bit OS. If you setup the DSN with the 64-bit version of ODBC admin, then a 32-bit Access will not see it!
Go back on the Windows 7 PC, and check exactly how the DSN is setup.
Is it a System, User, or File DSN?
Which drivers are installed for SQL Server?
(There are various different ODBC clients available for SQL Server.)
Replicate this DSN configuration when you create the DSN on Windows 10.
It sounds like you using the 'SQL Server Native Client' on Windows 7,
so make sure to install that on Windows 10.
See: Installing SQL Server Native Client
I have an old website that is built with classic asp and MS access 2000 and was running fine on an old server. I need it to work on new machine equipped with Windows Server 2008 R2 64bit & IIS7.5
I tested ASP classic and it is running fine on the new machine. What I am trying to do is to make connections with the ms access db.
I installed "Microsoft Access Database Engine 2010 Redistributable" 64bit and restarted the machine.
ASP code is something like this:
<%dim db
set db=server.createobject("adodb.connection")
db.open "Driver={Microsoft Access Driver (*.mdb)};DBQ=" & server.mappath("Staff.mdb")%>
I got the error message:
"500 - Internal server error.
There is a problem with the resource you are looking for, and it cannot be displayed."
Is there some kind of configuration I need to do on IIS or something...
Driver={Microsoft Access Driver (*.mdb)} is the ODBC driver name for the older "Jet" database engine. It ships with Windows, but it is only available to 32-bit applications and it only works with the older .mdb database file format.
If you need to
work with an .mdb database from a 64-bit application, or
work with an .accdb database from any application
then you need to have the newer Access Database Engine (a.k.a "ACE") installed, and your driver name needs to be Driver={Microsoft Access Driver (*.mdb, *.accdb)}.
I used to have to migrate a web system that is asp connected to the mdb database worked on windows server 2003 moved to work on windows server 2008 R2.
encountered the same problem and fix it this way
1.The default setting after the IIS installation is complete will cause the error time to run. The details of the problem will not be displayed on the web browser.
Solve the problem by : set IIS to show errors
(credit : https://learn.microsoft.com/th-th/iis/application-frameworks/running-classic-asp-applications-on-iis-7-and-iis-8/classic-asp-script-error-messages-no-longer-shown-in-web-browser-by-default)
2.The problem encountered is that the database or object is read only.
Solve the problem by :
Move the mdb file out of the web folder and not in the web subfolder. (ex : d:\web_data)
At the new folder of mdb, configure full control access to the users group of windows.
Specify a channel between asp and mdb with this command.
Set Conn = Server.Createobject("ADODB.Connection")
Conn.Open "PROVIDER=MICROSOFT.JET.OLEDB.4.0;DATA SOURCE=d:\web_data\data.mdb"
(credit : https://learn.microsoft.com/th-th/iis/application-frameworks/running-classic-asp-applications-on-iis-7-and-iis-8/using-classic-asp-with-microsoft-access-databases-on-iis)
(credit : https://www.thaicreate.com/asp/asp-ms-access-connect-database.html)
hope this is helpful. :-)
I am using windows 7 64 bit,VS 2010 and MS Office 2010. Trying to build an ssis pkg using an excel source, the problem arises as below.
Could not retrieve the table information for the connection manager 'Excel Connection Manager'.
Failed to connect to the source using the connection manager 'Excel Connection Manager'
I found some solutions on internet, tried these steps by
1) installing the MS access database engine 2010 redistributable_x64.exe. I restarted the system, But still the problem persists. i couldnt find the provider in the list of providers in the oledb source and so selected the jet 4.0 oledb provider and changed the extended properties to Excel 12.0, then i get the following error:
Test connection failed because of an error in initializing provider. Could not find installable ISAM.
and also if i use excel source, its throwing me an error as given above on the top.
2) Also, changed the run 64bit runtime to false and also back to True again.
3) tried to change the platform of the project , but it is disabled.
Could yopu please help me. Thanks in advance.
You need to install the 32 bits provider.
Even though your windows is 64 bits, the SSDT development environment is a 32-bit environment. The reason why you cant find the provider in the list of providers is because it only shows 32-bit data providers. You can only see 64-bit providers that have a 32-bit version available on the development machine.
Though its bit late but might to very helpful for other guys.
Visual Studio 2010/2012 comes with 32-bit version only and hence it cannot use ACE OLEDB 64-bit version, which comes with installation of office 2010 64-bit version.
So the solution here would be uninstall 64-bit version office 2010 and install it's 32-bit version. Re-try to add the excel connection manager.
This has resolved my issue and hope for other guys as well.
I have an application written in MS ACCESS 2007 using VBA, connecting to an SQL Server at the back end. Both Access and SQL Server are running locally.
My machine runs Access 2010 and MS SQL Server Express 2008 R2 (both 32-bit, on WinXP) with no problem.
I have another machine, Win7 64-bit, running both Access 2010 and SQL Server 2008 (NOT R2) 64-bit.
When I run the Access application on the 64-bit machine, I have a drop down box to select the SQL Server which holds the various databases. When I select the server, after a few seconds I get an error:
Run-time error '-2147024703 (800700c1)':
Automation error %1 is not a valid Win32 application.
When I select the Debug option, the yellow arrow points to:
Set oServer = New SQLDMO.SQLServer
The next line is:
oServer.Connect ServerName, strSQLUser, strSQLPwd
In the watch list, I can see that ServerName, strSQLUser, and strSQLPwd hold the right values to access the SQL Server. I've tested these in sqlcmd and successfully was able to query tables.
Can anyone please help me out on this one? I'm not sure what to do next.
Seems like you've got registered a 32-bit SQLDMO on your system that is being used for connection to the 64-bit instance. Check your registry / file system for SQLDMO.dll versions and register the correct one.
Also check MSDN "Installing SQL-DMO" because SQLDMO was scheduled for remove after SQL Server 2008 R2:
Avoid using this feature in new development work, and plan to modify applications that currently use this feature.
SQL Server Database Management Objects (SQL-DMO) has been removed from SQL Server 2008 R2 Express and the SQL Server 2008 R2 Feature Pack. SQL-DMO also does not support Database Engine features introduced after SQL Server 2000. We recommend that you modify applications that currently use this feature as soon as possible. If you must support SQL-DMO, install the Backward Compatibility Components from the SQL Server 2008 Feature Pack from the Microsoft Download Center. Do not use SQL-DMO in new development work; use SQL Server Management Objects (SMO) instead. You can obtain the SMO documentation by installing SQL Server 2008 R2 Books Online.
Thanks for this.
I looked to find SQLDMO.DLL 64-bit version, but although using the Backwards Comparability package for x64, installing using the MSI did not do the job.
I had to manually extract the files and place the correct version (which is ~2MB larger than the x86 version as an indication to knowing which one is the x64) and then run 'regsvr32 sqldmo.dll ' in the command line (very important: need to run cmd as Administrator for this to succeed).
After the module has been registered, my Access front end run great.
Having trouble getting my local IIS7 running C # MVC app to connect to a newly installed Sql 2008. IT was working wiht SQL Express, but we upgraded every machine to full SQL. Now, just my machine, will not connect to SQL 2008.
Followed many websites info, fooled wiht the user account both in IIS7 and SQL2008. Setting permissions to the DB's with db_owner(actually selected every permission) just not connecting.
I noticed the w3wp.exe service is not running. Not sure if that is the issue or if it was even running before.
Messed with the and tried all the sugeestions and tutorials out there that had to do with
Application pools are running, their set to the proper settings
IIs Account NetorkServices
Sql NT AUTHORITY\NETWORK SERVICE
created users for IIS APPPOOL\ASP.NET v4.0
When i check the sql logs there is no sign of it even trying to connect. The only message i get is when i restart IIs. Just says starting and stopping.
Been thru this before when i first tried to connect to SQL express, and was not this hard, and i did not touch anything in IIs when i installed sql 2008. So it should have connected.
Any other suggestions out there?
LLBL DataAccessAdapter should have string property ConnectionStringKeyName which contains app settings key (in web.config), which contains connection string. Visual studio does not use that connection string and you being able to connect to db from VS does not mean that connection string your application uses is valid.
Indirectly you lead me to the solution. lol
Started searching on running IIs and Sql 2008 on the same machine.
Running on a Win7 64bit, IIS7 an sql2008 R2.
Long story short, after hours and hours of fighting with IIS and SQL.
IIS7 --> Application Pools --> Select your pool --> Advanced settings --> General tab --> Enable 32-bit Applications set to true.
How it got to false, or why sqlexpress worked and sql2008 did not, not sure. But this fixed the issue.