I came across an syntax error message when I tried creating a table in sql-azure through a local SSMS connection. This error does not occur if I run the same query on a local host DB instead of my azure connection.
Create table Portfolio_Company_Financials
(
PCF_ID int not null identity(1,1) PRIMARY KEY,
CompanyID int,
ReportingDate date,
Revenue float,
)
Above throws the error:
Parse error at line: 3, column: 21: Incorrect syntax near 'identity'
It will execute when I comment out identity(1,1) and over. It has the same issue with with using using only primary:
...PCF_ID int not null PRIMARY KEY,...
Additionally it looks like I cannot manually change column properties through the SSMS object explorer and can only refresh/delete when right clicking to the column.
It looks like a SSMS/permissions/azure issue? Can anyone help me here?
This error occurs when you try to create the table in Microsoft Azure SQL Data Warehouse. Azure SQL Data Warehouse does not yet support primary keys and the identity property. You can confirm your version with the following sql:
select ##version
https://learn.microsoft.com/en-us/azure/sql-data-warehouse/sql-data-warehouse-tables-overview
Related
We are trying to work with temporal tables in SQL Server 2016. We are developing the SQL scripts in SSDT 15.1.6 in Visual Studio 2017, but we are experiencing issues when trying to deploy the dacpac that is generated during the build.
Our dacpac is deployed using SqlPackage.exe, and we encounter this error when attempting to deploy the dacpac:
Creating [dbo].[TestHISTORY].[ix_TestHISTORY]...
An error occurred while the batch was being executed.
Updating database (Failed)
Could not deploy package.
Error SQL72014: .Net SqlClient Data Provider:
Msg 1913, Level 16, State 1, Line 1
The operation failed because an index or statistics with name 'ix_TestHISTORY' already exists on table 'dbo.TestHistory'.
Error SQL72045: Script execution error. The executed script:
CREATE CLUSTERED INDEX [ix_TestHISTORY]
ON [dbo].[TestHistory]([SysStart] ASC, [SysEnd] ASC);
When we create the temporal table in SSDT we have the following:
CREATE TABLE [dbo].[Test]
(
[Id] INT NOT NULL PRIMARY KEY,
[SysStart] DATETIME2 (7) GENERATED ALWAYS AS ROW START NOT NULL,
[SysEnd] DATETIME2 (7) GENERATED ALWAYS AS ROW END NOT NULL,
PERIOD FOR SYSTEM_TIME ([SysStart], [SysEnd])
)
WITH (SYSTEM_VERSIONING = ON(HISTORY_TABLE=[dbo].[TestHISTORY], DATA_CONSISTENCY_CHECK=ON))
As far as I can tell the issue is with the dacpac creation. After the project is built, the dacpac created looks like this:
CREATE TABLE [dbo].[test]
(
[Id] INT NOT NULL PRIMARY KEY CLUSTERED ([Id] ASC),
[SysStart] DATETIME2 (7) GENERATED ALWAYS AS ROW START NOT NULL,
[SysEnd] DATETIME2 (7) GENERATED ALWAYS AS ROW END NOT NULL,
PERIOD FOR SYSTEM_TIME ([SysStart], [SysEnd])
)
WITH (SYSTEM_VERSIONING = ON (HISTORY_TABLE=[dbo].[testHISTORY], DATA_CONSISTENCY_CHECK=ON));
GO
CREATE TABLE [dbo].[testHISTORY]
(
[Id] INT NOT NULL,
[SysStart] DATETIME2 (7) NOT NULL,
[SysEnd] DATETIME2 (7) NOT NULL
);
GO
CREATE CLUSTERED INDEX [ix_testHISTORY]
ON [dbo].[testHISTORY]([SysEnd] ASC, [SysStart] ASC);
GO
I suspect because we are using a temporal table with a default history table we can't have the dacpac create those extra creation statements. Since this is effectively causing SQL Server to try to create those items twice, leading to the above error.
Does anyone know what we might be missing? Or if you are deploying temporal tables using a dacpac, is your only option to use user-defined history tables?
We've had a number of issues between temporal tables and DACPAC's. A few tips that will go a long way:
Explicitly declare history tables - This goes way further than one would think. When adding/removing columns, you can define a default on history tables, allowing you to bypass a number of issues that arise when data is already in the tables.
Add defaults to EVERYTHING - This cannot be overstated. Defaults are the best friend of a DACPAC.
Review the scripts - It's nice to think of DACFx as hands off, but it's not. Review the scripts once in a while, and you'll gain a ton of insight (it appears you already are!)
Explicitly name your indices - DACFx sometimes uses temporary names for indices/tables/other stuff. Consistency is king, right?
Review ALL publish profile options - Sometimes, there are settings you didn't think of in the profile. It took us a lot of manual intervention before we realized there was a setting for transactional scripts in the publish profile.
Also look into who is turning your DACPAC into a script. VS uses SqlPackage.exe, but I sometimes get different results from the DACFx DLLs. It's likely a config thing that's different between the two, but it's tough to find out. Just try both, and see if one works better.
Best of luck! Hope this helps!
One potential hacky work around you can try is pre-deployment scripts;
https://msdn.microsoft.com/en-us/library/jj889461(v=vs.103).aspx
They are executed between 'Generation of deployment script' & 'Execution of the deployment script'. So if you can't avoid collision on index name, you can probably rename existing index before upgrade, This is hacky and i am assuming you are deploying/updating schema of a live DB and not creating a new DB
BTW, Where are the column names 'ValidFrom' & 'ValidTo' found in error message coming from?, If it is auto generated then it should be 'SysEnd' & 'SysStart'
I am trying to running the below query:
SELECT TOP 1
*, (Title COLLATE utf8_general_ci)
FROM
BibTitles
WHERE
TitlesID > '.$last_iterate_book_id.'
ORDER BY
TitlesID ASC;
in PHP script. The above query is to get data from a SQL Server view.
When I am running the script, it is throwing the below error:
Invalid collation 'utf8_general_ci'
I am using the collation because, my database contains data in different language and showing me those data as question mark (???) instead of actual data. I can't alter the database as well as table due to permission issue.
Please help me with this.
I receive the following error (taken from replication monitor):
The option 'FILETABLE_STREAMID_UNIQUE_CONSTRAINT_NAME' is only valid when used on a FileTable. Remove the option from the statement. (Source: MSSQLServer, Error number: 33411)
The command attempted is:
CREATE TABLE [dbo].[WP_CashCenter_StreamLocationLink](
[id] [bigint] NOT NULL,
[Stream_id] [int] NOT NULL,
[Location_id] [numeric](15, 0) NOT NULL,
[UID] [uniqueidentifier] NOT NULL
)
WITH
(
FILETABLE_STREAMID_UNIQUE_CONSTRAINT_NAME=[UC_StreamLocation]
)
Now, for me there's two things unclear here.
Table already existed on subscriber, and I've set #pre_creation_cmd = N'delete' for the article. So I don't expect the table to be dropped and re-created. In fact, table still exists on subscriber side, although create table command failed to complete. What am I missing? Where does this create table command come from and why?
I don't understand why does this FILETABLE_STREAMID_UNIQUE_CONSTRAINT_NAME option appear in creation script. I tried generating create table script from table in SSMS and indeed, it's there. But what's weird, I can't drop and re-create the table this way - I get the very same error message.
EDIT: Ok, I guess now I know why the table is still there - I noticed begin tran in sql server profiler.
If your table on the publisher is truly not defined as a FileTable, then the issue has to do with the column named "Stream_id". I believe there is a known issue in SQL 2012 where if you have a column named "Stream_id", which is kind of reserved for FileTable/FileStream, it will automatically add that constraint, and unfortunately break Replication. The workaround here is to rename the column to something other than "Stream_id".
Another workaround is to set the schema option to not replicate constraints (guessing this will work). If you require constraints on the subscriber, you can then try to manually apply them on the sbuscriber after the fact (or script them out and use #post_snaphsot_script).
I have spent a few days trying to fix this problem. I have a SSIS package with 2 execute SQL tasks within a sequence container, one is a simple delete from table and the next one an simple insert the delete precedes the insert. The delete works fine so the connection etc is ok.
The Insert is failing with the following vague and unhelpful message.
failed with the following error: "Syntax error, permission violation, or other nonspecific error". Possible failure reasons: Problems with the query, "ResultSet" property not set correctly, parameters not set correctly, or connection not established correctly.
The insert has 1 input parameter which is a date which is bound to a datetime variable set to 01/01/2011. When I replace the ? in the sql task query with a hard coded date the task works. I have also looked at the locals at a pre-execute event break point on the insert task and the variable is ok.
I also fired up a SQL Profiler session and I see the delete query hitting the DB but nothing for the insert (when it uses the input parameter).
I am using Visual Studio 2005 Pro SP1 (Not my choice) and SQL Server 2005 SP3.
Regards
Mark
I know that you have found an answer to your question. However, I would like to clarify here that the following query you were executing using OleDb connection is valid and it does work within the Execute SQL Task in SSIS package.
INSERT INTO dbo.table1 (DateCol, OtherCol, OtherCol1)
SELECT ?, SourceCol1, SourceCol2 FROM dbo.SourceTable
Following example shows a successful implementation of the above mentioned query using SSIS 2005 (Business Intelligence Development Studio (BIDS) 2005)
Step-by-step process:
Create two tables named dbo.Source and dbo.Destination using the scripts provided under the Scripts section. Populate the table dbo.Source with data as shown in screenshot #1. Table dbo.Destination will initially be empty and will be populated with source data using an Execute SQL Task.
On the SSIS package, create an OLE DB Connection named SQLServer in the Connections Managers pointing to a SQL Server instance of your preference. Refer screenshot #2.
On the SSIS package, create a variable named RecordDate as shown in screenshot #3.
On the SSIS package, place an Execute SQL Task as shown in screenshot #4. Configure the task as shown in screenshots #5 and #6.
Screenshot #7 shows sample package execution.
Screenshot #8 shows data in the tables dbo.Source and dbo.Destination after package execution.
Hope that helps.
Scripts:
.
CREATE TABLE [dbo].[Destination](
[Id] [int] IDENTITY(1,1) NOT NULL,
[DateValue] [datetime] NOT NULL,
[ItemNumber] [varchar](50) NOT NULL,
[Qty] [int] NOT NULL,
CONSTRAINT [PK_Destination] PRIMARY KEY CLUSTERED ([Id] ASC)) ON [PRIMARY]
GO
CREATE TABLE [dbo].[Source](
[Id] [int] IDENTITY(1,1) NOT NULL,
[ItemNumber] [varchar](50) NOT NULL,
[Qty] [int] NOT NULL,
CONSTRAINT [PK_Source] PRIMARY KEY CLUSTERED ([Id] ASC)) ON [PRIMARY]
GO
Screenshot #1:
Screenshot #2:
Screenshot #3:
Screenshot #4:
Screenshot #5:
Screenshot #6:
Screenshot #7:
Screenshot #8:
You need to make sure your SQL Statement is of the correct type to be parameterized according to your connection manager.
If you're using OLE DB - your Insert statement needs to be of some kind like INSERT INTO Tbl(col) VALUES (?)
Resultset should be "None" (As there's nothing to return on your INSERT), and the Parameter Mapping tab should have a single parameter (or as many as ?'s you have, and Parameter Name should (for OLE DB) start on 0, then 1, 2 ... ,n. If you were using an ADO connection you would have to name the parameters Param1, Param2, ... ParamN.
You can see the reference for passing variables to the respective connection managers here: http://technet.microsoft.com/en-us/library/cc280502.aspx
Proper answer as per your comment:
You cannot use a parameter mapping in a query of that kind. But there is an easy way to do it.
Make a new variable sqlCommand (type string). click it in the list of variables, and press F4 to see properties. Change "EvaluateAsExpression" to true, and click the expression box to get up the expression window. In here make your query in a format like this "INSERT INTO tbl(dateCol,intCol,charCol) SELECT CONVERT(DATETIME,'" + (DT_STR,20,1252)#[User::dateVar] + "',104) AS dateCol, intCol, charCol from anotherTbl"
When you click Evaluate Expression you'll see a valid SQL statement being formed that you can use.
Now go back to the Execute SQL task, remove the parameter mapping. Close the dialog box, click the Execute SQL task, press F4, find the expressions line, click the ... and add an expression on the Property "SqlStatementSource" with expression #[User::sqlCommand] (or whatever you named your variable).
Now run the task and it should work without a problem.
You can find the expression here:
Objective:
To update datetime field (date+time) in parameter in sql task editor of SSIS package.
Description:
Step01: Created a variable having datatype as string.
e.g:
Variable name: ReconcileStartDateTime
Data Type: String
Step02: Assign value to a variable. create 'Execute SQL Task'
General:
SQL Command-> select cast(getdate() as nvarchar(100)) as StartDateTime
ResultSet-> Single Row
ByPassprepare-> True
Result set tab:
Result Name: StartDateTime
Variable Name: User::ReconcileStartDateTime
Step 03: Create Execute SQL Task and use query as below:
SqlStatement: Update OrderDetail set StartDate = cast(? as datetime) where ID= 101;
Parameter mapping: click ADD button, set variable name User::ReconcileStartDateTime; Datatype as Nvarchar; Parameter to 0
Result: When execute the SSIS package, datetime is set accordingly. SQL Profile would help to see the output.
I am trying to execute stored proc through SSIS and it gives me following error:
[Execute SQL Task] Error: Executing
the query "Exec sp1 ?" failed with
the following error: "Procedure: sp1
Line: 66 Message: Cannot insert
duplicate key row in object
'table.sq1' with unique index
'UIX_sp1_Key'.". Possible failure
reasons: Problems with the query,
"ResultSet" property not set
correctly, parameters not set
correctly, or connection not
established correctly.
Actually the stored Proc sp1 is truncating & reloading a data into a table.
I am not able to figure out where exactly its trying to insert duplicate record.
Thanks in advance.
Your data must have duplicate values across the key column(s). You could remove the primary key temporarily (or create another table with the same structure but without the definition of the primary key, but that would mean changing the stored procedure), then load the data into the table. Then use this SQL statement:
select keycol1 {,keycol2 {,keycol3} ...}, count(*)
from tablename
group by keycol1 {,keycol2 {,keycol3} ...}
having count(*) > 1
That will show you the data values that are duplicates across the key column(s).
If you are truncating the table before load, then you must have duplicate data in the source.
Examine this to see what there is. use Excel or Access or some such if needed to assist. Or drop the unique constraint then query the staging table with an aggregate query.