[roseg]

You’re referring to the global variables ($$) that are defined in D:\healthcomm\cloverleaf\cis19.1\integrator\master\AppDefaults\globalVariables.ini, for example.
However – as far as I understand – these variables cannot be used to store objects like DB connections.

Global variables created within a Tcl script (e.g., global dbConnection) are only valid within the scope of that specific script execution.

We’re currently using Cloverleaf 19.1 and already make use of Cloverleaf global variables ($$) in several Xlates.

Best regards,
Robert

Du meinst die Globalen Variablen ($$), die z. B. in der D:\healthcomm\cloverleaf\cis19.1\integrator\master\AppDefaults\globalVariables.ini definiert werden.
Diese Variablen können aber – nach meinem Verständnis – nicht für Objekte (z. B. DB-Verbindungen) genutzt werden.

Globale Variablen, die im TCL-Umfeld erstellt werden (z. B. global dbConnection), gelten hingegen nur innerhalb des aufgerufenen Scripts.

Wir setzen aktuell Cloverleaf 19.1 ein und nutzen bereits Cloverleaf Globale Variablen ($$) in mehreren Xlates.

Grüße
Robert

[roseg]

From my understanding, the following types of global variables exist:

💡 Quick Comparison:

Criterion | TCL global variable | Cloverleaf globalSet variable
———————————————————————————————–
Scope | Only during script runtime | Across messages (per process)
Visibility | Local to the thread | In the shared memory of the Cloverleaf site
Lifetime | Until script ends | Until process restart or global unset
Example | global myVar | globalSet myVar “abc”
Use for persistent DB connection? | ❌ No | ⚠️ Limited (not suitable for objects like DB handles!)
However, neither of the two options seems suitable for my goal.

Is Rob perhaps referring to a third possibility here?

Nach meinem Verständnis gibt es folgende globale Variablen:

💡 Vergleich auf einen Blick:

Kriterium | TCL global Variable | Cloverleaf globalSet Variable
———————————————————————————————–
Gültigkeit | Nur während Script-Laufzeit | Über Nachrichten hinweg (pro Prozess)
Sichtbarkeit | Lokal im Thread | Im Shared Memory der Cloverleaf-Site
Lebensdauer | Bis Script-Ende | Bis Prozess-Neustart oder global unset
Beispiel | global myVar | globalSet myVar “abc”
Nutzung für persistente DBConn? | ❌ Nein | ⚠️ Eingeschränkt (nicht für Objekte wie DB-Handles!)
Aber keine der beiden Varianten ist zielführend für mein Vorhaben.

Spricht Rob hier eventuell von einer dritten Möglichkeit?

• This reply was modified 3 weeks, 1 day ago by roseg.
• This reply was modified 3 weeks, 1 day ago by roseg.
• This reply was modified 3 weeks, 1 day ago by roseg.

[roseg]

Thank you for the feedback!

We had also already tried the global variable approach, but unfortunately we weren’t successful with it.
We even implemented a fallback that checked whether the variable had a value – and if it was empty, a new connection was established.
Unfortunately, the variable was always empty on each run of the Tcl script.

Unfortunately, we no longer have the script, but I’m quite sure we had everything inside the “run” section, which may have been the mistake?

How exactly should the code in the “start” section look?
<pre>start {
# Define a global variable
global dbConnection

# Establish database connection
if {$dbConnection eq “”} {
puts stdout “No connection found, creating new one…”
set connStr “Driver=SQL Server;DATABASE=cl_orderentry;UID=USER;PWD=PASS;Server=SQL-SERVER”
if {[catch {
tdbc::odbc::connection create dbConnection $connStr
} result]} {
puts stdout “Error: $result”
return {}
}
}
}

run {
[…]
set sqlstmnt “select Nachrichten from $dbtbl where Fallnummer = ‘$fallnr’ and Freischaltdatum is not null”
set free [dbConnection allrows $sqlstmnt]
[…]
}

shutdown {
dbConnection close
}

Vielen Dank für die Rückmeldungen!</pre>
Den Ansatz mit der globalen Variable hatten wir auch schon verfolgt, waren damit aber leider nicht erfolgreich.
Wir hatten sogar ein Fallback implementiert, das prüft, ob die Variable Inhalt hat – und wenn sie leer war, wurde eine neue Verbindung aufgebaut.
Leider war sie jedoch bei jedem Durchlauf des Tcl-Skripts immer leer.

Das ursprüngliche Skript haben wir leider nicht mehr, aber ich bin mir ziemlich sicher, dass wir alles im “run”-Teil untergebracht hatten – was eventuell schon der Fehler war?

Wie genau müsste der Teil im “start”-Abschnitt aussehen?
<pre>start {
# Definition einer globalen Variable
global dbConnection

# Datenbankverbindung aufbauen
if {$dbConnection eq “”} {
puts stdout “Verbindung nicht vorhanden, erstelle neue…”
set connStr “Driver=SQL Server;DATABASE=cl_orderentry;UID=USER;PWD=PASS;Server=SQL-SERVER”
if {[catch {
tdbc::odbc::connection create dbConnection $connStr
} result]} {
puts stdout “Fehler: $result”
return {}
}
}
}

