Attempting to configure the "sensitive" versions of the batch completed groups (SENSITIVE_BATCH_STARTED_GROUP/SENSITIVE_BATCH_COMPLETED_GROUP) that are listed in the doc for SQL 2019
https://learn.microsoft.com/en-us/sql/relational-databases/security/auditing/sql-server-audit-action-groups-and-actions?view=sql-server-ver15
I have set up all the data classifications and now need to set up the associated auditing.
Issue is I can't select them in the UI (they're not in the dropdown list) nor can I use them in T-SQL or PowerShell scripts either.
E.g. Whilst using BATCH_STARTED_GROUP works just fine, replacing just those characters in the same script with SENSITIVE_BATCH_STARTED_GROUP produces a syntax error but according to the doc it should be fine.
Am I missing a configuration option or something similar ?
Running SQL 2019 (15.0.4223.1)
Related
The documentation lists several "SENSITIVE" groups (e.g., SENSITIVE_BATCH_COMPLETED_GROUP) that are new for SQL 2019. I both want and need it. However, I can't find these to select. If I try to use the SENSITIVE groups in script, I get a syntax error. I'm at 15.0.4123 (CU 10).
https://learn.microsoft.com/en-us/sql/relational-databases/security/auditing/sql-server-audit-action-groups-and-actions?view=sql-server-ver15
Do I need to add a feature or install a feature pack to have access to this audit group?
I am using installshield 2016 ultimate version and little new to this. We have bunch of sql script which needs to be run all the time during installation, creating a database is one of the sql script in it. We want to change the collation for the database based on the language selected during installation. I have used the custom action but it failed as the update statement has to be executed before the database connection is established or services are started. I have also tried to use SELECTED_LANGUAGE=0x0409 (for english) as script condition but it shows an error stating "An invalid conditional statement was supplied.
Need help to write correct condition and if not how can i execute the sql based on language selected.
Click here for the screenshot
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'm using forms authentication to handle users and attempting to deploy my database to SQL Azure, but getting this error message:
The only table of the four listed that I utilize is aspnet_Membership, and the only other table I use is aspnet_Users from implementing forms authentication. What is TextInRowSize and why does SQL Azure care about it? Do I have any option to modify aspnet_Membership to make it compatible?
If it would be easier to remove the current system altogether and replace it with my own, I'm fine with that too.
That looks like an error in the data-tier application framework. I can suggest a workaround to get your database to Azure:
Use SqlPackage.exe (https://msdn.microsoft.com/en-us/library/hh550080(v=vs.103).aspx) from the command line to extract a dacpac file with all table data. Then use SqlPackage.exe to deploy that dacpac file to your database in Azure. The extract command would look something like:
C:\>"c:\Program Files\Microsoft SQL Server\120\DAC\bin\SqlPackage.exe" /a:extract /scs:"Data Source=yourSqlServer;Integrated Security=true;Initial Catalog=yourDatabase" /tf:C:\temp\mydatabase.dacpac /p:ExtractAllTableData=true
And the import command would look something like:
C:\>"c:\Program Files\Microsoft SQL Server\120\DAC\bin\SqlPackage.exe" /a:publish /tcs:"Data Source=yourAzureSQLServer.database.windows.net;User Id=yourUserId;Password=yourPassword;Initial Catalog=yourDatabase" /sf:C:\temp\mydatabase.dacpac
So quick suggestions since I see you are using V12 which should support those properties now.
First make sure you are using SSMS 2014 SP1 at least, this has a number of fixes for using V12. Secondly make sure you install the May 2015 update to DacFX (which is the program that creates bacpac files) you can install it here: http://www.microsoft.com/en-us/download/details.aspx?id=46898
This should get you to the best possible chance of your import/export working.
This was solved by generating a SQL Azure script for the DB, and running it on Azure. Here's how I solved it:
First, open SQL Server, right click the database you want to transfer and click "Tasks > Generate Scripts..."
Next, click "Advanced" on the scripting options panel and find the row "Script for the database engine type." Select "Windows Azure SQL Database" and click OK (Note: if you have data that you want to transfer as well, choose "Schema and Data" from the "Types of data to script" option).
Proceed thru the rest of the script generation dialog, remembering where you saved the script file. Connect to your database server using SQL Server or windowsazure.com. Generate a new query for your new database, enter the script that was generated by SQL Server and execute.
Seems like TextInRowSize stores large data for older SQL Server types such as text and ntext. You would need to change it's type to nvarchar(max).
Here's a link to a more detailed explanation.
http://www.dnnsoftware.com/wiki/unsupported-property-textinrowsize-set-and-is-not-supported-when-used-as-part-of-a-data-package