I am trying to access a file stored in a Microsoft Access database (I am working in Visual Studio Community 2015) and I ALSO have Office 365 64-bit version on my machine.
I set the Target CPU under compile to x64. I chose the database source type, and the dataset database model, when it asks me "which data connection should your application use to connect to the database?", I clicked New Connection, then I chose Microsoft Access Database File (OLE DB).
Under database file name, I clicked browse and selected the appropriate file (Sales.accdb). When I press "Test Connection" or Ok I get this error:
Unrecognized database format 'C:.....\Sales.accdb.
Any ideas as to what I am doing wrong?
It turns out that all I had to do was install the correct Access Database Engine which can be found at https://www.microsoft.com/en-us/download/details.aspx?id=13255
It installs and runs works perfectly now. I was apparently confused between the Access Database Engine needed by Visual Studio and the Access 2016 runtime which is a different thing altogether. This was pointed out to me by Gord Thompson.
The presence of the Office 365 is irrelevant - you need the correct MS Access DB Engine. See this SO post for details.
You need to do it in 32-bit MS Office (Access 2016 AKA Access 365 for now) with the 32-bit Access Database Engine. It works OK. Even though the two componets are both 32-bit, the Office has a small 64-bit installer file in it though, see the screenshot, and that has to be removed first - for how to see this advice.
The 64-bit Access 2016 with 64-bit Access Database Engine 2016 produce "The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine." problem.
Related
I'm running an MS Access database with VBA code that has libraries for Microsoft Office 2010. Currently, there are users that are upgrading their machine to Windows 10 running Access 2016.
When the database is opened on a new machine running Access 2016 the libraries for the Outlook changes to 16.0.
When I try to open the file in the old Access 2010 environment, I run into this error:
Missing msoutl.olb.
Is there a way to make the database backwards compatible?
It sounds like the users share the same frontend hosted in a network folder.
If not done already, split the database to have a single shared backend database file. Then, to avoid your issue, distribute a separate copy of the frontend to each user's workstation.
On the workstation, let the user launch the frontend using a shortcut that runs a script to always keep the frontend current. This method is described in detail in my article:
Deploy and update a Microsoft Access application with one click
experiencing an odd issue I've yet to see on any of my other machines. This is a fresh laptop, so I have installed VS 2017, SQL Server 2017 express, then created a quick sample project using one of the stock .net core projects (with authentication stored "in-app"). This, of course, creates some basic entity migrations and DB context.
When I run I'm getting access denied errors. So, of course, I checked SQL service default user which is an admin. I then run basic migration commands and receive this
So, of course, my next step was to double check the default data locations of SQL since it appears to be trying to store it in C:\Users root?! I have never had to bother touching this during install, but worth a look. And of course, they are as I expected in their default locations of C:\Program Files\ etc
Rapidly running out of things to try at this point - and considering this is a fresh windows 10 install, with bare-bones vs 2017 and SQL express 2017 it feels a lot like a bug here. Everything is a default if you were to File -> New Project -> .NET Core Web Application with INdividual accounts.
Anyone have any thoughts or things worth trying? Why is it trying to store my DB in C:\Users? Connection string -
"DefaultConnection": "Server=(localdb)\\mssqllocaldb;Database=aspnet-WebApplication3-53bc9b9d-9d6a-45d4-8429-2a2761773502;Trusted_Connection=True;MultipleActiveResultSets=true"
Thanks!
-Marc
You are not using SQL Server Express.
The local string says (localdb), which is the SQL Server engine running in user space. This is a big difference. Usually SQL Server or SQL Server express runs as service. (localdb) is not an alias for localhost (loopback address). It's a special name for a minified version of SQL Server which runs in user space.
When SQL Server runs as a service, it needs to have read/write permissions to the folder it writes. This is usually NOT THE CASE when the file is located within the User folder.
LocalDB on the other side, is always started when you start debugging your application and runs with the permissions of the user. So if your file was created by an admin user or outside of a directory you have write permissions.
Also, when you mount a database to SQL Server (Express), then the file is protected from write access to other applications, so LocalDB can't open it neither.
LocalDB is made for development to offer most of the SQL Server features but without all the hard setup and permanently running service in the background.
Essentially you have two options:
Use the SQL Server connection string as #TanvirArjel suggested
Detach the database from SQL Server express, copy it to your user folder (C:\Users\<myusername>\) and then correct the path to it
Then it should just work.
Notice that LocalDB is not meant to run in production, so you will likely experience issues when trying to run it in IIS (IIS Express and Console applications and WPF work fine).
Reasons for LocalDb not working with IIS is because ASP.NET (Core) applications within IIS run with a special user, but LocalDbs are always created in the users profile folder. Now, the accounts used by IIS don't have a profile and can't create the database and can't access any database outside (since localDbs are stored in user folder only the user who created it has access to it).
Here some source on it and the reasons behind it.
Using LocalDb with IIS
Write the connection string as follows.Hope it will work...
"DefaultConnection": "Server=YourPcName\\SQLExpressInstanceName;Database=aspnet-WebApplication3-53bc9b9d-9d6a-45d4-8429-2a2761773502;Trusted_Connection=True;MultipleActiveResultSets=true"
I am trying to find a solution to three issues I have encountered recently relating to SQL Server 2014. I am not an expert with this stuff by any means, but I've sort of fallen into needing to learn it in my current role. I went from never using SSMS a few months ago to (Trying) to teach myself how to use SSIS and SSRS. I've made a ton of progress, but now I'm stuck actually getting everything automated the way I want it.
The biggest challenge, and root of all my problems, stems from the fact that I am not a local admin on my machine. It was great to finally get IT to install the programs, but they do not want to give me, or anyone not in IT in my company, local admin access. Apart from asking my director to try to convince them to do so, I'm hoping for some solutions that would mean I don't have to call them every day to run these programs.
My integration server is running, I've got my SSIS packages built, but I can't connect to the Integration Server through SSMS, as I am not a local admin on my machine. I've read about going through dcomcnfg settings for REMOTE access issues, but I'm worried that won't help here since I'm trying to do this from the local machine and it still doesn't work. Any ideas as to how I can change the settings so that it runs for non-admin accounts or just make it work?
SSRS: I've built a report, and want to deploy it, but I don't have access to the reporting services configuration manager either. For whatever reason my reporting server is stopped in the server configuration manager. When I click on it, it says to use reporting services config mgr to tweak settings, so a bit stuck. Appears to be the same issue - not a local admin. Again, are there any settings I can change (getting IT to log in as an admin and walking them through what to change is my only choice, essentially).
SQL Server agent appears to be the same issue...
I could probably run my reports now, but it would be so much nicer to use these programs to the full extent. Any help would be appreciated here. I tried to research as much as possible, but most solutions seem to relate to logging on myself as an admin, running things as admin, etc, and I just can't do that.
Thanks!
You do not need to be local admin on your machine, SSIS and SSAS require Windows Authentication to log on remotely to the server via SSMS and publishing anything to the server from BIDS / SSDT Visual Studio Shell also requires WinAuth, though you can work locally and then swap the package to the server via Ctrl-C, and also instead of deploying SSRS you can login directly to the report manager and upload an RDL file (report). To start and stop SQL Agent services you need Windows Authentication via SSMS (in your setup), but to view the SQL Agent you must be in the SQL Server SysAdmin role (or at a grain level SQL Agent Reader via the MSDB rights.
I recommend you attempt to not get local administrator rights and instead ask 'merely' for rights to read and write to the server drives, and to manage only the aspects of SQL Server and it's services with a domain login on the server. You will require this anyway to check ingress and egress file locations and debug production issues (unless you have FTP to the box).
You do not have access to stop or start SQL Agent from your client SSMS also because I believe you are accessing it via SQL Authentication, which is not ideal or secure. But if you do not see the agent on the bottom left of SSMS it is because you do not have rights. If you see the Agent and it is red then the service is disabled and must be started.
You will need to get direct access to the SQL box (and you do not need local admin to manage SQL Server, just a domain account with some service rights and drive rights). If your system administrators are running SQL Server under Local Admin, then they should not be managing SQL Server in the first place (see my write up hyperlinked below).
The SSRS Team at Microsoft has merged into the SharePoint team, and SharePoint 2013 wraps up all of the BI tools right into it, so that is something you should also consider if you plan on building out a BI shop at your firm, i.e. you may not have to if you already have SharePoint installed.
Good luck, don't get discouraged.
What user account would you recommend running the SQL Server Express 2008 services in a development environment?
I have an old Access project (.adp) that was tied to a SQL Server database using integrated authentication. The .adp is only used this time of year. Since its last use, the SQL Server has been virtualized and patched to current. When I try to open the .adp, it gives me a "Cannot generate SSPI context" error. I got this with another .mdb and just remapped the linked tables through ODBC with a SQL Server login (integrated authentication is not a requirement). However, with this .adp file, just about all the options are greyed out. For example, Linked Table Manager and ODBC Database buttons are greyed out. I can't see any tables, nor apparently link or import any. Is there a way to remove integrated authentication from an .adp project? Or can I convert the database to an .mdb (exporting objects appears greyed out as well)?
NOTE: This is a limited use database with few users on its way out, so I'm very open to "creative" workarounds that don't require me rebuilding the whole thing.
Please, review the following:
Check that SQL Server allow integrated authentication
Your machine (where you open the adp project) and the server are both in the same
domain.
That error is typical when the client machine belongs to another domain or not belongs to any domain.
We have an application, consisting of an MS Access frontend (2007, mdb format), a few .net libraries and an SQL Server (2008) backend. I am working on an installer, which automatically installs the MS Access Runtime, our application, our libraries, SQL Server Express and configures everything.
Clearly, the MS Access application and the libraries (running in a normal, non-admin user context) need access to the SQL Server database. What is the best way to grant access to the application?
This is what I came up with. Unfortunately, all of these seem to have drawbacks:
SQL Server Compact Edition: Does not support views.
Application Roles: This seems to be best practice. However, it requires executing a stored procedure before accessing the database (I cannot pass the app credentials in the connection string). Thus, I cannot use this to attach the SQL Server tables as a linked tables in the Access MDB, which is a requirement of our Access application.
SQL Server User Instance: To quote from MSDN: "This feature will be removed in a future version of Microsoft SQL Server. Avoid using this feature in new development work..."
SQL Authentication: Microsoft says: "When possible, use Windows Authentication."
Using Windows authentication and granting BUILTIN\USERS full access: This is by far the easiest solution, but somehow it "seems wrong" to do that...
The application is targeted at a non-technical audience, so asking the user to configure permissions is not an option.
EDIT: Some clarification: It's a "local" application, i.e., the SQL Server is located on the same machine as the application; SQL Server access from the network is neither necessary nor desired. The software (a regular business application for managing stocks, invoices, etc.) will be available to download for free, so it should run in a variety of environments (domain/non-domain, different operating systems, etc.), and IT knowledge should not be required to install it -- apart from the usual "click on setup.exe, confirm UAC prompt, acknowledge the installation directory, etc.". I expect the most common scenarios to be "Windows XP, local admin user" and "Windows Vista/7, local admin user with UAC enabled". Since we want to follow good practices, running the application should not require "Run as Administrator" in the latter case.
#Heinzi write:
Using Windows authentication and
granting BUILTIN\USERS full access:
This is by far the easiest solution,
but somehow it "seems wrong" to do
that...
The usual approach here is to add a custom user group (e.g., "db-users") and put the users in that group. That way you can control exactly who is allowed access.
How about:
Use an Access ADP project, pre-configured to connect to the locally installed SQL Server instance.
Connect using BuiltIn\Users group (or SQL authentication) but grant only the bare minimum credentials. Enough to logon and ...
Call sp_setappprole to "elevate" the client connection to your defined application role's identity.
If sound like you have only got the tie of the iceberg. When it comes to selling and deploying access SQL applications.
I have take a different route. I have virtual computers as standalone workstation and domain server and workstation all virtual.
I have write a scripts they are a combination of VBA and VBScript.
Ask
Is the DB and App to run on single computer or different computers.
If different computer what is the name of the computer the DB is located on.
Is the DB and App to in a workgroup, homegroup or domain environment
Is the DB computer already have SQL Express or above
Is the App computer already have Access or Access Runtime installed.
If yes which version.
Will all or only limited users have access.
If limited what is the user group name of user to be have access to the data.
Does this group already exist
If No List the Name of the Users that Should Be Added to the Group
Also questions about the Admin Users and Group
The script start the virtual machines and goes through a series of steps to rep the MDB and SQL DB for deployment. Then creates an MSI for the Server Install with include a custom script that sets up the environment. Finally packages MDB in a nice MSI.
I have since enhanced the process to allow some questions to be answered at the beginning of the server installation. This means the user groups and users can be selected from the lists in the workstation or domain depending on prior questions asked.
If user the app user is a member of the Admin Group of the Workstation or Domain. They get extra menu options. That allow them to add or remove members from the DB user group for the workstation or domain. This I find is helpful.
I am now moving to the next stage and looking at hosting my assess app as an SasS (Software as a Service) (Rental). So the app can be use in any HTML5 Browser, Windows or Mac as Virtual Desktop or Android and Apple device. Having said that Access is a bit ugly on mobile devices.
When I am up and running I will make the platform available to others.