Insert Datetime schlägt fehl
verwendetes Datenbanksystem: <MS SQL 2008 R2>
Hallo,
da ich nur relativ ähnliche Fragen bei Google und im Forum gefunden habe, und mir nicht wirklich geholfen hat, stell ich mal mein Problem vor:
Ich will einen Datetime Wert in eine Spalte vom Typ Datetime einfügen, was eigentlich kein Problem ist, aber SQL macht mir einen Strich durch die Rechnung.
Hier ist der Query:
INSERT INTO [TableExample].[dbo].[RemoteSupport]
([CalculatedDuration],
[RealDuration],
[StartTime],
[Guid_ID],
[Session_ID],
[User_ID])
VALUES
('02:45:00',
'02:30:57',
'2014-03-28 14:43:56.070',
'00000000-0000-0000-0000-000000000000',
559,
73);
Die Fehlermeldung lautet:
Fehlermeldung:
Meldung 242, Ebene 16, Status 3, Zeile 1
Bei der Konvertierung eines varchar-Datentyps in einen datetime-Datentyp liegt der Wert außerhalb des gültigen Bereichs
Was läuft da falsch? Da es Ebene 16 ist, muss es ja an mir liegen.
Jemand eine Idee?
Danke!
Villeicht wird das Format nicht erkannt versuchsmal hiermit: convert(datetime, 'yyyy-mm-dd hh:mm:ss.mmm', 121), //yyyy-mm-dd hh:mm:ss.mmm
Einen Datetime-Wert als String an einen SQL-Server zu übergeben ist immer eine schlechte Idee.
Benutze lieber Parameter : [Artikelserie] SQL: Parameter von Befehlen
Grüße Bernd
Workshop : Datenbanken mit ADO.NET
Xamarin Mobile App : Finderwille Einsatz App
Unternehmenssoftware : Quasar-3
@BerndFfm
Das stimmt so nicht wirklich. Sobald jemand versucht aus dem querry auszubrechen wird dieser ungültig weil das format nicht eingehalten wurde.
Außerdem glaube ich nicht, das das Datum in dem Format vom benutzer eingegeben wird.
Da täuschst Du Dich Robin0. Wenn man den Aufbau des SQL Queries kennt und man eine Chance hat den String an die SQL-Schnittstelle zu kriegen, dann kann man problemlos SQL injecten.
Daher sollte man sich angewöhnen immer mit Parametern zu arbeiten.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Ich finde das ein datum generell nicht vom user eingegeben werden sollte.
Parameter sind eine gute sache, aber wenn man sich das datum sowiso aus einem DateTimePicker holt overkill.
Und wenn man schon den SQL string kommt, dann kommt man auch die sqlconnection.
Das Datum kann aber nicht immer automatisch ermittelt werden.
Ein DateTime-Picker ist aus ergonomischer-Sicht das so ziemlich schlechteste Mittel ein Datum einzugeben.Es sieht zwar toll aus; UI Designer freuts, aber in der Regel arbeitet man für effizientes Arbeiten mit Tabbing, also dem Springen in Formularen.
Wenn ich da nicht von Hand das Datum eintippen könnte (so wars am Anfang in meiner Rechnunsgverwaltung WISO nach der Designumstellung), sehr schnell über Numpad, würde die Anwendung aus meiner Buchhaltung fliegen.
WISO macht das mittlerweile so intelligent, dass es das Datum schon bei Eingabe genau erkennt.
Sprich springt es selbst von Tag zu Monat; geb ich nur "313" ein wird automatisch "31.03.2014" beim LostFocus...; 876324 mal schneller als erst zur Maus zu greifen und das Datum zu suchen. DateTime-Picker für die Anfänger gibts trotzdem.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
@Robin0:
Parameter sind eine gute sache, aber wenn man sich das datum sowiso aus einem DateTimePicker holt overkill.
Und wenn man schon den SQL string kommt, dann kommt man auch die sqlconnection.
Du hast wirklich nicht verstanden worum es geht.
Tu dir selber mal einen Gefallen und lese dir den Artikel zu den Parametern ganz genau durch.
Du wirst feststellen das es
- Kein Overkill ist, denn man macht es vernünftiger weise ein mal in seinem Dal,
- Viele Convertierungsprobleme wie z.b. dein Gefrickel von vornherein unnötig macht, und
- Eben gegen jede Art von SqlInjection schützt.
Also versuch nicht irgend jemanden davon zu überzeugen das gefrickel sinnvoll ist.