it seems that if I create a datetime field in llblgen, that it defaults to sql type datetime, which you would think would be OK.

BUT, EF CF must be assuming that a c# datetime is a datetime2 in the db (sql datetime's are not of sufficient precision/range so its not an unreasonable assumption), because I get errors when doing a commit, eg:

An error occurred while updating the entries. See the inner exception for details. ---> System.Data.SqlClient.SqlException: The conversion of a datetime2 data type to a datetime data type resulted in an out-of-range value.
The statement has been terminated.

and the sql for inserting (generated by EF) is:

exec sp_executesql N'INSERT [dbo].[MeetingAction]([Action], [ActionOnText], [ActionOnType], [ActionOnUserId], [Created], [DueDate], [MeetingId], [Modified], [Priority], [Status])
VALUES (@0, @1, @2, @3, @4, @5, @6, @7, @8, @9)
SELECT [Id], [Timestamp]
FROM [dbo].[MeetingAction]
WHERE @@ROWCOUNT > 0 AND [Id] = scope_identity()',N'@0 nvarchar(1000),@1 nvarchar(1000),@2 int,@3 uniqueidentifier,@4 datetime2(7),@5 datetime2(7),@6 int,@7 datetime2(7),@8 int,@9 int',@0=N'TEST-Meeting Action-2015-12-08T12:42:22-482',@1=N'action on text',@2=0,@3='4E9E435B-07DD-49F7-8E91-5E669E691733',@4='2015-12-08 12:42:22.4937708',@5='0001-01-01 00:00:00',@6=3,@7='2015-12-08 12:42:22.4937708',@8=0,@9=0

DueDate is the new field that is defined as datetime/datetime in llblgen. Created & Modified are existing fields that are defined as DateTime/datetime2. (DueDate is defined as:

@5 datetime2(7)

and the value passed as:

@5='0001-01-01 00:00:00'

Obviously I can mannually resolve this in llblgen, but the default has a mismatch vs EF6.1 CF.

I'm using lllblgen design Nov2015 EF 6.1.3 C#4.0

It indeed defaults to DateTime. This is currently unavoidable. It uses .NET -> DB type conversion definitions, which are defined in the driver. As more DB types map to DateTime it uses a sort order for preference, and DateTime is chosen first. In v4 this isn't editable. In v5 (post CTP) we have implemented a 'preferred DB type' for a typeshortcut, so you can define a type shortcut for DateTime which has as DB type 'DateTime2', so you can model the field with the custom type shortcut and it will automap the field to DateTime2 instead. Sadly that doesn't solve your problem today though.

The main issue is the null date though for DueDate. As the field isn't nullable the default value is sent (DateTime.MinValue it seems), and SQL Server's 'DateTime' type doesn't have the precision to store that nulldate (it goes back to 1750). That's causing the issue here. I think it's best to simply define it as a nullable field instead and store a null instead.

Would that suffice?

In this case it shouldnt be null (its mandatory), but it also should be validated as having a sensible value (we just hadnt implement validation yet :-) ), so we can work around it / its not a big problem

Ok Closed.