Different number of parses with different providers

Question

I tried to figure out
how could I control number of parsing from MS ADO app.
To my surprise it seems that there is no general way to do it.
The behaviour is heavily dependent on underlying OLEDB provider,
and for some of the providers (Oracle's own including)
I did not manage to reduce number of parses.
I wrote a simple vbs script that:
1. Opens the connection for the given provider
2. Executes ALTER SESSION SET session_cached_cursors=100
3. Creates ADO command with 'SELECT ... FROM USER_TABLES..'
     and with one parameter
4. Opens ADO recordset with this command, reads from and closes it
Here is the script:
'TestADOCommandParsing.vbs
Dim stConnectString
Dim stUID
Dim stPWD
Dim stTestTag
Dim stServer
Dim cn
Dim cmdALTER_SESSION
Dim cmdUserTables
Dim rsUserTables
Dim param
Dim nRows
Dim I
Const c_stProvider = "Ora" '"MS" '"ODBC" '
Const adVarChar = 200
Const adParamInput = 1
Const adUseServer = 2
Const adOpenStatic = 3
Const adLockReadOnly = 1
stUID = "..."
stPWD = "..."
stServer = "..."
stTestTag = "TestParsesADO_" & c_stProvider & "_1"
If c_stProvider = "MS" Then
stConnectString = "Provider=MSDAORA;" & _
"User ID=" & stUID & ";Password=" & stPWD & ";Data Source=" & stServer & ";"
ElseIf c_stProvider = "Ora" Then
'Oracle provider.
'The PLSQLRSet attribute [=1] specifies whether OraOLEDB needs to parse the PL/SQL
'stored procedures to determine if a PL/SQL stored procedure returns a rowset:
stConnectString = "Provider=OraOLEDB.Oracle;PLSQLRSet=0;" & _
"User ID=" & stUID & ";Password=" & stPWD & ";Data Source=" & stServer & ";"
ElseIf c_stProvider = "ODBC" Then
stConnectString = "Provider=MSDASQL.1;Extended Properties=" & _
"""DRIVER={Microsoft ODBC for Oracle};" & _
"UID=" & stUID & ";PWD=" & stPWD & ";SERVER=" & stServer & ";"""
End If
wscript.echo "Provider = " & c_stProvider
wscript.echo "stConnectString = " & stConnectString
     Set cn = CreateObject("ADODB.connection")
     cn.Open stConnectString
     Set cmdALTER_SESSION = CreateObject("ADODB.Command")
With cmdALTER_SESSION
.CommandType = 1 'adCmdText
.Prepared = False
.CommandText = _
"BEGIN EXECUTE IMMEDIATE 'ALTER SESSION SET session_cached_cursors=100'; END;"
Set .ActiveConnection = cn
End With
cmdALTER_SESSION.Execute
     Set cmdALTER_SESSION = Nothing
     Set cmdUserTables = CreateObject("ADODB.Command")
With cmdUserTables
Set .ActiveConnection = cn
.CommandType = 1 'adCmdText
'The Recordset parameters
'CursorLocation, CursorType, LockType
'seem to be irrelevant for reparsing of Oracle cursor.
'Oracle session_cached_cursors parameter also has no effect.
'Command.Prepared setting affects it, but only for ODBC-based provider:
'False: N parses, N executions
'True: 1 parse, N executions
.Prepared = True
.CommandText = _
"SELECT TABLE_NAME FROM USER_TABLES " & _
stTestTag & " " & _
"WHERE TABLE_NAME LIKE ? " & _
"ORDER BY TABLE_NAME"
Set param = .CreateParameter("TABLE_NAME_Pattern", adVarChar, adParamInput, 30, "%")
.Parameters.Append param
End With
     Set rsUserTables = CreateObject("ADODB.Recordset")
For I = 1 To 10
cmdUserTables.Parameters("TABLE_NAME_Pattern").Value = "QU_%"
With rsUserTables
'The Recordset parameters:
'CursorLocation, CursorType, LockType
'seem to be irrelevant for reparsing of Oracle cursor:
'.CacheSize = 100 'Irrelevant
'.CursorLocation = adUseServer 'adUseClient 'Irrelevant
'.CursorType = adOpenStatic 'adOpenForwardOnly 'Irrelevant
'.LockType = adLockReadOnly 'Irrelevant
.Open cmdUserTables
While Not .EOF
nRows = nRows + 1
.MoveNext
Wend
wscript.echo CStr(I) & ". nRows = " & CStr(nRows)
.Close
End With
Next
Before running tests:
VARIABLE SQLTextPattern VARCHAR2(100);
COLUMN HASH_VALUE FORMAT 9999999999
COLUMN SQL_TEXT FORMAT A40
COLUMN "Invalids" FORMAT 9999999
COLUMN "Parses" FORMAT 9999999
COLUMN "Execs" FORMAT 9999999
COLUMN "Parses/Execs" FORMAT 9999.99
COLUMN CH# FORMAT 999
COLUMN ROWS# FORMAT 9999
I ran TestADOCommandParsing1.vbs script 3 times with
different providers and table aliases to distinguish
SQL from different tests:
host cscript.exe TestADOCommandParsing1.vbs
After each run I changed table alias var:
EXEC :SQLTextPattern:='%TestParsesADO_Ora_1%';
or
EXEC :SQLTextPattern:='%TestParsesADO_ODBC_1%';
or
EXEC :SQLTextPattern:='%TestParsesADO_MS_1%';
and queried V$SQL, V$SYSSTAT.
Before running the tests:
SYSTEM@ADAS> SELECT NAME, VALUE
2 FROM V$SYSSTAT
3 WHERE NAME = 'session cursor cache hits'
4 ;
NAME VALUE
session cursor cache hits 91051
Test with Oracle OLEDB provider:
SELECT
          SUBSTR(SQL_TEXT,1,200) SQL_TEXT
          ,PARSE_CALLS PARSES
          ,EXECUTIONS EXECS
          ,CHILD_NUMBER CH#
          ,FIRST_LOAD_TIME
          ,ROWS_PROCESSED ROWS#
     FROM V$SQL
     WHERE SQL_TEXT NOT LIKE '%SQL_TEXT%'
          AND SQL_TEXT NOT LIKE '%SQLTextPattern%'
          AND SQL_TEXT LIKE :SQLTextPattern
     ORDER BY CH#
SQL_TEXT PARSES EXECS CH# ROWS#
SELECT TABLE_NAME FROM USER_TABLES TestP 21 0 0 0
arsesADO_Ora_1 WHERE TABLE_NAME LIKE :1
ORDER BY TABLE_NAME
SELECT TABLE_NAME FROM USER_TABLES TestP 0 10 1 230
arsesADO_Ora_1 WHERE TABLE_NAME LIKE :1
ORDER BY TABLE_NAME
SELECT NAME, VALUE FROM V$SYSSTAT...
NAME VALUE
session cursor cache hits 91062
Test with ODBC OLEDB provider:
SELECT ... FROM V$SQL ...
SQL_TEXT PARSES EXECS CH# ROWS#
SELECT TABLE_NAME FROM USER_TABLES TestP 1 0 0 0
arsesADO_ODBC_1 WHERE TABLE_NAME LIKE :V
001 ORDER BY TABLE_NAME
SELECT TABLE_NAME FROM USER_TABLES TestP 0 10 1 230
arsesADO_ODBC_1 WHERE TABLE_NAME LIKE :V
001 ORDER BY TABLE_NAME
SELECT NAME, VALUE FROM V$SYSSTAT...
NAME VALUE
session cursor cache hits 91062
Test MS OLEDB provider for Oracle:
SELECT ... FROM V$SQL ...
SQL_TEXT PARSES EXECS CH# ROWS#
SELECT TABLE_NAME FROM USER_TABLES TestP 11 0 0 0
arsesADO_MS_1 WHERE TABLE_NAME LIKE :V00
001 ORDER BY TABLE_NAME
SELECT TABLE_NAME FROM USER_TABLES TestP 0 10 1 230
arsesADO_MS_1 WHERE TABLE_NAME LIKE :V00
001 ORDER BY TABLE_NAME
SELECT NAME, VALUE FROM V$SYSSTAT...
NAME VALUE
session cursor cache hits 91062
As you see the number of parses (both soft and hard) differ from
provider to provider.
Provider Hard parses Soft parses Executions
ODBC 1 0 10     
MS for Oracle 11 0 10     
Oracle 11 10 10     
It looks like there is no way to control this 'bad' behaviour of
OLEDB providers, at least from ADO level. I looked through the docs on
Oracle provider for 8.1.6, but found nothing.
There is a temptation to drop all this stuff in favour of SQL
incapsulated in PL/SQL procedures...
Any comments?

Answer 1

D.Bender wrote:
Hello,
What's very confusing is that it doesn't always return the same number of readings. Sometimes it is 5, then 7 and afterwards 6 without changing anything. Since it is the first program for the Keithleys at work nobody can help me. I already tried highlighting execution and retain wire values. This way I saw that the VISA write command should give the correct command but the VISA read does not return the right number of readings. In addition to that I don't get any readings on the second iteration, so I can only see some on the first. The Keithley also does not show any new measurements (at least it does not show any numbers, only the typical "----").
I can't view your file but I have experience with the Keithley 2400 so here is my opinion.  
This is a common problem for new users working with buffers.  The most likely cause is that you are reading the buffer BEFORE it is full.  If you initiate the second measurement immediately, you will likely see a Keithley error caused by trying to set the buffer values while a measurement is in progress.  The keithley will immediately return the buffer contents when asked to.  You, as the programmer, must set up your LabVIEW code to wait for the buffer to fill, then read the values.  While a fixed delay before reading could work, here is a better solution.
I posted my code for a I-V sweep (set voltage, measure current over a linear range) here http://forums.ni.com/t5/LabVIEW/Error-code-110-in-​keithley-2400/m-p/2680579#M797618.  (sorry I don't have access to the files right now to upload them here.  The idea is first set the registers to watch for the buffer to become full.  When full, the SRQ bit will be set to 1.  After starting the measurement, i probe the SRQ value in a while loop.  Once it's set to 1, read the buffer and reset registers.  This method is outlined in the Keithley 24xx SMU manual (I can't remember which page).