TIA Probleme mit real Variablen im SQL

Christmaspoo

Level-1
Beiträge
250
Reaktionspunkte
33
Zuviel Werbung?
-> Hier kostenlos registrieren
Hallo,

ich habe eine Datenbankverbindung, welche bis auf eine "Kleinigkeit" funktioniert. In der Datenbank werden 104 Werte gespeichert, von denen ~90 den typ real haben sollen. Die variablen sind im WinCC als real angelegt. wenn ich dort eine Real mit Nachlommastelle 0 eingebe funktioniert die Verbindung zur DB einwandfrei. Trage ich in der DB händsich eine Real mit Nachkommastellen ein, klapp das laden in die SPS auch. Nur leider bin ich nicht in der lage eine Real mit Nachkommastelle per skript in die DB zu schreiben. In diesem Fall stürzt das Skript ab, nachdem ich den String generiert habe, noch bevor ich die Verbindung zur DB aufbaue. Woran kann das liegen? Google war leider nicht sonderlich hilfreich.

Edit: Beispielstring
Code:
SQL = "UPDATE `Table` Set `var1` = '" & SmartTags("Tag1") &_
             "',`var2` = '" & SmartTags("tag2")  & "' WHERE (`Artikelnummer` = '"&Artikelnummer&"');"

Tag1 und Tag2 sind Typ Real
 
Zuletzt bearbeitet:
Zuerst, erwähn um welche WinCC es handelt.

Wenn du in WinCC eine Ausgabefeld mit die Variabel( n) einrichtet, wird dann Sinnvolle Wert(e) angezeigt ?

Um ein Hinweis warum das Skript crascht, vor die Zeile füg ein:
Code:
undefined

Nach die Zeile füg ein:
Code:
If Err.Number <> 0 Then
ShowSystemAlarm "SQL Skript Fehler: " & CStr(Err.Number) & " " & Err.Description
Err.Clear
Exit Sub
End If
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Die variablen sind im WinCC als real angelegt. wenn ich dort eine Ganzzahl eingebe funktioniert die Verbindung zur DB einwandfrei.
:unsure: Du trägst in eine REAL-Zahl eine GanzZahl ein??? INT (= 16 Bit) oder DINT (= 32 Bit)? Oder was meinst Du mit GanzZahl?
Meinst Du eine REAL-Zahl, bei der "zufällig" die NachKaommaStellen alle 0 sind?
Meinst Du mit REAL (= 32 Bit) evtl. LREAL (= 64 Bit)? :unsure:

Trage ich in der DB händsich eine Real ein, klapp das laden in die SPS auch.
...
Nur leider bin ich nicht in der lage eine Real mit Nachkommastelle per skript in die DB zu schreiben.
:unsure: ??? :unsure:
 
Zuerst, erwähn um welche WinCC es handelt.

Wenn du in WinCC eine Ausgabefeld mit die Variabel( n) einrichtet, wird dann Sinnvolle Wert(e) angezeigt ?

Um ein Hinweis warum das Skript crascht, vor die Zeile füg ein:
Code:
undefined

Nach die Zeile füg ein:
Code:
If Err.Number <> 0 Then
ShowSystemAlarm "SQL Skript Fehler: " & CStr(Err.Number) & " " & Err.Description
Err.Clear
Exit Sub
End If
Ok, danke. Die Fehlermeldung ist ".....data truncated for coloumn...." Scheint eine Datentypunverträglichkeit zu sein.

in der SPS sind die Variablen alles als real eingestellt. wenn ich die in der MYSQL Workbench auf real stelle korriegiert die Workbench das auf double. Ist hier mein Problem?
 
Wenn Du Realzahlen in eine SQL Datenbank schreiben willst, kommt die Syntax mit dem Komma nicht klar.
Du musst das Komma vorher in einen Punkt wandeln.

Replace (CStr(HMIRuntime.Tags ("realwert ").Read),",",".")

Wenn Du nur WinCC schreibst, nehme ich an "V7.5".
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Wenn Du Realzahlen in eine SQL Datenbank schreiben willst, kommt die Syntax mit dem Komma nicht klar.
Du musst das Komma vorher in einen Punkt wandeln.

Replace (CStr(HMIRuntime.Tags ("realwert ").Read),",",".")

Wenn Du nur WinCC schreibst, nehme ich an "V7.5".
Habe es gerade auch gefunden, dennoch danke. Meine Lösung sieht aus wie Folgt:

