I have a very strange and very frustating problem:
I'm trying to connect to an remote SQL Server Database, and i gotta some errors, like:
I've tried to connect to an specific remote SQL that has only one instance (SQL Server 2008). When i use the correct connection string, with server address and instance name, o get the following error:
But when i remove the instance name, it works:
Calling with customer's service from this server, they said that this server has only one SQL, so it allows you to connect without instance.
But my real problem is that i'm trying to connect to another server that has more than only one instances of SQL, so i'm getting the same old error:
And if i remove the instance, i get login error, cos my user and passwd was not found at default sql server.
I have tried several changes:
I've changed my Management Studio from 2017 to 2014.
I've formatted my computer last night, trying to solve this problem,
but i still got the same errors
I've asked to some friends to connect to this same server, exacly
the same way that i'm trying, and they sucessfully connected.
I really dont know what I'm doing wrong. Somebody knows how to help?
Thank you.
I created an Access front end for a SQL DB on my PC for use throughout my company. I am using a file ODBC connection and putting both the ODBC file and the Access file on a shared network drive.
When I load the access file, for some reason it seems to default to using my windows login credentials and pulls in the data perfectly. When a user attempts to open the file, they receive an error message saying "ODBC --call failed.". I can open the Linked Table Manager for them and check 'ask for new location' then specify the ODBC file and it all works fine...however it doesn't seem to save anything. I get the error each time someone other then myself opens this file.
Any idea what could be wrong? I am not an Access guy by trade, it just seems to be the tool we need for the moment.
--EDIT: For Clarification I am using a file ODBC connection
--Edit 2--
Riddle me this. So I have been troubleshooting this issue and I came across something interesting. I was logged in as one of my users and did the following:
Create a new access file that references a file ODBC connection on the desktop.
Create 3-4 linked tables in the access file, using the ODBC file on the desktop.
Save and close the access file.
Re-Open said file.... and I get an ODBC connection error! Right after everything was fine in a fresh file!
Anyone ever experience this?
i assume you didn't install the ODBC correctly on each users PC.
you should create the ODBC-definition. You can create the relevant statements directly in the registry, see this branch
HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI
if you give the same name as on your developer machine, then it works. that's how i do it with my client applications that i develop on my machine and then install it at client site
After beating my head against the wall having this same issue, I finally discovered I had a checkbox on the Access form that defaulted to NULL. Since I put the backend into SQL, the checkbox fields cannot be NULL but the 'ODBC Call Failed' message did not help. I finally tried to add a record directly on the table via Access and it gave more information. I set all the checkboxes to default to zero and it resolved the problem!
Well, I was able to narrow the issue a bit. Access for some reason keeps trying to use Windows Credentials instead of the username in my ODBC file. I can't find a way around it, but I was able to resolve the issue by creating logins on my SQL Server for the windows users that need access.
I am not incredibly happy about needing to manage more logins, but that's what i did to resolve this issue.
I don't mean to resurrect the dead, but I had this same error stem from a different issue.
I was using an ODBC connection. When running the file using the 'Design' run button it worked fine. When I tried using the Navigation Pane and double clicking on it, the error would happen.
The structure of my query was the problem; I was porting a SQL server query over and the single quote ' parameter passing was not well received in Access. Changing these over to double quotes " made it work.
When I click on the "Databases" node in "Object Explorer" it just keeps on "Loading items" until at some point it just hangs.
This happens only when connecting to a remote server, not when accessing a database on my PC.
It also doesn't happen with any other node.
The guys at the web-hosting company didn't have any trouble with it. (But they're running 2008, and so is the SQL server there)
I reinstalled the whole SQL server etc. but to no avail.
What might be the problem?
I experienced this same problem: when accessing a remote server with the Object Explorer, SSMS would hang indefinitely. The Windows System Event Log would show DCOM error 10009 ("DCOM was unable to communicate with the computer MACHINE_NAME using any of the configured protocols.").
The solution was to clear the MRU history and other settings from my profile. To do that:
Close any open instances of SSMS 2012
In Explorer, open "%AppData%\Microsoft\SQL Server Management Studio"
Rename the "11.0" folder to something else, like "11.0.old"
Open SSMS 2012
You'll see that your MRU list has been cleared. You should then be able to re-enter your credentials and use SSMS as normal.
If everything works, you can delete the renamed folder. Otherwise, delete the new "11.0" folder that was created and rename the original one back to "11.0".
I have no idea whether it's actually the MRU list that's causing this problem or if it's some other profile data.
We were able to discover that SSMS is trying to make a DCOM connection over port 135 to the SQL Server (perhaps for SSIS, T-SQL Debugging, or something else). Our firewall was configured to block port 135. By opening the port in the firewall we were able to use SSMS (hence the reason it worked against local databases but not remote ones). Unfortunately, an open port 135 is an invitation for a lot of attacks, so that wasn't a practical solution for us.
Turn Auto-Close off on all the databases. Worked like a charm to me!
Every time you expand or refresh the database list, server has to awake the databases causing the hang.
Just run this to find all the databases that have auto-close on
SELECT name, is_auto_close_on
FROM master.sys.databases AS dtb
WHERE is_auto_close_on = 1
ORDER BY name
Credits to http://social.msdn.microsoft.com/Forums/sqlserver/en-US/99bbcb47-d4b5-4ec0-9e91-b1a23a655844/ssms-2012-extremely-slow-expanding-databases?forum=sqltools
To turn-off this setting for a database - Right click on database instance in object explorer -> Click properties -> Click "Options" in left navigation pane in database properties window -> Change the value of Auto Close property to "False" in right pane as shown in the snapshot below:
Assuming you have access to only one database at the hosting company (which is almost always the case, at least with a certain username/password), you can avoid the need to use the dropdown at all by setting your registered server to default to the database you're supposed to access:
(It may take longer here, too, but this will be one-time. You can also type it instead of waiting for the list to populate.)
This way, even if the login the host created for you routes you to tempdb or something by default, Management Studio will still put you in the context of your database.
I see now that you are talking about the Object Explorer node, not the "Use database" dropdown that I somehow interpreted incorrectly. An exercise to try might be to highlight the databases node (don't expand it) and click on F7 (Object Explorer Details). If this loads for you then it can be an alternative to navigate through the hierarchy and, as a bonus, you can show lots of entity attributes here and also multi-select, two things you have no control over in Object Explorer.
If that doesn't help, then your host should be helping you better than they appear to be. If SSMS 2012 is supported then they should be able to test this in SSMS 2012 and confirm or deny that they can reproduce it. If it is not supported then I think your recourse is to install SSMS 2008 as well (they can co-exist) and use it for managing this specific server.
Of course, just about anything that you can do in Object Explorer (and plenty of things you can't), you can do by using the catalog views and/or DMVs. So before you determine what to do, you may want to review (or share with us) exactly what you are using Object Explorer for - if there is a way to do it without Object Explorer, you might like the workaround better than having two versions of the tool (since the improvements in 2012 SSMS have absolutely nothing to do with Object Explorer).
In my case deleting the profile folder worked exactly once. The next time I opened SSMS 2012 it would freeze again when connecting to a server. SP1 didn't fix this either.
That was until I found the following simple workaround described on a ticket by Ben Amada over at connect.microsoft.com: Always close the Object Explorer Details before closing SSMS 2012.
So the complete workaround for me is this:
Follow Jaecen's answer, but close SSMS 2012 again after it created a clean profile folder
Apply Hoodlum's recommendation and copy SqlStudio.bin from the old profile folder to the new one (the old profile folder can be deleted afterwards)
Everytime before closing SSMS 2012 make sure the Object Explorer Details window is closed
The first two steps are required only once, or if the Object Explorer Details window was left open accidentally.
Edit
I just noticed that closing the Object Explorer Details window is also required when (re-)connecting to an SQL server in the same SSMS session. So basically whenever connecting to a server the Object Explorer Details windows has to be closed.
I spent over a month with Microsoft SQL Support troubleshooting this. It has been submitted as a bug.
I have both SQL 2012 SSMS and VS 2012 installed on Win 7 (64).
Deleting the profile folder never worked for any reasonable length of time.
The workaround we found was to ensure that my SSMS profile defaulted to the Master database when connecting. It appeared to have something to do with the fact that I'm connecting with Windows Authentication and I belong to more than one AD group that have SQL permissions assigned AND I don't have SQL specific permissions set up on my AD account.
I am connecting to several remote servers rangig from 2000 to 2012.
SMSS on local PC is SQL Server 2012,SMSS is 11.0.2100.60
SSMS freezes several times a day.When this occurs, I go via RDP to the
local server / SMSS / Activity Monitor and kill the processes from my PC with Database Name = master, one at a time, until SMSS on my PC unfreezes.
This always works, however, a cure for the disease raher than the symptoms would be highly welcome.
Have some SQL Servers from 2000 to 2012,
access then through SMSS from my desktop.
Problem occurs with varying frequency, looks like this: when I collapse a server in object explorer, SMSS freezes.
looking in activity monitor on the server in question, i find a process in master db with host = my desktop executing the following query
SELECT dtb.name AS [Name] FROM master.dbo.sysdatabases AS dtb ORDER BY [Name] ASC SMSS
killing the process frees SMSS.
Here is what worked for me
Open SSMS
click on connect to object explorer button
in the connect to server dialog box expand options >>
click reset all
Done!
I've test approximately all above answers but my SSMS got stuck in expanding the database list. I found the problem finally. The problem was because of a database that I restored it but It did restore correctly at the end. Then When I expanded the database list it was sticking.
I run a the query
SELECT
dtb.name AS [Name]
,dtb.database_id AS [ID]
,CAST(has_dbaccess(dtb.name) AS bit) AS [IsAccessible] FROM master.sys.databases AS dtb
Then the result took too long and at the end timed out but When I filter the stuck database I got result.
SELECT
dtb.name AS [Name]
,dtb.database_id AS [ID]
,CAST(has_dbaccess(dtb.name) AS bit) AS [IsAccessible] FROM
master.sys.databases AS dtb
Where name <> 'StuckDB' ORDER BY [Name] ASC
At the end I decided to detach StuckDB to solve my problem.
I have now applied SQL 2012 Service Pack 1 (through Windows Update) and it seems to work fine now, though it does take a very long time to load.
"Open SSMS click on connect to object explorer button in the connect to server dialog box expand options >> click reset all" - it works
I solved this problem by changing my default database back to master.
Go to database properties at SSMS and change compatibility to 2012. Then check.
I am new to replication. I have two sql server 2008 servers running on windows 2008 R2. The servers are in two different locations and on two different domains. I have been able to use aliases to get both "Snapshot publication" and "Transactional Publication" working perfectly. But what I need is "Transactional publication with updatable subscriptions" so if a change is made on either server, the changes are replicated to the other server.
When I run through the New Publication, I get through every page to the very end with no problem but when I click the finish button I get an error. There are three actions and it fails on the first action called "Creating Publication 'xxxx'" The message I get is "SQL Server could not create publication 'xxxx'. an exception occurred while executing a Transact-SQL statement or batch. The distributor has not been installed correctly."
I have searched for an answer and cannot find it. I think this is a permission problem between the two servers but I have no idea how to solve it.
Any help would be appreciated.
In my experience the installation of different types of replication over the top of one that was previously implemented can cause issues.
If able I would suggest clearing all replication and starting from scratch with your new approach.
You have to run a variety of stored procedures to get it completely off the server. Using the GUI only doesn't do nearly as good a job of cleaning everything off.
This guide from Microsoft should get you started.
http://msdn.microsoft.com/en-us/library/ms152757.aspx
Lately there has been a problem running some of our reports in access. Last week(the beginning of the week) we tried to run a reports lets call it A and it kept giving us the log in prompt. Even when the correct user-name and password were entered the log in box would just keep reappearing until cancel was pressed.
I clicked the debug and checked the query. I then logged into the database it is pulling the data from with the same user-name and password and received no trouble. Around Wednesday A was working again, even though nothing was changed. This week A is working but another report B is doing the same thing..
Anyone have any idea what this could be? I'm thinking maybe someone else has the report open? Any help is appreciated.
EDIT: I have narrowed down the error to one linked table that is causing the login prompt. It seems it has the DSN setup but no database specified. So i just need to relink the table..Is there anyway to do this at the GUI level? Also should I leave this question up for future users or just delete it?
Was the login prompt from Access or from Windows? If from Windows, then I'd say that there was some sort of file permission or network access issue at hand. If from Access, then I would say that something in the SYSTEM.MDW that you are using is corrupt or has been reconfigured.
If the login prompt is from ODBC it probably means that the credentials that are being used to access the backend database (per your comments you mentioned it was SQL Server) are either invalid or disabled. (Or it could be as simple as the backend database is/was temporarily unavailable).
If you are using linked tables in Access to a SQL Server it means that an ODBC connection was created and you might try verifying that the ODBC connection is working ( Control Panel, Administrative Tools, Data Sources(ODBC) ). In that dialog there is a place to test the connection.