SQL-Server und das Datumsformat

  • VB.NET

Es gibt 9 Antworten in diesem Thema. Der letzte Beitrag () ist von ErfinderDesRades.

    SQL-Server und das Datumsformat

    Ich habe ein Problem mit dem SQL-Datenformat. Es geht darum, aus einer bestehenden MS-Access 97 Datenbank Tabellen in einen SQL-Server zu übernehmen. Der SQL-Server ist hier als English/US eingerichtet und kann wegen einer ausserdem laufenden Software nicht auf Deutsch umgestellt werden.

    Nun habe ich bereits alles mögliche versucht, aber in der SQL-Tabelle kommt entweder nur der 01.01.1900 an oder aber der .ExecuteNonQuery Befehl meldet einen SQL-Ausnahmefehler. Folgende Dinge habe ich bereits probiert - als Beispiel dient das Datum 22.08.2010......

    meinDatum = "22.08.2010"

    ExeSQL.CommandText =
    "UPDATE Lieferant SET GültigBis = CONVERT(datetime, " & meinDatum & ", 101) WHERE ID = " & lfdnr - liefert eine SQL.Exception Near 2010
    meinDatum = "22/08/2010"

    ExeSQL.CommandText = "UPDATE Lieferant SET GültigBis = CONVERT(datetime, " & meinDatum & ", 101) WHERE ID = " & lfdnr - schreibt 01.01.1900 in die Datenbank

    meinDatum = "08/22/2010"

    ExeSQL.CommandText = "UPDATE Lieferant SET GültigBis = CONVERT(datetime, " & meinDatum & ", 101) WHERE ID = " & lfdnr - schreibt 01.01.1900 in die Datenbank

    ExeSQL.CommandText = "UPDATE Lieferant SET GültigBis = " & DateValue(meinDatum) & WHERE ID = " & lfdnr - SQL-Fehler near 2010

    ExeSQL.CommandText = "UPDATE Lieferant SET GültigBis = " & #2010/08/22# & WHERE ID = " & lfdnr - SQL-Fehler

    ExeSQL.CommandText = "UPDATE Lieferant SET GültigBis = " & #08/22/2010# & WHERE ID = " & lfdnr - SQL-Fehler



    mehr Varianten fallen mir nicht mehr ein und ich wäre sehr dankbar für den ein oder anderen Tipp.




    Roy1305 schrieb:

    Ich habe ein Problem mit dem SQL-Datenformat.

    Dann lass das doch sein ... !!!

    SELECT foo FROM table where MeinDatum = @Datum

    -> Command.Parameters.Add(new DBParameter() with {.ParameterName="@Datum", .Value=Now()}

    Stichwort für Suche zb OleDBParameter, DBParameter etc


    BTW: [VB 2010] MS SQL Compact 3.5 und DateTime - ich bin zu dumm
    Immer und immer und immer und immer und immer WIIEEEEEDER das blöde Datumsproblem, das sich SOOOOOO einfach lösen läßt, wenn man halt parametrisierte Queries verwendet, die - nebenbei bemerkt - sowieso "besser" sind.

    SQL-Abfrage

    1. UPDATE `tabelle`SET `spalte` = '2012-02-22' WHERE `id` = 5


    oder picos bessere Variante mit DBParametern

    PS: Umlaute als Spaltennamen zu verwenden könnte leicht zu komplikationen führen wenn nicht das richtige Encoding gewählt wurde. Nur mal so als Tipp.

    Hi Dodo!

    IMO sollteman das Einfrickeln von Werten in Command-Texte ühaupt nicht mehr empfehlen oder auch nur vorführen.

    Das ist einfach eine NoGo - Vorgehensweise, so quick and dirty wie mw. mit Strict Off zu proggen. Das Theater mittm DatumsFormat ist ja nur das am häufigsten auftretende Problem: Unkenntnis der korrekten funktionierenden Formatierung.
    Hinzu kommen noch ganz allgemein Kultur-Inkompatiblitäten, tw. Sql-Dialekte und die Gefahr von Angriffen per Sql-Injection.
    All das wird ausgeräumt, wenn mans halt richtig macht (naja - Sql-Dialekte nur teilweise).

    Dasses diese Möglichkeit des Werte-Einfrickelns in .Net ühaupt noch gibt, ist in meinen Augen ein sau-gefährliches Fehldesign des Frameworks (jaja, Abwärtskompatiblität - aber kannmanschon von "Noob-Kompatiblität" sprechen)

    Schon, aber da ich SQL von PHP her kenne, mache ichs btw. immernoch so. Ja ich weiß auch gibts DbParameter mittlerweile in PHP, aber selbst andere große Frameworks machen SQL Queries noch über diese Methode. In VB (wenn ich es mal brauche) mache ich es demnach auch so, weils eben auch schneller ist als noch mehrere Zeilen Code mit den DBParametern zu "opfern". Ich würd mir das auch liebend gerne angewöhnen, aber habe meist nicht den Elan dazu.

    Dodo schrieb:

    als noch mehrere Zeilen Code mit den DBParametern zu "opfern".
    mit bischen programmieren kann man diese stereotypen Parameter-Befüllungs-Zeilen in eine Methode packen, die dann sogar praktischer aufzurufen ist als das String-Gefrickel.

    Kann man sogar sehr allgemein lösen, denn eine Connection hat die CreateCommand-Methode, sodass sich sogar eine Extension schreiben ließe, die dann so aufzurufen wäre:

    VB.NET-Quellcode

    1. dim cmd as DBCommand = myConnection.CreateQuery("UPDATE `tabelle`SET `spalte` = ? WHERE `id` = ?", DateTime.Now, 5)

    Dann hat man nur ein einziges String-Gefrickel, an nur einer Stelle, und das frickelt keine Werte in einen CommandText, sondern analysiert den CommandText, und setzt für die '?' geeignete ParameterBezeichner ein.

    Hallo,

    ja - ich komme direkt aus der VB6 Welt und bin erst kürzlich umgestiegen. Deshalb bin ich aber noch lange kein "Noob". Aus euren Antworten bin ich nur bedingt schlau geworden. Zumindest eine Grobrichtung habe ich dadurch finden können. Eine Antwort, die eine Lösung darstellt hätte so aussehen können:
    ---> F2 = FeldInhalt (in diesem Fall 22.10.2012)
    Dim Connection AsNewSqlConnection(ConnString_WWS)
    Dim CommandSQL AsString = "UPDATE Lieferant SET GültigBis = @MyDatum WHERE ID = @ID;"Dim Command AsNewSqlCommand(CommandSQL, Connection)
    Command.Parameters.Add("@ID", SqlDbType.Int)Command.Parameters("@ID").Value = lfdnr
    Command.Parameters.AddWithValue("@MyDatum", DateValue(F2))
    Try
    connection.Open()
    Dim rowsAffected AsInteger = Command.ExecuteNonQuery()
    Catch ex AsException Dim MyError = ex.Message
    Finally
    Connection.Close()EndTry
    Im übrigen weiß ich nicht was gegen eine "quick and dirty" Lösung spricht, wenn es sich um ein Transferprogramm für einen speziellen Kunden handelt, welches nur ein einziges mal laufen wird. Mir ist klar, das man unter Umständen etws genervt ist, wenn man eine Frage schon in der einen oder anderen Form zig mal gelesen hat aber euch sollte auch klar sein, das man hier nichts ohne Grund reinschreibt und eine Antwort sollte eben auch eine Antwort sein und ein bisschen mehr enthalten als nur "Schlaumeierei" oder eben ein hastig hingeworfenes Stichwort.
    Trotzdem danke ...

    Roy1305 schrieb:

    ja - ich komme direkt aus der VB6 Welt und bin erst kürzlich umgestiegen. Deshalb bin ich aber noch lange kein "Noob".

    Ich meine den Begriff "Noob" nicht beleidigend. Sondern das drückt nur aus, dass jmd. sich nicht auskennt mit der Materie.
    Und dassis numal zwangsläufig der Fall, wenn jmd. grade von VB6 auf .Net umgestiegen ist.

    Versuche's zu akzeptieren, dass du in .Net ausnahmslos alles über Bord werfen mußt, was du dir an Kenntnissen in VB6 angeeignet hast. Also mit der Zeit (wenn du gut bist) kommst du von selber drauf, aber man kommt sicher wesentlich schneller voran, wenn man das von vornherein bei jedem Problem, was man anfasst, mitberücksichtigt.

    Andernfalls produzierst du am laufenden Meter VB6-Lösungen, soweit .Net die noch unterstützt, die aber von einem .Net-Progger-Standpunkt her gesehen einfach grauenhaft sind.

    Am schnellsten gelingt der Einstieg, wennde dieses Buch durcharbeitest.

    Roy1305 schrieb:

    Im übrigen weiß ich nicht was gegen eine "quick and dirty" Lösung spricht

    Wie lange hast du denn jetzt gebastelt und versucht? aha! Mit DBParametern ist man 17 Sekunden langsamer .... WENN die quick&dirty Lösung beim ersten Versuch läuft - was wegen SQL-Dialekten etc halt nicht unbedingt klar ist.


    oder eben ein hastig hingeworfenes Stichwort.

    1. bin ich froh, dass du mich nicht meinst, denn ich habe ja ein Codebeispiel skizziert UND ein Stichwort geliefert
    und
    2. wenn einem das richtige Stichwort FEHLT, hilft einem Google Null. HAT man das richtige Stichwort, liegt die Lösung nur 0.3 Googles entfernt!

    Roy1305 schrieb:

    Im übrigen weiß ich nicht was gegen eine "quick and dirty" Lösung sprich, wenn man...t

    von "dagegen sprechen" sprechen in dem Sinne, dass man das Schlechte daran sucht, kann man bei q&d garnet.
    Weil an q&d ist nichts schlechtes dran, sondern es ist selbst das Schlechte.

    Roy1305 schrieb:

    ...wenn man...
    Jut, obs in deinem Einzelfall schadlos anwendbar ist, konnten wir bis post#7 ja nicht wissen. Und selbst danach haltichs nicht für einen guten Rat, dich am Erlernen einer sauberen Vorgehensweise zu behindern, indem man dein q&d-Interesse bedient.

    Roy1305 schrieb:

    ...sollte auch klar sein, das man hier nichts ohne Grund reinschreibt...
    Dassis eine sehr sehr mutige Behauptung, ums mal nett zu sagen.
    Gut, ohne Grund im engerern Sinne wird vlt. nix geschrieben, aber unerfreulich viel ist ohne Sinn.

    Über picoflop darfstedich nicht aufregen, der ist böse und gemein :evil: .
    So wird man fast zwangsläufig mit der Zeit, wenn man sich viel im Forum engagiert - die Gründe führst du ja selbst eiglich ziemlich gut an.

    Sinnigerweise hatterja sogar eine Warnung in seim Avatar, also besser vom Emotionalen abstrahieren, und sich auf die inhaltlich-sachliche Komponente konzentrieren, denn die ist ausnahmslos von fabelhafter Qualität, soweit ich das ühaupt beurteilen (kann? darf? nicht? - machich trotzdem :P ).

    nochn Tipp: VB-Tag richtig benutzen

Facebook
Telefonspende