Pro*C mangling our query

Question

I was wondering if anyone could help me with this problem? (I have raised an SR with Oracle, but thought I'd hedge my bets ;-)
Our Pro*C application has suddenly started screwing up one of our queries. Below is an extract from a 10046 SQL trace.
=====================
PARSING IN CURSOR #1 len=57 dep=0 uid=47 oct=3 lid=47 tim=2383911068 hv=1227232938 ad='19e2c4e0'
select zz_dbvr into :b0:b1  from zz_ where zz_dbky='0000'
END OF STMT
PARSE #1:c=0,e=486,p=0,cr=0,cu=0,mis=1,r=0,dep=0,og=4,tim=2383911063
BINDS #1:
EXEC #1:c=15625,e=2888,p=0,cr=0,cu=0,mis=0,r=0,dep=0,og=4,tim=2383946705
WAIT #1: nam='SQL*Net message to client' ela= 4 p1=1111838976 p2=1 p3=0
FETCH #1:c=0,e=35,p=0,cr=2,cu=0,mis=0,r=1,dep=0,og=4,tim=2383952308
WAIT #1: nam='SQL*Net message from client' ela= 16414 p1=1111838976 p2=1 p3=0
WAIT #1: nam='SQL*Net break/reset to client' ela= 57 p1=1111838976 p2=0 p3=0
WAIT #1: nam='SQL*Net message to client' ela= 3 p1=1111838976 p2=1 p3=0
WAIT #1: nam='SQL*Net message from client' ela= 578 p1=1111838976 p2=1 p3=0
STAT #1 id=1 cnt=1 pid=0 pos=1 obj=9602 op='TABLE ACCESS BY INDEX ROWID OBJ#(9602) (cr=2 r=0 w=0 time=25 us)'
STAT #1 id=2 cnt=1 pid=1 pos=1 obj=9603 op='INDEX UNIQUE SCAN OBJ#(9603) (cr=1 r=0 w=0 time=13 us)'You'll notice it's trying to select into ':b1:b0', which is obviously not correct.
But then, according to the trace file, Oracle goes ahead with the PARSE, EXECUTE and FETCH steps with no problem. The FETCH appears to be correctly fetching the one row. There's even a query plan when the cursor is closed.
But our Pro*C application is reporting an error, SQLCODE = -162. This is consistent with the 'SQL*Net break/reset to client' event.
Has anybody seen this before?
Things that are weird:
1. Error ORA-00162 is "external dbid length string is greater than maximum (string)" and this does not appear relevent.
2. Query has bad syntax but appears to parse, execute and fetch ok.
3. Get 'SQL*Net break/reset to client' but this running on the server, so not expecting network problems.
4. OBJ#(9602) and OBJ#(9603) do not correspond to the OBJECT_IDs of the table and index in the query - I thought they should.
Oracle 9.2.0.1 on Windows 2003 r2 32-bit.
Thanks for any help.

Answer 1

Hi Jonah,
Thanks for your interest, and sorry for my late reply.
1. This was the weirdest problem and I never get to the bottom of it, even with Oracle support's help. The SQLCODE returned changed randomly from day-to-day and was masking the true problem (which was just some simple TNS issue).
2. This was my ignorance. The syntax :b0:b1 means that b0 is the regular bind variable, and b1 is an 'indicator' variable - used to indicate whether the value of b0 is null. I guess this is necessary when your bind variable has no concept of 'null', like C/C++ int and bool.
http://download.oracle.com/docs/cd/B19306_01/appdev.102/b14407/pc_02prc.htm#i2000
3. Don't know too much about why this was in the trace file...
4. This was my mistake - running in the wrong database!