Thanks Scott, it was actually the DC AI and a few of the forums that appear to indicate that you could set "%String(MAXLEN = "")", but I have since updated the datatype to "%VarString" instead which I believe is the better choice.

I have now fixed my "Invalid precision value" error. Adding context below for anyone who runs into the same issue I did:

I'd started the debugging session by starting an ODBC trace, and then restarting the Business Operation. From the information I had seen online, the operation you need tracing must be restarted after the ODBC trace has been started, otherwise the trace won't be written to the ODBC .LOG file.

Once the trace had started and Business Operation restarted, I'd sent in a ORU^R01 result, processed it within my Business Operation and the same error "Invalid Precision Value" occurred. 

The ODBC log file, contained the following output:

mgr"            610c-ed8 ENTER SQLBindParameter 
HSTMT               0x0000020D973CB220 
UWORD                        8 
SWORD                        1 <SQL_PARAM_INPUT> 
SWORD                       -8 <SQL_C_WCHAR> 
SWORD                       12 <SQL_VARCHAR> 
SQLULEN             2147483647 
SWORD                        0 
PTR                0x0000020D9AEFF5E0 
SQLLEN                   257 
SQLLEN *            0x0000020D97055BD0 

mgr"            610c-ed8 EXIT  SQLBindParameter  with return code -1 (SQL_ERROR) 
HSTMT               0x0000020D973CB220 
UWORD                        8 
SWORD                        1 <SQL_PARAM_INPUT> 
SWORD                       -8 <SQL_C_WCHAR> 
SWORD                       12 <SQL_VARCHAR> 
SQLULEN             2147483647 
SWORD                        0 
PTR                0x0000020D9AEFF5E0 
SQLLEN                   257 
SQLLEN *            0x0000020D97055BD0

With some assistance from ClaudeAI, I was able to interpret the "problematic" value was with the "SQLULEN" parameter and the ODBC driver not accepting an infinite fixed precision value for normal binding.

From reading similar posts on the forum, one suggestion was to treat the string as a LOB. To do that I'd updated my Business Operation logic so the observationtext was being written to a stream.

        Set observationtextstream = ##class(%Stream.TmpCharacter).%New() 
        Do observationtextstream.Write(pRequest.observationtext) 
        Set params(8) = observationtextstream
        ....
        Set status = ..Adapter.ExecuteProcedureParmArray(,,query,"iiiiiiiii",.params)
        ....
        kill observationtextstream
        Return status

Because I have no need to interact with this property anywhere else, I've used the TmpCharacter stream class.

Once the logic was in place, I then restarted my BusinessOperation, resubmitted the ORU^R01 message, and the binding worked without any issue and successfully inserted the message into the table. I'm sure this approach is probably overkill, but it's the only way I've managed to get the ODBC/ObjectScript to play nicely together!

Thanks Scott, this is really helpful, and much appreciated for taking the time to respond.

I've now got my classes more organised, and everything from a syntax perspective I believe is correct, however, I am still running into an issue when the BusinessOperation tries to bind the parameters, and I believe it's something to do with me using varchar (max) in my SQL table.

There actual error text is this:

ERROR #6022: Gateway failed: BindParameters. 
ERROR <Ens>ErrGeneral: SQLState: (HY104) NativeError: [0] Message: [Microsoft][ODBC Driver 18 for SQL Server]Invalid precision value

The same error occurs regardless of SQL ODBC driver I use, so I get the impression the issue is actually with the BusinessOperation, rather than with the ODBC or database.

When I run the stored procedure directly in SSMS with the exact same data contained within the "PatientRequest" (listed below) object it runs without any issues, so that rules out a stored procedure issue in my eyes.

Here is my basic BusinessOperation:

