Datumswerte in MySQL schreiben, Klasse als Ersatz für datetime.now?

  • VB.NET

Es gibt 23 Antworten in diesem Thema. Der letzte Beitrag () ist von tragl.

    Datumswerte in MySQL schreiben, Klasse als Ersatz für datetime.now?

    Hi,
    ich muss meine DB leider von MS SQL auf MySQL umstellen. Dabei stolpere ich darüber, Datum- und Zeitwerte in MySQL zu schreiben.
    Das gute alte date.now kann ich nicht mehr benutzen, es muss bei MySQL wohl anders formatiert werden. date.now.ToString("yyyy-MM-dd HH:mm:ss") funktioniert, wird mir aber zu unübersichtlich und fehleranfällig zu tippen.

    Frage 1: Irre ich mich, gibt es komfortablere Wege den Datumstring zu formatieren?

    Falls nicht, Frage 2:
    Wie könnte ich ein ähnliches Konstrukt wie den Befehl "datetime" aufbauen. Ein Traum wäre z.B. folgendes: MySQLDate.now.addminutes(2) mit der Ausgabe in der richtigen Formatierung. Wobei das "addminutes" stellvertretend für die Optionen bei "datetime" steht. Ginge das mit Structure oder vielleicht besser Klassen?


    Und, offtopic - kann ich eine Sub so erzeugen, dass mir beim Aufruf dieser Sub mehrere Optionen für die Werteübergabe angezeigt werden? Also nicht stumpf meinesub("wert1"), sondern die Intellisense gibt mir nach "meinesub(" z.b. "Wert1", "Wert2" etc. vor und ich kann nichts anderes eingeben?!
    Grüße,
    Hanuta

    *Topic verschoben*
    Brauch' ich die?

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „Marcus Gräfe“ ()

    DatumString
    In einer DB haben DatumStrings nix verloren. Es gibt dort sicherlich einen oder sogar mehrere Datentypen für Datumse, und die sollten verwendet werden - keine Strings.
    Auch im Code haben Strings nix verloren, es gibt (System.Date) oder (System.DateTimeOffset, wenns ganz genau sein soll).
    Daten sollten unbedingt(!!!) mit DbParametern an die DB gesendet werden, und ein DbParameter für Date verlangt ein Date, keinesfalls einen DatumString.
    Siehe Must-Know: Sql-Injection
    Siehs positiv: Der Umstieg scheint also eine guter Anlass, jetzt mal ein paar entscheidende Dinge gradezuziehen.

    BlueLagoonX schrieb:

    Moin,

    wie schreibst du denn die Datumswerte in die Datenbank? Zeig bitte mal etwas Code.
    Grüße


    Moin,
    "UPDATE tbl_VMs SET ZeitAbbruch = '" & Date.Now.AddMinutes(2) & "' " wäre ein Beispiel wie ich es bisher bei MS SQL benutzt habe. Wobei ZeitAbbruch natürlich den Datentyp Datetime2 hat.
    Bei MySQL und dem Datentyp 'Datetime' schreibt er dabei nur Nullen in die DB. da hilft dieses Monstrum, aber halt extrem unschön:
    "UPDATE tbl_VMs SET ZeitAbbruch = '" & Date.Now.AddMinutes(2).ToString("yyyy-MM-dd HH:mm:ss") & "' "


    ErfinderDesRades schrieb:


    Auch im Code haben Strings nix verloren, es gibt (System.Date) oder (System.DateTimeOffset, wenns ganz genau sein soll).
    Daten sollten unbedingt(!!!) mit DbParametern an die DB gesendet werden,
    und ein DbParameter für Date verlangt ein Date, keinesfalls einen
    DatumString.
    Siehs positiv: Der Umstieg scheint also eine guter Anlass, jetzt mal ein paar entscheidende Dinge gradezuziehen.


    Grüß Dich! Nein, wie gesagt, ich nutze ja Datetime2 bzw. jetzt Datetime. Strings sind ih bah, das ist nur das, was ich bisher für MySQL ergoogelt habe. Als Krücke zum Füttern für MySQL. Gefällt mir aber nicht, daher dieser Thread ;)

    Das Thema Parameter wird nicht funktionieren, fürchte ich. Dafür habe ich imho viel zu viele zu unterschiedliche Querys. Mal wird kein Datum übergeben, mal 3 in einem Query. Ich hab in meinem Prog grob geschätzt 100-200 Querys, die alle komplett unterschiedlich sind...
    Gibt es denn wirklich die Gefahr, bzw. Möglichkeit, dass jemand von außerhalb in meinem kompilierten Programm eine bestimmte Sub aufruft um dort Code zu platzieren? In der URL einer Website klar, aber innerhalb des Programms?
    Und, P.S. - der Umstieg ist schon das Ergebnis, ein paar Dinge gradezuziehen :)

    Btw, erinnerst Du Dich, wir sprachen vor ca. 8 Wochen über das Thema Verbindungen offen zu halten oder nach jeder Query wieder zu schließen? Beim SQL-Server im LAN habe ich keinen Performanceunterschied gespürt. Jetzt nutze ich einen MySQL vom Provider, der benötigt ca. 1sek für eine kleine Abfrage inkl. Verbindungsaufbau. Wenn ich aber die Verbindungen geöffnet halte, kommt er annähernd an den lokalen Server ran. Nur mal zur Info...
    Brauch' ich die?

    Du wirst, wenn du sauber arbeiten willst, nicht um Parameter herum kommen.
    Egal was man in der Datenbank machst, mach es mit Parametern. SQL Injections, Fehler bei der Formatierung (es muss nur ein Host mit englischem Windows/SQL Server sein und schon knallt dir dein formatiertes Datum um die Ohren) und vor allem die Lesbarkeit der Abfragen, wären nur einige der Sachen die man damit richtig umgehen kann, alles andere ist Pfusch.

    Hier mal ein schnelles Beispiel, wie ich solche Abfragen löse.

    VB.NET-Quellcode

    1. Private Shared ReadOnly Property UpdateCommand As String
    3. Get
    4. Dim SqlStr As New StringBuilder
    6. With SqlStr
    7. .Append("UPDATE " & "tbl_VMs" & " SET ")
    9. .Append("ZeitAbbruch" & "=" & "@" & "ZeitAbbruch")
    11. .Append(" WHERE Deine Condition")
    13. Return .ToString
    14. End With
    15. End Get
    17. End Property
    19. Public Shared Sub UpdateWasAuchImmer(ByVal Connection As MySqlConnection, Optional ByVal CloseConnection As Boolean = False)
    21. Using Cmd As New MySqlCommand(UpdateCommand, Connection)
    22. With Cmd
    23. With .Connection
    24. If Not .State = ConnectionState.Open Then .Open()
    25. End With
    27. With .Parameters
    28. .AddWithValue("@" & "ZeitAbbruch", Date.Now.AddMinutes(2))
    29. End With
    31. .ExecuteNonQuery()
    33. With .Connection
    34. If CloseConnection AndAlso .State = ConnectionState.Open Then .Close()
    35. End With
    36. End With
    37. End Using
    39. End Sub


    Wenn sich die Gegebenheiten im SQL String ändern, schreib eine identische Property UpdateCommand mit einem Parameter und dem geänderten SQL String, zusätzlich noch eine weitere Update Routine.

    VB.NET-Quellcode

    1. Private Shared ReadOnly Property UpdateCommand(ByVal Nachricht As String) As String
    3. Get
    4. Dim SqlStr As New StringBuilder
    6. With SqlStr
    7. .Append("UPDATE " & "tbl_VMs" & " SET ")
    9. .Append("ZeitAbbruch" & "=" & "@" & "ZeitAbbruch" & ", " &
    10. "Nachricht" & "=" & "@" & "Nachricht")
    12. .Append(" WHERE Deine Condition")
    14. Return .ToString
    15. End With
    16. End Get
    18. End Property
    20. Public Shared Sub UpdateWasAuchImmer(ByVal Connection As MySqlConnection,
    21. ByVal Nachricht As String,
    22. Optional ByVal CloseConnection As Boolean = False)
    24. If Nachricht Is Nothing Then Nachricht = String.Empty
    26. Using Cmd As New MySqlCommand(UpdateCommand(Nachricht), Connection)
    27. With Cmd
    28. With .Connection
    29. If Not .State = ConnectionState.Open Then .Open()
    30. End With
    32. With .Parameters
    33. .AddWithValue("@" & "ZeitAbbruch", Date.Now.AddMinutes(2))
    34. .AddWithValue("@" & "Nachricht", Nachricht)
    35. End With
    37. .ExecuteNonQuery()
    39. With .Connection
    40. If CloseConnection AndAlso .State = ConnectionState.Open Then .Close()
    41. End With
    42. End With
    43. End Using
    45. End Sub


    Geht sicher auch schöner, aber so ist es relativ funktional.

    Eine Sekunde für eine "kleine Abfrage inkl. Verbindungsaufbau" halte ich für übertrieben. Ich habe einige Programme, die sowohl auf MSSQL als auch auf MySQL Datenbanken laufen. Selbst große abfragen laufen da in Mullisekunden durch.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „BlueLagoonX“ ()

    Hanuta schrieb:

    Das Thema Parameter wird nicht funktionieren, fürchte ich. Dafür habe ich imho viel zu viele zu unterschiedliche Querys. Mal wird kein Datum übergeben, mal 3 in einem Query. Ich hab in meinem Prog grob geschätzt 100-200 Querys, die alle komplett unterschiedlich sind...
    Dassis wumpe.
    Der Aufwand, eine Query mit oder ohne Parameter zu schreiben ist - wenn mans geschickt anfängt - derselbe.

    Zum Risiko hab ich ja das Tut verlinkt. Also SqlInjection ist eines der Risiken, und wenn man dafür offene Anwendungen verteilt ist das imo grob fahrlässig (und ich persönlich würde es sogar befürworten, wenn der Gesetzgeber da iwie tätig würde).
    Anderes Risiko sind Länder-Einstellungen. Datumse sind da natürlich für die meisten Probleme gut, aber auch mit Zahlen, und sogar mit Texten kann man auf Nase fallen aufgrund von Kultur-Einstellungen.

    Wobei dein Datum-String-Format glaub ziemlich international verträglich ist. Aber das muss ja kein Grund sein, DbParameter nicht zu verwenden.

    Hanuta schrieb:

    …Und, offtopic - kann ich eine Sub so erzeugen, dass mir beim Aufruf dieser Sub mehrere Optionen für die Werteübergabe angezeigt werden? Also nicht stumpf meinesub("wert1"), sondern die Intellisense gibt mir nach "meinesub(" z.b. "Wert1", "Wert2" etc. vor und ich kann nichts anderes eingeben?!


    Ich bin mir nicht sicher, was du mit dieser Frage meinst. Eventuell suchst du aber dies: docs.microsoft.com/de-de/dotne…res/procedure-overloading

    Hanuta schrieb:


    Das gute alte date.now kann ich nicht mehr benutzen, es muss bei MySQL wohl anders formatiert werden. date.now.ToString("yyyy-MM-dd HH:mm:ss") funktioniert, wird mir aber zu unübersichtlich und


    versuche es mal so
    Beispiel Tabelle(tableTest) anlegen nur mit Datetime feld

    VB.NET-Quellcode

    1. 'Tabelle erstellen
    2. create table TestTable
    3. (deinZeitFeld datetime);


    30 minuten hinzufügen

    VB.NET-Quellcode

    1. select date_add(deinZeitFeld,interval 30 minute) from TestTable;

    Ui, danke für die Antworten, da hatte ich ein paar Hausaufgaben...

    @ErfinderDesRades Ok, es ist angekommen, also wirklich wichtig. Dann muss ich es "nur noch" umsetzen...
    @BlueLagoonX: Super, vielen Dank für das Beispiel, damit kann ich etwas anfangen. Klappt super, schreibt sogar Mikrosec in die DB =O
    Zwei Fragen dazu, mir erscheint es grad noch tierisch aufwendig. Muss ich da nicht für jede unterschiedliche Query eigene Subs bauen? Das wäre doch riesig?! Steh ich auf der Leitung?
    Um mir wenigstens die Property updatecommand zu sparen, was ist mit folgendem Umbau:

    VB.NET-Quellcode

    1. Public Shared Sub UpdateWasAuchImmer(ByVal Connection As MySqlConnection, query As String, ID As Integer, tim As DateTime, Optional ByVal CloseConnection As Boolean = False)
    2. Using Cmd As New MySqlCommand(query, Connection)
    3. With Cmd
    4. With .Connection
    5. If Not .State = ConnectionState.Open Then .Open()
    6. End With
    7. With .Parameters
    8. .AddWithValue("@" & "ZeitAbbruch", tim)
    9. .AddWithValue("@" & "ID", ID)
    10. End With
    11. .ExecuteNonQuery()
    12. With .Connection
    13. If CloseConnection AndAlso .State = ConnectionState.Open Then .Close()
    14. End With
    15. End With
    16. End Using
    17. End Sub

    ...welches ich dann mit UpdateWasAuchImmer(DBCommonConnection, "UPDATE tbl_vms SET ZeitAbbruch = @ZeitAbbruch WHERE ID = @ID", 14, Date.Now.AddMinutes(2), True) aufrufen würde.

    - Baue ich da ein neues Tor für Injektion?
    - Aber selbst wenn es ok wäre, muss ich dennoch für jede Query eine eigene Sub bauen?
    - Das Ganze betrifft nur Schreibvorgänge, oder? Lesen geht wie bisher ohne Parametrisieren?!


    @zorroot: Auch interessant, was für meine Schnipselsammlung ;) Aber leider nein.
    Beispiel der Aufruf der "UpdateWasAuchImmer". Der erste Parameter ist die Connection, es ist eine von dreien. Ich will mich einfach nicht vertippen und es komfortabler haben. Nach Tippen des "AuchImmer(" sollen mir die 3 Optionen dieses Parameters angezeigt werden (DBCommonConnection oder DBXYConnection etc.), als eine Art Dropdownliste wie die Intellisene sie nutzt.


    @Kasi: Mhm, ich sehe, ich muss SQL lernen. Ich beschränke mich meist darauf, den Querystring mit VB-Mitteln zusammen zu bauen...
    Brauch' ich die?

    Mit Dataset->Db habich ein Dingens vorgestellt, was alle Standard-queries abdecken kann und mehr.
    Dazu gehört lesen und schreiben, und beides natürlich mit Parametern.

    Aber man muss seine Datenverarbeitung nach einem bestimmten Prinzip ausrichten, man muss sehr sorgfältig daten-modellieren, und ohne Databinding mit ins Boot zu holen hätte ich sowieso kein Bock auf garnix.

    Die Vorstellung von 200 Queries an allen Ecken und Enden verteilt passt da nicht sehr gut zu.
    In meine Welt gibts zu einer Anwendung ein Datenmodell. Das Datenmodell gibts in zwei Ausführungen, einmal inne DB und einmal inne Anwendung.
    Inne Anwendung werden die Daten verarbeitet.
    Gelegentlich werden die Datenmodelle gegeneinander synchronisiert, also Änderungen werden in die Db geschrieben, bzw. Daten werden vonne DB geholt. Das sind Lese- und Schreib-Vorgänge - die sind aber vollautomatisch.
    Das Datenmodell ist ja bekannt, und dementsprechen baut mein Automat die Queries zum Lesen und Schreiben. Hast du nix mit zu tun, es sei denn Spezialwünsche.

    Iwelche Sql-Kunststückchen kann man machen, aber das bringt nix. Am Ende müssen die Daten doch wieder ins Datenmodell der DB.
    Also pfeif ich auf Sql-Kunststückchen - ich mach meine Kunststücke in Vb.Net - das ist als Sprache der Sprache Sql um Welten überlegen.

    also imo muss man nur minimal Sql lernen oder auch garnix. (Achdoch - man muss eine sinnvolle Where-Klausel formulieren können - mit Parametern (aber die kriegste ja bei mir geschenkt). Und man musses erst wenn man Multi-User unterwegs ist, und mit > 10000 Datensätzen - und dahin muss man erstmal kommen.)
    Was man lernen muss ist Datenmodellierung und Databinding. Und Vb.net muss man lernen, typisiert programmieren, die richtigen Klassen verwenden und auf die richtige Weise.

    Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von „ErfinderDesRades“ ()

    Die Sache mit dem Databinding hatten wir vor einer Weile als Thema. Deine Tutorials haben mich da hingeführt, ist auch zweifelsohne ein feines Ding - bei mir ist das Problem aber so, dass verschiedene Clients an der DB arbeiten und so Veränderungen sofort eingepflegt werden müssen. Da kann ich ja nicht das ganze Dataset zurückschreiben, das zieht den anderen Clients ja den Boden unter den Füßen weg.

    Ja, wenn schon "Frickelei", dann auch eigentlich lieber in VB als SQL, finde ich auch übersichtlicher. Aber Kleinigkeiten lassen sich doch schön mit SQL erledigen, mir fällt da der "SELECT TOP x" ein. Hat mir einiges an Programmieraufwand erspart.

    Was hältst Du von meinem Umbau? Heble ich damit den Sicherheitsvorteil wieder aus?
    Brauch' ich die?

    Hanuta schrieb:

    Da kann ich ja nicht das ganze Dataset zurückschreiben, das zieht den anderen Clients ja den Boden unter den Füßen weg.
    Da fühle ich mich ungründlich gelesen.
    "das ganze Dataset" wird nicht zurückgeschrieben, sondern nur vorgenommene Änderungen.
    Der Vorgang ist höchst effizient, auch grade was Db-Traffic angeht.

    Dass du einen Umbau planst ist mir wiederum entgangen. Du musst iwie von SqlServer auf MySql migrieren, hab ich mitbekommen. Und vielleicht konnten wir dich überzeugen, zukünftig DBParameter zu verwenden - das habich schon nicht als eindeutige Aussage empfangen.
    Meinst du mit "Umbau" den Code aus post#9?
    Da codest du dich ja dumm und dämlich, wenn du jetzt deine 200 Queries durch solche 200 Methoden ersetzen willst.
    Und Post#9 zeigt ja nur ein UpdateCommand, fehlen ja noch Select, Insert, Delete.

    wie man den Sch... von der Backe kriegt habich nun ja oft genug drauf hingewiesen - übrigens mein Automat unterstützt auch Queries mit Select Top x ... oder Distinct.

    Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von „ErfinderDesRades“ ()

    Hanuta schrieb:

    @zorroot: Auch interessant, was für meine Schnipselsammlung Aber leider nein.Beispiel der Aufruf der "UpdateWasAuchImmer". Der erste Parameter ist die Connection, es ist eine von dreien. Ich will mich einfach nicht vertippen und es komfortabler haben. Nach Tippen des "AuchImmer(" sollen mir die 3 Optionen dieses Parameters angezeigt werden (DBCommonConnection oder DBXYConnection etc.), als eine Art Dropdownliste wie die Intellisene sie nutzt.


    OK. Da kommen verschiedene Lösungen in Betracht.
    1.) Konstanten docs.microsoft.com/de-de/dotne…tatements/const-statement
    Definiere 3 Konstanten vom Typ MySqlConnection. Nachdem du "UpdateWasAuchImmer(" getippt hast must du nur noch den oder die ersten Buchstaben der Konstanten tippen und Intellisense zeigt dir die gewünschte Auswahl.

    2.) Enumeration docs.microsoft.com/de-de/dotne…statements/enum-statement
    Eigentlich perfekt für deine Zwecke geeignet, nur unterstützt ENUM leider keine Strings (und ich vermute mal, das MySqlConnection im Prinzip ein String ist). Google kann hier helfen, "vb.net enum mit strings" liefert einige ältere und neuere Beispiele, z.B. codeproject.com/Articles/33455/String-Enumerations-in-VB-NET

    Die vorgestellten Beispiele sind für meinen Geschmack aber eher "Overkill", deshalb könnte man mit ein paar kleinen Änderungen an MySqlConnection doch noch mit einer Enumeration zum Erfolg kommen. Direkt nach dem Tippen von "Updatewasauchimmer Klammer auf" springt Intellisense an und steht auch schon fast auf einem der drei möglichen Werte. Mein Beispiel:

    VB.NET-Quellcode

    1. Public Class Form1
    3. Enum myDBConnection As Integer
    4. DB_Eins = 1
    5. DB_Zwei = 2
    6. DB_Drei = 3
    7. End Enum
    9. Public Function MySqlConnection(ein_Wert As Integer) As String
    10. Select Case ein_Wert
    11. Case 1
    12. Return "Oh Yeah!"
    13. Case 2
    14. Return "We are the champions"
    15. Case 3
    16. Return "Human"
    17. Case Else
    18. Return "Dies ist keine gültige DB !!!"
    19. End Select
    20. End Function
    22. Public Sub Updatewasauchimmer(Connection As myDBConnection)
    23. MessageBox.Show(MySqlConnection(Connection))
    24. End Sub
    26. Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
    27. Updatewasauchimmer(myDBConnection.DB_Zwei)
    28. End Sub
    30. End Class

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „zorroot“ ()

    Moin Zorrot,
    danke für Deine Mühe, aber das Ganze läuft grad aus dem Ruder, ich hatte auf etwas kleines, süßes gehofft
    private sub Change(Connection as mysqlconnection{connect1, connect2, connect3}) <- so etwas in der Art
    Konstanten kann ich leider nicht als connection deklarieren. Also weiter 3 public Variablen nutzen...

    Tach Erfinder,
    doch gelesen habe ich, ich glaube und hoffe es auch verstanden zu haben.
    Wir hatten das Thema schon mal, da sind wir beide zu dem Schluss gekommen, dass es bei meinem Einsatzzweck mit Databindings nicht funktionuckelt. Beim Aktualisieren des Datasets auf dem Server gibt es ja einen Fehler (Parallelitätsverletzung glaube ich) wenn zwei User Teile des gleichen Datasets hintereinander schreiben wollen. Daher der Schluß - es geht halt nicht mit Databinding. Ich benutze ja durchaus ein typisiertes Dataset zum Lesen und Rechnen der Felder, die sich nicht ständig ändern. Nur die Ergebnisse der Operationen werden mittels Update, Insert etc. geschrieben.

    Und ja, ihr habt mich von der Theorie her überzeugt. Ich schrieb doch schon "@ErfinderDesRades Ok, es ist angekommen, also wirklich wichtig. Dann muss ich es "nur noch" umsetzen..." Daher frage ich ja jetzt auch schon zum dritten Mal ob mein Umbau als sicher zu betrachten ist, und wie ich es umgehen kann 200 solcher Subs zu schreiben. Du hast ja vollkommen recht, wenn Du schreibst dass dies ein Mörder-Code-Aufwand wäre.
    Also, theoretisch eine feine Sache - nur wie wäre es praktisch umzusetzen, da komme ich nicht weiter....
    Brauch' ich die?

    Hanuta schrieb:

    Wir hatten das Thema schon mal, da sind wir beide zu dem Schluss gekommen, dass es bei meinem Einsatzzweck mit Databindings nicht funktionuckelt... Parallelitätsverletzung ... Daher der Schluß - es geht halt nicht mit Databinding.
    Hmm - habich grad nicht parat. Kannst du mir das verlinken?

    Ja, die Stelle lese ich iwie anders als du.
    Du folgerst aus der Parallelitätsverletzung ein KO fürs Dataset.
    Ich folgerte daraus ein KO für dein DbWrite-Dingens - weil das scheinbar Parallelitätsverletzungen ignoriert.
    Daraufhin sagtest du, dass Parallelitätsverletzungen nicht vorkommen - jeder User bearbeitet seine eigenen Datensätze.
    Und damit ist wieder alles Butter, weil eine richtig implementiertes Dataset<->Db-Synchronisation meldet nur Parallelitätsverletzungen, wenn sie auch tatsächlich auftreten.

    An der zitierten Stelle poppt weiter unten auch wieder dein Missverständnis auf:

    Hanuta schrieb:

    Ach ne, das würde dann wirklich Chaos geben wenn jeder Client die komplette DB zurückschreiben würde...
    Ein Dataset schreibt nur Änderungen in die DB - nichts weiter!.

    Moin,
    das ist jetzt nur aus meiner Erinnerung gesprochen - aber ich bin mir sicher, dass die Parallelitätsverletzung auch so entstand. Jeder Client hatte das Dataset geladen, aber jeder einen anderen Datensatz daraus bearbeitet. Beim Update kam dann der Fehler.
    Aber Du schriebst grade so schön "weil eine richtig implementiertes Dataset<->Db-Synchronisation" - ist die Standard Update-Funktion dazu nicht in der Lage? Wäre Dein Konstrukt da flexibler, könnte ich ihm sagen "den Datensatz mit dieser ID updaten, den Rest ignorieren"?

    Jau, und ein anderer Gedanke - könnte ich nicht nur den einen benötigten Datensatz aus der DB ziehen und nur diesen einen dann zurückschreiben? Dann könnte es ja theoretisch niemals eine Paradingsdaverletzung geben. Außer beim Beispiel unten...

    Und ja, natürlich ignoriert mein SQL-Update Befehl Parallelitätsverletzungen. Aber das kann ich in Kauf nehmen, da mein Prog ja nunmal nur einen DS bearbeitet, der kann also unbesorgt gespeichert werden.
    Ein Beispiel, was öfter vorkommt: Mitarbeiter A bearbeitet grade den DS von Kunden K. Mitarbeiter B nimmt einen Anruf vom Kunden K an, und muss ein Datenfeld (letzterKontakt) im DS des Kunden ändern. Dieses Datum interessiert Mitarbeiter A überhaupt nicht, aber keiner von beiden kann den DS dann wirklich speichern, es würde zu einer Parallelitätsverletzung kommen.
    Brauch' ich die?

    Hanuta schrieb:

    Aber Du schriebst grade so schön "weil eine richtig implementiertes Dataset<->Db-Synchronisation" - ist die Standard Update-Funktion dazu nicht in der Lage?
    Welche Standard-Update-Funktion? Ich wüsste nicht, dass es eine gibt.

    Hanuta schrieb:

    Wäre Dein Konstrukt da flexibler, könnte ich ihm sagen "den Datensatz mit dieser ID updaten, den Rest ignorieren"?
    nee, der updatet halt was geändert wurde. Wäre doch das pure Chaos, wenn Dinge geändert würden, dann aber beim Update ignoriert.

    Hanuta schrieb:

    A bearbeitet grade den DS von Kunden K. Mitarbeiter B nimmt einen Anruf vom Kunden K an, und muss ein Datenfeld (letzterKontakt) im DS des Kunden ändern.
    ach - das ist ja lustig! An anderer Stelle hast du behauptet, jeder MA hat immer nur seine eigenen Datensätze.

    Jo, für das Problem wüsste ich auch nix anneres als die Parallelitätsverletzung zu ignorieren, weil sie liegtt ja tatsächlich vor.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von „ErfinderDesRades“ ()

    eine Client-Server Anwendung kann mann nicht so Programmieren
    Punkt... Ende.. Aus

    aussage von EDR
    Iwelche Sql-Kunststückchen kann man machen, aber das bringt nix. Am Ende müssen die Daten doch wieder ins Datenmodell der DB.
    Also pfeif ich auf Sql-Kunststückchen - ich mach meine Kunststücke in Vb.Net - das ist als Sprache der Sprache Sql um Welten überlegen.

    das ist Blödsinn, wenn du nix mit SQL am Hut hast kannst du das nicht beurteilen


    also imo muss man nur minimal Sql lernen oder auch garnix. (Achdoch - man muss eine sinnvolle Where-Klausel formulieren können - mit Parametern (aber die kriegste ja bei mir geschenkt). Und man musses erst wenn man Multi-User unterwegs ist, und mit > 10000 Datensätzen - und dahin muss man erstmal kommen.)

    das ist noch größerer Blödsinn, das mann überhaupt kein SQL lernen muss


    @Hanuta
    ich kann dir nur empfehlen wenn du mit MySQL Arbeiten willst die möglichkeiten auszuschöpfen
    hier ein LInk
    w3schools.com/sql/func_mysql_date_add.asp

Facebook
Telefonspende