Applies To:
  • CitectSCADA X.xx
Summary:
I am performing SQL updates/inserts to an Oracle database on the I/O server. The inserts are triggered by defined events (there are three) on the I/O server. Each of the events calls the same Cicode function with different parameters. I am assuming that each event will cause a new thread to be spawned for this function.

The function performs correctly 99% of the time. When it fails, the error status returned from SQLExec is 274, but the individual query strings I link together (using SQLAppend) do form a legal SQL statement (I have actually cut and pasted from my error log file to Oracle's SQL Worksheet and executed the statement successfully).

My question is: is the 'SQL buffer' referred to in the SQLAppend help topic a shared resource? And if it is, should it be? I really cannot come up with a better way to explain why I would get a 274 error message on the SQLExec function call.

 

Solution:
The error 274 'Invalid argument' in association with the SQL functions will normally mean that the handle to the SQL functions is invalid. This could be the result of another thread closing the connection. The 'SQL Buffer' is shared for each handle to an SQL connection. If you are opening the connection to your database outside of your common function, then the buffer will be shared and this may be the cause of your problem. You can fix this by putting a critical section around the code to protect this. Something like this:

INT hSQL; // global handle, connected at startup

FUNCTION
YourFunction()

EnterCriticalSecion("MySQL");

SQLSet(hSQL, "<your SQL command>")
SQLAppend(hSQL, "<more SQL commands>");
SQLExec(hSQL, "");

LeaveCriticalSection("MySQL");

END

 
Keywords:
 

Attachments