Sitecore Invalid Column Name 'Stamp' - sql-server

We have recently upgraded from Sitecore 6.5, rev. 4 to Sitecore 6.6 initial release - and finally to Sitecore 7.0, initial release.
At this point I first began getting the following error (after logging into the content editor and performing a few simple operations): Invalid object name 'EventQueue'. Upon investigating this, I discovered that our Sitecore databases were outright 'missing' this table, which I then added to each of the databases. I resumed testing and promptly discovered the missing column 'stamp' error.
My question is, at what point was this field added to the table, and what data type should it be - I'm guessing bigint, but I'd like to be sure? Also, by chance are there any other known changes to this table and/or the schema, (since it's introduction in 6.3), that I should be aware of, ahead of time?
I really, really don't want to have to back-track and try to re-run the SQL scripts for every upgrade version since Sitecore 6.3. Just the thought of that makes me sick to my stomach...

The EventQueue table has not changed from Sitecore 6.3 rev 110112 (Initial Release) to the latest version of Sitecore. You could drop and re-create the EventQueue table:
CREATE TABLE [dbo].[EventQueue](
[Id] [uniqueidentifier] NOT NULL,
[EventType] [nvarchar](256) NOT NULL,
[InstanceType] [nvarchar](256) NOT NULL,
[InstanceData] [nvarchar](max) NOT NULL,
[InstanceName] [nvarchar](128) NOT NULL,
[RaiseLocally] [int] NOT NULL,
[RaiseGlobally] [int] NOT NULL,
[UserName] [nvarchar](128) NOT NULL,
[Stamp] [timestamp] NOT NULL,
[Created] [datetime] NOT NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO
ALTER TABLE [dbo].[EventQueue] ADD CONSTRAINT [DF_EventQueue_Created] DEFAULT (getutcdate()) FOR [Created]
GO
Note that you could download the latest version of Sitecore from SDN as a zip archive and attach the empty databases to compare. Previous versions are also available for download.
But since you may have missed out on a whole bunch of other stuff, I would recommend you compare the database schema from a fresh DB using something like Redgate SQL Compare or Microsoft SQL Server Data Tools from within Visual Studio

It sounds like your upgrade wasn't successfull. I would not create these things manually. You would miss out on any indexes etc. that Sitecore might create.
The event queues was introduced in 6.3 and the event queue table should have been added then. The table was created by the following script: http://sdn.sitecore.net/upload/sdn5/products/sitecore6/updates/sitecorecms630.zip
You might just use this, but I would validate that everything in your upgrades have gone right.

Related

VS Database Project keeps skipping a table

I have a Visual Studio (2019) Database Project that skips generating a table no matter what I do, and I cannot figure out why.
Background:
I created the project by importing from a SQL database up in Azure that had an existing table structure. The database was pretty much a prototype and I was pulling it in to speed up creating the "real" database.
I then modified pretty much all of the tables in the project, applying some standard naming conventions, indexes, etc. I added seed data files as part of the Post Deployment, etc.
Then to prep for a test of clean install of the database and the test data, I drop everything in the SQL Server database.
What I tried:
First I attempted to publish the database project to my newly empty database. I "Generate Script", execute the script (from VS) only to discover that it is trying to add an index to a table that doesn't exist. I swear the Item table is there...and sure enough it is in the Project. It is set to build too. But looking at the deploy script, it does not have the Item table.
What I tried next:
Fast forward to my next attempt, ignoring hours of VS updates, build, rebuild, clean, restarts, etc. I move on the doing a schema compare from my project to the empty database, knowing that it will generate all of my create statements but not include my post-deploy files. (I decide I can hand-run them later). Compare against an empty database looks like one would expect (nothing but whitespace on the right side of the schema compare screen). I generate the update script and look at the "Preview" (excerpt below) and my Item table is there:
** Highlights
Tables that will be rebuilt
None
Clustered indexes that will be dropped
None
Clustered indexes that will be created
None
Possible data issues
None
** User actions
Create
[db_executor] (Role)
[dbo].[ApiKey] (Table)
[dbo].[AppLog] (Table)
[dbo].[AppLog].[IX_AppLog_SessionId] (Index)
[dbo].[Customer] (Table)
[dbo].[Customer].[IX_Customer_ExternalId] (Index)
[dbo].[Customer].[IX_Customer_OrganizationId] (Index)
[dbo].[Customer].[UX_Customer_Name] (Index)
[dbo].[CustomerDepartment] (Table)
[dbo].[CustomerDepartment].[IX_CustomerDepartment_DepartmentId] (Index)
[dbo].[CustomerSetting] (Table)
[dbo].[CustomerSetting].[IX_CustomerSetting_SettingId] (Index)
[dbo].[Department] (Table)
[dbo].[Department].[IX_Department_ExternalId] (Index)
[dbo].[Department].[UX_Department_Code] (Index)
[dbo].[ImageResource] (Table)
[dbo].[Item] (Table)
[dbo].[Item].[IX_Item_UPC] (Index)
<snip>
Next I look at the SQL script generated and find that my Item table is omitted again, with the index on Item coming right after the ImageResource table create:
PRINT N'Creating [dbo].[ImageResource]...';
GO
CREATE TABLE [dbo].[ImageResource] (
[ImageResourceId] INT IDENTITY (1, 1) NOT NULL,
[URL] NVARCHAR (2048) NULL,
[ContentType] NVARCHAR (128) NOT NULL,
[Width] INT NULL,
[Height] INT NULL,
[IsActive] BIT NOT NULL,
[Created] DATETIME2 (7) NOT NULL,
[CreatedBy] NVARCHAR (128) NOT NULL,
[Modified] DATETIME2 (7) NULL,
[ModifiedBy] NVARCHAR (128) NULL,
CONSTRAINT [PK_ImageResource] PRIMARY KEY CLUSTERED ([ImageResourceId] ASC)
);
GO
PRINT N'Creating [dbo].[Item].[IX_Item_UPC]...';
GO
CREATE NONCLUSTERED INDEX [IX_Item_UPC]
ON [dbo].[Item]([UPC] ASC);
Any suggestions?
EDIT1:
To add some additional information, I do see in the output script that there are a few ALTERS that point to my "skipped" tables. So VS clearly thinks that the table exists in the destination DB. Since it doesn't, I speculate that the destination database metadata must be stored / cached somewhere and that it is out of date. I have deleted the obj and bin folders. Anyone know if/where this cached destination DB metadata could be?
EDIT2:
So confusingly, if I click "Publish" instead of "Generate Script" to magically deploy the database the publish actually works, creating all of the tables. But what is extra weird is the ProjectName.publish.sql that gets generated as part of the publish is just like the one that gets created is you select "Generate Script" in that it is missing 5 out of the 25 tables. So the SQL commands that are run under-the-covers during the Publish is not the same as the ProjectName.publish.sql that is output.
Unfortunately, I need the publish SQL file to give to the DBA to run "for real", I can only do a direct VS deploy to my dev database.

How to deploy temporal tables with dacpac and SqlPackage.exe

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'

Avoid schema mismatch in System-Versioned tables

Looking for a workaround for:
Error: SQL71609: System-versioned current and history tables do not have matching schemes. Mismatched column: 'XXXX'.
When trying to use SQL 2016 System-Versioned (Temporal) tables in SSDT for Visual Studio 2015.
I've defined a basic table:
CREATE TABLE [dbo].[Example] (
[ExampleId] INT NOT NULL IDENTITY(1,1) PRIMARY KEY,
[ExampleColumn] VARCHAR(50) NOT NULL,
[SysStartTime] datetime2 GENERATED ALWAYS AS ROW START HIDDEN NOT NULL,
[SysEndTime] datetime2 GENERATED ALWAYS AS ROW END HIDDEN NOT NULL,
PERIOD FOR SYSTEM_TIME (SysStartTime,SysEndTime)
)
WITH (SYSTEM_VERSIONING=ON(HISTORY_TABLE=[history].[Example]))
GO
(Assuming the [history] schema is properly created in SSDT). This builds fine the first time.
If I later make a change:
CREATE TABLE [dbo].[Example] (
[ExampleId] INT NOT NULL IDENTITY(1,1) PRIMARY KEY,
[ExampleColumn] CHAR(50) NOT NULL, -- NOTE: Changed datatype
[SysStartTime] datetime2 GENERATED ALWAYS AS ROW START HIDDEN NOT NULL,
[SysEndTime] datetime2 GENERATED ALWAYS AS ROW END HIDDEN NOT NULL,
PERIOD FOR SYSTEM_TIME (SysStartTime,SysEndTime)
)
WITH (SYSTEM_VERSIONING=ON(HISTORY_TABLE=[history].[Example]))
GO
Then the build fails with the error message above. Any change to the data type, length, precision, or scale will result in this error. (Including changing from VARCHAR to CHAR and VARCHAR(50) to VARCHAR(51); changing NOT NULL to NULL does not produce the error.) Doing a Clean does not fix things.
My current workaround is to make sure I have the latest version checked in to source control, then open the SQL Server Object Explorer, expand the Projects - XXXX folder and navigate to the affected table, then delete it. Then I have to restore the code (which SSDT deletes) from source control. This procedure is tedious, dangerous, and not what I want to be doing.
Has anyone found a way to fix this? Is it a bug?
I'm using Microsoft Visual Studio Professional 2015, Version 14.0.25431.01 Update 3 with SQL Server Data Tools 14.0.61021.0.
I can reproduce this problem. We (the SQL Server tools team) will work to get this fixed in a future version of SSDT. In the meantime, I believe you can work around this by explicitly defining the history table (i.e. add the history table with its desired schema to the project), and then manually keep the schema of the current and history table in sync.
If you encounter problems with explicitly defining the history table, try closing Visual Studio, deleting the DBMDL file in the project root, and then re-opening the project.
We just experienced this issue. We found a workaround by commenting out the system versioning elements of the table (effectively making it a normal table), building the project with the schema change we needed (which succeeds), and then putting the system versioning lines back in place (which also succeeds).
Just in case someone faced the same issue:
The fix is to go to [YourDatabaseProject]/bin/Debug folder and clear it and then build without removing anything.
Hope this helps!

Sql Server ODBC Date Field - Optional feature not implemented

I have a SQL Server table which has fields of type Date in it. I am trying to update or insert a record into the table via Micosoft Access using ODBC. I get the error:
[ODBC SQL Server Driver]Optional feature not implemented
when I try and update or insert a record.
I have to use Date fields not DateTime fields in my table because I am using very old dates going back 2000 years.
Is there any way round this problem, which I assume is caused by the Date fields?
This is what the table looks like
CREATE TABLE [dbo].[Person](
[PersonId] [int] IDENTITY(1,1) NOT NULL,
[DOB] [date] NOT NULL,
[DOD] [date] NULL DEFAULT (NULL),
[Name] [nvarchar](100) NOT NULL)
You best bet is to dump the use of the "legacy" sql driver, and user the newer native 10 or 11 driver. The older driver will view date fields as text, but using the newer native 10/11 driver will see the column as a date column. This will require you to re-link your tables.
If you can't change your SQL Server version, an easier solution is to pass the date as an adVarChar, and then do a CAST(#param AS DATE) in your SQL stored procedure.
I've experienced the same problem today.
I use MsAccess 2010 for developlemt, and have MsSql2012 at back-end.
There was no problem on my computer,
but other clients that use the accde runtime version has experienced this trouble.
After several trials;
Issue resolved when replacing DATE type with SMALLDATETIME. please try this..?
Indeed I only needed the date part, not the time, but ok anyway!
[DOB] [date] NOT NULL,
[DOD] [date] NULL DEFAULT (NULL),
Hope this helps to you as well

How to script non-default collation and skip explicit scripting for default collation?

In SSMS 2008 R2, I created a table:
aTest(Albnian varchar(10), Dflt varchar(10))
In SSMS table designer, both columns have the collation: "<database default>" (under "Column Properties" → "Table Designer")
I changed the collation of the column "Albnian" to a non-default, for example, Albanian_CI_AS.
If I script the table in SSMS (right click on "aTest" → "Script Tables as" → "CREATE To" → "New Query Editor Window", I get [1] with no explicit collations scripted at all.
Bad.
Obviously, one would expect the table to be scripted with explicit collation for non-default collation (the one that the developer intentionally introduced with a specific purpose) and no collation for default collation.
In SSMS menu → Tools → Options → SQL Server Object Explorer → Scripting, I changed:
Include collation: True
Script defaults: False
but now, I am getting all column collations scripted, both default and non-default ones [2].
How can I configure script generation to script non-default collation and skip the default ones, as in [3]?
[1] Default scripting of table:
CREATE TABLE [dbo].[aTest]
(
[Albnian] [varchar](10) NOT NULL,
[Dflt] [varchar](10) NOT NULL
) ON [PRIMARY]
[2] Table script after "Include collation" changed to True
CREATE TABLE [dbo].[aTest]
(
[Albnian] [varchar](10) COLLATE Albanian_CI_AS NOT NULL,
[Dflt] [varchar](10) COLLATE Cyrillic_General_CI_AS NOT NULL
) ON [PRIMARY]
[3] Needed collation script generation behavior:
CREATE TABLE [dbo].[aTest]
(
[Albnian] [varchar](10) COLLATE Albanian_CI_AS NOT NULL,
--non-default should be scripted
[Dflt] [varchar](10) NOT NULL
-- default database collation should not be scripted
) ON [PRIMARY]
Related question:
What issues to anticipate having different collations between development and production SQL Servers?
I submitted a suggestion through MS Connect:
Collations are scripted either for all columns or for none
Here's the related response:
Posted by Microsoft on 11/11/2010 at 10:16 AM
Hi Gennady:
Thanks for writing in to Microsoft. We greatly value your feedback. We understand your problem, and how fixing this could improve productivity.
However, given the work that would be involved in implementing this work, and our set of deliverables, we do not think, we would be able to get to this in the near future.
Having said that, we value your suggestions, and would like to assure you that, we would keep these ideas in mind, when we do revisit this feature in the future.
Thanks again for providing feedback and making SQL Server the greatest Database server.
Regards
Chandramouli

Resources