Wie im anderen Thema erwähnt würde ich nicht den standalone Konfiguration nutzen, sondern das XAE Supplement dann ist das nicht "ausgelagert" und das Lizenzthema sollte einfacher von Statten gehen.
Desweiteren lege ich die DB und die jeweiligen Tabellen immer manuell über (bei MS SQL) die Server Management Studio (SSMS) an. Das ist recht einfach. Am längsten habe ich benötigt um die Rechtevergabe des MS SQL korrekt einzustellen damit überhaupt eine Verbindung möglich ist. Ich beschreibe kurz was ich gemacht habe (ist sicherlich nicht die beste IT technisch sicherste Lösung aber für den ersten Test ideal).
1. User im SSMS anlegen z.b. TwinCAT mit Passwort (wichtig: nicht die Windows auth.. nutzen, sondern Benutzername und Passwort)
2. Der angelegten Datenbank mit Rechtsklick-> Sicherheit-> den User TwinCat hinzufügen und alle Berechtigungen geben
3. Das muss wohl auch gemacht werden, wieso auch immer: Der angelegten Tabelle ebenfalls mit Rechtsklick->Sicherheit den User Twincat hinzufügen
Wenn das so gemacht wurde ist alles für den User Twincat geöffnet. Man kann dann auch das SSMS schließen, neu öffnen und nicht die WinAuth Methode wählen, sondern sich mit dem neu angelegten User Twincat nun hier einloggen. Dann mal einen Eintrag in der Tabelle mache ob das funktioniert. Wenn ja weiß man, dass der User Schreibrechte hat und Leserecht. Dann geht es in Twincat. Hier alles wie lt. Doku anlegen
Hier die Doku:
https://download.beckhoff.com/downl...on/twincat3/TF6420_TC3_Database_Server_DE.pdf
Auf Seite 23 seht ihr das oben erwähnte supplement anstatt der Standalonevariante
Auf Seite 24 dann direkt die Beispielkonfig für einen SQL
Ich nutze allerdings nicht die autologging Funktion, sondern einfach den FB SQLInsertEx (oder so ähnlich). Man gibt dann einfach ein SQL Statement als String an und fertig: "INSERT INTO DB.Table (xy1, xy2,xy3) VALUES ('12','23','12')
Was mir aufgefallen ist, wenn man sehr viele Inserts hintereinander durchführt kann es sein, dass diese u.U. nicht richtig durchgeführt wurden obwohl der Baustein keinen Fehler meldet. Ich habe etwas die Ursachen gesucht und ich denke es liegt an der ODBC Schicht oder was auch immer im Hintergrund die Schnittstelle zwischen TC und DB schafft.
Um das Problem zu eliminieren habe ich folgendes gemacht:
1. Interner Puffer im TC der alle zu sendende Kommandos zwischenspeichert
2. Durchlaufen dieses Puffers und z.B. 10 Datensätze auf einmal als Bulk zusammenfassen. Das sieht dann so aus:
"INSERT INTO DB.Table (xy1, xy2,xy3) VALUES ('12','23','12'), ('12','23','12'), ('12','23','12'), ('12','23','12'), ('12','23','12'), ('12','23','12'), ('12','23','12')
Dann überträgt das System mit einem Rutsch x Datensätze und die Zugrifffrequenz nimmt deutlich ab
3. Wichtig: Die Länge des Insertstrings ist begrenzt. Mit der FB EX Variante sind glaube ich 10000 Zeichen möglich. Das muss im Code halt abgefangen werden, dass der String nicht länger wird, sonst -> Problem
