Conference orarep::nomahs::sql_services

Are they getting any sqlbugchk.dmp files?

I have a customer with very similiar problems.  He gets an sql dmp file
with exception sql$$execute_blob_get.

Hi Erich and Jerry,

I'm going to try to set up a system with Rdb 6.1-04 and see if we can reproduce
it here. Meanwhile, the common thread seems to be Rdb 6.1-04 on Alpha.

For what its worth, COSI-F-ACCVIO happens when SQL or Rdb calls COSI to probe
an argument. If the probe fails, COSI-F-ACCVIO is returned. The reason why the
executor doesn't go down is that SQL/Services doesn't know that anything nasty
has happened - it just gets back a SQLCODE of -1, which may be a valid error
code for certain user-createable error conditions, so we just feed it back to
the client; only the error text in this case is indicative of something nasty
going on. 

Erich, do you happen to have the part of the client log that contained the
prepare for this statement? I'd be interested in seeing the metadata for
this column. For example, this particular string would appear to have 1
segment of 4 bytes, ODBC meanwhile is asking for a max of 4092, which is
what it always does. In any event, it might be interesting to see how
the column is defined, which the PREPARE-ACK would tell us.

----PACKET ID: 81, PACKET SEQUENCE: 0
--------SQLSRV_OPEN_CURSOR ACK
------------SQLERRD[1]
----------------SQLSRV_GENERALIZED_NUMBER, len: 1
--------------------len: 1, value: 4		    <--longest segment length
------------SQLERRD[3]
----------------SQLSRV_GENERALIZED_NUMBER, len: 1
--------------------len: 1, value: 1		    <--number of segments
------------SQLERRD[4]
----------------SQLSRV_GENERALIZED_NUMBER, len: 1
--------------------len: 1, value: 4		    <--total size of
------------SQLERRD[5]
----------------SQLSRV_GENERALIZED_NUMBER, len: 1
--------------------len: 1, value: 0		    <--all segments
--------END OF MESSAGE

PROTOCOL LEVEL LOG CLIENT: write (logonly)
----PACKET ID: 82, PACKET SEQUENCE: 0
--------SQLSRV_FETCH
------------CURSOR NAME
----------------SQLSRV_ASCII_STRING, len: 13
--------------------len: 13, value: LST_CURB935F0
------------SELECT LIST SQLDA
----------------len: 2, value: 1
------------SQLVAR
----------------len: 2, value: 0
------------SQLLEN
----------------len: 2, value: 4092		    <--client has 4092 buffer
--------END OF MESSAGE

Jerry, did you have any luck in getting a bugcheck dump from the customer?
The SQL bugcheck dump would be interesting too.

Thanks,

Si

You can copy the full client log from node ataxp1""::CLIENT_47243.LOG (DECnet
13.1)


Thank you for looking at this.

Ciao,
	erich

>Jerry, did you have any luck in getting a bugcheck dump from the customer?
No.

>The SQL bugcheck dump would be interesting too.
Thought I had it around but can't find it.

My customer is trying to get upgraded to 6.1A and/or find a way to repro.
I figured engineering would not want to spend much time on a 6.1-04
bugcheck when that was all they had.  And luckily had an understanding
customer.

Did you find anything in the client logfile ?

Thank you,
	erich

Hi Erich,

I took a look at the client log file, but didn't see anything interesting 
in there that might indicate some form of earlier failure, or anything else
that might indicate why it might be going wrong from a SQL/Services
point of view; everything looks just as it should until the COSI-F-ACCVIO.

Does this customer have any SQL bugcheck dumps? I'm beginning to think
that's the only place left to go - if SQL wrote a bugcheck, then at least
we can figure out where it was on the stack.

Si

The ct. told me that he had no RDS* dumps, but I did not check for SQL. The
customer is not in the office, You'll here more on Monday.

Ciao,
	erich

The customer did not find any SQL bugcheckdumps in his directory, he is working
on a repcase that he'll send to me.

I'll update this note as soon as I have more info.

Thank you,
	erich

To update this stream:
I could not reproduce this problem with 6.1A and I sent the customer this
version. I got no feedback however if he installed it.
The right solution should be to run Rdb 6.1A.

erich