Master Chief:Microsoft
SQL Server 2005 - 9.00.5000.00 (Intel X86) Dec 10 2010 10:56:29
Copyright (c) 1988-2005 Microsoft Corporation Express Edition on
Windows NT 6.0 (Build 6002: Service Pack 2)
Da Du ja sowieso die kostenlose Express Edition von SQL-Server 2005 einsetzt, wäre es keine Option gleich auf SQL-Server 2008 oder 2012 (Express) zu wechseln?
Master Chief:Tools ist eine statische Klasse von mir. Und die Methode ConvertToDate, macht nichts anderes, als der Input zu einem DateTime zu konvertieren. Dies gibt mir die Sicherheit, dass auch wirklich immer ein DateTime gesetzt wird.
public static DateTime ConvertToDate(object o)
{
try
{
return DateTime.Parse(o.ToString());
}
catch (Exception)
{
// Könnte vlt hier das Problem liegen?
return new DateTime();
}
}
Keine Ahnung ob das die Ursache sein kann, jedenfalls würde ich das nicht so machen.
Birthday = Tools.ConvertToDate(data["Birthday"])Was ist
data für ein Typ? Vermutlich ist
data["Birthday"] sowieso schon ein DateTime Objekt. Du brauchst es dann also bloss dazu zu casten
Birthday = (DateTime)data["Birthday"];Dann wäre es unnötig und fehleranfällig es in einen String umzuwandeln (
ToString()), um es danach wieder in ein DateTime Objekt zu parsen. Die Fehlerquelle dabei ist die Lokalisierung. ToString wandelt das DateTime Objekt mithilfe der momentanen CultureInfo um(z.B. "en-US" oder "de-DE"). Denkbar ist auch dass aus diesem Grund in ConvertToDate ein fehlerauftritt bei
DateTime.Parse(o.ToString()). Dann würde im Catch block ein DateTime Objekt erzeugt werden welches niedriger ist(1/1/0001 12:00:00 AM oder DateTime.MinValue) als in SQL-Server erlaubt(01/01/1753). Damit tust Du Dir also erst Recht keinen Gefallen. An der Stelle sollte der ursprüngliche Fehler auf jeden Fall geworfen und nicht unterdrückt werden.
Ich würde auf jeden Fall mal einen
Haltepunkt setzen(ebenfalls im Catch-Block) um die Werte an der Stelle zu inspizieren.
Gruß
