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.
Related
I have two databases on the same SQL server. One for an ERP database that I am able to read tables and one I created in MS Access. A store procedure on the MSAccess database is updating some tables from the ERP DB. The MS Access DB from here on is independently running.
When I installed on other computers, the Access Database is giving me a connection error when I am logged in as another user than myself.
- Are permissions from the ERP database affecting me in my Access Database? Should I worry about them?
- Is Windows Authentication enough to make the connection happen?
- Do I need to Map the users over from the ERP database?? if so, how do I do it?
- Can I grant every user on the Server permission to access my tables using Windows Authentication? do I need to go down this road? How do I do it?
I am just not too sure what to do from here on. Here is some more information about the issue.
-In my database I have a ODBC stringconnection that looks like this:
Driver={SQL Server Native Client 11.0};Server=SERVER;Database=DATABASENAME;Trusted_Connection=yes;
-I am packaging an exe file using SSESETUP which is awesome.
-I am installing on the new computer and able to launch when I am logged on as myself however, I am getting a connection error when I am logged in as another user on the same computer. (Note: I am not able to debug from here on and see the vba because I am running under Access runtime 2013 only.)
I would appreciate if someone can assist me in narrowing my search for a solution.
Bottom line, it sounds like you need to set up database permissions on your SQL Server for each Windows account that will be using your Access db.
Here are specific answers to your questions:
Are permissions from the ERP database affecting me in my Access
Database
Yes, of course they are. Regardless of how you connect to the database the permissions will always be in effect.
Should I worry about them?
Yes, of course you should. Otherwise you won't be able to work with the data.
Is Windows Authentication enough to make the connection happen?
To make the connection, yes. SQL Server supports Windows authentication in both security modes (Windows only and mixed mode). But, this is just the connection. You also need to take the database permissions into consideration. Your Windows login needs to be granted the appropriate permissions within the specific database in order to do anything.
Do I need to Map the users over from the ERP database?
Map to what? Access? Based on the connection string in your question you're using Windows authentication to connect Access to SQL Server, so Access will connect to SQL Server under the security context of whoever is running Access. So the SQL Server permissions will need to be configured for each user who will be running your Access db.
Can I grant every user on the Server permission to access my tables
using Windows Authentication?
Access to the SQL Server tables? Sure, you could. But you should limit it to only the necessary permissions. Granting access for everyone is likely overkill and not best practice.
I have an old ASP Classic site which connects to a SQL Server database which uses a Linked Server to access a Microsoft Access database via OPENQUERY in a view (!), like this:
A Linked Server is configured to connect to the Access database using Microsoft.ACE.OLEDB.12.0
A view view_requests retrieves the data from a table in the Access database:
SELECT *
FROM OPENQUERY(MY_LINKED_SERVER, 'SELECT * from Requests') AS Rowset_1
The ASP Classic page retrieves the data:
Set getRequests = dbConnect.Execute("SELECT * FROM view_requests")
Since moving it from a Server 2003 to a Server 2012 machine it no longer works.
The error given on the ASP page is:
OLE DB provider "Microsoft.ACE.OLEDB.12.0" for linked server "MY_LINKED_SERVER" returned message "Cannot start your application. The workgroup information file is missing or opened exclusively by another user.
But I have a feeling this is misleading for several reasons. The error seems to occur in lots of different scenarios and none of the posts I've found represent mine exactly. The main thing to note is that the view works fine and I can therefore access the data via SQL Server, which to me suggest it's not an issue with user mappings and so on, but I may be wrong. The problem occurs when connecting via the ASP Classic page. We've tried using both .mdb and .accdb formats.
Any suggestions on what I can try would be much appreciated. Thanks!
This sounds like it might be a permissions problem (I was going to say 'access' but that came out confusing!).
How are you controlling access to the SQL database? Is it Windows Authentication or using a SQL logon? If it's Windows Auth, then you need to give either the calling user's (if using Impersonation on the web site) or the Windows Identity that ASP.NET is running under access to the Access database file. If using a SQL Logon then you need to give the Windows Identity that SQL Server is running under that access.
The error is not necessarily accurate and from my experience, it probably is not. The account that SQL Server is running under (NOT the SQL Login) must have full permission on the folder where the Access file is located. Another possibility is that the linked server is not using the correct ACE driver, or it is not installed. If using SQL Server 64 bit, you'll need the 64 bit ACE driver.
It seems the issue was that we were incorrectly mapping the SQL user to the remote server (Linked Server > Properties > Security), even though it seemed we'd tried every possible combination of settings under the sun! So it seems the original misleading error was trying to tell us that the user didn't have the permission.
It is currently working with the Local Login mapped to Admin, the default Access database user which has a blank password. Under For a login no defined in the list above, connections will: we have selected Be made using the login's current security context.
Thanks to AVG for pointing me in the right direction.
I have an analysis services cube in SQL server 2005 which I'm connecting to via an excel front end.
When I connect via one user its fine, but when I log on to the same machine as another user I get an error in my excel spreadhseet - "user...does not have access to the [Cube name] database"
Obviously the first user has the correct permissions, but how do I set up analysis services to allow other users to join the party?
Login to the machine with an account that is an administrator (Domain\CubeAdmin) on the cube. Connect to the cube in BIDS (run devenv.exe and open Analysis Services Database).
Under Roles, create a reader role and in the Membership tab, add the user account (Domain\NewUser).
All this will only work if the SSAS Server Administrator gives the Domain\NewUser access to the server.
The Windows user accounts that you are trying to access SQL Analysis Services with need to be added to the Roles in the Cube that would allow the permissions you want.
If you are connecting over HTTP using msmdpump.dll through IIS you need to turn on Authentication for that site and allow the Windows user account to access the site.
If the IIS site using msmdpump is on another machine and you aren't using a domain then the accounts would need to exist on both servers with the same password.
I know this is old but for other's reference, I had to repair the MS Office install to resolve a connectivity issue with SSAS. The user was added to the role, but the error "Cannot connect to server" was displayed when connecting.
Raj has already answered the initial question... You need users to be set up with at least read access to your SSAS instance.
However, the error "Cannot connect to server" does not necessarily mean it's an authentication issue, it actually doesn't mean much. I've seen this error on Excel 2007 on various occasions, where the underlying error could be anything, this is just a generic error from Excel.
Several aspects that caused problems on my end were (things to check):
User has access to the web site (if not using anonymous auth)
ADOMD and OLEDB for Analysis Services are installed locally (correct version)
User propagated to SSAS has read access to instance (are you using ApplicationPoolIdentity?)
Handler mapping (script mapping for *.dll) is set up
For a complete guide of how to set up HTTP access for SSAS check:
Microsoft - Configure HTTP Access to SSAS via IIS
Cheers
I have an Sql Server database that includes a linked server to an MS Access mdb database. The Access database has workgroup security and requires a valid user name and password. This is easily set up in the linked server dialog in sql management studio. The problem is that the Sql Server needs to be able to find the MS Access mdw file to be able to login.
The only way I have managed to get this to work is by setting the Registry value SystemDB of the registry key :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines
to the path of the workgroup file but this causes other problems (like with other MS Access apps or Excel).
Is there a better way of doing this?
I haven't done this for a while, nor in recent versions of SQL server, but I seem to remember that when you add a link to a Jet database it provides the opportunity to define the workgroup, username and password. Certainly if you're using ODBC, that's part of the basic ODBC driver for Jet.
We are troubleshooting a SQL Server 2005 connection issue on a closed-source third-party ASP.NET application. The application is a .NET application and the developing company is using a custom formatted configuration file that stores the SQL Server authentication information.
The application when trying to connect to our SQL Server box is getting a "Cannot open database 'databasename'. Login failed for user 'username'" error. We have tested connecting to the SQL Server box from the web server using SQL Server Management Studio and the login information provided to their app, it works perfectly.
Is there any easy way that we can sniff/determine the SQL Server Connection information they are trying to use inside their SqlCommand? Debugging their code is not an option, as it is compiled in Release Mode, and we don't have source. We simply need something to be able to identify why their app cannot connect.
run profiler and choose Security Audit: Audit Login, Audit Login Failed and Audit Logout events. choose all columns.
from that you'll get the app name, and the user that tries to log in from the login failed event.
once you get that check which database is default for that user in SQL Server users.
I just asked some of the guys here and they both recommended trying reflector. If you had some hard coded values in the library, you should be able to see something there.