Versions in use:
SQL Server 2016
Azure Data Studio 1.36.2
SQL Server Schema Compare 1.13.1
Problem: there is something wrong with my Azure Data Studio apply schema to SQL Server 2016.
It say I'm not the login manager but there is no login manager role in SQL Server.
And it has worked before updating Azure Data Studio to v1.36.X
https://imgur.com/a/JFWFOtn
Finally, I found the problem
Misused sqllinlinetablevaluedfunction and sqlmultistatementtablevaluedfunction
In my project There are many function use sqllinlinetablevaluedfunction instead of sqlmultistatementtablevaluedfunction but It's should be used sqlmultistatementtablevaluedfunction
so I change to Correct Type then It's worked. The error never show
Related
I use Microsoft SQL Server Management Studio v17.2. I know that for exporting data to JSON must use method like this:
SELECT *
FROM table1
WHERE [conditions]
FOR JSON PATH, ROOT('root')
but when I use this code in SQL Server Management Studio, an error occurred:
Incorrect syntax near 'json'.
Please help me solve this error.
This doesn't have anything to do with Management Studio; the version of SSMS you're using is irrelevant. It has to do with the version of SQL Server you're running the code against, which is completely separate from the version of SSMS.
FOR JSON was introduced in SQL Server 2016. If you are not running 2016 or better (or Azure SQL Database), you'll need to upgrade, or use a different approach to get your data into JSON format.
I have a SQL Azure database. I'm able to export the Database using Tasks > Export Data Tier Application. This is successful.
I then try to use Import Data Tier Application in my local SQL server and I get the following error:
Could not import package. Warning SQL0: A project which specifies
Microsoft Azure SQL Database v12 as the target platform may experience
compatibility issues with SQL Server 2008. Warning SQL72012: The
object [db_Data] exists in the target, but it will not be dropped even
though you selected the 'Generate drop statements for objects that are
in the target database but that are not in the source' check box.
Warning SQL72012: The object [db_Log] exists in the target, but it
will not be dropped even though you selected the 'Generate drop
statements for objects that are in the target database but that are
not in the source' check box. Error SQL72014: .Net SqlClient Data
Provider: Msg 102, Level 15, State 1, Line 1 Incorrect syntax near
'CREDENTIAL'. Error SQL72045: Script execution error. The executed
script: CREATE DATABASE SCOPED CREDENTIAL [databasenameAzureStorageCredential]
WITH IDENTITY = N'SHARED ACCESS SIGNATURE';
I have SQL Server Management Studio 14.0.17289.0 and everything is up to date.
I have read different posts on Stack overflow and done some googling but unsure the best way to move forward. How can I solve this?
It seems like there is a compatibility mode differences in your local SQL server DB and Azure SQL server DB. Check your compatibility level and if it is mismatched here is the resource to solve that. The error was because you use SSMS version 'X' to generate the bacpac against Azure SQL version 'Y'. Try to generate the same bacpac using SSMS version 'Y' and it works for me.
Please download the latest version of SQL Server Management Studio from here to have the best user experience with Azure SQL Database. SSMS v14 is too old. The current version of SSMS is v17.9.
Remove (drop) the database scoped credential named "databasenameAzureStorageCredential" before exporting the database. The following query should give you a list of credentials created.
SELECT * FROM sys.database_scoped_credentials
In general, you need to remove references to external sources before exporting your database.
Using a VS2010 SP1 Data-tier application project, I created the simplest database I could:
CREATE TABLE [dbo].[Table1]
(
column_1 int NOT NULL,
column_2 int NULL
)
I then successfully built the .dacpac, and verified it by deploying it using SSMS 2008 R2 to a local SQL Express instance (everything worked fine).
I then tried using SSMS 2008 R2 to deploy the .dacpac to a SQL Azure server. The wizard managed to get through every step (including creating the database and creating the schema), but failed on the last step - "Registering the DAC in DAC metadata" - with an IndexOutOfRangeException (see below).
I tried to do this against an existing SQL Azure server, against a new SQL Azure server (both fail with the same exception), and against a SQL Azure server with an empty database by the same name (this one failed with an SSMS runtime exception).
I'm now out of ideas. Any ideas on how to deploy .dacpacs to SQL Azure would be greatly appreciated.
System.IndexOutOfRangeException: Index was outside the bounds of the
array. at
Microsoft.SqlServer.Management.Smo.SqlPropertyMetadataProvider.PropertyNameToIDLookupWithException(String
propertyName, PropertyAccessPurpose pap) at
Microsoft.SqlServer.Management.Smo.SqlSmoObject.GetDbComparer(Boolean
inServer) at
Microsoft.SqlServer.Management.Smo.SqlSmoObject.InitializeStringComparer()
at
Microsoft.SqlServer.Management.Smo.AbstractCollectionBase.get_StringComparer()
at
Microsoft.SqlServer.Management.Smo.SimpleObjectCollectionBase.InitInnerCollection()
at
Microsoft.SqlServer.Management.Smo.SmoCollectionBase.get_InternalStorage()
at
Microsoft.SqlServer.Management.Smo.SmoCollectionBase.GetObjectByKey(ObjectKeyBase
key) at
Microsoft.SqlServer.Management.Smo.DatabaseCollection.get_Item(String
name) at Microsoft.SqlServer.Management.Dac.RegisterDacStep.Execute()
at
Microsoft.SqlServer.Management.Dac.TransactionalActionManager.ManagedActionStep.TransactionalStep.DoExecute()
at
Microsoft.SqlServer.Management.Dac.TransactionalActionManager.ManagedActionStep.Execute()
at
Microsoft.SqlServer.Management.Dac.TransactionalActionManager.ExecuteActionSteps(IEnumerable`1
managedActionSteps) at
Microsoft.SqlServer.Management.Dac.TransactionalActionManager.Go() at
Microsoft.SqlServer.Management.Dac.DacStore.Install(DacType dacType,
DatabaseDeploymentProperties deploymentProperties, Boolean
skipPolicyValidation, Boolean skipDacRegistration)
Do you have the latest build of SSMS? You should be running SSMS R2 SP1. It has fixes for the DAC PAC specifically.
Here it is: http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=26727
According to Microsoft, there is apparently some kind of issue around which order you install VS 2010 SP1 and SQL 2008 R2 SP1.
Herve's answer may address the problem as well (i.e. reinstall SQL 2008 R2 SP1), but I was not able to verify it because I already solved the issue by following the SQL Azure team's recommended solution - go to http://www.microsoft.com/download/en/details.aspx?id=26728 and download / install the new SMO MSI (which is listed as 1033\x64\SharedManagementObjects.msi).
Thanks MS!
I have a dev workstation with sql 2005 installed and in it I created a linked server to a odbc connection to a clarion database. I can run select statements against it inside sql Mgt studio. When I take a second workstation and connect to the sql on the first box using sql mgt studio, then try the exact same query I get
OLE DB provider "MSDASQL" for linked server "liveclarion" returned message "[SoftVelocity Inc.][TopSpeed ODBC Driver][ISAM]ISAM Table Not Found".
Any thoughts? It appears to have the same functionality on a second sql server. No remote sql mgt studio connect success in queries against my linked ODBC clarion DB.
All done with windows authentication and the same AD user.
The error returned by the ODBC driver is "SAM table not found".
So I'm assuming you have a table called SAM - presumably in a table called Sam.Tps?
I'm wondering if you need to set a path to that file - ie if there's some difference in path or file name validity between your two tests. One assumes not, but I'd look in that direction first.
I have a Windows 2008 Server (x64) running Microsoft SQL 2008 (x64) and I'm creating a Linked Server connection to an Oracle server. I'm able to make the connection, but I cannot see any information regarding which schema a table belongs to.
In SQL 2005, my linked servers show the schema information as I would expect.
Does anyone know how to resolve this issue? Is it an issue with the provider, OraOLEDB.Oracle?
Any help or pointers would be appreciated.
#Boojiboy - When you are looking at the tables via a linked server, there used to be a column for what schema. It appears that in the latest the new Oracle OLEDB drivers don't show this information any longer.
It looks like sp_tables_ex will do the trick, it came from the below article.
--verify tables OK exec sp_tables_ex #table_server = 'LINKED_ORA',
#table_schema='MySchema'
#table_schema is optional. If not
provided, you will get a list of all
tables in all schemas.
http://it.toolbox.com/blogs/daniel-at-work/linking-sql-server-2005-to-oracle-26791
Also in the SQL 08 > Server Objects > Providers
make sure your OraOLEDB.Oracle provider is allowing inprocessing