I'm trying to use a localDB as a local development database, but not matter what I do, I always get the exception Login failed for user 'DOMAIN\user'.
Example: right-click on data connections in the server explorer pane in vs2012. Select add connection, select Microsoft SQL Server Database File under data source and click continue. Browse to the location you want to save the database file, use windows authentication, click okay, see error.
I've tried removing all sql components from my machine and installing a fresh instance of SQL Server Express LocalDB several times to no avail.
How do I figure out which data user the database is expecting? How can I install it so that my current user can use it?
Any Help will be much appreciated.
Related
Attempting to view the a view or procedure:
from SQL Server Management Studio 17.4 in Azure SQL Datawarehouse notes the error:
I can however, delete and create any object that I want.
How can I work to ensure I can view the objects definition?
UPDATED
Concerning setting the options in SSMS to SQL Datawarehouse, there is not that option:
Please change this setting under Tools... Options. That should resolve the error. I wish we didn't have to change this but at lease we have a workaround.
In SSMS 17.5 there are a few more options. You can have it automatically detect what type of database you're connected to and script accordingly. Or you can force it to script for a particular database type like the following screenshot.
It appears there is a bug in certain versions of SSMS (such as 17.5) where if the DW user isn't also a user in the master database then scripting fails. The easy fix for this is having the server admin connect to the master database and run:
CREATE USER MyUserNameHere FROM LOGIN MyUserNameHere;
Sorry you're seeing this. I've been able to repro this on SSMS 17.4 and 17.5. We are looking at this now.
This seems to be a defect in the upgrade path for 17.5 as this should be supported without having to change the script settings. We are investigating this and will try to get an update out as soon as possible.
I'm trying to get into Sage 50 (v20 2014) via ODBC in Excel 2016 64bit. I keep running into connection problems.
I've set up a 64bit DSN using the utility on the Sage disk and I get the following...
If I go through 'Data/From other sources/From Microsoft Query' I get the usual 'Choose data source' box and the Sage DSN is visible. If I click it and click ok MS Query launches and then crashes immediately and I get 'Microsoft Query has stopped working'.
Interestingly, if I go back to the 'Choose Data Source' box, I get the error 'One or more of the folders in the search path could not be accessed'.
The default path set in the DSN is to 'C:\ProgramData\Sage\Accounts\2014\Company.000\ACCDATA' - the actual Sage database that I'm trying to access is in a network folder - 'V:\SHARED\Sage\COMPANY.002\ACCDATA'. I've tried both paths in the DSN and get the same results.
If I go through 'Data/New Query/From Other Sources/From ODBC' and then choose the Sage DSN, I get a full list of the tables but when I click on one of them to generate a preview, I get the following error...
DataSource.Error:ODBC:ERROR[42S02] Table not found
Details:
DataSourceKind=Odbc
DataSourcePath=dsn=SageLine50v20
OdbcErrors=Table
Also, if I use 'From data Connection Wizard', Excel crashes as soon as I choose the Sage DSN.
I'm not using any kind of connection string so I don't think it's authenticating with a user - I'm wondering if that would make a difference and if so, what would the connection string be?
I've been through everything that comes up if I google the problem and I've set up logins correctly etc but it will not connect. I don't know if this might be a 32/64bit comparability issue, but I'm using the 64bit Sage driver from the disk so I assumed that it wouldn't be a problem.
I've also tried connecting with MS PowerBI but I get the same problems.
Sage 50 is temperamental in how it allow connections to their database, what I mean: When it don't change the port, it just reject connections in awkward ways or not connect at all.
I didn't find a solution. However I found this workaround: Open sage, login and close it then connect using the DSN sage created with the sysadmin account(It grants you full access).
When defining the data path, it is critical to include a final backslash e.g
C:\ProgramData\Sage\Accounts\2018\COMPANY.001\ACCDATA\
When I select from the Ribbon Get External Data -> From SQL Server I get the following Assertion Failed dialog from EXCEL:
I have tried this with an Admin account, and after logging off and on, with the same results. If I select -> From Analysis Services I don't get the dialog.
f I choose Ignore I get a dialog to specify connection details but it always fails, reporting an inability to locate the server, even though in SSMS and through TFS I can connect to the server without issues. The DB server is my local machine, though a Named Instance.
(Yes, I have very carefully checked that the server name is correctly specified.)
Has anyone seen this before and can assist in diagnosing the issue?
Update:
The error dialog occurs immediately on clicking on From SQL Server.
If I opt to Retry from the dialog, I get the standard Microsoft Excel has stopped working, would you like to check online for a solution etc. dialog. If I attempt to debug the code I am informed that Source is not available, although symbols appear to be successfully downloaded form the Microsoft Symbol Server.
I am currently having serious issues connecting to a FoxPro database using an ODBC connection from IIS7.5
The database is on another machine than the IIS server and is accessed via a fileshare.
When I call the webpage from IE on the IIS server everything works fine. When I call the webpage from another machine I get a '[Microsoft][ODBC Visual FoxPro Driver]Cannot open file' error.
The application pool runs as a domain user.
When I run ProcMon on the IIS Server and call the page, when it is called from the IIS Server it accesses the offending file and then a whole bunch of other FoxPro files for that database.
When I run the page from another machine, I get an ACCESS DENIED error when it tries to access the first file.
It is a CreateFile call for a file called Comp_W.DBC that fails.
I checked and it is the same user that is invoking these calls to the fileshare so it is not differing credentials that is causing the problem. I even went as far as making the app pool account a domain admin to see if that might sort out the issue but still the same problem.
I cannot move the database onto the same server as IIS. I have tried to run the web application on the same server as the FoxPro database but I hit different issues to do with the fact that OWA runs on that server, and the 32bit ODBC driver causes conflict with an OWA dll that is loaded as a global module. I really need it to run IIS on a separate server from the FoxPro database.
The server(s) do not seem to be running kerberos as the delegation tab is not present when you administer users.
Any help would be greatly appreciated.
James :-)
I'd use the Visual FoxPro OLE DB driver instead of ODBC, because it's newer, faster and won't conflict with OWA. That would let you move it onto the IIS server.
Past experience suggests that you haven't given the IIS user permission to access the folder where the DBFs live. When you run IE on the local machine, you're passing the credentials right through -- when you run it on another machine, I believe the anonymous user rules come into play. (Been a while since I had to debug this one, take it with a grain of salt.)
I cannot attach a new Service based database(.mdf) to a C# project that I started. It shows:
Connections to SQL Server Database file(.mdf) require sql server 2008 express to be installed and running on a local computer.The current version of the SQL express can be downloaded.
But I already have SQl Server 2008 R2 installed.I've learned that a .mdf file cannot be "just" attached if the SQl server is a full version, then do I have to create a new database to accomplish the task?Or is there anything else that I can do?
As it's mentioned by Mostafa you should go to Tools->Options->Database Tools->Data Connections->SQL Server Instance Name and blank the SQLEXPRESS in that field. actually there is no need for instance name just blank it.
Use the VS 2010 menu Tools/Connect to database and, in the dialog that opens, fill the field "Attach a database file". AFAIK it's a known problem of VS 2010.
The visual studio has a default sql server instance name to connect to. The installer sets it up to point to the SQL Server Express by default. You have to change the Tools->Options->Database Tools->Data Connections->SQL Server Instance Name to point to your installed SQL Server instance name.