Assume that I have a query like:
INSERT INTO SomeTable(SomeCol) Values('ışç');
It succesfully inserts. But when i execute a select query for it, I get:
isc
My team mates don't have this problem. I also don't have this problem when I do this through the app I'm developing.
I guess it is about my management studio collation. I tried to find a menu to change it but I was not able to.
Related
I am trying to install some application on Windows Server 2019. The application relies on a database, so I also have SQL Server 2016 (v 13.0.1601.5) on the server. But during installation, I get an error message, basically telling me some SQL script, say "abc.sql" has encountered a problem and cannot continue. When I open SQL Server's XEven Profiler, I surely see what the problem is; it fails to create a stored procedure because of some bug in the code, something like this:
CREATE PROCEDURE [dbo].[doSomethingNice] (**#problematicParameter** int, #nonProblematicParameter int)
AS
BEGIN
SET NOCOUNT ON;
update [dbo].[SomeTable]
set SomeField =**#ProblematicParameter**
where
SomeOtherField= #nonProblematicParameter
END
Of course, the problem is the casing.
XEvent Profiler kindly specifies which application runs the query, and in this case, it is Windows Installer.
client_app_name: Windows Installer - Unicode
I believe (more likely hope), if I can somehow get hold of the original script file, abc.sql, I can fix it and run it from SQL Server Management Studio. This would work since the installer program provides the option of using an existing database instead of creating a new one.
I scoured the Temp directory but could not find the said script. I know it must be somewhere on the disk. How can I find where it is? Does XEvent Profiler provide that data?
I’m really confused with how to use database projects in Visual Studio (2019).
I’ve created a new project and imported my database into it. I then can happily edit the SQL and commit it into source control, however, when I try to deploy the items to the server it fails due to unresolved references.
To get around this I have added in a reference to my database and changed the SQL to use the reference like so:
SELECT * FROM [$(DataBase)].dbo.TableName
The project then builds and I can deploy the SQL to my server with:
Tools> SQL server > New Schema Comparison
However what do I then do if I want to edit that SQL and make any changes?
Currently I’m using the “open by default” feature to open the SQL into SSMS (as the editor in visual studio does not appear to have the ability to execute the sql), and then find and replacing the [$(Database)] text with my database name, then making and testing my changes and then cut and pasting it back into Visual Studio and find and replacing the [$(database)] text back in.
I can’t help but think that I'm surely missing something here‽ I find it hard to believe that the workflow is this longwinded.
I'm using SSMS (from SQL Server 2014 Developer edition) to work with SQL Azure. It's running on Windows 10. I have a number of databases set up on Azure, and have always used SSMS to work with them. I have also installed devart's dbForge Studio for SQL and use that from time to time.
I've now hit a very weird problem. I was about to create a view, and clicked the + next to a table to expand the nodes below. Then I clicked the + next to columns and got a strange error as follows:
TITLE: Microsoft SQL Server Management Studio
Failed to retrieve data for this request. (Microsoft.SqlServer.Management.Sdk.Sfc)
For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft%20SQL%20Server&LinkId=20476
ADDITIONAL INFORMATION:
unknown property IsMemoryOptimized (Microsoft.SqlServer.Management.Sdk.Sfc)
Having dismissed this error, everything seemed fine, however, until I noticed that I no longer have a Columns node under that table. Or indeed any table (see screenshot).
I tried the following trouble-shooting steps:
Restart SSMS. No change
Restart the PC. No change
Use the "Repair" option in the SQL Server Installation Center to repair the Management tools. No change
Then I tried connecting to another database entirely, and I can see columns again! But when I connect back to this one, no columns.
To be clear, the columns ARE there, I can use them in SELECT statements, and I can use Script table as --> Create and SSMS creates a script including all the column names.
I can also see the columns if I use DBForge instead of SSMS.
Anyone ever come across this? It's a real mystery to me, so I'm hoping someone here can help. Incidentally, I did follow the link in the error message above to see if there's more information, but no luck.
This is a bug in SSMS. Ensure that your SSMS 2014 is updated (https://www.microsoft.com/en-us/download/details.aspx?id=46694) or, even better, use the latest version of SSMS (http://blogs.msdn.com/b/sqlreleaseservices/archive/2015/09/01/announcing-sql-server-management-studio-august-2015-release.aspx).
I just got approved for the Azure SQL Data Warehouse Preview, and just finished "provisioning" my new server and database. I followed a link to a 'Getting Started' page from Microsoft (Get started: Connect ...), and read that the two best (only?) ways of querying the database were through sqlcmd and Visual Studio 2013.
I ignored this advice first, and fired up SSMS, connected to the database, and then tried to open a new query window. I immediately received the following error: 'Unable to apply connection settings. The detailed error message is: 'NoCount' is not a recognized option.' After clicking OK, the query window did open up, but many T-SQL statements did not work such as a simple:
CREATE TABLE dbo.tblTest (acct_id nvarchar(255) NOT NULL)
I would receive a 'Command(s) completed successfully.' message, however no table was created.
Ok, I fired up Visual Studio 2013, connect to my Azure SQL Data Warehouse, and open it up in SQL Server Object Explorer. I right-clicked the specific database, and selected 'New Query', enter the same T-SQL CREATE TABLE statement as above, then hit execute. Once I hit execute, I get the exact same error message as above. This time around I was able to open a new query window at least, but after attempting to execute the query I still get the 'NoCount' is not a recognized option error.
I'm completely new to data warehouses, and still very much a beginner with T-SQL and SQL Server as well. But, I haven't been able to find anything that would explain why I'm receiving these errors, and right now I'm basically at a standstill until I can understand what's going on. Any help is appreciated, thanks.
I've experienced this. Your connection isn't actually recognised as a SQL DW connection. I bet your query window is a .sql file, not a .dsql as it needs to be.
Go back into the Azure portal and use the link to connect using SSDT from there. You should get a connection in the SQL Server Explorer pane which looks different, and when you start a New Query based on it, you should get a .dsql window, not a .sql one.
Have you checked the version of SSDT that you are using? It sounds like you may be on a version prior to 12.0.50623, which doesn't take into account that SET NO COUNT is not supported by SQL Data Warehouse at the moment. Newer versions of SSDT have adjusted for this. We recommend updating SSDT here and then connecting using the SQL Server Object Explorer with the directions in our documentation.
I am running Visual Studio 2015 Enterprise, and what I had to do to get this error resolved was install SSDT October 2015 Preview in Visual Studio. The link I used is: https://msdn.microsoft.com/en-us/library/mt204009.aspx
Prior to installing this, I had the latest released version for VS2015...had to install the Preview to get it to work. Also, it solved the issue where I was not able to see ANY of the tables in the Azure Data Warehouse database - just a couple of views, which made querying difficult (could still get a list of available tables from sys.tables)
I hope this helps somebody!
I installed SQL Server 2008 Express with Advanced Services, but when I try to create a new database, the option Full-Text indexing is greyed out, I believe the full-text indexing has been installed, because I did a query as below:
use [mydbname]
select fulltextserviceproperty('isfulltextinstalled')
This query returns 1, so I think it has been successfully installed.
Full-text indexing is supported in MSSQL Express with Advanced Services edition, which I have installed. Page for reference:
http://www.microsoft.com/downloads/details.aspx?familyid=B5D1B8C3-FDA5-4508-B0D0-1311D670E336&displaylang=en
Make sure NAMED PIPES is enabled in the protocols in configuration manager as full text service needs this!
Is the service started? I think a default install of 2008 Express has FTS stopped.
In 2005 Express (IIRC) you had to make the catalogs manually, rather than through managmement studio; you could try that and see if you get an error:
use MyDatabaseName
go
EXEC sp_fulltext_database 'enable'
go
CREATE FULLTEXT CATALOG MyFullTextCatalog
If you need to manually create the indexes you can do something like:
CREATE FULLTEXT INDEX ON MyDatabaseName.dbo.MyTableToSearch
(
MySearchColumn
Language 1033
)
KEY INDEX MyCurrentIndex;
You can view all the full text enabled value for each DB with this code:
select name, DATABASEPROPERTY(name,'IsFulltextEnabled')
from master..sysdatabases where dbid > 4
Pollus
Coincidentally I was just reading a performance guide for FTS in SQL 2008 and came across this:
The New Database dialog box in
Management Studio has an option grayed
out. Just below the name and owner
there is a grayed out check box. In
the released version of SQL Server
2008 the full text options are on by
default. This was left in place in
case any customers had references to
it in scripts.
So it looks like it's greyed out on purpose :)
The page here gives information on how to confirm that you've installed full-text with the SQL Server install as well as steps to install it after the fact.
This page has a decent walk-through of setting it all up.
Also, make sure that the service is running.
Hopefully one of them will point you in the right direction.
The following list highlights the major SQL Server components that are not supported in SQL Server Express:
Reporting Services
Notification Services
Integration Services
Analysis Services
Full text search
OLAP Services / Data Mining
From:
http://msdn.microsoft.com/en-us/library/ms165636.aspx
Beware of current compatibility level set in your DB when configuring SQL Server Fulltext
In case it might help people having the same issues I found, I'm posting this here because it's related to the question.
I had a SQL Server DB installed by an external company. We asked for some modification to its software that required adding fulltext search features in the database.
I had a test database that I had created from scratch beside this company database to test the configuration of these services.
When I tried to create a Fulltext catalog in SQL Server 2008 all options where greyed out for the company's database, whereas in the database created from scratch everything was OK, the screen was not greyed out and I could for example state that I wanted accents to be ignored.
Out of despair, I started to compare every parameter between the two databases, and I found that that the company's database compatibility level was set to 'Sql Server 2000 (80)'. As soon as I changed that to 'SQL Server 2008 (100)', everything started to work fine, the Fulltext catalog creation scren was no longer greyed out.
I found a note, in this article somehow related to this compatibility issue:
https://msdn.microsoft.com/en-us/library/ms142583.aspx#OV_ft_predicates