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!
Related
SQL Server Management Studio used to have Debug functionality that would allow to step through the code and watch the values etc. Referring to How to add the Debug button to SSMS v18?, I understand that the functionality is removed from SQL Server Management Studio V18.1.
But what is the alternative now? How do you step through the code to pinpoint a bug in the code?
You can use Visual Studio (the full IDE) to do it:
Use "Server Explorer" (Under the View menu) to connect to your DB
Right-click the DB and choose "New Query" (or find a stored procedure to debug)
Set a break point (F9 key or otherwise) on a line of SQL
Right-click inside the SQL editor and choose "Execute with Debugger"
Your best option is to not upgrade version 18.X, but stay on 17.9 until the Microsoft Product Manager gets sacked. A similar thing happened in going from SQL Server 2000 to SQL Server 2k5. Eventually, they capitulated and re-introduced the feature.
Ta for answer above, but when trying to debug with Sever Explorer, I find that "SQL Debugging is not supported on Microsoft Azure SQL Database'... ho hum, so I downgrade to SSMS 17.9 or dump the database to local and do it there.
Nice, I just wanted to quickly debug something... by the time I've done that lot I'll have forgotten what the problem I was trying to fix was !
It's deprecated, so you don't. Personally, I never use the feature and I'm assuming many others didn't either (which is why it's being retired).
The work around is to debug stored procedures by outputting values using PRINT or RAISERROR. Using BEGIN TRAN / ROLLBACK this works well because you can easily run code against the same data.
It's not the same as step through debugging, but it works.
As a .NET Desktop developer, I have a lot of experience working with various databases that are already up and running; but I'm not a DBA. I'm currently working at a company where I am ther only software guy here to build them software from scratch -- their previous enterprise-level solution was an Access database with macros and a couple forms built it. So, I basically have no one else to go to.
With that preface, how the heck do I get a database -- ANY DATABASE!!! -- added to my VS solution? I've been beating my head against this for almost 6 hours and have made zero headway. At this point, I'm ready to say, "Screw MS databases!" and start looking at MySQL or PostgreSQL or something.
The desktop application I'm developing has to work whether there is an internet connection or not, so I need a local database that installs with ClickOnce. From what I've found so far:
SQL Server [Express] 2016+ requires Windows 8 or later (a non-starter since 95% our customers are still running Windows 7)
SQL Server Compact is being deprecated and won't work past VS2013
I think LocalDB is what replaces Compact in 2016+ (?)
Okay, so I started with this tutorial:https: //learn.microsoft.com/en-us/visualstudio/data-tools/create-a-sql-database-by-using-a-designer However, trying to add a "Service-based Database" just gives me this error once: "The 'DBProviderFactories' section can only appear once per config file." I try again and get this error repeatedly: "Unable to find DbProviderFactory for type System.Data.SqlClientConnection" I've Googled both errors and all the answers that I've been able to find pertain to VS2010 or earlier and their solutions are either not applicable or don't work.
Next, I tried this tutorial: https://msdn.microsoft.com/en-us/library/aa983322.aspx I've tried adding new data connections through the "Server Explorer" panel. I don't see "[*] Compact" as an option. When I try "Microsoft SQL Server Database File", I just get the error: Unable to find the requested .Net Framework Data Provider. It may not be installed."
I've even tried adding data sources through the "Data Sources" panel; that doesn't work either.
I've installed the "Data storage and development" addon from the Visual Studio Installer, several versions of SQL Server 2014, SQL Server Compact 4.0, and maybe a few other executables from Microsoft's website.
Nothing works.
Help...
I think I just found it!
Evidently, there are "machine.config" files on your computer. Search for them all, and make sure that there is only a single tag for "DbProviderFactories". I can add a database object now. Hopefully, this puts me in business...
https://social.msdn.microsoft.com/Forums/vstudio/en-US/7b4f353b-77fd-427c-976b-5968abc88c13/visual-studio-2010-unable-to-find-the-requested-net-framework-data-provider-for-sql?forum=vseditor
If what you are saying is that you are writing a browser based application - then one would migrate the tables to SQL Server (Express) or even MySQL - it really doesn't matter. Then write a new web app. The existing Access app would serve as a model for seeing features & screen layout but is otherwise not portable.
On the other hand, if you are re-writing a Windows application; then the decision is whether the payload requires a server solution or if one can stay at the PC level. If the payload is suitable for PC then a re-write using either Visual Studio or Access again.
Access is a front end db - the tables in the back end whether they be stored in SQL Server or an Access file are entirely passive. All the processing is done by the user's PC. If the payload allows that then this is the lowest cost re-write option.
If you've outgrown a PC level payload - then one must develop a back end database feature set with a more passive front end.
I created SSIS packages and used the Integration Services Deployment Wizard to deploy it out to the server. I'm manually going to the Integration Services Catalog access through SQL Server 2012 and right-clicking and executing my package.
However, the package keeps failing and I'm getting the following errors when I check the execution report's messages.
They appear to be failing on data tasks where I have script components.
Assign :Error: CS2001 - Source file 'C:\Windows\TEMP.NETFramework,Version=v4.0.AssemblyAttributes.cs' could not be found, CSC, 0, 0
Assign :Error: Failed to compiled scripts contained in the package. Open the package in SSIS Designer and resolve the compilation errors.
This answer is a more detailed version of UberDoodles answer.
In Windows Explorer.
Navigate to C:\Windows\Temp\
Right click the folder and select properties
Go to tab Security, choose Advanced
On the default tab Permissions, choose Change Permissions
For the relevant Permission entry, choose edit.
By default, I had 'allow' checked for Traverse folder / execute file, Create files / write data and Create folders / append data.
Also check 'allow' for List folder / read data and Take ownership.
Press OK, the window closes
Press Apply and confirm anything you need.
Additionally, the logged in user had already Full control, but when I changed this for the entry 'Users', it worked for me.
(based on microsoft file/folder permissions).
I had the same problem today, just on SQL 2016.
For me it helped to change the target server version in Visual Studio project properties from SQL Server 2012 to SQL Server 2016.
I was investigating the same issue, and I came across a solution here :
https://social.msdn.microsoft.com/Forums/vstudio/en-US/73e67f3a-c575-4c73-a71d-ed7a2aeabb50/csc-error-cs2001-source-file-cwindowstempnetframeworkversionv40assemblyattributescs?forum=msbuild
Basically, the account which the package runs under needs to have full permissions to the C:\Windows\Temp\ folder, so that it can create temporary classes.
It worked for me :)
I had the same problem. I first used Eric G. response and added the List and Read permission to the c:\windows\temp. After I got everything working I went back and removed that permission. I then redeployed my solution from Visual Studio, this time designating the deployment target as SQL Server 2014 (which was the environment I was using) using Martin's solution. I then reran the process, and it worked with the List and Read removed.
I kept it using Martin's solution, as I don't like to have special permissions granted if I don't need them.
Good Luck
[Visual Studio 2017 15.9.16]
I just restarted Visual Studio as Administrator and the issue disappeared, which confirms the permissions idea of the answers above but spared me all work.
It's not a quirk though, as per this question and its answer you need that kind of permission for several tasks, like profiling and debugging under certain conditions.
For the sake of completeness, this blog says you might incur in some security contraindication if run VS as administrator when opening third-party solutions.
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 backed up my database table's and entire schema into .sql script using Visual Studio's Database Publishing Wizard.
I then tried to re-create those tables on another PC, not before re-creating the database itself, with the same exact name and everything (using a script that I created via SSMS's Script Database as).
I then open that tables .sql file using SSMS and execute it.
SSMS reports:
Command(s) completed successfully
But examining Object Explorer reveals that no tables were created.
Why is this happening?
What have I missed?
I've just been having the exact same problem symptoms also using Visual Studio's Database Publishing Wizard, - but with a slightly different cause / fix.
Even though SQL Server Management Studio says it is connected to the correct database (in the drop down in the ribbon, and in the status bar of the window), it wasn't actually connected to anything.
To identify and fix either:
SELECT DB_NAME() AS DataBaseName
If you get
master
(or any other unexpected database name) as the result, then you are connected to the wrong database and should select the correct DB from the dropdown. This was the cause of your problem.
If you get
Command(s) completed successfully
then somehow you aren't connected at all - this happened to me.
To fix, click the "change connection" button to disconnect and reconnect.
Check whether you have selected database. Most of the times we execute query in Master db by mistake.
-- Mark as answered if this answer really answered your question
Check if you are running "Execute" or jut Parsing the code. It was a late night, I was tired, and kept running a query to create a table, successfully, but no new table. The next day with a clear mind i noticed that i was not actually running the query, i was parsing it.