I tried to migrate my Classic ASP application with its Access DB from Windows 7 Professional to Windows Server 2012.
For standard script without accessing access db, it's working fine.
But I got error when the script use access db, by the following:
Microsoft OLE DB Provider for ODBC Drivers error '80004005'
[Microsoft][ODBC Driver Manager] Data source name not found and no
default driver specified /includes/public.asp, line 64
Here is my connection string
strConn = "DRIVER={Microsoft Access Driver (*.mdb)}; DBQ=" & server.mappath("../private/apps.MDB")
In application pool, I've set
.NET Framework Version = No Managed Code
Enable32Bit Application = True
ManagedPipelineMode = Classic
What am I doing wrong?
The "Microsoft Access Driver" is the desktop driver installed when Office Access or the Office Access Redistributable is installed, it is not intended for use in server-side applications. The current Access driver is also known as ACE (Access Connectivity Engine) and replaces the JET engine for single-user desktop applications only.
Instead, please use the JET 4.0 OLEDB or ODBC driver (ODBC is preferred). This driver is included in MDAC which comes with Windows Server out-of-the-box. The connection string template is this:
Provider=Microsoft.Jet.OLEDB.4.0;Data Source=c:\somepath\myDb.mdb;
OR
Provider=Microsoft.Jet.ODBC.4.0;Data Source=c:\somepath\myDb.mdb;
Note that the JET 4.0 driver is only available in 32-bit mode (but you've already set your application-pool to 32-bit so this won't be an issue).
Note that JET is effectively obsolete at this point (its successor, ACE, is only intended for use in single-user desktop applications) as evidenced by its availability only in 32-bit versions. Server-side and multi-user applications should use SQL Server (SQL Server now supports "LocalDb"-mode which introduces a simpler working experience, similar to Access, and it's available in Express Edition). If you absolutely need something simple and low-resource I would suggest SQLite, however you will be responsible for using the SQLite API correctly in a multithreaded/concurrent environment like a webserver (including Classic ASP).
Update:
I'll revise my answer to warn that using LocalDb with ASP.NET, or server applications in general, is inadvisable - and of little point, actually - if you're using LocalDb then you already have SQL Server installed, and if you already have SQL Server installed then you might as well use it in "normal mode" rather than LocalDb mode.
Related
Can I install both ODBC Driver 13 and ODBC Driver 11 on the same server?
I need to access Microsoft SQL 2008 database and Microsoft SQL 2016 database. First one requires ODBC Driver 11. Second one requires ODBC Driver 13.
Would they be independently use by the system?
Update:
I have installed both drivers 11 and 13. I still can't work with my 2008 database.
Not sure if I need to restart? Did not restart as installation did not ask for it.
It appears you can simultaneously install ODBC 11 and 13|13.1 since the filenames are different and even Microsoft suggests you can change the connection string. (I do not have yet a server with SQL 2016 on testing environment. Therefore, I can not test it).
How to differentiate which application will use which?
To quote from the Microsoft's pages:
When an application uses the driver, the application should indicate
that it depends on the driver through the install option APPGUID.
Doing so enables the driver installer to report dependent applications
before uninstalling. To specify a dependency on the driver, set the
APPGUID command-line parameter to your product code when silently
installing the driver. (A product code must be created when using
Microsoft Installer to bundle your application setup program.) For
example:
msiexec /i msodbcsql.msi APPGUID={ <Your dependent application's APPGUID> }
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 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.
I'm working with
1) Window7 32bit
2) VS 2005
3) language: C#
I made an application that connects to an Access file and deployed the applicatioin with Clickonce on my computer.
I published in release/any cpu mode.
The prerequisites was .Net Framework 2.0.
When I installed the appliction on another computer (Window7 64bit, MS Access Database Engine 2010 32bit), an error occurred.
The error message was Cannot Connect to Database.... System.Data.
My connection string is Provider=Microsoft.ACE.OLEDB.12.0;Data Source=....
64-bit and 32-bit components don't play well together.
I had a similar issue with 64-bit Windows and a 32-bit ODBC driver. You most likely need the 64-bit version of the Access database driver.
I usually make applications with the front end in Access 2003 - 2007 and the back-end on SQL Server 2008. When I create an ODBC to link the tables in access I have two choices in the ODBC Data Source Administration page on my Windows XP PC:
Server 2008: SQL Server Native Client 10.0 v.2007.100.2531.00
SQL Server v. 2000.85.1132.00
Which of these should be better and compatible on PCs with just Access 2000?
The native client has support for some additional (more advanced?) features of sql server 2008 (and 2005 I believe).
However, out of the box, you are far more likely to find the standard sql server driver installed on the computer.
Unless you are using some type of installer, or some other software installs this native client driver, then you are best to stick with the default non native driver for maximum compatibility. And, there is just the plain issue that the standard driver is most likely to be already installed on your client side computer.
So, that new native driver not going to be installed by default, and you likely have somewhat better luck with the non native default driver. I had a few issues come up with exporting date columns when using the new native driver (can't recall just right now what the issue was, but there was an issue).
Note that your connection strings are/will be slightly different for the native driver, and if you have some re-link code, that code will fail on computers without the native driver. So, while you have both on your computer, you can't assume this will be the case on other computers. So, you should have special and good reaons to choose/use the new native drivers for 2008/2005, but if not, then use the standard ones.