Code:
SQL = "UPDATE `Table` Set `var1` = '" & Replace(SmartTags("Tag1"), ",", "." &_
             "',`var2` = '" & Replace(SmartTags("tag2"), ",", "."  & "' WHERE (`Artikelnummer` = '"&Artikelnummer&"');"
 
Ich denke, es wäre sinnvoll gewesen, zuerst einmal "händisch" gebildete Strings an die DB zu senden.
Damit hättest Du mit relativ kleinem Aufwand auskundschaften können, was die DB "erwartet" bzw. welche Schreibweisen sie als fehlerhaft zurückweist oder ignoriert.
Zusätzlich auch die negativen und positiven Grenzwerte austesten, sofern Dir die entsprechende Doku der DB fehlt.

... wenn ich dort eine Real mit Nachlommastelle 0 eingebe funktioniert die Verbindung zur DB einwandfrei. ...
Wirklich mit NachKommaStelle 0? Also auch mit dem DezimalPunkt oder ggfs DezimalKomma?

Wenn erst mal klar ist, was die DB akzeptiert und was nicht, dann erst lohnt es sich, sich die Ausgabe eines Panels oder einer SPS mit den entsprechenden "Aufbereitungen" des Formats in Angriff zu nehmen.
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Das Komma wurde bei Wert 0 von der Steuerung einfach ausgelassen beim Senden. Daher hat es mit Nachkommastelle 0 funktioniert.
Das habe ich mir schon gedacht. Also war eindeutig das DezimalKomma der Auslöser des Problems.
Das hätte man bei einer "händischen" ZusammenStellung eines Strings an die DB leicht austesten können.

PS:
Der Tipp, die Kommata durch Punkte zu ersetzen, könnte auch eine Falle in sich bergen.
Falls die vorliegende, zu wandelnde Zahl bereits Punkte enthält (z.B. 1.234,56) dann müssten die vorhandenen Punkte vorher noch entfernt werden. Oder Punkte müssen durch Kommata und "gleichzeitig" Kommata durch Punkte ersetzt werden.
Zuerst alle Punkte in Kommata und dann erst alle Kommata in Punkte umwandeln (oder umgekehrt) tut's dann nicht.
Man könnte z.B. ...
1. alle Punkte durch ein garantiert nicht verwendetes Zeichen ersetzen
2. dann alle Kommata durch Punkte ersetzen
3. abschliessend noch alle Vorkommen des einen, ansonsten nicht verwendeten Zeichens, durch Kommata ersetzen.
 
Ich würde da eher schauen, ob ich die Regionale Settings alle gleich bekomme, alternativ diese wenn möglich abfragen und dann bedingt ersetzen.
 
Ich würde da eher schauen, ob ich die Regionale Settings alle gleich bekomme, alternativ diese wenn möglich abfragen und dann bedingt ersetzen.
Ja, da muss man ansetzen, an der Ursache des Problems anstatt kurzerhand Kommas in Punkte umzuwandeln oder umgekehrt. Ich habe schon WinCC Visu gesehen, wo durch solch (oft woanders abgegucktes) vermeintlich cleveres Skripting in der Visu keine Zahlen mit Nachkommastellen eingegeben werden konnten, was die Macher noch nichtmal gemerkt hatten, weil gar nicht getestet...

Harald
 
Zuviel Werbung?
-> Hier kostenlos registrieren
Man kann in die Visu erkennen ob Komma oder Punkt als Dezimaltrenner eingestellt ist:
Damit kann man z.B. ein Warnhinweis ausgeben.
 
Ehe ich in den regional settings rumwurschtel, bleibe ich lieber beim "replace". Spätestens bei einem Rechnerwechsel geht dann das große Rätselraten los warum etwas nicht mehr funktioniert.
 
Trage ich in der DB händsich eine Real mit Nachkommastellen ein, klapp das laden in die SPS auch.
Bedeutet das, Du überträgst die REAL-Zahlen in beiden Richtungen? Von der DB zur SPS/WinCC und umgekehrt?
Ich lese mittlerweile aus Deiner Beschreibung, dass die Übertragung von der DB zur SPS funktioniert mit und ohne NachKommaStellen, aber in der Richtung WinCC zur DB funktioniert es nur, wenn keine NachKommaStellen übertragen werden müssen?

Überträgst Du von der DB direkt in die SPS oder zur WinCC und von da aus weiter zur SPS?
 
Zuletzt bearbeitet:
Zuviel Werbung?
-> Hier kostenlos registrieren
Für die Richtung SQL-DB > WinCC/SPS wird kein "replace" benötigt. Hier wird die Komma Konvertierung seltsamerweise im Hintergrund durchgeführt. Deshalb klappte dieser Scriptteil des TE wohl auch.
 
Für die Richtung SQL-DB > WinCC/SPS wird kein "replace" benötigt. Hier wird die Komma Konvertierung seltsamerweise im Hintergrund durchgeführt. Deshalb klappte dieser Scriptteil des TE wohl auch.
Wirklich seltsam. Eigentlich wollte ich darauf hinaus, zu prüfen, welches "Format" in der Richtung DB -> WinCC/SPS benutzt wird und dann in der Richtung WinCC -> DB dasselbe zu benutzen.

Weiss jemand, wer bzw. was da im Hintergrund ggfs konvertiert oder auch nicht?

Edit:
Wird evtl. nie ein "Tausender Trennzeichen" verwendet, so das Komma und Punkt gleichermaßen akzeptiert werden?
Wird evtl. die Exponential-Schreibweise verwendet?
 
Zuletzt bearbeitet:
Weiss jemand, wer bzw. was da im Hintergrund ggfs konvertiert oder auch nicht?

Das lässt sich gar nicht so pauschal beantworten.
Die Regional-Einstellungen können auf jedem beteiligtem System zuschlagen.
Server, DB-Client und Applikationen.
Da hilft letztlich nur Testen und Dokumentieren.
 
Zurück
Oben