Think your spot on about the connection pooling...doing a runnning test at the moment to see how long it takes for the db server to flush any open connections.
And yes your correct in that the number of connections allowed is licensed based and at the moment it's only allowing 1 connection. however without checking the connection is already open and just re-opening a new connection it would max out the number of licensed connections anyway....but atleast think i'm getting somewhere now. and yeah think i will implement an script connector to handle all incoming messages, but would still prefer the 'easy' approach of using your SQL connector for outgoing messages as these require no pre-processing.
Will let you know how I get on, but if you have any more thoughts, specially about whether the rollback error would potentially be fatal and stop further reconnects, please let me know.
Interesting, this is exactly how the SQL Connector opens a new database connection for every transaction (Except that it is implemented with the "using" clause. Apparently the ODBC driver treats opening the database connection from the SQL Connector and from the Scripting Connector differently. This also indicates that the database probably only supports one connection at the same time.
I actually implemented something similar in the mean time and was trying to implement a database connection and found something interesting using:
OdbcConnection Conn = new System.Data.Odbc.OdbcConnection("DSN=ClearSCADA;LOCATION=MAIN;UID=xxxx;PWD=xxxx;LOCALTIME=False;");
That actually revives the SQL Connector...bizzare. although for some reason the SQL Connector then appears failed for about 5-10sec after the timer next executes the above (probably because now the connection really is already open). Thinking that I might be able to put some sort of check in prior to trying to open the connection again.
You can use scheduled events in a script with the Timer object. The code snippet below shows how to use the timer. It is important to disable the timer when the Scripting Connector is stopped, the (old) script stays in memory and the event will still fire when it is not needed any more.
This will not solve your problem with the database connection since there is no way from a script to influence the SQL Connector.
public void OnLoad(IScriptHost host)
this.host = host;
// Create a new Timer object that calls OnTimedEvent
myTimer = new System.Timers.Timer(10000);
myTimer.Elapsed += new System.Timers.ElapsedEventHandler(OnTimedEvent);
myTimer.Enabled = true;
public void OnUnload()
// Important! Disable the timer before unloading the Scripting Connector
myTimer.Enabled = false;
myTimer = null;
private void OnTimedEvent(object source, System.Timers.ElapsedEventArgs e)
// Show the timer event in the Event Log
PostEventLog("OnTimedEvent called", "", EventLog.Information);
I'm also thinking of using the scripting connector for sending certain messages after other criteria is met...ie. file exists, etc. I can see in the c# skeleton script that there is an onload event, but the other event handlers are just for messages received. What would be the best way to run a scheduled operation in this code? ie. Add a timer to the onload function which calls my schedule function?
I'm thinking this may also solve my database reconnection issue (as documented in last post). ie. I could possibly put some odbc connection code in there that checks if the connection is alive, else tries to reconnect, etc. Don't suppose you have some example c# code handy?
Most Users Ever Online: 494
Currently Browsing this Page:
Guest Posters: 390
Newest Members:, Henk Helmantel
Administrators: Henk Helmantel: 610