|
Then I'm going to guess it is the date-format; if Sql Server has a different one than your system, switching days and months might lead to an out-of-range for the month-part.
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
Any luck yet? If no, I'll try to recreate the problem here 
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
So a datetime, not a datetime2?
SQL's datetime type can't handle dates earlier than 1753/01/01, whereas the default value for .NET's DateTime type is 0001/01/01.
It sounds like Linq to SQL is passing in .NET's default value to the SQL query, which is then failing to convert it to a datetime.
If possible, try changing the column type to datetime2. Otherwise, you'll need to provide a default value which is within the range of SQL's datetime type.
datetime (Transact-SQL) - SQL Server | Microsoft Docs[^]
datetime2 (Transact-SQL) - SQL Server | Microsoft Docs[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
It's a DateTime.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
So you'll need to specify a default which is in range for the SQL type. Eg:
ModifiedDT = u.ModifiedDT.GetValueOrDefault(System.Data.SqlTypes.SqlDateTime.MinValue.Value)
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
That worked. Thanks!
Interesting though, you would think that in a Linq To SQL statement that the default for that would be SqlDateTime.MinValue.Value.
Also, any reason to use this syntax over
ModifiedDT = u.ModifiedDT.Value
Seems like they're both doing the same thing and it's less verbose.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
.Value will throw an exception if it's null, whereas .GetValueOrDefault() will return the default value instead.
I think it would be odd if .GetValueOrDefault() returned different values depending on whether it was executed by Linq to Objects or Linq to SQL.
You could always use the null-coalescing operator instead:
ModifiedDT = u.ModifiedDT ?? System.Data.SqlTypes.SqlDateTime.MinValue.Value
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
One thing I was just thinking.. I'd rather have this be null than min value, so that I can tell if it's been set
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Which is even simpler.
ModifiedDT = u.ModifiedDT
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Ya I guess this is all for nothing
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
I'm curious how you guys do exception handling in your DAL.
My Apps are usually structured like this... The Client (this case a WPF app) calls the BL, which then calls the DAL:
WPF App
private async void AddUser()
{
UserEntity user = new UserEntity
{
FirstName = "Jack",
LastName = "Stone",
UserName = "jstone",
Password = ""
};
await Task.Factory.StartNew(() =>
{
IBizObj bo = new BizObj(connString);
bo.AddUser(user);
}).ContinueWith(task =>
{
UserList.Add(user);
});
}
Bis Layer
public class BizObj : IBizObj
{
IRepository _repoisitory;
<pre>
public BizObj(string connectionString)
{
_repoisitory = new FalconRepository(connectionString);
}
public int AddUser(UserEntity entity)
{
return _repoisitory.AddUser(entity);
}
}
DAL
public int AddUser(UserEntity entity)
{
using (var dc = GetDataContext())
{
int results = 0;
try
{
User user = new User
{
FirstName = entity.FirstName,
LastName = entity.LastName,
UserName = entity.UserName,
Password = entity.Password,
CanLogIn = entity.CanLogIn,
PasswordChangeDate = entity.PasswordChangeDate,
CreatedByUserId = 1,
CreatedDT = DateTime.Now,
};
dc.Users.InsertOnSubmit(user);
dc.SubmitChanges();
results = user.Id;
}
catch (Exception e)
{
}
return results;
}
}
So, the question is wwhat is the correct way to handle the exception on the DAL? Would you handle the exception in the UI, the DAL, both?
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
The general rule of thumb is that you should only handle exceptions at the point that you can actually do anything with them. In your example, for instance, what good does it do handling the exception in the DAL? What are you going to do with it? Are you going to log that there was an exception and then return a value of 0 to indicate that the request failed for some reason? In that case, you're going to have to have something in your business layer that knows that a result of 0 means that there was an exception internally. In which case, why did you bother handling it in the DAL at all?
|
|
|
|
|
I'd handle it in the DAL, log it in the DAL log with as much detail as possible, and then throw a new exception with the current exception as the inner exception. The BL can handle it or not as it choses, but since there may be multiple DAL layers, it's important (to me at least) to log it correctly for later analysis - and that means as early as possible before you lose potentially useful info, or debug opportunities.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
If my Try/Catch caught a "File Not Found" exception, the user could probably fix that - ensure the file is there.
But for something like this, an exception when adding a user, what can the user do?? Nothing really. Most likely, the exception is something beyond the ability of the user to fix.
So, again, aside from logging, what "handling" should take place? And where?
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
That's up to the BL and / or PL - the DAL can't do anything about telling the user, so logging it is all it can and should do. Passing the exception up gives the higher levels a chance to report / recover / ignore the error.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
Sorry, I'd have to disagree with you on this one. If you catch and log the exception in the DAL, then let this bubble up to be caught and logged again (this time as an inner exception), you're polluting your exception logs. Effectively you are double logging this exception. If the logging engine uses structured logging (and most do nowadays), then navigating to the DAL log and extracting useful information from it is straightforward. More importantly, you avoid a double exception penalty which could be costly in terms of performance.
|
|
|
|
|
What's the "user" doing while his "user record" is being added "asynchronously" and there is an error in the DAL?
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
That's the point of my question. I don't want to block the UI, but I also want to handle the exception.
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
Don't make it async then.
Every "transaction" should return a "return code" to the "caller"; the ui in this case.
Make a "synchronous" call with say a 5 sec. timeout. A timeout is a "no server response".
Don't leave the user hanging; you need to tell them success or failure.
In any event, if it's not a duplicate, etc. it's a "system error" and needs to be escalated.
"Graceful degeneration". If the user CANNOT proceed, these is nothing "graceful" you can do except inform the user.
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
ContinueWith doesn't really belong in an async method.
private async void AddUser()
{
UserEntity user = new UserEntity
{
FirstName = "Jack",
LastName = "Stone",
UserName = "jstone",
Password = ""
};
await Task.Run(() =>
{
IBizObj bo = new BizObj(connString);
bo.AddUser(user);
});
UserList.Add(user);
} Also, you should try to avoid async void methods wherever possible.
Avoid async void methods | You’ve Been Haacked[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
So the method doesn't need to return anything, and I'd like the UI to remain resonsive until the server trip is finished. What's the right approach here?
If it's not broken, fix it until it is.
Everything makes sense in someone's mind.
Ya can't fix stupid.
|
|
|
|
|
The code I posted will push the IBizObj onto a background thread. When it completes, the method will result on the UI thread to run the UserList.Add code. There's no need to use ContinueWith here.
Ideally, your method should return a Task. If you want it to be a "fire and forget" call, assign the returned task to a discard variable:
_ = AddUser(); That way, any unhandled exceptions will raise the TaskScheduler.UnobservedTaskException[^] event.
With an async void method, any unhandled exceptions could bring down the entire process.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
I have this setup of a list containing dates and strings:
var d0 = new DateTime(2019, 10, 20);
var d1 = new DateTime(2018, 10, 20);
var d2 = new DateTime(2019, 10, 21);
var d3 = new DateTime(2019, 10, 20);
var d4 = new DateTime(2017, 10, 21);
var d5 = new DateTime(2013, 10, 22);
var d6 = new DateTime(2015, 10, 21);
var d7 = new DateTime(2010, 10, 23);
var d8 = new DateTime(1995, 10, 20);
var d9 = new DateTime(2019, 10, 22);
var list = new List<(DateTime Date, string Name)>();
list.Add((d0, "D0"));
list.Add((d1, "D1"));
list.Add((d2, "D2"));
list.Add((d3, "D3"));
list.Add((d4, "D4"));
list.Add((d5, "D5"));
list.Add((d6, "D6"));
list.Add((d7, "D7"));
list.Add((d8, "D8"));
list.Add((d9, "D9")); I want to use LINQ to transform the list in the following order:
(2019-10-20, "D0")
(2018-10-20, "D1")
(2019-10-20, "D3")
(1995-10-20, "D8")
(2019-10-21, "D2")
(2017-10-21, "D4")
(2015-10-21, "D6")
(2013-10-22, "D5")
(2019-10-22, "D9")
(2010-10-23, "D7") Notice the month and day decides the order, not the year.
I have tried to mess around with LINQ's GroupBy() method, but cannot understand how to group dates where months and days are equal.
Also there is a sorting rule:
Notice the "D0"-item comes before the "D1"-item, even if the "D1"-item has year set to 2018 and the "D0"-item has year set to 2019.
|
|
|
|
|
You're not grouping the list; you're sorting it.
With LINQ:
var sortedSequence = list
.OrderBy(p => p.Date.Month)
.ThenBy(p => p.Date.Day)
.ThenBy(p => p.Name); With a custom comparer:
public class MonthDayNameComparer : IComparer<(DateTime date, string name)>
{
public int Compare((DateTime date, string name) left, (DateTime date, string name) right)
{
int result = left.date.Month.CompareTo(right.date.Month);
if (result == 0) result = left.date.Day.CompareTo(right.date.Day);
if (result == 0) result = StringComparer.Ordinal.Compare(left.name, right.name);
return result;
}
}
...
list.Sort(new MonthDayNameComparer());
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Thank you!
The LINQ example worked just fine!
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
