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
Related
I want to use bitemporal historization in Microsoft SQL Server as in know it from e.g. DB2 (https://www.ibm.com/docs/en/db2-for-zos/12?topic=tables-creating-bitemporal).
There we can create a table via
CREATE TABLE policy_info
(policy_id CHAR(4) NOT NULL,
coverage INT NOT NULL,
bus_start DATE NOT NULL,
bus_end DATE NOT NULL,
sys_start TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW BEGIN,
sys_end TIMESTAMP(12) NOT NULL GENERATED ALWAYS AS ROW END,
create_id TIMESTAMP(12) GENERATED ALWAYS AS TRANSACTION START ID,
PERIOD BUSINESS_TIME(bus_start, bus_end),
PERIOD SYSTEM_TIME(sys_start, sys_end));
where
SYSTEM_TIME (works in MSQL_Server) refers to technical information in database changes and logs everything in a history-table and
BUSINESS_TIME (does it exist in MSQL server?) refers to the business-reated validity of data (e.g. the lastname of Employee with Employee_ID = 4711 was "Schmidt" from 3.6.21 until 5.7.21 and "Müller" from 6.7.21 until 23.1.22).
Does Microsoft SQL-Server provide a feature analogue to the BUSINESS_TIME in DB2?
Answer from comment: There is no bitemporal historization for SQL-Server.
I have tested this:
dateCreated(sqltype: 'datetime')
and this
dateCreated column: 'DateCreated', sqltype:'datetime'
and neither of them works. I always get datetime2.
Hope it's possible to solve.
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!
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.
I am exporting data from an existing sql server 2012 table by using the ssms option database right click -> Tasks -> generate scripts. This works fine except for date columns.
Example output:
INSERT INTO Employees VALUES (1, 'Frank', ,CAST(0x16190B00 AS Date));
I Don' find a way to export date columns to a format like 2.10.2012. I can think about adding a string column and cast the date column values as a string, but this is just a work around.
Can someone help me out here?
Like Mikael said, this is a bug which will be fixed in the next major release of SQL Server