Invalid object name sysservers - sql-server

I'm using SQL Server 2008 R2. This is my query:
SELECT * FROM sysservers
It works fine when I execute it in SQL Server but when I use the query in VB.net this error comes out:
Invalid object name 'syservers'

You shouldn't be using sysservers anymore - this is a 2000 system table that is only still provided for backward compatibility reasons. You should be using sys.servers and you might want to be explicit about where to find it as well:
SELECT * FROM master.sys.servers;

Related

Using SQL Server view in Microsoft Query

I have a view in SQL Server named item_movement, now I want to query using Microsoft Query in Excel:
select * from item_movement
But I'm getting this error - why? Is it possible to use Microsoft Query for querying views?
Found out the issue had to use the keyword
use mydbname before query

How do I test whether a given SQL Syntax is valid for an older version of SQL Server

I regularly end up developing on projects where either the Central Test server, or Prod server is an older version of SQL Server than my local install.
e.g. Prod is SQL Server 2014. Local install in SQL Server 2019.
Mostly that's fine, it just means I have to remember to only use old syntaxes. (:cry:)
But occasionally I forget which syntaxes are old. Ooops.
Obviously our test environments catch this, but it would be great to be able to tell my Local Server ... "only accept SS2014 syntax", and have these mistakes caught before they're committed/pushed.
I thought this was what CompatibilityLevel was supposed to do. But either it doesn't, or I'm using it wrong. (See below)
How should I achieve this? (other than just installing a different SQL version!)
Attempt so far:
Run ALTER DATABASE MyLocalProjectDB SET COMPATIBILITY_LEVEL = 120; (120 represents SS2014)
Run SELECT name, compatibility_level FROM sys.databases WHERE name = db_name(); to confirm that the previous command "worked".
Run DROP TABLE IF EXISTS [ATableThatDoesExist], to see if the syntax is accepted. It was.
DROP IF EXISTS was new to SS2016:
MSDN: IF EXISTS ... Applies to: SQL Server ( SQL Server 2016 (13.x) through current version).
Additional Source
Why hasn't this worked?

SUSER_SID support for Azure SQL

SUSER_SID has two optional parameters. I am using only first 'login'. Documentation for it applies to Azure SQL Database, but it doesn't work. For 'login' parameter is says "Applies to: SQL Server 2008 and later".
When I call SELECT SUSER_SID('test');
using SSMS, I get the error:
'SUSER_SID' cannot be invoked with parameters in this version of SQL Server.
I am using Azure SQL Server ver. 12.0.2000.8
How is that possible, what am I missing?
Odd, this isn't actually documented but I get the same problem. (Will raise this on the document's GitHub).
If you want the sid you could use sys.database_principals instead:
SELECT dp.sid
FROM sys.database_principals dp
WHERE dp.name = N'test';
for this question I asked Azure Support. They told me that:
Based on the online document, the parameter “login” applies to SQL Server 2008 and later version, and the parameter2 applies to SQL Server 2012 and later version. That is the reason why we will get the error message “'SUSER_SID' cannot be invoked with parameters in this version of SQL Server.” while running the command SELECT SUSER_SID('serveradmin') , because Azure SQL database does not support SUSER_SID() with parameters.
If you want to check the SID, please consider running the command in below instead:
select name, sid from sys.sql_logins where name = 'test'
Here's the screenshots:
Hope this helps.

SQL Server returns incorrect XML value for parent node after installation of CU14

We recently updated SQL Server from:
Microsoft SQL Server 2017 (RTM-CU9-GDR) (KB4293805) - 14.0.3035.2 (X64)
to:
Microsoft SQL Server 2017 (RTM-CU14-GDR) (KB4494352) - 14.0.3103.1 (X64)
In one of the extraction jobs we are using SQL like:
SELECT
XMLNode_Root.R.value('./#ID', 'INTEGER') AS [SellerID],
CAST(XMLNode_Root.R.value('../#ID', 'VARCHAR(25)') AS BIGINT) AS [ApplicationID]
FROM Stage.LoanAppl_XML AS AD
CROSS APPLY AD.ApplicationXMLPackage.nodes('//MessageResponse/body/Application/Seller') AS XMLNode_Root(R)
OPTION(USE HINT('ENABLE_PARALLEL_PLAN_PREFERENCE'));
Recently, on random occasions this select started to return NULL values for ApplicationID column even the ID is defined in the parent.
What is interesting:
1. If I do any change to SQL Select, like change case or add spaces it returns correct values.
2. Running dbcc freeproccache solves the problem for some time.
I have execution plan saved before and after clearing cache, but can't post it now.
I wonder if anybody had similar issue and was able to find a solution.

OBJECT_ID() fails to get object id in SQL Server 2014

print2
I've tried every possible way to get the ID of the object through OBJECT_ID() but it seems like i can only find the object searching it manually in 'sys.objects'. In SQL 2008 it works just fine, same code. I'm using SQL Server 2017 in the picture.
Does anyone know if this is a problem with SQL Server 2014? Am I missing something?
object_id('tempdb..#some_name') will only return a NOT NULL result if the temp table was created in the same session.
It looks as though it was created by a different connection.
For your use case (commented out) you can just do
DROP TABLE IF EXISTS #some_name
Anyway if you are on SQL Server 2017 as stated.
But the screenshot shows 12.0.2000 which is SQL Server 2014 so that won't work on that version.

Resources