I feel that the title pretty much speaks for itself. I keep getting a server 500 error when i try to access a page on my site that is using the Access DB.
I created an ODBC (32 bit) Data Source using the driver Driver do Microsoft Access (*.mdb).
I am sure i am using the wrong drivers/IIS configurations. This used to be hosted on an old server and we are trying to move everything over.
Would anyone be able to point me in the right direction? Thanks!
EDIT
I was able to get errors printed to my page. Below is the following error:
Microsoft OLE DB Provider for ODBC Drivers error '80004005'
[Microsoft][ODBC Driver Manager] Data source name not found
and no default driver specified
When I enable 32-bit Applications I get the following error:
HTTP Error 404.17 - Not Found
The requested content appears to be script and will
not be served by the static file handler.
This issue is related to running 32bit applications on a 64bit server. Furthermore, if you have installed something else on it (for example, Outlook Web Access, or OWA for short) it can disrupt the IIS with adding it's 64bit modules to load globally, and that would effectively cause errors on 32bit pools.
The following debugging is assuming you have a requirement to run 32bit ASP application on a 64bit IIS server.
You have to set your application pool to run as 32bit
If the 32bit pool stops right after you make a request for an ASP page, it means that most probably there are 64bit modules failing to load. You need to see which dll is creating the issues by viewing the Windows Event log (eventvwr). Then, one by one, you edit the applicationHost.config file and add preCondition="bitness64" to each module that you see in the eventvwr until you get rid of all the errors in the log.
When finished with step #2, your pool should be working, but your app might not - it will most probably report 404.17, even if there is an ISAPI handler for ASP. When you open IIS, on the left side choose the server and on the right open the ISAPI and CGI restrictions. You will see that there's an ASP entry there (if not - you need to install it as a feature on the server). The ASP might point to something like %windir%\system32\asp.dll, but you need to make another entry. Your appPool is running as 32bit on a 64bit machine (that's shortened as WOW64 = 32bit Windows application running on Windows 64bit - Windows on Windows64), and you need to add an asp from %windir%\SYSWOW64\asp.dll. Also, add the corresponding handler (navigate to handlers, and practically repeat the entry for asp but use the SYSWOW64 folder instead of system32)
This should (finally) get it working.
Related
i develop an Asp core web application (.net framework).
how i specify a run as 32-bit applications?
the publish wizard do not give way to change the Target Runtime, which the selected option is x64 is selected.
I installed on my machine the x86 version of .NET Core Installer.
publish wizard screenshot:
PS Why do I need x86.
I had to run the site on a computer that installed Microsoft Access 32-bit (2003, for an old software).
I also need to access data in Microsoft Access file, which requires me to use the Microsoft.Jet.OLEDB.4.0 driver.
The problem is, probably, that the app's core ASP.NET always running as 64-bit applications, is what gives me the known exception 'driver not registred'
stil after set "enable 32-bit application" in IIS.
i cant install the 64-bit access driver engine, because it requires the removal of MS Access 32-bit...
As mentioned here you need to add the "runtimes" key to your project.json file like below image.
Once you do this, the Target Runtime entry in Publish menu will list all of your specified runtimes. Although this is not enough to get it working since using the Publish menu and selecting x86 version will have no effect and will result in x64 binary files. (This bug may be fixed in future).
The workaround is to navigate to your project folder where the project.json resides. Open a command prompt and type the following to have your binary in desired runtime:
dotnet publish --runtime win7-x86
If you get any error yet, you may need to have the corresponding runtime installed (Download form here).
More info:
https://learn.microsoft.com/en-us/dotnet/articles/core/app-types
https://learn.microsoft.com/en-us/dotnet/articles/core/rid-catalog#what-are-rids
There is also a platform key under buildOptions listing all possible targets, but yet because of some issues (like #1624) it has no effect and it seems the system ignores that.
I have a Web-API project that is configured with a connection string which sets the Data Source to an alias defined in SQL Server Configuration Manager. The server runs fine when launched through Visual Studio 2013, but when launched as a separate process using %PROGRAMFILES%\IIS Express\iisexpress.exe it fails to connect and eventually times out with the error:
System.ComponentModel.Win32Exception (0x80004005): The network path was not found
The process works as expected if the connection string is modified to specify the actual server (e.g. localhost) rather than using the alias.
I discovered this question asked on a RedGate forum which seems to indicate that at least one other person has had this issue as well.
This issue of the alias not getting picked up ended up being a result of the 64-bit version of IIS Express running a process that tries to connect to a 32-bit install of SQL Server 2008. Once I changed the execution path to %PROGRAMFILES(x86)%\IIS Express\iisexpress.exe then it worked correctly.
My company has developed an application with Visual Basic 6.
The application uses an Access database via an ODBC datasource.
The Access database is a file with the ".mdb" extension.
We have not noticed any slow data access when running the application in the following environment :
OS : Windows 7 32 bits.
Installed version of MS Access : Access 2007.
Access driver used by the OBDC datasource : Microsoft Access Driver (*.mdb) version 6.01.7601.17632.
But we have noticed slow data access when running the application in the following environment :
OS : Windows 7 64 bits.
Installed version of MS Access : Access 2010 or 2003.
Access driver used by the ODBC datasource : Microsoft Access Driver (*.mdb) version 6.01.7601.17632.
I have googled for a while to find a solution.
Other developpers have experienced the same problem according to articles found on the Internet.
For information the tracing feature is not enabled in my ODBC 32 bits administrator.
The following page mentions the tracing feature :
http://answers.microsoft.com/en-us/office/forum/office_2010-access/my-solution-to-access-being-slow-with-odbc/a5a6522f-a70f-421e-af1b-48327075e010
I have also tried without success to disable the LLMNR protocol as mentionned in the following page :
http://accessexperts.net/blog/2011/11/02/windows-7-64bit-slow-with-access-2007-solved/
Any help will be greatly appreciated
There are number things to check, the first and foremost thing you want to do is create in your application what we call a persistent connection. A persistent connection simply means that somewhere in your startup code, you open up a table from the back end to a record set, and keep it open for the duration of any other operations you do in that application.
The reason why a persistent connection often makes a huge difference is that the newer operating systems tend to do have a tremendous amount of additional security and overhead when a connection to the databases created. And it turns out that generally opening and closing tables in access databases requires that these connections are also opened and closed. If you force the persistent connection to remain open at all times, then this very slow and large overhead process that interferes with general performance of general updates in your code will now not be incurred.
Give the above a try, since this setup very often cure is this performance issue and problem.
I have an application that uses the MS Access 2003 front end to connect to both a MS SQL and a Sybase database. This application uses VBA (Visual Basic 6) and this cannot be changed. We are in the midst of a conversion from Windows XP (where the application runs fine) to Windows 7.
On Windows 7, attempts to connect to the Sybase databsae fail. The application uses a pass through query and when the failure occurs, I receive the following message:
An unexpected error occurred in Call_SP.
Error number: 48
Error description: Error in loading DLL
Error source: Secure open security
The particular line of code where this is throwing the error is:
For Each qryDef In dbLocal.QueryDefs
The items in this line of code are defined like this:
Dim dbLocal As Database
Dim qryDef As QueryDef
Set dbLocal = CurrentDb()
When originally launching the application, there was a missing reference for Microsoft DAO 3.6 Object Library. I copied the dao360.dll file to C:\Program Files (x86)\Common Files\Microsoft Shared\DAO, registered it using regsvr32.exe, and set the reference (Tools -> References) to this file.
At this point, I suspect the problem may have something to do with user rights on this machine, but I'm stuck on where to start. Users do have "read and execute" rights on the dao360.dll file.
We have a lot of legacy apps written in Access, so our systems use Access 2003, but Word, Excel, and Outlook 2010. We are moving to Windows 7 64-bit.
If I was in your shoes, I would try the following:
Remove and re-install Access
And I would run a registry cleaner like CCleaner to remove broken library reference from the registry before re-installing Access and applying all updates.
The fact that the dao360.dll was missing or improperly registered shows that there is at least one installation issue on that machine.
Also, remove and re-install your ODBC drivers for the other databases.
Try on the same machine from a different user
Create a new user on the machine, then log under that user and check if you still get the issue.
Try from a different machine
Use the same database, make sure the DAO references are selected, and try code query again.
If it still doesn't work, then there is another issue somewhere, and it's not related necessarly to DAO.
You mention using Sybase and SQL Server.
Are the ODBC drivers functioning properly? Could there be some corruption there too on the machine?
What if you create a new database and try a single pass-through query using the same connection string?
32 and 64 bits mixup
Are you sure all dependent software and database drivers are installed for 32bit?
If you are trying to access an ODBC data source that uses a 64bit driver from a 32bit app, it will fail.
In Win7 x64 the ODBC console available from the Administrative Tools in the Control Panel is not 32bit!
You need to create your DSN using C:\Windows\SysWOW64\odbcad32.exe instead.
There is no need to attempt to re-register the dao library here and doing such is a silly wild goose chase and amounts to wasting company resources. Installing Access 2003 on that computer should work just fine and installing 2003 on that computer will ALSO correctly install the DAO libraries (attempting to copy and re-register the DAO library has the potential to turn your computer into a complete mess here – don't do this and it not required).
There are either some broken references or perhaps the ADO library was placed higher up in the references as compared to the DAO library. In fact check the references in the VBA editor. If ADO is not being used, then remove the reference.
Also if outlook is being used from this application then remove the outlook reference in this application. You REALLY need to use late binding for Outlook automation code.
I have run Access 2003 on windows 7 x64 since the win 7 beta and I had zero problems here. This is nothing to do with x64 or win7, but only that of behaviors of a typical broken reference.
The solution that I came up with was to use weak typing, and to reference all DAO objects through CurrentDb. The only references I have in my project are VBA and the Microsoft Access Object Library, which are required anyway. It is a bit radical, but it does give you something that can be deployed on any platform.
The project of every newly created Access database includes a reference to a DAO library. But DAO library references are no longer updated when databases are deployed on different machines. That feature was broken in Access 2007, when the DAO library was renamed.
In your example, this would be:
Dim qryDef As Object
For Each qryDef In CurrentDb.QueryDefs
Problem ocured when x86 and x64 version of OS/Access are instaled.
You need to create directory (I'm sure it does not exsit and You need administrative rights to do this):
C:\Program Files\Common Files\microsoft shared\DAO
Copy dao360.dll from C:\Program Files (x86)\Common Files\microsoft shared\DAO
to the directory created in step (1)
Now add reference in your VBA application.
I deployed an MDE file on the terminal server and when I double clicked the MDE i have the following error. " There isn't enough memory to perform this operation. Close unneeded programs and try again.
I never had any issues on local machine.
I tried de-compiling and compacting and again compiling. I can open other forms but only SwitchBoard is the issue. Any thoughts? Hardly there are 9 links from the MainMenu.
If you're in the console session on the terminal server (at a KVM?), or if you enable "Install Mode" (after you remote desktop, running "CHANGE USER /INSTALL"), does the problem still occur? I don't know of any specific issues with MDE applications over terminal services, but trying those two things will let you know if it's related to the TS configuration, or if it's a problem running that MDE on the server itself.
Can you update the question with the version of both Windows Server and Access you're using? This Microsoft KB article suggests a problem when you have Windows Server 2003 and Access 2000, so some more detail would be helpful here.