I've tried to deploy a small website (ASP.NET) which is using an MS ACCESS 2010 db. Deploying the website on the server I get the following error:
The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine.
Connectionstring used : Provider=Microsoft.ACE.OLEDB.12.0; Data Source=path-to-db
MS Office is not installed on the server and neither is the Access Database engine. The website is runnin in a shared hosting environment, so I am not able to install office on that server, so may I somehow deploy the provider by dll's?
Is it possible to deploy the drivers needed for ASP.Net to connect to the database without having to run an installation on the server. As this is in a shared hosting environment, I am not able to install anything. Only fileupload by ftp.
Open IIS, navigate to Application Pools, find the appPool for your website, right click, advanced settings, set "Enable 32-Bit Applications" to true.
Looking around, this has nothing to do with Office. If you're only using Access as the database, then you don't need to install it. Info here: http://www.mytechsupport.ca/forums/index.php?topic=11237.0
I found this StackOverflow thread with the same error you did so it sounds like it might be the same issue. Microsoft.ACE.OLEDB.12.0 provider is not registered
If its running windows then look through that thread and see if the 64-bit issue is the problem. I've had this same issue before and its apparently quite common. You may need to e-mail whoever for support on your server.
Is it running Linux? If it is running linux then the issue might be just an entire lack of the driver to connect to Access databases. If this is the case I would e-mail your support and ask them if they can install the proper drivers for you. Info here: http://nixcraft.com/databases-servers/11878-connect-microsoft-access-database-php-linux-server.html
Related
I'm a contractor working remotely on a legacy ASP.NET application. I'm struggling to stand up a local instance of the project due to the error SQL Exception - SQL Server does not exist or access denied. I suspect this is because of the use of Windows Authentication for the SQL databases backing the project.
Before I launch into a lot more detail I'll ask my question: what are my options to pass Windows credentials to an SQL server in an ASP.NET project built on OSX?
I believe I've proven this is possible with some steps I'll detail below, but the actual implementation in an ASP.NET project is escaping me due to my inexperience with everything .NET, and the many-fold differences between my setup and the typical dev.
Standard Dev Setup
The devs I'm working alongside are using Windows machines housed in their corporate domain, running Visual Studio 2012. Because they're already logged into their machines with the appropriate credentials, the use of Integrated Security=SSPI in the SQL connection string "just works".
My Setup
I'm running a Mac Mini outside of their corporate domain, and using Visual Studio in conjunction with Mono to support the .NET Framework-based project. Passing the SSPI option won't work out of the box because I'm not connected to any Active Directory. That said, I do have valid credentials to log into their network.
What's worked so far
I've proven that a connection to their network resources is possible:
When logged into a virtual Windows machine, I can connect to a shared drive on that network with the credentials I was provided.
I then set up that same shared drive on my Mac Mini with those same credentials.
Using SQL Pro for MSSQL, I was able to connect to the desired database using my credentials.
As I understand it, what I'm looking for can be accomplished on Windows with Credential Manager, so bottom line I think I'm looking for the equivalent solution on OSX that plays nicely with ASP.NET project as compiled by Visual Studio.
tried looking at other examples on this and am a bit confused. I have 2 web servers that are load balanced and a sql server box (sql 2012). my cube is created on the sql server box (i see it in management studio). when i try to access via my asp.net page i receive the above error.
now, i see the msolap110.dll in C:\Program Files (x86)\Microsoft Analysis Services\AS OLEDB\110 on the sql box. do i need to do something permission wise with the dll or something? do i need to install analysis services on the web server? is there a specific port or something (doubtful as sql is running fine).
connection string is as follows:
"Provider=msolap;Data Source=;Initial Catalog=AutoOLAPAW;Cube Name=SampleCube;"
going to try to force to use MSOLAP.5 but waiting on a republish from our security/deployment group.
this all works fine in dev but my (more secured/stripped down) prod/qa is where i'm seeing the issue. using iis7 on both.
If you are using ADOMD.NET then either set CopyLocal=True on that reference on your ASP.NET source code so Microsoft.AnalysisServices.AdomdClient is deployed with the web app... Or install SQL_AS_ADOMD.msi from:
https://www.microsoft.com/en-us/download/details.aspx?id=49999
If you are using OLEDB then install SQL_AS_OLEDB.msi from that same link.
If you don’t want the SQL2012 version but want the latest then install from here and use Provider=MSOLAP in the connection string (instead of a number like MSOLAP.5).
I want to make an installer for a client which installs
a web app on IIS
a mssql db
a window service
I am totally naive to thinking of the solution for this automated deployment through an installer (msi or exe). The installer may hint the user for prerequisites for example MSSQL server and upgrading/installing IIS before the web app installation can proceed. Is it possible?
Yes, it is possible. You need to first select in an authoring tool for Windows Installer. Some examples are Windows Installer XML (WiX) and InstallShield (various editions from free to pricey). You'll have some kind of EXE bootstarpper/chainer where you can handle prerequisite installation such as windows features and database engines. Or you can choose to simply ship an MSI that detects and blocks if these are missing and put the effort on the user to manage their baseline environment. The actual MSI will then likely have features for web, service and sql. The web feature will install a bunch of files and configure the IIS meta. The windows service will install some files and create a windows service. The SQL feature will ask for connection string information, execute some sql scripts and possibly configure the web and service layers' connection strings.
Some of this can be deferred until after the installation and placed into a custom configuration utility to simplify the installer work.
There are various design decisions that can be made so it can't be answered in more detail in a simple question format.
Okay, I have a problem with OLEDB. I have install the "AccessDataBaseEngine.exe" and I am able to upload an Excel file to a Gridview on my local server. When I try to upload on my online web application (With Windows Azure) I get the following error: "The 'Microsoft.ACE.OLEDB.1.0' provider is not registered on the local machine." It does not make any sense to me as to why it does not work and after searching the web everyone suggests to install the AccessDataBaseEngine 2007 (which i did) and as mentioned above it works only on the local server. Anyone knows how to resolve this?
Thanks in Advance.
I have created a web application that runs a DTS remotely from a sql server 2000.
I made it worked in the visual studio environment but when i deploy it,
it doesn't work and the error message says :
DataPump_Task Failed.
I am not sure about my findings but...
does the problem has something to do with my IIS settings?
I am running IIS 7 on windows 7.
Thanks for your help.
When you execute a DTS Package from an ASP page, the package executes in the security context of the Web site visitor, which may be that of the Windows user (if the web site is configured for Basic or NT Authentication) or of the Anonymous account.
The package does not execute in the security context of the user ID supplied to load the package from SQL Server. Therefore, it is important to make sure that the account executing the package has appropriate Windows permissions to all resources that the package may use, such as disk files, DLLs, or other drivers (for import/export operations) especially when the Web site is configured for Anonymous access.
If a package works in the DTS designer and works from other client applications, but fails from Web applications, troubleshooting should begin with permissions issues.
For additional information about determining which Windows account will be used to execute the DTS package, see this article http://support.microsoft.com/kb/269074/EN-US