Applies To:
  • CitectSCADA 3.xx, 4.xx, 5.xx
Summary:
1. If SQLConnect() is called and the ODBC source is unavailable (due to a network error), all Citect's tasks hang up for about 30 seconds.

2. During the execution of a series of query statements, any keystrokes in Citect get 'eaten' and the computer will error beep upon any kind of operator input.  After completion of the query normal operation is restored.

 

Solution:
1. ODBC calls are blocking functions and it is not recommended that they be executed on a Citect Server.  If you execute SQL calls on a Citect Client, only that client is affected and there is no effect on I/O, Alarms, etc.

2. Since the ODBC calls are blocking, it is recommended to find out which queries take the longest to execute.  For example: using codetrace() you may find some statements take a long time slice to execute (~150mSec in this case);

1 Running

1 SQLExec(0,"SELECT * FROM RECIPE WHERE RNUMBER = 1234 AND VESSEL = 'C3P'");

1 0 = SQLExec(); 154 ms

1 Preempted

1 End Running Slice 162 ms

Once you find the bottlenecks add a Sleep() function in between query statements in your cicode to improve the performance of Citect as shown below;

sSQL = "SELECT * FROM RECIPE WHERE RNUMBER =" + StrTrim(sFNLA) + " AND VESSEL = '" + sID + "'";
iStatus = SQLExec(hMyFile, sSQL);
Sleep(2);

Add the Sleep() after the SQLExec() functions that take the longest time to execute.

If SQL queries require a lot of execution time, it is also an idea to consider using 'stored procedures'.  Then the query is executed at the database side, and not in Citect. For more information on this see Kbase articles Q1813, and Q1843.

CIT has confirmed this to be a problem in Citect for Windows version 1.10 to 5.21.  We are researching this problem and will post new information here as it becomes available.

 
Keywords:
 

Attachments