ADO.NET/SQL Mystery

In using two different SQL Database server (one for
development and one for production) a call to a stored
procedure is storing incorrect data. We use ADO.NET SQL
Data Adpaters and have set the stored procedure
parameters. Tracing through on the debugger shows the
correct data in the dataset but the SQL Profiler shows
that the second parameters is coming in as a -1 (which is
not the data in the dataset). To make matters worse this
only occurs on the Development sever with the production
server executing without error.

What could be the difference in the two servers that
parses the ADO.NET interface parameters?

William
Mon Oct 27 10:38:54 CST 2003

The code being executed is not the same as the code you're testing with?

--
____________________________________
Bill Vaughn
MVP, hRD
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________

"Perley" <anonymous@discussions.microsoft.com> wrote in message
news:075e01c39c85$8bb31a60$a101280a@phx.gbl...
> In using two different SQL Database server (one for
> development and one for production) a call to a stored
> procedure is storing incorrect data. We use ADO.NET SQL
> Data Adpaters and have set the stored procedure
> parameters. Tracing through on the debugger shows the
> correct data in the dataset but the SQL Profiler shows
> that the second parameters is coming in as a -1 (which is
> not the data in the dataset). To make matters worse this
> only occurs on the Development sever with the production
> server executing without error.
>
> What could be the difference in the two servers that
> parses the ADO.NET interface parameters?

Patrice
Mon Oct 27 10:47:08 CST 2003

Not having the same pramater probably explians the different result set...

Now it would interesting to see from where comes this parameter (another
query ?). Most of these problems are likely related to different data.

Patrice

--

"Perley" <anonymous@discussions.microsoft.com> a écrit dans le message de
news:075e01c39c85$8bb31a60$a101280a@phx.gbl...
> In using two different SQL Database server (one for
> development and one for production) a call to a stored
> procedure is storing incorrect data. We use ADO.NET SQL
> Data Adpaters and have set the stored procedure
> parameters. Tracing through on the debugger shows the
> correct data in the dataset but the SQL Profiler shows
> that the second parameters is coming in as a -1 (which is
> not the data in the dataset). To make matters worse this
> only occurs on the Development sever with the production
> server executing without error.
>
> What could be the difference in the two servers that
> parses the ADO.NET interface parameters?

Perley
Mon Oct 27 12:00:21 CST 2003

Source code in both case (development and Production) is
exactly the same. Have triple checked the stored
procedures and table definitions on the two servers and
they match extactly.

>-----Original Message-----
>The code being executed is not the same as the code
you're testing with?
>
>--
>____________________________________
>Bill Vaughn
>MVP, hRD
>www.betav.com
>Please reply only to the newsgroup so that others can
benefit.
>This posting is provided "AS IS" with no warranties, and
confers no rights.
>__________________________________
>
>"Perley" <anonymous@discussions.microsoft.com> wrote in
message
>news:075e01c39c85$8bb31a60$a101280a@phx.gbl...
>> In using two different SQL Database server (one for
>> development and one for production) a call to a stored
>> procedure is storing incorrect data. We use ADO.NET SQL
>> Data Adpaters and have set the stored procedure
>> parameters. Tracing through on the debugger shows the
>> correct data in the dataset but the SQL Profiler shows
>> that the second parameters is coming in as a -1 (which
is
>> not the data in the dataset). To make matters worse
this
>> only occurs on the Development sever with the production
>> server executing without error.
>>
>> What could be the difference in the two servers that
>> parses the ADO.NET interface parameters?
>
>
>.
>

Perley
Mon Oct 27 12:06:15 CST 2003

This was my orginal thought. The parameter that is=20
failing is a index number returned on saving the the=20
parent data record. As stated the debugger shows the data=20
has been updated when looking at the dataset prior to the=20
call to the Data Adapter interface to store the=20
information.

Matters have gotten even more interesting since this code=20
is within a wizard to process forms. On the first pass=20
through the error occurs if you run through the wizard a=20
second time (no unload load since the wizard runs=20
circularly) the data is stored correctely. All of this is=20
only against the development server and both cases perform=20
correctly on the production server.

It appears to be an ADO.NET error in extracting the data=20
from the DataSet since I performed a test using a foreach=20
DataRow in the appropriate table and found that the data=20
loaded into the local (foreach) DataRow is wrong (contains=20
the -1). But the question remains if it is a extracting=20
problem in ADO.NET why does it work in all other cases.


>-----Original Message-----
>Not having the same pramater probably explians the=20
different result set...
>
>Now it would interesting to see from where comes this=20
parameter (another
>query ?). Most of these problems are likely related to=20
different data.
>
>Patrice
>
>--=20
>
>"Perley" <anonymous@discussions.microsoft.com> a =E9crit=20
dans le message de
>news:075e01c39c85$8bb31a60$a101280a@phx.gbl...
>> In using two different SQL Database server (one for
>> development and one for production) a call to a stored
>> procedure is storing incorrect data. We use ADO.NET SQL
>> Data Adpaters and have set the stored procedure
>> parameters. Tracing through on the debugger shows the
>> correct data in the dataset but the SQL Profiler shows
>> that the second parameters is coming in as a -1 (which=20
is
>> not the data in the dataset). To make matters worse=20
this
>> only occurs on the Development sever with the production
>> server executing without error.
>>
>> What could be the difference in the two servers that
>> parses the ADO.NET interface parameters?
>
>.
>