[c#]Param. Query geeft nog steeds problemen met DateTime?

[TeeDee]

Op mijn localhost heb ik een webforms applicatie gemaakt die een bepaalde aanvraag in een database stopt. Deze database is een SQL 7 db op een andere server.

Zodra ik de applicatie vanaf http://localhost/aanvraag uitvoer dan ondervind ik geen problemen met mijn DateTime velden.

C#:

insertdata.Parameters.Add("@p_Aankomsttijd", SqlDbType.DateTime);
insertdata.Parameters["@p_Aankomsttijd"].Value = txtaandatum.Text;

Voer ik diezelfde applicatie van http://intranet/aanvraag uit, krijg ik een error op het DateTime veld.

code:

System.FormatException: String was not recognized as a valid DateTime.

Alle 2 de apps zetten de data in dezelfde MS SQL server.

De localhost server is een NL Windows 2000 Prof. De intranet server is een UK Windows 2000 server. Maar dat lijkt me niet relevant, want doordat ik een Parametrized Query gebruik maakt het toch niet uit hoe je format is?

Iemand een idee wat dit kan zijn en zo ja, hoe je dit kan oplossen?

[dominic]

txtaandatum.Text wellicht een ander formaat door de regional settings? Het is trouwens nooit verstandig een stringwaarde direct aan een parameter te hangen, altijd eerst testen of deze goed is.

[whoami]

Je moet je text wel converten naar een date voordat je die aan je parameter toekent:

code:

myCommand["myDateParam"].Value = Convert.ToDateTime (txtDatum.Text);

Waarom gebruik je trouwens geen calendar of datetimepicker control die de gebruiker toelaat om een datum te specifieren ?

[TeeDee]

dominic schreef op 22 oktober 2004 @ 10:15:
txtaandatum.Text wellicht een ander formaat door de regional settings?

Als je vanaf de zelfde machine de applicatie aanroept, dus localhost en intranet worden vanaf mijn machine aangeroepen zou dat toch geen problemen moeten geven, omdat het regional settings gebeuren toch clientside gebeurt?

Het is trouwens nooit verstandig een stringwaarde direct aan een parameter te hangen, altijd eerst testen of deze goed is.

Eens, daarom maak ik van te voren ook gebruik van een RegularExpressionValidator.

whoami schreef op 22 oktober 2004 @ 10:23:
Je moet je text wel converten naar een date voordat je die aan je parameter toekent:

code:

...

Waarom gebruik je trouwens geen calendar of datetimepicker control die de gebruiker toelaat om een datum te specifieren ?

Ik zal het invoeren, daar niet van, maar verklaart nog niet waarom het op mijn localhost wel werkt.

Calendar, Datetimepicker control zal ik eens nalopen.

[ Voor 41% gewijzigd door TeeDee op 22-10-2004 10:25 ]

[whoami]

TeeDee schreef op 22 oktober 2004 @ 10:23:
[...]

Dat zou kunnen, maar dat verklaart niet waarom dezelfde app op mijn localhost wel werkt.

SQL Server gaat die datum (die jij als datetime gespecifieerd hebt als parameter in je query) als string krijgen. SQL Server zal dus zelf de conversie moeten gaan toepassen en gaat daarbij rekening gaan houden met de settings van de server, terwijl jij anders de datum als een datum doorgeeft met de settings van de client als je Convert.ToDateTime gebruikt.
Dat verklaart het dus wel. Kijk maar eens met de SQL Profiler welke query je doorkrijgt.

[ Voor 10% gewijzigd door whoami op 22-10-2004 10:27 ]

[TeeDee]

whoami schreef op 22 oktober 2004 @ 10:27:
[...]

SQL Server gaat die datum (die jij als datetime gespecifieerd hebt als parameter in je query) als string krijgen. SQL Server zal dus zelf de conversie moeten gaan toepassen en gaat daarbij rekening gaan houden met de settings van de server, terwijl jij anders de datum als een datum doorgeeft met de settings van de client als je Convert.ToDateTime gebruikt.
Dat verklaart het dus wel. Kijk maar eens met de SQL Profiler welke query je doorkrijgt.

Ah, ik dacht dat dat dus niets van doen had met de settings van de server maar juist met de settings van de client.

Ik ga het even proberen!

edit:

C#:

insertdata.Parameters.Add("@p_Aankomsttijd", SqlDbType.DateTime);
insertdata.Parameters["@p_Aankomsttijd"].Value = Convert.ToDateTime(txtaandatum.Text);

Blijft alsnog dezelfde foutmelding genereren.
De uiCulture van de App staat op nl-NL (Dutch). Is dat een probleem?

[ Voor 18% gewijzigd door TeeDee op 22-10-2004 10:32 ]

[whoami]

TeeDee schreef op 22 oktober 2004 @ 10:29:
[...]

Ah, ik dacht dat dat dus niets van doen had met de settings van de server maar juist met de settings van de client.

Als je de datum als een string doorgeeft, kan SQL Server toch niet weten welke settings er op de client gelden?
Je moet je datum als een datum doorgeven, en niet als een string.

[whoami]

Hum, het is idd zo dat die Convert.ToDateTime op de server draait en dus de regional settings van de server gebruikt, en niet van de client. Dom van me.
Je kan wel de regional settings die de user gebruikt meegeven aan die Convert.ToDateTime. Kijk eens naar de overloads, je kan een de Culture meegeven die ingesteld is als setting in de browser van de client:

code:

CultureInfo c = new CultureInfo(Request.UserLanguages[0]);
Convert.ToDateTime (eendatum, c);

Zoiets geloof ik.

[TeeDee]

Zo, even het CultureInfo erin gezet.

En daar komt de foutmelding:

code:

Cultuur nl is neutraal. Deze kan niet voor het indelen en parseren worden gebruikt
en kan daarom niet als de huidige cultuur van de thread worden ingesteld.

Ik heb ook geprobeerd om de uiCulture van de app op niets te zetten, maar dat geeft dezelfde melding.
Eens even in CultureInfo duiken.

[TeeDee]

En het werkt:

C#:

CultureInfo c = new CultureInfo("nl-NL", true);
insertdata.Parameters.Add("@p_Aankomsttijd", SqlDbType.DateTime);
insertdata.Parameters["@p_Aankomsttijd"].Value = Convert.ToDateTime(txtaandatum.Text, c);

De boolean true geeft dus aan dat als de CultureInfo van de client gelijk is aan die van de server, de Info van de client gebruikt dient te worden. Kan handig zijn, misschien dat die ook gewoon op false gezet kan worden.

Waarom het eerst niet werkte is, omdat mijn Culture op nl ingesteld staat. Blijkbaar mag dat niet.
nl-NL does the trick.

Dank aan whoami!

_{nogmaals, een param. query moet dit gezeik toch juist tegengaan?}

[whoami]

Je hebt neutrale cultures, en specifieke cultures.

[gorgi_19]

C#:

CultureInfo c = new CultureInfo(Request.UserLanguages[0]);

Is trouwens best link; een invalid culture c.q. geen geselecteerd land zorgt voor een crash van je applicatie. Imho valt dit ook onder: "Never trust user input"

[whoami]

gorgi_19 schreef op 22 oktober 2004 @ 18:54:

C#:

CultureInfo c = new CultureInfo(Request.UserLanguages[0]);

Is trouwens best link; een invalid culture c.q. geen geselecteerd land zorgt voor een crash van je applicatie. Imho valt dit ook onder: "Never trust user input"

Is waar. Het is natuurlijk de taak van de programmeur om dit te controleren.

[whoami]

TeeDee schreef op 22 oktober 2004 @ 11:28:
_{nogmaals, een param. query moet dit gezeik toch juist tegengaan?}

Als jij die param. query goed gebruikt wel ja.
Maar zoals jij hem gebruikt, ging je gewoon 'text' aan die query gaan doorgeven.
Je moet dus nog aangeven dat het om een datum gaat, en aangezien het om een web-applicatie gaat, wil je die datum in de vorm van de client gebruiken. Echter, de asp.net code draait op de server, dus moet je op een of andere manier aangeven welk in welk formaat je die datum wilt.

[ Voor 33% gewijzigd door whoami op 23-10-2004 10:06 ]

[riezebosch]

Mijn ervaring met SQL is dat het áltijd goed gaat als je "yyyy-mm-dd" doorgeeft in je query, ongeacht de taalinstellingen van de client/server. Weet niet of dit van toepassing is op je probleem?

[gorgi_19]

riezebosch schreef op 23 oktober 2004 @ 11:14:
Mijn ervaring met SQL is dat het áltijd goed gaat als je "yyyy-mm-dd" doorgeeft in je query, ongeacht de taalinstellingen van de client/server. Weet niet of dit van toepassing is op je probleem?

Ja, maar mbv Parametrized queries gaat dit geintje niet op Je geeft dan nl een DateTime struct op

[ Voor 6% gewijzigd door gorgi_19 op 23-10-2004 11:16 ]

[Verwijderd]

TeeDee schreef op 22 oktober 2004 @ 11:28:

Waarom het eerst niet werkte is, omdat mijn Culture op nl ingesteld staat. Blijkbaar mag dat niet.
nl-NL does the trick.

Deze setting in je web.config zetten is toch iets makkelijker...

[whoami]

Ik vind het maar ranzig om die settings hard coded in je web-config of in je code te plaatsen.
Je gaat er dan vanuit dat iedereen met dezelfde culture-settings werkt enzo....

Het is imo beter dat je je gebruikers laat specifieren welke culture ze willen gebruiken; dat kan je dan opslaan in hun profiel ofzo.