Whether in a script window or in a stored procedure, is there any way to get SQL Server Management Studio to follow the current target a synonym points to so that syntax checking works? I'm writing SQL statements that reference a synonym that may, at different times, point to a table in one or another instance (dev, test, etc.) of the same database. It would be really nice if I didn't have red squiggles under all of the column names belonging to the underlying table when I know they're correct! Is there any way to get SSMS to figure out that they're correct?
Related
I'm following a course on edX and I'm using the AdventureWorksLT database for the exercises, everything seems fine.
However, in the Object Explorer I can't see the attributes (columns) of a table.
When I expand the table I see 4 subfolders:
Keys (which generates an error when I try to open it)
Constraints
Triggers
Statistics
No attributes/columns of the table.
Does anyone know how to fix this? I really need this sometimes to see, for instance, the type of attribute (i.e. varchar or int).
The database is hosted on Microsoft Azure and I'm using SQL Server 2014 Management Studio and database.
I've done some searching and can't seem to find an answer anywhere.
What can happen (if anything) if an entry in an SQL DB contains actual SQL code?
I've just found that an internal application at work (SQL based) can insert anything into a table including code. The datatype of the columns with this ability is Varchar.
Is there any risk with this ability, and what/how can this be a bad thing?
The following query is written using SQL Server 2014 CONTAINS function.
SELECT
Org1.OrganizationPK
,*
FROM Organization Org1
WHERE Org1.Deleted = 0
AND CONTAINS (Org1.NAME,'"chris6*"')
AND org1.OrgDomainInd = 1
But, the above query is NOT working.
I have followed this article to understand more about CONTAINS function. I have verified those examples as-they-are. Even here also, I am not getting any results.
I have verified this post from stackoverflow, but I could not apply for my requirement.
Hence, I am getting doubt whether I need to do anything more to configure SQL Server 2014 to work with CONTAINS fuction? Please let me know if there is anything I need to do to make SQL Server 2014 ready to use CONTAINS function.
If there is nothing like that, please suggest me the solution.
Please don't suggest me to use LIKE operator. I am telling this why because, most of my colleagues suggested me same; hence, as a precautionary matter I am writing this statement here.
I am running behind my schedule to complete this task.
Before CONTAINS will work against a column you need setup full text index. This is actually a different engine which runs as a separate service in SQL Server, so make sure it is installed an running.
Once you're sure the component is installed (it may already be installed) You need to do the following:
Create a Full-Text Catalogue
Create a Full-Text Index (you can have multiple of these in the same catalogue) against the tables/columns you want to be able to use full-text keywords
Run a Population which will crawl the index created & populate the catalogue (these are seperate files which SQL Server needs to maintain in addition to mdf/ldf )
There's an ok tutorial on how to do this by using SSMS in SQL Server 2008 by Pinal Dave on CodeProject. SQL Server 2014 should be very similar.
You can also perform these steps with TSQL:
CREATE FULLTEXT CATALOG
CREATE FULLTEXT INDEX
ALTER FULLTEXT INDEX
I believe that contains functionality can only be used in tables configured to use/support Full Text Search -- an elderly feature of SQL Server that I have little experience with. If you are not using Full Text Search, I'm pretty sure contains will not work.
I'm using a MS SQL Server db and use plenty of views (for use with an O/R mapper). A little annoyance is that I'd like to
use schema binding
update with scripts (to deploy on servers and put in a source control system)
but run into the issue that whenever I want to e.g. add a column to a table, I have to first drop all views that reference that table, update the table, and then recreate the views, even if the views wouldn't need to be updated otherwise. This makes my update scripts a lot longer and also, looking the diffs in the source control system, it is harder to see what the actual relevant change was.
Is there a better way to handle this?
I need to still be able to use simple and source-controllable sql updates. A code generator like is included in SQL Server Management Studio would be helpful, but I had issues with SQL Server Management Studio in that it tends to create code that does not specify the names for some indices or (default) constraints. But I want to have identical dbs when I run my scripts on different systems, including the names of all contraints etc, so that I don't have to jump through loops when updating those constraints later.
So perhaps a smarter SQL code generator would a solution?
My workflow now is:
type the alter table statement in query editor
check if I get an error statement like "cannot ALTER 'XXX' because it is being referenced by object 'YYY'."
use SQL Server Managment Studio to script me create code for the referenced object
insert a drop statement before the alter statement and create statement after
check if the drop statement creates error and repeat
this annoys me, but perhaps I simply have to live with it if I want to continue using schemabinding and script updates...
You can at least eliminate the "check if I get an error" step by querying a few dynamic managment functions and system views to find your dependencies. This article gives a decent explanation of how to do that. Beyond that, I think you're right, you can't have your cake and eat it too with schema-binding.
Also keep in mind that dropping/creating views will cause you to lose any permissions that were granted on those objects, so those permissions should be included in your scripts as well.
I've tried the obvious:
USE linkedServerName.databaseName
Which gives me the error:
`Could not locate entry in sysdatabases for database 'linkedServerName'.
If something like this were possible, it'd save me a bunch of clicking around in management studio!
Linked server definitions are designed for use as part of the four-part naming convention:
[LinkedServerDefinition.][DatabaseName.][SchemaName.]DatabaseObject
for example, OtherServer.Database.dbo.MyTable
They might have other uses, but with the USE statement is not one of them.
Would
SELECT * from LinkedServerDefinition.master.sys.databases
help in identifying what databases are "over ther"?