INVALID OREF message

[sue]

Hello,
I am try to access a SQL Server database from a ensemble business
operation with an outbound sql adapter. I have created the DSN and a
credential. I set the query up, then call
set tSC = ..Adapter.ExecuteQuery(.tResult,query)
When the next line do tResult.Next() is executed it gives the INVALID
OREF error implying it cannot find the tResult value.
Does anyone have any idea what is or how I can find out what is
wrong.
Thanks
Sue

[Anthony Beukes]

Hi Sue,

I would expect that the ExecuteQuery() method failed for some reason,
possibly a problem in the query.

Have a look at the status code returned in "tSC".

You can try something like the following to trace the error:

...
set tSC = ..Adapter.ExecuteQuery(.tResult,query)

if $$$ERROR(tSC) $$$TRACE($system.Status.DisplayError(sc))
...

Regards
Tony

[Ted Peck]

Anthony, thanks for giving her this good advice to check the error status.
However I think $system.Status.DisplayError() does its output to the current
device, not to its return value. Also the status is in tSC, not sc, and the
correct macro is $$$ISERR, not $$$ERROR. Technically the proper line would
be

> if $$$ISERR(tSC) $$$TRACE($$$StatusDisplayString(tSC))

However even this is redundant because the framework will log the error if
she just returns it, like this:

> Set tSC = ..Adapter.ExecuteQuery(.tResult,query)
> If $$$ISERR(tSC) Quit tSC
> While tResult.Next() {

> ...

Ted

[Patrick McGibbon]

Hi all,

 

Working on a system upgrade at a UK hospital.

 

Ensemble routes order results message to (new version of) PAS (ORU^R01) and PAS should send an ACK.

 

This is an Ensemble routing production that worked fine with previous version of PAS.

 

Ensemble is complaining with the following error message:

 

ERROR <Ens>ErrTCPTerminatedReadTimeoutExpired: TCP Read timeout (5) expired waiting for terminator SegDelimAscii=13,on

 

 

Has anyone seen this before?

 

This happens for many, but not all, of the results messages we send through.  This message type is the only one we are sending on this operation, so the type may not be significant.

 

It’s almost as if the ACK is missing a carriage return.  If we’re even getting the ACK…

 

Our next steps are to put WireShark on the tcp connection to see exactly what’s going back and forth, but if it’s an obvious one that someone has seen before, then maybe you can save us some work.

 

BTW, I’ve tried messing around with the Framing property on the operation, but to no (useful) effect.

 

cheers,

Pat

 

ps Sorry I truncated the error message – but I think the important bit is there.  I can get the complete message later on when I’m back on-site, if it helps.  Ditto $zv.

 

 

--------------------------------------------------------------

 

Pat McGibbon

Sales Engineer

Intersystems (UK)

+44 (0)1753 855450 (office)

+44 (0)7786 396469 (mobile)

 

 

 

Intersystems Ensemble: The Integration of Power and Ease http://www.intersystems.co.uk/ensemble

Intersystems Caché: Make Applications Faster http://www.intersystems.co.uk/cache

[Dale du Preez]

Hi Pat,

In general, getting a full trace on the communication is the best approach for this sort of problem. In my experience, there is a single character missing somewhere from ACKs that make the ACK not conform to any particular framing, and the quickest way to catch this is to trace what each system is sending. Given that the error isn't happening all the time, this may be somewhat expensive, but I've found from my experiences that taking one step outside Ensemble makes this much easier.

Let me know if you can (or can't) get a trace - I'll be more than happy to look through it.

Yours,
Dale

-----Original Message-----
From: Ensemble-in...@googlegroups.com on behalf of Patrick McGibbon
Sent: Sun 2008/11/16 09:19 AM
To: Ensemble-in...@googlegroups.com
Subject: [InterSystems-EnsHlth] Ensemble not coping with dodgy ACK, we think

Hi all,



Working on a system upgrade at a UK hospital.



Ensemble routes order results message to (new version of) PAS (ORU^R01) and PAS should send an ACK.



This is an Ensemble routing production that worked fine with previous version of PAS.



Ensemble is complaining with the following error message:

<http://nhslensemblecl:1972/csp/lothian/UtilEnsMsgTrace.csp?$ID1=95813880> 

ERROR <Ens>ErrTCPTerminatedReadTimeoutExpired: TCP Read timeout (5) expired waiting for terminator SegDelimAscii=13,on





Has anyone seen this before?



This happens for many, but not all, of the results messages we send through.  This message type is the only one we are sending on this operation, so the type may not be significant.

It's almost as if the ACK is missing a carriage return.  If we're even getting the ACK...

Our next steps are to put WireShark on the tcp connection to see exactly what's going back and forth, but if it's an obvious one that someone has seen before, then maybe you can save us some work.



BTW, I've tried messing around with the Framing property on the operation, but to no (useful) effect.



cheers,

Pat

ps Sorry I truncated the error message - but I think the important bit is there.  I can get the complete message later on when I'm back on-site, if it helps.  Ditto $zv.

[Ted Peck]

The truncated portion of the error message ought to include any partial data that was received before the timeout.  In other words if there was really an ACK there but missing a CR, you would see it here. Also an ACK normally includes several lines (segments) ; if this was a framing error then you would only see this error on the last line.

[Patrick McGibbon]

Just for follow up, we did put WireShark on the Ensemble box and we could see that we were not getting the ACK at all.

 

Turns out that the results message is getting corrupted by the time it arrives at the PAS, so it gets confused and never ACKs.

 

We know that the ORU was good when it left the Ensemble machine, thanks to WireShark again.  We are now going through the fun of tracing traffic on the PAS Unix box.

 

cheers,
Pat

--------------------------------------------------------------

Pat McGibbon
Sales Engineer
Intersystems (UK)
+44 (0)1753 855450 (office)
+44 (0)7786 396469 (mobile)

 

Intersystems Ensemble: The Integration of Power and Ease http://www.intersystems.co.uk/ensemble
Intersystems Caché: Make Applications Faster http://www.intersystems.co.uk/cache

<BR