Two Process Instances Using SQL 6.5 SPs Return Different Values

Two Process Instances Using SQL 6.5 SPs Return Different Values

Post by Pat Harm » Wed, 14 Apr 1999 04:00:00



This is a similar to a problem that I reported about four weeks ago.

Under SQL Server 6.5/SP5a on an Alpha running NT 4.0 Service Pack 4. If I
execute two instances of a MS C console program at the same time, which
extract their
data from complex read only SQL Server Stored Procedure Cursors via ODBC 3,
sometimes
the data is the same, sometimes not   :-(

It also cannot be predicted when the data will not match. If the program is
executed, multiple times in a sequential fashion, this is not a problem, the
output always matches. Note, that when the outputs do not match, neither
match the output that comes from any of the good concurrent or sequential
executions.

Coming from a mainframe environment, is there something obvious that I'm
missing here ? Is their some extra locking that I have to control. My only
hint so far,
is that the fields that appear to differ are subject to the CONVERT
statement
of a DECIMAL field to a SMALLINT field egCONVERT(SMALLINT, weight * 100).
Does SQL Server 6.5 have some thread safety problems ?

Regards
Pat Harms

 
 
 

Two Process Instances Using SQL 6.5 SPs Return Different Values

Post by Pat Harm » Fri, 16 Apr 1999 04:00:00


A new twist has developed ;^} . On a slower machine, with less memory (128
Mb compared to 1GB). The problem occurs for non-concurrent execution.

On this machine, if SQL Server is restarted, the query run, several separate
C programs/calling read-only Cursor/SPs via ODBC, when the procedure cache
gets between 60 and 75 % allocated, a rerun of the query returns NULL for
the DECIMAL column !!

Has anyone seen this before, or anything similar.

Regards
Pat Harms


>This is a similar to a problem that I reported about four weeks ago.

>Under SQL Server 6.5/SP5a on an Alpha running NT 4.0 Service Pack 4. If I
>execute two instances of a MS C console program at the same time, which
>extract their
>data from complex read only SQL Server Stored Procedure Cursors via ODBC 3,
>sometimes
>the data is the same, sometimes not   :-(

>It also cannot be predicted when the data will not match. If the program is
>executed, multiple times in a sequential fashion, this is not a problem,
the
>output always matches. Note, that when the outputs do not match, neither
>match the output that comes from any of the good concurrent or sequential
>executions.

>Coming from a mainframe environment, is there something obvious that I'm
>missing here ? Is their some extra locking that I have to control. My only
>hint so far,
>is that the fields that appear to differ are subject to the CONVERT
>statement
>of a DECIMAL field to a SMALLINT field egCONVERT(SMALLINT, weight * 100).
>Does SQL Server 6.5 have some thread safety problems ?

>Regards
>Pat Harms