run {
[…]
set sqlstmnt “select Nachrichten from $dbtbl where Fallnummer = ‘$fallnr’ and Freischaltdatum is not null”
set free [dbConnection allrows $sqlstmnt]
[…]
}

shutdown {
dbConnection close
}</pre>

[roseg]

Thank you very much for the quick response!

We have a DB server with a single database containing many tables that are accessed via Cloverleaf. Several routes therefore need to establish and tear down a connection to this DB server, the database, and the respective tables in parallel.

The central IB thread (Process1) distributes to 6 dispatcher threads (each in its own process). These dispatcher threads in turn distribute to around 10 destination threads each (in the OB site). Dispatcher and destination threads run in the same process.

In our current TCL script, we are using standard TCL methods:

tcl
package require tdbc::odbc set connStr {Driver=SQL Server;DATABASE=**********;UID=**********;PWD=**********;Server=**********}

tdbc::odbc::connection create db $connStr

…to establish and close the database connection.

Another approach we tried was using a Database-Inbound and a Database-Outbound thread. These connect via the database configurations defined in Cloverleaf (Options -> Site Preferences -> Database Configurations ->
jdbc:sqlserver://<server>:<port1433>;DatabaseName=<database>
[Driver Class: com.microsoft.sqlserver.jdbc.SQLServerDriver]
[mssql-jdbc-6.2.2.jre8.jar])

Are these the “Data Direct ODBC Drivers” you were referring to?

When using the DB-Inbound and DB-Outbound threads, we are currently failing to pass an SQL statement or parameters for a stored procedure from the TCL script to the thread.

If possible, we would like to establish one database connection per site — or per process — to a shared/central database that can then be used by all threads (regardless of which process they belong to).

Any insights & experiences would be greatly appreciated! 🚀

 

Vielen Dank für die schnelle Rückmeldung!

Wir haben einen DB-Server mit einer Datenbank, die viele Tabellen enthält, auf die über Cloverleaf zugegriffen wird. Mehrere Routen müssen daher parallel eine Verbindung zu diesem DB-Server, zur Datenbank und zu den jeweiligen Tabellen aufbauen und auch wieder abbauen.

Der zentrale IB-Thread (Process1) verteilt auf 6 Dispatcher-Threads (jeweils 1 Prozess). Diese Dispatcher-Threads verteilen weiter an jeweils ca. 10 Destination-Threads (in die OB-Site). Dispatcher-Threads und Destination-Threads laufen im selben Prozess.

Im aktuellen TCL-Skript verwenden wir Standardmittel von TCL:

tcl
package require tdbc::odbc set connStr {Driver=SQL Server;DATABASE=**********;UID=**********;PWD=**********;Server=**********}

tdbc::odbc::connection create db $connStr

…um die Datenbankverbindung aufzubauen und wieder zu schließen.

Ein anderer Ansatz war, einen Database-Inbound- und einen Database-Outbound-Thread zu verwenden. Diese Threads verbinden sich über die in Cloverleaf konfigurierten Datenbanken (Options -> Site Preferences -> Database Configurations ->
jdbc:sqlserver://<server>:<port1433>;DatabaseName=<database>
[Driver Class: com.microsoft.sqlserver.jdbc.SQLServerDriver]
[mssql-jdbc-6.2.2.jre8.jar])

Sind das die “Data Direct ODBC-Treiber”, die du meinst?

Bei der Verwendung von Database-Inbound- und Outbound-Threads scheitern wir aktuell an der Übergabe eines SQL-Statements bzw. an der Übergabe von Parametern für Stored Procedures aus dem TCL-Skript an den Thread.

Falls möglich, möchten wir gerne pro Site oder alternativ pro Prozess eine Verbindung zu einer gemeinsamen bzw. zentralen Datenbank aufbauen, die dann von allen Threads (egal in welchem Prozess) verwendet werden kann.

Wir freuen uns über jeglichen Input & Erfahrungen! 🚀

• This reply was modified 3 weeks, 6 days ago by roseg.

[roseg]

Hello Rob,
thank you for the fast feedback.

We start the engine right after we start the site daemon. I can’t say for sure whether the Lock Manager is running, where can I check?

“Are you starting as a different user…”
Yes, the script is executed under a different user.

“remove the “rdm.taf”…”
That worked straight away, but what does rdm.taf do? and would there be another way without deleting files?

We just noticed during testing that our script to stop the monitor daemon gives the following feedback:
“Killing hcimonitord

The syntax of the command is incorrect.
Unable to invoke hcicmd:
”
Despite the feedback, the Monitor Deamon is stopped.
Maybe we are doing something wrong here that will prevent the processes from starting later?

We stop the monitor daemon with the following command:
[code]Start-Process -FilePath “$env:HCIROOT\bin\perl.exe” -ArgumentList “-I $env:HCIROOT\lib\perl5 -I $env:HCIROOT\bin $env:HCIROOT\bin\hcisitectl.pl -k m”[/code]

Thanks for all replies

Greetings

[Author]

Replies