I've read up on how to do a cross-server query:
serverName.DBName.SchemaName.TableName
I do just this and I get an error telling me that the server is not found on sys.servers. I queried sys.servers but I just see my own server's name and nothing else.
--Am I missing something? The error message also gives me a stored procedure's name. But I am just not sure why this is not working, shouldn't it be working just fine?? I do have credentials/permissions on BOTH servers to read and write. So I don't think it's a permission thing.
Error message:
Could not find server 'targetServerName' in sys.servers. Verify that
the correct server name was specified. If necessary, execute the
stored procedure sp_addlinkedserver to add the server to sys.servers.
You need to create a link to the other servers. You can do this with the sp_addlinkedserver stored procedure or via the Sql Server Management Studio gui.
Related
I am trying to configure the distribution of SQL Server (2016). This is an Azure SQL VM. However, when doing so I get the following error:
TITLE: Configure Distribution Wizard
------------------------------
SQL Server is unable to connect to server 'COMPANY-SQL'.
SQL Server replication requires the actual server name to make a connection to the server. Specify the actual server name, ''. (Replication.Utilities)
(note it is not actually COMPANY-SQL but a similar naming format). I have tried, as suggested in many posts to sp_dropserver and sp_addserver. This successfully creates ##SERVERNAME set to company-sql-2 which is the name of both my Azure resource (not sure where COMPANY-SQL originates). I'm lost as to how to connect here despite already being connected to the database & why the error says the actual server name is simply ''.
SQL Server is unable to connect to server 'COMPANY-SQL'.
SQL Server replication requires the actual server name to make a connection to the server. Specify the actual server name, ''. (Replication.Utilities)
SERVERPROPERTY: The Windows server and instance name, which together make up the specific server instance, are provided by the ServerName attribute.
##SERVERNAME: The name of the local server as it is set up right now is provided by ##SERVERNAME.
Run the following commands together and you will get two different names.
SELECT SERVERPROPERTY(N'servername')
SELECT ##SERVERNAME
then change the server name by dropping the name got by ##SERVERNAME command with sp_dropserver procedure and set name got by SERVERPROPERTY command with sp_addserver procedure then Restart the SQL Server Service.
I have cloned our Microsoft SQL to a new server. The server contains a few databases and "SQL Server Agent" jobs that run on a scheduled basis. I have tried changing all existing references to this new server name and use accounts on this new server. However I am still getting the following error in my error log and my jobs fails to run (btw, this is through Microsoft SQL Management Studio),
[298] SQLServer Error: 15404, Could not obtain information about Windows NT group/user 'DOMAIN\user_account', error code 0x534. [SQLSTATE 42000] (ConnIsLoginSysAdmin)
I've got a couple of Maintenance Plans which are pointing to the old server. For some unknown reason I can't edit the existing connection and I can't delete it. I can add a new one but the other connection can not be removed.
I need to know where I need to change for this error to go away and the jobs start running.
This may be because SQL has the wrong server name in Master. Here is another article on the subject.
SQL Server Central Article
In order to fix this, run a search on Master with the following code:
use master
select SERVERPROPERTY('servername')
select ##SERVERNAME
select SERVERPROPERTY('machinename')
go
If you see the old server name in the list you will have to drop the server and add the new one
use master
exec sp_dropserver "OldServerNmae"
go
use master
exec sp_addserver "NewServerName","local"
go
Before dropping a database on an Azure Sql Server I have to check if another user is connected to that db.
Using the stored procedure sp_who2 fails with:
"Could not find stored procedure 'sp_who2'."
Trying to get informations from sys.sysprocesses also fails with message:
"Reference to database and/or server name in 'master.dbo.sysprocesses' is not supported in this version of SQL Server."
How do I get the info I need?
Quick googling found that this approach works quite well in SQL Azure. However it works only in the contexts of a concrete database! Remember that in SQL Azure you can only work with single DB at a time. If you need data from more than one DB you have execute the statement for each DB separately.
Side note, I could not get sp_who working in SQL Azure.
EDIT
The following is screenshot provided for evidence:
This wiki post outlines both a problem and a solution. I wanted to post this for others that may be having similar problems, as I couldn't find anything specifically to solve this problem elsewhere.
We recently upgraded our SQL Server 2000 database to SQL Server 2005. One of the databases on the server is a back-end to a MS Access database. The MS Access database uses pass-through queries, via DSN-less ODBC to connect to SQL Server.
An example of the DSN-less connection string is shown below:
ODBC; DRIVER=SQL Server;SERVER=servername;APP=Microsoft® Access (Pass Through
Query);DATABASE=databasename;Network=DBMSSOCN;ConnectionTimeout=20;
Trusted_Connection=Yes
After the upgrade, we found that users were unable to run the pass-through queries, and were getting the following error displayed :
ODBC -- connection to 'SQL Server
' failed
This initially appeared to be a permission issue, as elevating the priveledges of the SQL server logins to sysadmin server role alleviated the problem (but obviously this isn't a great solution).
After taking the logins back out of the sysadmin role we found that when connecting to SQL Server via Management Studio, the login could execute the stored procedures. The very same login could not from within MS Access. This pointed to something MS Access was doing while trying to execute the stored procedures - rather than a permission issue.
We ran a trace on the server using Profiler, and this showed up MS Access trying to execute the following command prior to stored proc execution:
DBCC TRACEON(208)
It appeared to fail at this command, prior to stored procedure execution. Research on the web showed that DBCC TRACEON(208) is equivalent to using 'SET QUOTED IDENTIFIERS ON' command, and that in SQL 2005 priveledges to run this DBCC command had been revoked.
After further research, we found references to MS Query having a similar problem, and that the APP component of the connection string should be changed from 'MS Query' to something else.
On a hunch, we changed our APP component of the ODBC connection string, and MS Access no longer tried executing DBCC TRACEON(208) prior to stored procedure execution.
After further testing, we tracked the problem down to the 'copyright' symbol included in the APP component :
APP=Microsoft® Access (Pass Through Query)
By removing the copyright symbol, all was well with the connection and the application worked as it had previously done on SQL 2000.
Hope this helps out anyone else having a similar problem.
Isn't that the registered trademark symbol?
I believe you hit on one of sql server 2005's defences against odbc based attacks. Since there isn't anything on the internet about it, it is likely something MS handled internally.
We are using a SQL Native Client to connect to a local SQL Server 2005 from a Borland application. It will fine for selects, inserts, and updates. When we delete we get the error:
Could not find server
SERVERNAME\SQLEXPRESS in
sys.servers. Verify that the correct
server name was specified. If
necessary, execute the stored
procedure sp_addlinkedserver to add
the server to sys.servers
The default instance, the only instance, is SERVERNAME\SQLEXPRESS, and we are not using linked servers. Any ideas? I believe we moved the MDF and LDF files to a new server for this DB, and then reattached it.
Update 1
There is no SQL. This is all happening through programmatic interaction with cursors. It is an ODBC driver using ADO. You run TableObj->Delete to remove the record.
Got it. I ran
SELECT ##servername
That returned the old host name of the box. I than ran
sp_dropserver 'OLDHOSTNAME\SQLEXPRESS'
go
sp_addserver 'NEWHOSTNAME\SQLEXPRESS', local
I then got
Server 'NEWHOSTNAME\SQLEXPRESS' is not
configured for DATA ACCESS
I ran
sp_serveroption 'ICS-POS3-NEW\SQLEXPRESS', 'data access' , 'true'
This got me the error
Transaction context in use by another
session
Which is because of linked servers. I found that the local option on the add server did not take affect until I restarted the server. I restarted, then it just worked.