Class JWDEV.SQLTesting.JWDEVBusinessOperation Extends Ens.BusinessOperation 
{ 

Parameter ADAPTER = "EnsLib.SQL.OutboundAdapter"; 

Property Adapter As EnsLib.SQL.OutboundAdapter; 

Parameter INVOCATION = "Queue"; 

Method OnMessage(pRequest As JWDEV.SQLTesting.PatientRequest, Output pResponse As JWDEV.SQLTesting.PatientResponse) As %Status 
{ 
    Try{ 

        Set query = "{call dbo.sp_insert_or_update_radiologyreports(?,?,?,?,?,?,?,?,?)}" 
        Set params = 9 
        Set params(1) = pRequest.patientid 
        Set params(2) = pRequest.accession 
        Set params(3) = pRequest.patientname 
        Set params(4) = pRequest.dob 
        Set params(5) = pRequest.sex 
        Set params(6) = pRequest.placerordernumber 
        Set params(7) = pRequest.universalserviceid 
        Set params(8) = pRequest.observationtext 
        Set params(9) = pRequest.observationdatetime 
        Set status = ..Adapter.ExecuteProcedureParmArray(,,query,"iiiiiiiii",.params) 

        If $$$ISERR(status){ 
            $$$LOGERROR($SYSTEM.Status.GetErrorText(status)) 
            Return status 
        } 
        Return status 

    } Catch(ex) { 
        Set status = ex.AsStatus() 
        $$$LOGERROR($SYSTEM.Status.GetErrorText(status)) 
        return status 
    } 
} 

} 

Here is the Request Class:

Class JWDEV.SQLTesting.PatientRequest Extends Ens.Request 
{ 

Property patientid As %String(MAXLEN = 50); 

Property accession As %String(MAXLEN = 50); 

Property patientname As %String(MAXLEN = 200); 

Property dob As %String(MAXLEN = 25); 

Property sex As %String(MAXLEN = 10); 

Property placerordernumber As %String(MAXLEN = 25); 

Property universalserviceid As %String(MAXLEN = 150); 

Property observationtext As %String(MAXLEN = ""); 

Property observationdatetime As %String(MAXLEN = 25); 

Storage Default 
{ 
<Data name="InsertDataDefaultData"> 
<Subscript>"InsertData"</Subscript> 
<Value name="1"> 
<Value>name</Value> 
</Value> 
<Value name="2"> 
<Value>mrn</Value> 
</Value> 
<Value name="3"> 
<Value>patientid</Value> 
</Value> 
<Value name="4"> 
<Value>accession</Value> 
</Value> 
<Value name="5"> 
<Value>patientname</Value> 
</Value> 
<Value name="6"> 
<Value>dob</Value> 
</Value> 
<Value name="7"> 
<Value>sex</Value> 
</Value> 
<Value name="8"> 
<Value>placerordernumber</Value> 
</Value> 
<Value name="9"> 
<Value>universalserviceid</Value> 
</Value> 
<Value name="10"> 
<Value>observationtext</Value> 
</Value> 
<Value name="11"> 
<Value>observationdatetime</Value> 
</Value> 
</Data> 
<DefaultData>InsertDataDefaultData</DefaultData> 
<Type>%Storage.Persistent</Type> 
} 

} 

Here is my SQL table schema:

[PatientID] [nvarchar](50) NOT NULL, 
[AccessionNumber] [nvarchar](50) NOT NULL, 
[PatientName] [nvarchar](200) NOT NULL, 
[DOB] [nvarchar](25) NOT NULL, 
[Sex] [nvarchar](10) NOT NULL, 
[PlacerOrderNumber] [nvarchar](25) NOT NULL, 
[UniversalServiceID] [nvarchar](150) NOT NULL, 
[ObservationText] [nvarchar](max) NOT NULL, 
[ObservationDateTime] [nvarchar](25) NOT NULL, 
[DateTimeInserted] [datetime] NOT NULL, 
 CONSTRAINT [PK_Radiology_Reports] PRIMARY KEY CLUSTERED 
( 
[PatientID] ASC, 
[AccessionNumber] ASC 
)

I'm not sure whether varchar (max) needs to be handled different compared to other varchar types in ObjectScript. I did see it was possible to explicitly define parameter types within "Specifying Parameters in an InterSystems IRIS Multidimensional Array", and I had attempted this, but I've not had any success as of yet.

Have you had any experience with this error or how to correctly handle varchar (max) datatypes in ObjectScript?

Thanks for commenting, Mark, and sorry for the late response!

I can only imagine that this was the issue, as at times the engine used to run very slowly and it seemed to match the times when the rule wouldn't load.

We've since updated the engine infrastructure and it appears to have resolved this issue as it hasn't come back since!

Thanks,

Josh

Hi Prasanth,

Thanks for your reply, this is great news!

I presume that there is no special characters or format that I'd need to use in this case, I could simply do the following and it would work:

I would test this theory, but unfortunately our IE is heavily locked down and needs firewall rules enabling before I can test.