I have two datetime pickers on my form. I want a function that will return all datetimes from a specific table (which are values of a specific column) between those two dates.
My method looks like this:
public DateTime[] GetAllArchiveDates(string username = null)
{
var result = new DateTime[0];
if (username != null)
{
result = this._context.archive.OrderBy(s => s.IssuingDate).Where(s => s.insertedBy == username).Select(s => s.issuing_date).Distinct().ToArray();
}
else
{
result = this._context.archive.OrderBy(s => s.IssuingDate).Select(s => s.issuing_date).Distinct().ToArray();
}
return result;
}
But I am getting this error:
System.NotSupportedException: 'The specified type member 'IssuingDate' is not supported in LINQ to Entities. Only initializers, entity members, and entity navigation properties are supported.'
How to do this?
The cause of your error message
You should be aware about the differences between IEnumerable and IQueryable.
An object of a class that implements IEnumerable holds everything to enumerate over the sequence of items it represents. You can ask for the first item of the sequence, and once you've got one, you can ask for the next item, until there are no more items.
On the other hand, an object of a class that implements IQueryable holds everything to ask another process to provide data to create an IEnumerable sequence. To do this, it holds an Expression and a Provider.
The Expression is a generic representation of what kind of IEnumerable must be created once you start enumerating the IQueryable.
The Provider knows who must execute the query, and it knows how to translate the Expression into a format that the executor understands, for instance SQL.
There are two kinds of LINQ statements. Those that use deferred execution, and those that don't. The deferred functions can be recognized, because they return IQueryable<TResult> (or IEnumerable). Examples are Where, Select, GroupBy, etc.
The non-deferred functions return a TResult: ToList, ToDictionary, FirstOrDefault, Max.
As long as you concatenate deferred LINQ functions, the query is not executed, only the Expression is changed. Once you start enumerating, either explicitly using GetEnumerator and MoveNext, or implicitly using foreach, ToList, Max, etc, the Expression is sent to the Provider who will translate it to SQL and execute the query. The result is represented as an IEnumerable, on which the GetEnumerator is performed.
What has this to do with my question?
Because the Expression must be translated into SQL, it can't hold anything that you invented. After all, SQL doesn't know your functions. In fact, there are a lot of standard functions that can't be used in an IQueryable. See Supported and unsupported LINQ functions
Alas you forgot to give us the archive class definition, but I think that it is not a POCO: It contains functions and properties that do more than just get / set. I think that IssuingDate is not just get / set.
For IQueryables you should keep your classes simple: use only {get; set;} during your query, nothing more. Other functions can be called after you've materialized your IQueryable into something IEnumerable which is to be executed within your local process
Back to your question
So you have a database with a table Archive with at least columns IssuingDate and InsertedBy. It seems that InsertedBy is just a string. It could be a foreign key to a table with users. This won't influence the answer very much.
Following the entity framework code first conventions this leads to the following classes
class Archive
{
public int Id {get; set;}
public DateTime IssuingDate {get; set;}
public string InsertedBy {get; set;}
...
}
public class MyDbContext : DbContext
{
public DbSet<Archive> Archives {get; set;}
}
By the way, is there a proper reason you deviate so often from Microsoft standards about naming identifiers, especially pluralization and camel casing?
Anyway, your requirement
I have two datetime pickers on my form. I want a function that will return all datetimes from a specific table (which are values of a specific column) between those two dates.
Your code seems to do a lot more, but let's first write an extension function that meets your requirement. I'll write it as an extension method of your archive class. This will keep your archive class simple (only {get; set;}), yet it adds functionality to the class. Writing it as an extension function also enables you to use these functions as if they were any other LINQ function. See Extension methods demystified
public static IQueryable<Archive> BetweenDates(this IQueryable<Archive> archives,
DateTime startDate,
DateTime endDate)
{
return archives.Where(archive => startDate <= archive.IssuingDate
&& archive.IssuingDate <= endDate);
}
If I look at your code, you don't do anything of selecting archives between dates. You do something with a userName, ordering, select distinct... It is a bit strange that you first Order all your million archives, and then decide to keep only the ten archives that belong to userName, and if you have several same issuing dates you decide to remove the duplicates. Wouldn't it be more efficient to first limit the number of issuing dates before you start ordering them?
public static IQueryable<archive> ToIssuingDatesOfUser(this IQueryable<archive> archives,
string userName)
{
// first limit the number of archives, depdning on userName,
// then select the IssuingDate, remove duplicates, and finally Order
var archivesOfUser = (userName == null) ? archives :
archives.Where(archive => archive.InsertedBy == userName);
return archivesOfUser.Select(archive => archive.IssuingDate)
.Distinct()
.OrderBy(issuingDate => issuingDate);
}
Note: until now, I only created IQueryables. So only the Expression is changed, which is fairly efficient. The database is not communicated yet.
Example of usage:
Requirement: given a userName, a startDate and an endDate, give me the unique issuingDates of all archives that are issued by this user, in ascending order
public ICollection<string> GetIssuingDatesOfUserBetweenDates(string userName,
DateTime startDate,
DateTime endDate)
{
using (var dbContext = new MyDbContext(...))
{
return dbContext.Archives
.BetweenDates(startDate, endDate)
.ToIssuingDatesOfUser(userName)
.ToList();
}
}
In a previous question I presented these models:
public class Calendar
{
public int ID { get; set; }
public ICollection<Day> Days { get; set; }
}
public class Day
{
public int ID { get; set; }
public DateTime Date { get; set; }
public int CalendarID { get; set; }
}
There is a uniqueness constraint so that you can't have more than one Day with the same Date and CalendarID.
My question now is what if I want to move all days one day into the future (or whatever). The easiest code is just a for loop like
for(Day day in days) {
day.Date = day.Date.AddDays(1);
db.Entry(day).State = EntityState.Modified;
}
await db.SaveChangesAsync();
This will fail, however, because it thinks you are creating duplicates of some of the dates, even though once they're all updated it will work out.
Calling SaveChangesAsync after each day (assuming you process the days in the correct order) would work, but seems massively inefficient for this basic task.
An alternative to updating the Date would be to transfer all the other data of each day to the next one, but this also seems inefficient and could in some cases be undesirable because it means that data is dissociated from the Day's primary key value.
Is there a way to update all the dates while keeping the uniqueness constraint?
The number of SQL UPDATE statements won't change if you call SaveChanges() for each record instead of calling it only once, but at least you'll get the correct order. There's some overhead because of state cleaning and connection management but it's not massively inefficient.
If date shifting is an isolated business transaction you could use a simpler solution instead of fighting with ORM - call a stored procedure or execute SQL directly with something similar to:
var sql = "UPDATE d SET Date = DATEADD(d, 1, Date) FROM (SELECT * FROM Day WHERE CalendarID=#calendarId ORDER BY Date DESC) d";
var updateCnt = db.Database.ExecuteSqlCommand(sql, new SqlParameter("#calendarId", calendar.Id);
if (updateCnt != days.Count)
{
//oops
}
One of the many possible solutions is removing all the records before you do the update.
You can first get your days, store them in memory.
var days = db.Day.Tolist();
Truncate the table, so they won't collide with the new list coming:
db.ExecuteCommand("TRUNCATE TABLE Day");
Do your stuff:
foreach(var day in days)
{
day.Date=day.Date.AddDays(1);
}
Insert your new list.
Now you should be able to save it:
db.SaveChanges();
This should be efficient enough since the quickest way to wipe data is to truncate, and your day objects are child objects.
HOWEVER
If a property is changing a lot, probably it's not a good idea to make it a primary key.
If you find yourself in a conflict with fundamentals, it's quite possible that you made an architectural mistake.
I strongly recommend you to change your primary key to something else, you can even roll a uniqueidentifier column to store Id.
I'm using entity framework to setup a table using fluent-api configuration:
Property(g => g.DateTime).IsRequired().HasColumnType("datetime2").HasPrecision(0);
The table does indeed get created successfully:
CREATE TABLE [dbo].[Foo] (
[DateTime] DATETIME2 (0) NOT NULL,
);
The precision of the datetime2 column has been set to 0 as you can see. I thus expect the retrieved date-time values to not include milliseconds at all, aka dates should look like '13 March 2016 18:35:37.0000'. However the retrieved dates always include milliseconds. Here's the code I'm using:
var dbcontext = new ApplicationDbContext(); //foo table is empty
dbcontext.Foo.Add(new Entry { DateTime = DateTime.Now });
dbcontext.SaveChanges();
var date = dbcontext.Foo.First().DateTime; //this should be identical to DateTime.Now above except for milliseconds which should be set to zero right?
How can I achieve the desired effect without resorting to zeroing-out milliseconds manually (via C# code either before insertion or after retrieval)?
If you need just date and time without any milliseconds, use smalldatetime MS SQL type instead. It has accuracy of 1 seconds.
If for some reason you want to have datetime2 in the database, there's no automatic way you can achieve desired behavior. You can create a (calculated) property MyDateTimeWithoutMs that get and set the correct value for the database connected property.
internal DateTime databaseDateTime { get; set; }
public DateTime MyDateTimeWithoutMs
{
get
{
return databaseDateTime.DateTimeWithoutMs();
}
set
{
databaseDateTime= value.ToDateTimeWithoutMs();
}
}
In your model mapping add ignore for calculated property and map the database property to the actual column name.
public class EntryMap : EntityTypeConfiguration<Entry >
{
public Entry Map()
{
Property(t => t.databaseDateTime)
.HasColumnName("DateTime");
Ignore(t => t.MyDateTimeWithoutMs );
Hats off to #JonSkeet who tipped me off as to what was amiss. Turns out that the first dbcontext I instantiated had some sort of caching going on which in turn was causing the date-time value provided to be returned as-is with its milliseconds component intact (go figure ...). One way to go about this, in order to get the desired behavior is to re-instantiate a db-context and start on a tabula-rasa basis to guarantee that no cached values will be return on datetime:
var dbcontext = new ApplicationDbContext(); //foo table is empty
dbcontext.Foo.Add(new Entry { DateTime = DateTime.Now });
dbcontext.SaveChanges();
var dbcon2 = new ApplicationDbContext(); //vital
var date = dbcon2.Foo.First().DateTime;
Alternatively you may use .Entry().Reload() which has the benefit that it doesn't need a new db-context to be instantiated:
var dbcontext = new ApplicationDbContext(); //foo table is empty
var entry = new Entry { DateTime = DateTime.Now };
dbcontext.Foo.Add();
dbcontext.SaveChanges();
dbcontext.Entry(entry).Reload(); //doesnt suffer from the quirks of dbcontext.Gigs.First()
P.S.: Last but not least if you are using this code in a unit-test project make sure to rebuild the project before giving it a go (at least that's what I had to do to make things work in my project)
I've got a datatable with 5 columns, where a row is being filled with data then saved to the database via a transaction.
While saving, an error is returned:
The conversion of a datetime2 data type to a datetime data type resulted in an out-of-range value
It implies, as read, that my datatable has a type of DateTime2 and my database a DateTime; that is wrong.
The date column is set to a DateTime like this:
new DataColumn("myDate", Type.GetType("System.DateTime"))
Question
Can this be solved in code or does something have to be changed on a database level?
Short Answer
This can happen if you do not initialize a value to a DateTime field; the field does not accept NULL values, and it's a value type, so the default value of the non-nullable DateTime type will be used.
Setting the value fixed it for me!
Long Answer
The value of default(DateTime) is DateTime.MinValue (or new DateTime(1, 1, 1) or 01/01/0001), which is not a valid SQL datetime value.
The lowest valid value for SQL Server datetime is 01/01/1753 due to its use of a Gregorian calendar. SQL Server DateTime2 however supports dates starting at 01/01/0001. Entity Framework by default uses DateTime2 for representing dates, so the generated SQL is implicitly coercing the generated DateTime2 value to a DateTime value on the SQL Server-side.
Both the DATETIME and DATETIME2 map to System.DateTime in .NET - you cannot really do a "conversion", since it's really the same .NET type.
See the MSDN doc page: http://msdn.microsoft.com/en-us/library/bb675168.aspx
There are two different values for the "SqlDbType" for these two - can you specify those in your DataColumn definition?
BUT: on SQL Server, the date range supported is quite different.
DATETIME supports 1753/1/1 to "eternity" (9999/12/31), while DATETIME2 supports 0001/1/1 through eternity.
So what you really need to do is check for the year of the date - if it's before 1753, you need to change it to something AFTER 1753 in order for the DATETIME column in SQL Server to handle it.
Marc
In my SQL Server 2008 database, I had a DateTime column flagged as not nullable, but with a GetDate() function as its default value. When inserting new object using EF4, I got this error because I wasn't passing a DateTime property on my object explicitly. I expected the SQL function to handle the date for me but it did not. My solution was to send the date value from code instead of relying on the database to generate it.
obj.DateProperty = DateTime.now; // C#
for me it was because the datetime was..
01/01/0001 00:00:00
in this case you want to assign null to you EF DateTime Object... using my FirstYearRegistered code as an example
DateTime FirstYearRegistered = Convert.ToDateTime(Collection["FirstYearRegistered"]);
if (FirstYearRegistered != DateTime.MinValue)
{
vehicleData.DateFirstReg = FirstYearRegistered;
}
This one was driving me crazy. I wanted to avoid using a nullable date time (DateTime?). I didn't have the option of using SQL Server 2008's datetime2 type either
modelBuilder.Entity<MyEntity>().Property(e => e.MyDateColumn).HasColumnType("datetime2");
I eventually opted for the following:
public class MyDb : DbContext
{
public override int SaveChanges()
{
UpdateDates();
return base.SaveChanges();
}
private void UpdateDates()
{
foreach (var change in ChangeTracker.Entries<MyEntityBaseClass>())
{
var values = change.CurrentValues;
foreach (var name in values.PropertyNames)
{
var value = values[name];
if (value is DateTime)
{
var date = (DateTime)value;
if (date < SqlDateTime.MinValue.Value)
{
values[name] = SqlDateTime.MinValue.Value;
}
else if (date > SqlDateTime.MaxValue.Value)
{
values[name] = SqlDateTime.MaxValue.Value;
}
}
}
}
}
}
Sometimes EF does not know that is dealing with a computed column or a trigger. By design, those operations will set a value outside of EF after an insert.
The fix is to specify Computed in EF's edmx for that column in the StoreGeneratedPattern property.
For me it was when the column had a trigger which inserted the current date and time, see below in the third section.
Steps To Resolve
In Visual Studio open the Model Browser page then Model then Entity Types -> then
Select the entity and the date time property
Select StoreGeneratedPattern
Set to Computed
For this situation other answers are workarounds, for the purpose of the column is to have a time/date specified when the record was created, and that is SQL's job to execute a trigger to add the correct time. Such as this SQL trigger:
DEFAULT (GETDATE()) FOR [DateCreated].
I ran into this and added the following to my datetime property:
[Column(TypeName = "datetime2")]
public DateTime? NullableDateTimePropUtc { get; set; }
If we dont pass a date time to date time field the default date {1/1/0001 12:00:00 AM} will be passed.
But this date is not compatible with entity frame work so it will throw
conversion of a datetime2 data type to a datetime data type resulted in an out-of-range value
Just default DateTime.now to the date field if you are not passing any date .
movie.DateAdded = System.DateTime.Now
The easiest thing would be to change your database to use datetime2 instead of datetime. The compatibility works nicely, and you won't get your errors.
You'll still want to do a bunch of testing...
The error is probably because you're trying to set a date to year 0 or something - but it all depends on where you have control to change stuff.
I found this post trying to figure why I kept getting the following error which is explained by the other answers.
The conversion of a datetime2 data type to a datetime data type resulted in an out-of-range value.
Use a nullable DateTime object.
public DateTime? PurchaseDate { get; set; }
If you are using entity framework
Set the nullable property in the edmx file to True
As andyuk has already pointed-out, this can happen when a NULL value is assigned to a non nullable DateTime field. Consider changing DateTime to DateTime? or Nullable<DateTime>. Bear in mind that, in case you are using a Dependency Property, should also make sure that your dependency property's type is also a nullable DateTime type.
Below is a real life example of an incomplete DateTime to DateTime? type adjustment that raises the odd behaviour
The Entity Framework 4 works with the datetime2 data type so in db the corresponding field must be datetime2 for SQL Server 2008.
To achive the solution there are two ways.
To use the datetime data type in Entity Framwork 4 you have to switch the ProviderManifestToken in the edmx-file to "2005".
If you set corresponding field as Allow Null (it converts it to NULLABLE) so then EF automatically uses date objects as datetime.
Add the below mentioned attribute on the property in your model class.
Attribute = [DatabaseGenerated(DatabaseGeneratedOption.Computed)]
Reference = System.ComponentModel.DataAnnotations.Schema
Initially I forgot to add this attribute. So in my database the constraint was created like
ALTER TABLE [dbo].[TableName] ADD DEFAULT (getdate()) FOR [ColumnName]
and I added this attribute and updated my db then it got changed into
ALTER TABLE [dbo].[TableName] ADD CONSTRAINT [DF_dbo.TableName_ColumnName] DEFAULT (getdate()) FOR [ColumnName]
Created a base class based on #sky-dev implementation. So this can be easily applied to multiple contexts, and entities.
public abstract class BaseDbContext<TEntity> : DbContext where TEntity : class
{
public BaseDbContext(string connectionString)
: base(connectionString)
{
}
public override int SaveChanges()
{
UpdateDates();
return base.SaveChanges();
}
private void UpdateDates()
{
foreach (var change in ChangeTracker.Entries<TEntity>())
{
var values = change.CurrentValues;
foreach (var name in values.PropertyNames)
{
var value = values[name];
if (value is DateTime)
{
var date = (DateTime)value;
if (date < SqlDateTime.MinValue.Value)
{
values[name] = SqlDateTime.MinValue.Value;
}
else if (date > SqlDateTime.MaxValue.Value)
{
values[name] = SqlDateTime.MaxValue.Value;
}
}
}
}
}
}
Usage:
public class MyContext: BaseDbContext<MyEntities>
{
/// <summary>
/// Initializes a new instance of the <see cref="MyContext"/> class.
/// </summary>
public MyContext()
: base("name=MyConnectionString")
{
}
/// <summary>
/// Initializes a new instance of the <see cref="MyContext"/> class.
/// </summary>
/// <param name="connectionString">The connection string.</param>
public MyContext(string connectionString)
: base(connectionString)
{
}
//DBcontext class body here (methods, overrides, etc.)
}
I ran into this issue on a simple console app project and my quick solution is to convert any possible datetime2 dates to a nullable datetime by running this method:
static DateTime? ParseDateTime2(DateTime? date)
{
if (date == null || date.ToString() == "1/1/0001 12:00:00 AM")
{
return null;
}
else
{
return date;
}
}
This is certainly not a completely comprehensive method, but it worked for my needs and maybe it'll help others!
In my case, when a NULL value is explicitly assigned for Nullable DateTime column and then you try to save the changes. This error will pop up.
In my case we were casting a Date to a Datetime and we got this error.
What happens is that Date has a "more programmer oriented" minimum of 01/01/0001, while Datetime is stuck at 1753
Combine that with a data collection error on our part, and you get your exception!
Sometimes it works fine on development machines and not in servers. In my case I had to put :
<globalization uiCulture="es" culture="es-CO" />
In the web.config file.
The timezone in the machine (Server) was right (to the CO locale) but the web app did not. This setting done and it worked fine again.
Off course, all dates had value.
:D
Adding this code to a class in ASP.NET worked fort me:
protected override void OnModelCreating(DbModelBuilder modelBuilder)
{
modelBuilder.Properties<DateTime>().Configure(c => c.HasColumnType("datetime2"));
}
I'm aware of this problem and you all should be too:
https://en.wikipedia.org/wiki/Year_2038_problem
In SQL a new field type was created to avoid this problem (datetime2).
This 'Date' field type has the same range values as a DateTime .Net class. It will solve all your problems, so I think the best way of solving it is changing your database column type (it won't affect your table data).
Check out the following two:
1) This field has no NULL value. For example:
public DateTime MyDate { get; set; }
Replace to:
public DateTime MyDate { get; set; }=DateTime.Now;
2) New the database again. For example:
db=new MyDb();
Problem with inherited datetime attribute
This error message is often showed when a non-nullable date field has value null at insert/update time. One cause can be inheritance.
If your date is inherit from a base-class and you don't make a mapping EF will not read it's value.
For more information:
https://weblogs.asp.net/manavi/inheritance-mapping-strategies-with-entity-framework-code-first-ctp5-part-3-table-per-concrete-type-tpc-and-choosing-strategy-guidelines
I saw this error when I wanted to edit a page usnig ASP.Net MVC. I had no problem while Creating but Updating Database made my DateCreated property out of range!
When you don't want your DateTime Property be Nullable and do not want to check if its value is in the sql DateTime range (and #Html.HiddenFor doesn't help!), simply add a static DateTime field inside related class (Controller) and give it the value when GET is operating then use it when POST is doing it's job:
public class PagesController : Controller
{
static DateTime dateTimeField;
UnitOfWork db = new UnitOfWork();
// GET:
public ActionResult Edit(int? id)
{
Page page = db.pageRepository.GetById(id);
dateTimeField = page.DateCreated;
return View(page);
}
// POST:
[HttpPost]
[ValidateAntiForgeryToken]
public ActionResult Edit(Page page)
{
page.DateCreated = dateTimeField;
db.pageRepository.Update(page);
db.Save();
return RedirectToAction("Index");
}
}
Check the req format in DB. eg my DB have Default value or Binding (((1)/(1))/(1900))
System.DateTime MyDate = new System.DateTime( 1900 ,1, 1);
For me I have had a Devexpress DateEdit component, which was binded to nullable datetime MSSQL column thru the Nullable model property. All I had to do was setting AllowNullInput = True on DateEdit. Having it "Default" caused that the date 1.1.0001 appeared - ONLY BEFORE leaving the DateEdit - and then I got this conversion error message because of subsequent instructions mentioned above.
you will have date column which was set to lesathan the min value of allowed dattime like 1/1/1001.
to overcome this issue you can set the proper datetime value to ur property adn also set another magical property like IsSpecified=true.
For Code First Context:
Go from this
public DateTime Created { get; set; }
To this. Add the [DatabaseGenerated(DatabaseGeneratedOption.Computed)] attribute.
[DatabaseGenerated(DatabaseGeneratedOption.Computed)]
public DateTime Created { get; set; }
in your model.
Be sure to add this to the top as well
using System.ComponentModel.DataAnnotations.Schema;