[ASP.NET/ADO.NET] SQLDateTime 1/1/1753 - 31/12/9999

[tazzman]

Aangaande deze error, is het dus nooit mogelijk om in een .NET applicatie op een SQL Server 2000 database data op te slaan welke OUDER is dan 1/1/1753?

Ik struikelde over deze error vanwege een kleine typo in een stukje code maar deze error heeft mij aan het denken gezet. Ik heb gezocht op Internet (websites, newsgroups) en inderdaad overal wordt gezegd.. de datum moet tussen 1/1/1753 en 31/12/9999 liggen.

Maar wat nou als ik informatie wil opslaan die OUDER is? Denk bijvoorbeeld aan een gemeentearchief, of familie stamboom applicatie of wat concreter... inventarisatie paketten voor Musea waar toch veel items van ouder dan 1753 in opgenomen moeten worden.

Moet ik dan de boel gaan opslaan in varchar2 velden? Dat kan nooit de bedoeling zijn.

Weet iemand of Oracle 9i of 10g in combinatie met een .NET applicatie deze restrictie ook heeft? Is het gewoon iets van SQL Server 2000 of ADO.NET?

Het lijkt mij namelijk nogal vreemd om dergelijke beperkingen hard te coderen in SQL Server ...

[stp_4]

Sla er wat naslagwerk van SQL server op na. Je kan de laagste datum wel aanpassen

[whoami]

De minimum datum die je in SQL Server 2000 in een DateTime field kunt opslaan is idd 1/1/1753.
Een datetime field is nl. niets anders dan 2 getallen; die getallen houden vanaf een bepaalde datum (in dit geval 1/1/1753) bij, hoeveel dagen (voor het datum gedeelte) er al verstreken zijn. Op die manier wordt de datum bijgehouden.
Wellicht kan je nog wel ergens zelf instellen vanaf welke datum er moet geteld worden, maar dat weet ik niet zeker.

[ Voor 3% gewijzigd door whoami op 09-02-2004 11:46 ]

[tazzman]

stp_4 schreef op 09 februari 2004 @ 11:44:
Sla er wat naslagwerk van SQL server op na. Je kan de laagste datum wel aanpassen

Mag je mij toch es gaan vertellen hoe dan.

SqlDateTime.MinValue Field
Represents the minimum valid date value for a SqlDateTime structure.

[Visual Basic]
Public Shared ReadOnly MinValue As SqlDateTime
[C#]
public static readonly SqlDateTime MinValue;
[C++]
public: static SqlDateTime MinValue;
[JScript]
public static var MinValue : SqlDateTime;
Remarks
The minimum valid date for a SqlDateTime structure is January 1, 1753.

Als er gewoon in de MSDN staat dat de minValue voor de date 1/1/1753 dan lijkt mij niet dat je dit zo maar even kan aanpassen. Tis een ready only static.. het lijkt mij echt een hard gecodeerde minValue in SQL Server.

[ Voor 6% gewijzigd door tazzman op 09-02-2004 11:49 ]

[whoami]

Ik denk niet dat het aangepast kan worden:

SQL Server Books Online (BOL) defines the ranges of the two datetime data types this way: "Use datetime to store dates in the range from January 1, 1753, through December 31, 9999. Use smalldatetime to store dates in the range from January 1, 1900, through June 6, 2079." Two of these dates seem arbitrary. Why is the earliest datetime value in 1753? And why is the last smalldatetime value not at the end of a century, or even at the end of a month? I mentioned in my last column that datetime values use 4 bytes to store the number of days before or after the base date. Smalldatetime values use only 2 bytes. Generally, 2 bytes can hold numbers between -215 and +215 - 1, using 15 of the 16 bits for the data and one bit for the sign. If you ignore the sign and use that 16th bit for data, the range of possible values more than doubles. Instead of a maximum 2-byte value of 32,767, the value is 65,535. And 65,535 days after the base date of January 1, 1900, is June 6, 2079.

The reason for the early cutoff of possible datetime values isn't mathematical but historical. In September 1752, Great Britain adopted the Gregorian calendar, which differed from the one previously used in Great Britain and its colonies by 12 days. The change happened on September 2, 1752, so the next day was September 14, 1752.

SQL Server rejects all values it cannot recognize as dates between 1753 and 9999
Values for datetime earlier than January 1, 1753, are not permitted

Best wel kut eigenlijk.

[tazzman]

Tja, dan toch maar terug naar Oracle 9i of 10g. Daar kan ik overigens niet rouwig om zijn hoor (Groot Oracle fan hier).

Thx voor de input!