OleDb Parameters BUG or BAD DESIGN

**Miha Markic** · Nov 15 '05, 07:27 PM

Re: OleDb Parameters BUG or BAD DESIGN

Hi,

If you are using OleDb than markers for parameters are probably question
marks (?).
So, adding the parameters in the same order is the only way for OleDb to
recognize them.
Or is your scenario different?

--
Miha Markic - RightHand .NET consulting & software development
miha at rthand com

https://www.rthand.com

<discussion@dis cussion.microso ft.com> wrote in message
news:u8OyKKq2DH A.2792@TK2MSFTN GP09.phx.gbl...[color=blue]
> Hi,
>
> I was performing SQL UPDATE queries and I notice that they SUCCEED on[/color]
the[color=blue]
> ExecuteNonQuery () call with NO exceptions raised BUT they fail at the
> Database. They say they succeed in the code but they fail at the database.
>
> To fix this they Parameters.Add must be called in the ORDER they are in
> the SQL STATEMENT.
>
> This is confusing and bad.
>
> How to repro.
> Construct a SQL query with the @ParamName .... out of order from the
> Parameter.Add(" @ParamName", var); calls.
>
>
>
> Thanks.
>
>
>[/color]

**Guest** · Nov 15 '05, 07:27 PM

Re: OleDb Parameters BUG or BAD DESIGN

I use DatabaseCommand .Parameters.Add ("@ParamName ", paramVar);

This is how it is documented and how it works today, the problem is the
ORDER oft he Parameter.Add( method calls MUST match the order in the SQL
statement.

This is NOT documented nor the logical design if we are using NAMED
PARAMATERS.

If it is dependant on the order we do NOT need named parameters then. That
is the entire concept of named parameters.

Its a bug or bad design in my book.

"Miha Markic" <miha at rthand com> wrote in message
news:%23qiaPSq2 DHA.2208@TK2MSF TNGP12.phx.gbl. ..[color=blue]
> Hi,
>
> If you are using OleDb than markers for parameters are probably question
> marks (?).
> So, adding the parameters in the same order is the only way for OleDb to
> recognize them.
> Or is your scenario different?
>
> --
> Miha Markic - RightHand .NET consulting & software development
> miha at rthand com
> www.rthand.com
>
> <discussion@dis cussion.microso ft.com> wrote in message
> news:u8OyKKq2DH A.2792@TK2MSFTN GP09.phx.gbl...[color=green]
> > Hi,
> >
> > I was performing SQL UPDATE queries and I notice that they SUCCEED on[/color]
> the[color=green]
> > ExecuteNonQuery () call with NO exceptions raised BUT they fail at the
> > Database. They say they succeed in the code but they fail at the[/color][/color]
database.[color=blue][color=green]
> >
> > To fix this they Parameters.Add must be called in the ORDER they are[/color][/color]
in[color=blue][color=green]
> > the SQL STATEMENT.
> >
> > This is confusing and bad.
> >
> > How to repro.
> > Construct a SQL query with the @ParamName .... out of order from the
> > Parameter.Add(" @ParamName", var); calls.
> >
> >
> >
> > Thanks.
> >
> >
> >[/color]
>
>[/color]

**Guest** · Nov 15 '05, 07:27 PM

Re: OleDb Parameters BUG or BAD DESIGN

There are 2 issues here.

1. It programatically succeeds on the ExecuteNonQuery () call when in fact
it does NOT succeed

and

2. Named parameters are not processed correctly if they are not in order of
the sql statement placement

"Miha Markic" <miha at rthand com> wrote in message
news:%23qiaPSq2 DHA.2208@TK2MSF TNGP12.phx.gbl. ..[color=blue]
> Hi,
>
> If you are using OleDb than markers for parameters are probably question
> marks (?).
> So, adding the parameters in the same order is the only way for OleDb to
> recognize them.
> Or is your scenario different?
>
> --
> Miha Markic - RightHand .NET consulting & software development
> miha at rthand com
> www.rthand.com
>
> <discussion@dis cussion.microso ft.com> wrote in message
> news:u8OyKKq2DH A.2792@TK2MSFTN GP09.phx.gbl...[color=green]
> > Hi,
> >
> > I was performing SQL UPDATE queries and I notice that they SUCCEED on[/color]
> the[color=green]
> > ExecuteNonQuery () call with NO exceptions raised BUT they fail at the
> > Database. They say they succeed in the code but they fail at the[/color][/color]
database.[color=blue][color=green]
> >
> > To fix this they Parameters.Add must be called in the ORDER they are[/color][/color]
in[color=blue][color=green]
> > the SQL STATEMENT.
> >
> > This is confusing and bad.
> >
> > How to repro.
> > Construct a SQL query with the @ParamName .... out of order from the
> > Parameter.Add(" @ParamName", var); calls.
> >
> >
> >
> > Thanks.
> >
> >
> >[/color]
>
>[/color]

**Ron Allen** · Nov 15 '05, 07:27 PM

Re: OleDb Parameters BUG or BAD DESIGN

I don't know why this call succeeds but the OleDb database interface
doesn't support named parameters. See the remarks section of
OleDbParameter Class (
ms-help://MS.VSCC.2003/MS.MSDNQTR.2003 FEB.1033/cpref/html/frlrfsystemdata ole
dboledbparamete rclasstopic.htm )
on my machine.
You can name them any way you like but they are position dependent and
only require a name to access them in the collection.

Ron Allen
<discussion@dis cussion.microso ft.com> wrote in message
news:eBE0Ufq2DH A.3468@TK2MSFTN GP11.phx.gbl...[color=blue]
> There are 2 issues here.
>
> 1. It programatically succeeds on the ExecuteNonQuery () call when in fact
> it does NOT succeed
>
> and
>
> 2. Named parameters are not processed correctly if they are not in order[/color]
of[color=blue]
> the sql statement placement
>
>
>
>
>
>
>
>
> "Miha Markic" <miha at rthand com> wrote in message
> news:%23qiaPSq2 DHA.2208@TK2MSF TNGP12.phx.gbl. ..[color=green]
> > Hi,
> >
> > If you are using OleDb than markers for parameters are probably question
> > marks (?).
> > So, adding the parameters in the same order is the only way for OleDb to
> > recognize them.
> > Or is your scenario different?
> >
> > --
> > Miha Markic - RightHand .NET consulting & software development
> > miha at rthand com
> > www.rthand.com
> >
> > <discussion@dis cussion.microso ft.com> wrote in message
> > news:u8OyKKq2DH A.2792@TK2MSFTN GP09.phx.gbl...[color=darkred]
> > > Hi,
> > >
> > > I was performing SQL UPDATE queries and I notice that they SUCCEED[/color][/color][/color]
on[color=blue][color=green]
> > the[color=darkred]
> > > ExecuteNonQuery () call with NO exceptions raised BUT they fail at the
> > > Database. They say they succeed in the code but they fail at the[/color][/color]
> database.[color=green][color=darkred]
> > >
> > > To fix this they Parameters.Add must be called in the ORDER they[/color][/color][/color]
are[color=blue]
> in[color=green][color=darkred]
> > > the SQL STATEMENT.
> > >
> > > This is confusing and bad.
> > >
> > > How to repro.
> > > Construct a SQL query with the @ParamName .... out of order from[/color][/color][/color]
the[color=blue][color=green][color=darkred]
> > > Parameter.Add(" @ParamName", var); calls.
> > >
> > >
> > >
> > > Thanks.
> > >
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

**Guest** · Nov 15 '05, 07:27 PM

Re: OleDb Parameters BUG or BAD DESIGN

You say on one hand it doesnt support named parameters then on the other you
say "only require a name to access them in the collection." so which is it?
Yes or no?

"Ron Allen" <rallen@_nospam _src-us.com> wrote in message
news:uIe$Ptq2DH A.208@TK2MSFTNG P12.phx.gbl...[color=blue]
> I don't know why this call succeeds but the OleDb database interface
> doesn't support named parameters. See the remarks section of
> OleDbParameter Class (
>[/color]
ms-help://MS.VSCC.2003/MS.MSDNQTR.2003 FEB.1033/cpref/html/frlrfsystemdata ole[color=blue]
> dboledbparamete rclasstopic.htm )
> on my machine.
> You can name them any way you like but they are position dependent and
> only require a name to access them in the collection.
>
> Ron Allen
> <discussion@dis cussion.microso ft.com> wrote in message
> news:eBE0Ufq2DH A.3468@TK2MSFTN GP11.phx.gbl...[color=green]
> > There are 2 issues here.
> >
> > 1. It programatically succeeds on the ExecuteNonQuery () call when in[/color][/color]
fact[color=blue][color=green]
> > it does NOT succeed
> >
> > and
> >
> > 2. Named parameters are not processed correctly if they are not in[/color][/color]
order[color=blue]
> of[color=green]
> > the sql statement placement
> >
> >
> >
> >
> >
> >
> >
> >
> > "Miha Markic" <miha at rthand com> wrote in message
> > news:%23qiaPSq2 DHA.2208@TK2MSF TNGP12.phx.gbl. ..[color=darkred]
> > > Hi,
> > >
> > > If you are using OleDb than markers for parameters are probably[/color][/color][/color]
question[color=blue][color=green][color=darkred]
> > > marks (?).
> > > So, adding the parameters in the same order is the only way for OleDb[/color][/color][/color]
to[color=blue][color=green][color=darkred]
> > > recognize them.
> > > Or is your scenario different?
> > >
> > > --
> > > Miha Markic - RightHand .NET consulting & software development
> > > miha at rthand com
> > > www.rthand.com
> > >
> > > <discussion@dis cussion.microso ft.com> wrote in message
> > > news:u8OyKKq2DH A.2792@TK2MSFTN GP09.phx.gbl...
> > > > Hi,
> > > >
> > > > I was performing SQL UPDATE queries and I notice that they SUCCEED[/color][/color]
> on[color=green][color=darkred]
> > > the
> > > > ExecuteNonQuery () call with NO exceptions raised BUT they fail at[/color][/color][/color]
the[color=blue][color=green][color=darkred]
> > > > Database. They say they succeed in the code but they fail at the[/color]
> > database.[color=darkred]
> > > >
> > > > To fix this they Parameters.Add must be called in the ORDER they[/color][/color]
> are[color=green]
> > in[color=darkred]
> > > > the SQL STATEMENT.
> > > >
> > > > This is confusing and bad.
> > > >
> > > > How to repro.
> > > > Construct a SQL query with the @ParamName .... out of order from[/color][/color]
> the[color=green][color=darkred]
> > > > Parameter.Add(" @ParamName", var); calls.
> > > >
> > > >
> > > >
> > > > Thanks.
> > > >
> > > >
> > > >
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

**Guest** · Nov 15 '05, 07:27 PM

Re: OleDb Parameters BUG or BAD DESIGN

There is still the issue of it reporting a SUCCESS when it obviously fails
on the UPDATE at the database.

With the above out of order parameters its still returning success (no
exceptions) on the update when infact its NOT updating, zero rows affected.

"Ron Allen" <rallen@_nospam _src-us.com> wrote in message
news:uIe$Ptq2DH A.208@TK2MSFTNG P12.phx.gbl...[color=blue]
> I don't know why this call succeeds but the OleDb database interface
> doesn't support named parameters. See the remarks section of
> OleDbParameter Class (
>[/color]
ms-help://MS.VSCC.2003/MS.MSDNQTR.2003 FEB.1033/cpref/html/frlrfsystemdata ole[color=blue]
> dboledbparamete rclasstopic.htm )
> on my machine.
> You can name them any way you like but they are position dependent and
> only require a name to access them in the collection.
>
> Ron Allen
> <discussion@dis cussion.microso ft.com> wrote in message
> news:eBE0Ufq2DH A.3468@TK2MSFTN GP11.phx.gbl...[color=green]
> > There are 2 issues here.
> >
> > 1. It programatically succeeds on the ExecuteNonQuery () call when in[/color][/color]
fact[color=blue][color=green]
> > it does NOT succeed
> >
> > and
> >
> > 2. Named parameters are not processed correctly if they are not in[/color][/color]
order[color=blue]
> of[color=green]
> > the sql statement placement
> >
> >
> >
> >
> >
> >
> >
> >
> > "Miha Markic" <miha at rthand com> wrote in message
> > news:%23qiaPSq2 DHA.2208@TK2MSF TNGP12.phx.gbl. ..[color=darkred]
> > > Hi,
> > >
> > > If you are using OleDb than markers for parameters are probably[/color][/color][/color]
question[color=blue][color=green][color=darkred]
> > > marks (?).
> > > So, adding the parameters in the same order is the only way for OleDb[/color][/color][/color]
to[color=blue][color=green][color=darkred]
> > > recognize them.
> > > Or is your scenario different?
> > >
> > > --
> > > Miha Markic - RightHand .NET consulting & software development
> > > miha at rthand com
> > > www.rthand.com
> > >
> > > <discussion@dis cussion.microso ft.com> wrote in message
> > > news:u8OyKKq2DH A.2792@TK2MSFTN GP09.phx.gbl...
> > > > Hi,
> > > >
> > > > I was performing SQL UPDATE queries and I notice that they SUCCEED[/color][/color]
> on[color=green][color=darkred]
> > > the
> > > > ExecuteNonQuery () call with NO exceptions raised BUT they fail at[/color][/color][/color]
the[color=blue][color=green][color=darkred]
> > > > Database. They say they succeed in the code but they fail at the[/color]
> > database.[color=darkred]
> > > >
> > > > To fix this they Parameters.Add must be called in the ORDER they[/color][/color]
> are[color=green]
> > in[color=darkred]
> > > > the SQL STATEMENT.
> > > >
> > > > This is confusing and bad.
> > > >
> > > > How to repro.
> > > > Construct a SQL query with the @ParamName .... out of order from[/color][/color]
> the[color=green][color=darkred]
> > > > Parameter.Add(" @ParamName", var); calls.
> > > >
> > > >
> > > >
> > > > Thanks.
> > > >
> > > >
> > > >
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

**Miha Markic** · Nov 15 '05, 07:27 PM

Re: OleDb Parameters BUG or BAD DESIGN

Hey discussion man,

SQL *named* parameter markers are *not* supported via OleDb managed
provider.
Read this:

Error - Office.com

http://support.microsoft.com/default.aspx?scid=kb;en-us;316744

--
Miha Markic - RightHand .NET consulting & software development
miha at rthand com

https://www.rthand.com

<discussion@dis cussion.microso ft.com> wrote in message
news:uoOCEvq2DH A.2868@TK2MSFTN GP09.phx.gbl...[color=blue]
> You say on one hand it doesnt support named parameters then on the other[/color]
you[color=blue]
> say "only require a name to access them in the collection." so which is[/color]
it?[color=blue]
> Yes or no?
>
>
>
>
> "Ron Allen" <rallen@_nospam _src-us.com> wrote in message
> news:uIe$Ptq2DH A.208@TK2MSFTNG P12.phx.gbl...[color=green]
> > I don't know why this call succeeds but the OleDb database interface
> > doesn't support named parameters. See the remarks section of
> > OleDbParameter Class (
> >[/color]
>[/color]
ms-help://MS.VSCC.2003/MS.MSDNQTR.2003 FEB.1033/cpref/html/frlrfsystemdata ole[color=blue][color=green]
> > dboledbparamete rclasstopic.htm )
> > on my machine.
> > You can name them any way you like but they are position dependent and
> > only require a name to access them in the collection.
> >
> > Ron Allen
> > <discussion@dis cussion.microso ft.com> wrote in message
> > news:eBE0Ufq2DH A.3468@TK2MSFTN GP11.phx.gbl...[color=darkred]
> > > There are 2 issues here.
> > >
> > > 1. It programatically succeeds on the ExecuteNonQuery () call when in[/color][/color]
> fact[color=green][color=darkred]
> > > it does NOT succeed
> > >
> > > and
> > >
> > > 2. Named parameters are not processed correctly if they are not in[/color][/color]
> order[color=green]
> > of[color=darkred]
> > > the sql statement placement
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > "Miha Markic" <miha at rthand com> wrote in message
> > > news:%23qiaPSq2 DHA.2208@TK2MSF TNGP12.phx.gbl. ..
> > > > Hi,
> > > >
> > > > If you are using OleDb than markers for parameters are probably[/color][/color]
> question[color=green][color=darkred]
> > > > marks (?).
> > > > So, adding the parameters in the same order is the only way for[/color][/color][/color]
OleDb[color=blue]
> to[color=green][color=darkred]
> > > > recognize them.
> > > > Or is your scenario different?
> > > >
> > > > --
> > > > Miha Markic - RightHand .NET consulting & software development
> > > > miha at rthand com
> > > > www.rthand.com
> > > >
> > > > <discussion@dis cussion.microso ft.com> wrote in message
> > > > news:u8OyKKq2DH A.2792@TK2MSFTN GP09.phx.gbl...
> > > > > Hi,
> > > > >
> > > > > I was performing SQL UPDATE queries and I notice that they[/color][/color][/color]
SUCCEED[color=blue][color=green]
> > on[color=darkred]
> > > > the
> > > > > ExecuteNonQuery () call with NO exceptions raised BUT they fail at[/color][/color]
> the[color=green][color=darkred]
> > > > > Database. They say they succeed in the code but they fail at the
> > > database.
> > > > >
> > > > > To fix this they Parameters.Add must be called in the ORDER[/color][/color][/color]
they[color=blue][color=green]
> > are[color=darkred]
> > > in
> > > > > the SQL STATEMENT.
> > > > >
> > > > > This is confusing and bad.
> > > > >
> > > > > How to repro.
> > > > > Construct a SQL query with the @ParamName .... out of order[/color][/color][/color]
from[color=blue][color=green]
> > the[color=darkred]
> > > > > Parameter.Add(" @ParamName", var); calls.
> > > > >
> > > > >
> > > > >
> > > > > Thanks.
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

**Guest** · Nov 15 '05, 07:27 PM

Re: OleDb Parameters BUG or BAD DESIGN

Ok, make it a FEATURE REQEST then :D

The collection can be accessed by parameter name so why cant we have named
parameters?

"Miha Markic" <miha at rthand com> wrote in message
news:uYlfj1q2DH A.1736@TK2MSFTN GP09.phx.gbl...[color=blue]
> Hey discussion man,
>
> SQL *named* parameter markers are *not* supported via OleDb managed
> provider.
> Read this:
> http://support.microsoft.com/default...b;en-us;316744
>
> --
> Miha Markic - RightHand .NET consulting & software development
> miha at rthand com
> www.rthand.com
>
> <discussion@dis cussion.microso ft.com> wrote in message
> news:uoOCEvq2DH A.2868@TK2MSFTN GP09.phx.gbl...[color=green]
> > You say on one hand it doesnt support named parameters then on the other[/color]
> you[color=green]
> > say "only require a name to access them in the collection." so which is[/color]
> it?[color=green]
> > Yes or no?
> >
> >
> >
> >
> > "Ron Allen" <rallen@_nospam _src-us.com> wrote in message
> > news:uIe$Ptq2DH A.208@TK2MSFTNG P12.phx.gbl...[color=darkred]
> > > I don't know why this call succeeds but the OleDb database[/color][/color][/color]
interface[color=blue][color=green][color=darkred]
> > > doesn't support named parameters. See the remarks section of
> > > OleDbParameter Class (
> > >[/color]
> >[/color]
>[/color]
ms-help://MS.VSCC.2003/MS.MSDNQTR.2003 FEB.1033/cpref/html/frlrfsystemdata ole[color=blue][color=green][color=darkred]
> > > dboledbparamete rclasstopic.htm )
> > > on my machine.
> > > You can name them any way you like but they are position dependent[/color][/color][/color]
and[color=blue][color=green][color=darkred]
> > > only require a name to access them in the collection.
> > >
> > > Ron Allen
> > > <discussion@dis cussion.microso ft.com> wrote in message
> > > news:eBE0Ufq2DH A.3468@TK2MSFTN GP11.phx.gbl...
> > > > There are 2 issues here.
> > > >
> > > > 1. It programatically succeeds on the ExecuteNonQuery () call when[/color][/color][/color]
in[color=blue][color=green]
> > fact[color=darkred]
> > > > it does NOT succeed
> > > >
> > > > and
> > > >
> > > > 2. Named parameters are not processed correctly if they are not in[/color]
> > order[color=darkred]
> > > of
> > > > the sql statement placement
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > "Miha Markic" <miha at rthand com> wrote in message
> > > > news:%23qiaPSq2 DHA.2208@TK2MSF TNGP12.phx.gbl. ..
> > > > > Hi,
> > > > >
> > > > > If you are using OleDb than markers for parameters are probably[/color]
> > question[color=darkred]
> > > > > marks (?).
> > > > > So, adding the parameters in the same order is the only way for[/color][/color]
> OleDb[color=green]
> > to[color=darkred]
> > > > > recognize them.
> > > > > Or is your scenario different?
> > > > >
> > > > > --
> > > > > Miha Markic - RightHand .NET consulting & software development
> > > > > miha at rthand com
> > > > > www.rthand.com
> > > > >
> > > > > <discussion@dis cussion.microso ft.com> wrote in message
> > > > > news:u8OyKKq2DH A.2792@TK2MSFTN GP09.phx.gbl...
> > > > > > Hi,
> > > > > >
> > > > > > I was performing SQL UPDATE queries and I notice that they[/color][/color]
> SUCCEED[color=green][color=darkred]
> > > on
> > > > > the
> > > > > > ExecuteNonQuery () call with NO exceptions raised BUT they fail[/color][/color][/color]
at[color=blue][color=green]
> > the[color=darkred]
> > > > > > Database. They say they succeed in the code but they fail at the
> > > > database.
> > > > > >
> > > > > > To fix this they Parameters.Add must be called in the ORDER[/color][/color]
> they[color=green][color=darkred]
> > > are
> > > > in
> > > > > > the SQL STATEMENT.
> > > > > >
> > > > > > This is confusing and bad.
> > > > > >
> > > > > > How to repro.
> > > > > > Construct a SQL query with the @ParamName .... out of order[/color][/color]
> from[color=green][color=darkred]
> > > the
> > > > > > Parameter.Add(" @ParamName", var); calls.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Thanks.
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

**Miha Markic** · Nov 15 '05, 07:27 PM

Re: OleDb Parameters BUG or BAD DESIGN

Hi,

<discussion@dis cussion.microso ft.com> wrote in message
news:uBYA%23zq2 DHA.1660@TK2MSF TNGP09.phx.gbl. ..[color=blue]
> There is still the issue of it reporting a SUCCESS when it obviously fails
> on the UPDATE at the database.
>
> With the above out of order parameters its still returning success (no
> exceptions) on the update when infact its NOT updating, zero rows[/color]
affected.

Since when should SQL server (or any other database server) complain when
there are no rows updated?
If you take a look at ExecuteNonQuery () you'll see that it returns the
number of rows affected.

--
Miha Markic - RightHand .NET consulting & software development
miha at rthand com

https://www.rthand.com

**Ron Allen** · Nov 15 '05, 07:27 PM

Re: OleDb Parameters BUG or BAD DESIGN

For access them in the collection I mean in the Parameters collection of the
command i.e.,
myCommand.Param eters["paramName"].Value = xx
to access the parameter for modification. The names don't mean anything to
the positioning of the parameter in the CommandText of the query. These
type of queries are normally written as
Select myField from myTable Where (myField2 = ?) AND (myfield3 = ?)
or
Insert into myTable (myField1, myField2) VALUES (?, ?)
where the parameter positions are indicated by the ? symbols.

Ron Allen
<discussion@dis cussion.microso ft.com> wrote in message
news:uoOCEvq2DH A.2868@TK2MSFTN GP09.phx.gbl...[color=blue]
> You say on one hand it doesnt support named parameters then on the other[/color]
you[color=blue]
> say "only require a name to access them in the collection." so which is[/color]
it?[color=blue]
> Yes or no?
>
>
>
>
> "Ron Allen" <rallen@_nospam _src-us.com> wrote in message
> news:uIe$Ptq2DH A.208@TK2MSFTNG P12.phx.gbl...[color=green]
> > I don't know why this call succeeds but the OleDb database interface
> > doesn't support named parameters. See the remarks section of
> > OleDbParameter Class (
> >[/color]
>[/color]
ms-help://MS.VSCC.2003/MS.MSDNQTR.2003 FEB.1033/cpref/html/frlrfsystemdata ole[color=blue][color=green]
> > dboledbparamete rclasstopic.htm )
> > on my machine.
> > You can name them any way you like but they are position dependent and
> > only require a name to access them in the collection.
> >
> > Ron Allen
> > <discussion@dis cussion.microso ft.com> wrote in message
> > news:eBE0Ufq2DH A.3468@TK2MSFTN GP11.phx.gbl...[color=darkred]
> > > There are 2 issues here.
> > >
> > > 1. It programatically succeeds on the ExecuteNonQuery () call when in[/color][/color]
> fact[color=green][color=darkred]
> > > it does NOT succeed
> > >
> > > and
> > >
> > > 2. Named parameters are not processed correctly if they are not in[/color][/color]
> order[color=green]
> > of[color=darkred]
> > > the sql statement placement
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > "Miha Markic" <miha at rthand com> wrote in message
> > > news:%23qiaPSq2 DHA.2208@TK2MSF TNGP12.phx.gbl. ..
> > > > Hi,
> > > >
> > > > If you are using OleDb than markers for parameters are probably[/color][/color]
> question[color=green][color=darkred]
> > > > marks (?).
> > > > So, adding the parameters in the same order is the only way for[/color][/color][/color]
OleDb[color=blue]
> to[color=green][color=darkred]
> > > > recognize them.
> > > > Or is your scenario different?
> > > >
> > > > --
> > > > Miha Markic - RightHand .NET consulting & software development
> > > > miha at rthand com
> > > > www.rthand.com
> > > >
> > > > <discussion@dis cussion.microso ft.com> wrote in message
> > > > news:u8OyKKq2DH A.2792@TK2MSFTN GP09.phx.gbl...
> > > > > Hi,
> > > > >
> > > > > I was performing SQL UPDATE queries and I notice that they[/color][/color][/color]
SUCCEED[color=blue][color=green]
> > on[color=darkred]
> > > > the
> > > > > ExecuteNonQuery () call with NO exceptions raised BUT they fail at[/color][/color]
> the[color=green][color=darkred]
> > > > > Database. They say they succeed in the code but they fail at the
> > > database.
> > > > >
> > > > > To fix this they Parameters.Add must be called in the ORDER[/color][/color][/color]
they[color=blue][color=green]
> > are[color=darkred]
> > > in
> > > > > the SQL STATEMENT.
> > > > >
> > > > > This is confusing and bad.
> > > > >
> > > > > How to repro.
> > > > > Construct a SQL query with the @ParamName .... out of order[/color][/color][/color]
from[color=blue][color=green]
> > the[color=darkred]
> > > > > Parameter.Add(" @ParamName", var); calls.
> > > > >
> > > > >
> > > > >
> > > > > Thanks.
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

**Guest** · Nov 15 '05, 07:27 PM

Re: OleDb Parameters BUG or BAD DESIGN

Ok, fine but then why does it allow me to use names? I think it confuses
the issue.

I can use these named parameters in the database itself. So this is a SQL
standard with named parameters? IF so, will this be in the longhorn API set
to support named parameters?

"Ron Allen" <rallen@_nospam _src-us.com> wrote in message
news:%23wIef$q2 DHA.2000@TK2MSF TNGP11.phx.gbl. ..[color=blue]
> For access them in the collection I mean in the Parameters collection of[/color]
the[color=blue]
> command i.e.,
> myCommand.Param eters["paramName"].Value = xx
> to access the parameter for modification. The names don't mean anything[/color]
to[color=blue]
> the positioning of the parameter in the CommandText of the query. These
> type of queries are normally written as
> Select myField from myTable Where (myField2 = ?) AND (myfield3 = ?)
> or
> Insert into myTable (myField1, myField2) VALUES (?, ?)
> where the parameter positions are indicated by the ? symbols.
>
> Ron Allen
> <discussion@dis cussion.microso ft.com> wrote in message
> news:uoOCEvq2DH A.2868@TK2MSFTN GP09.phx.gbl...[color=green]
> > You say on one hand it doesnt support named parameters then on the other[/color]
> you[color=green]
> > say "only require a name to access them in the collection." so which is[/color]
> it?[color=green]
> > Yes or no?
> >
> >
> >
> >
> > "Ron Allen" <rallen@_nospam _src-us.com> wrote in message
> > news:uIe$Ptq2DH A.208@TK2MSFTNG P12.phx.gbl...[color=darkred]
> > > I don't know why this call succeeds but the OleDb database[/color][/color][/color]
interface[color=blue][color=green][color=darkred]
> > > doesn't support named parameters. See the remarks section of
> > > OleDbParameter Class (
> > >[/color]
> >[/color]
>[/color]
ms-help://MS.VSCC.2003/MS.MSDNQTR.2003 FEB.1033/cpref/html/frlrfsystemdata ole[color=blue][color=green][color=darkred]
> > > dboledbparamete rclasstopic.htm )
> > > on my machine.
> > > You can name them any way you like but they are position dependent[/color][/color][/color]
and[color=blue][color=green][color=darkred]
> > > only require a name to access them in the collection.
> > >
> > > Ron Allen
> > > <discussion@dis cussion.microso ft.com> wrote in message
> > > news:eBE0Ufq2DH A.3468@TK2MSFTN GP11.phx.gbl...
> > > > There are 2 issues here.
> > > >
> > > > 1. It programatically succeeds on the ExecuteNonQuery () call when[/color][/color][/color]
in[color=blue][color=green]
> > fact[color=darkred]
> > > > it does NOT succeed
> > > >
> > > > and
> > > >
> > > > 2. Named parameters are not processed correctly if they are not in[/color]
> > order[color=darkred]
> > > of
> > > > the sql statement placement
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > "Miha Markic" <miha at rthand com> wrote in message
> > > > news:%23qiaPSq2 DHA.2208@TK2MSF TNGP12.phx.gbl. ..
> > > > > Hi,
> > > > >
> > > > > If you are using OleDb than markers for parameters are probably[/color]
> > question[color=darkred]
> > > > > marks (?).
> > > > > So, adding the parameters in the same order is the only way for[/color][/color]
> OleDb[color=green]
> > to[color=darkred]
> > > > > recognize them.
> > > > > Or is your scenario different?
> > > > >
> > > > > --
> > > > > Miha Markic - RightHand .NET consulting & software development
> > > > > miha at rthand com
> > > > > www.rthand.com
> > > > >
> > > > > <discussion@dis cussion.microso ft.com> wrote in message
> > > > > news:u8OyKKq2DH A.2792@TK2MSFTN GP09.phx.gbl...
> > > > > > Hi,
> > > > > >
> > > > > > I was performing SQL UPDATE queries and I notice that they[/color][/color]
> SUCCEED[color=green][color=darkred]
> > > on
> > > > > the
> > > > > > ExecuteNonQuery () call with NO exceptions raised BUT they fail[/color][/color][/color]
at[color=blue][color=green]
> > the[color=darkred]
> > > > > > Database. They say they succeed in the code but they fail at the
> > > > database.
> > > > > >
> > > > > > To fix this they Parameters.Add must be called in the ORDER[/color][/color]
> they[color=green][color=darkred]
> > > are
> > > > in
> > > > > > the SQL STATEMENT.
> > > > > >
> > > > > > This is confusing and bad.
> > > > > >
> > > > > > How to repro.
> > > > > > Construct a SQL query with the @ParamName .... out of order[/color][/color]
> from[color=green][color=darkred]
> > > the
> > > > > > Parameter.Add(" @ParamName", var); calls.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Thanks.
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

**Ron Allen** · Nov 15 '05, 07:27 PM

Re: OleDb Parameters BUG or BAD DESIGN

Well, I think that OleDb isn't going to support them ever but I haven't
looked thouroughly at the Whidbey documents yet and I know that Database
access is supposed to be improved. MS seems to be pushing people to go to
MSDE instead of Access for local databases and I'd imagine that this will
intensify when the 'Yukon' version of SQL server is released. FWIW I've
just finished migrating our large in-house billing system to MSDE/SQL server
from Access and found about double the performance and much lower memory
requirements on the client. Doing everything through StoredProcedure s is
much easier and the nested select logic is much cleaner.
The names appear to be there just to satisfy the IDBParameter interface
and, of course, to make them easy to access through the Parameters
collection for the programmer. It would certainly make things easier if
names were supported though.

Ron Allen

<discussion@dis cussion.microso ft.com> wrote in message
news:%23%23yt5D r2DHA.4060@TK2M SFTNGP11.phx.gb l...[color=blue]
> Ok, fine but then why does it allow me to use names? I think it confuses
> the issue.
>
> I can use these named parameters in the database itself. So this is a SQL
> standard with named parameters? IF so, will this be in the longhorn API[/color]
set[color=blue]
> to support named parameters?
>
>
> "Ron Allen" <rallen@_nospam _src-us.com> wrote in message
> news:%23wIef$q2 DHA.2000@TK2MSF TNGP11.phx.gbl. ..[color=green]
> > For access them in the collection I mean in the Parameters collection of[/color]
> the[color=green]
> > command i.e.,
> > myCommand.Param eters["paramName"].Value = xx
> > to access the parameter for modification. The names don't mean[/color][/color]
anything[color=blue]
> to[color=green]
> > the positioning of the parameter in the CommandText of the query. These
> > type of queries are normally written as
> > Select myField from myTable Where (myField2 = ?) AND (myfield3 = ?)
> > or
> > Insert into myTable (myField1, myField2) VALUES (?, ?)
> > where the parameter positions are indicated by the ? symbols.
> >
> > Ron Allen
> > <discussion@dis cussion.microso ft.com> wrote in message
> > news:uoOCEvq2DH A.2868@TK2MSFTN GP09.phx.gbl...[color=darkred]
> > > You say on one hand it doesnt support named parameters then on the[/color][/color][/color]
other[color=blue][color=green]
> > you[color=darkred]
> > > say "only require a name to access them in the collection." so which[/color][/color][/color]
is[color=blue][color=green]
> > it?[color=darkred]
> > > Yes or no?
> > >
> > >
> > >
> > >
> > > "Ron Allen" <rallen@_nospam _src-us.com> wrote in message
> > > news:uIe$Ptq2DH A.208@TK2MSFTNG P12.phx.gbl...
> > > > I don't know why this call succeeds but the OleDb database[/color][/color]
> interface[color=green][color=darkred]
> > > > doesn't support named parameters. See the remarks section of
> > > > OleDbParameter Class (
> > > >
> > >[/color]
> >[/color]
>[/color]
ms-help://MS.VSCC.2003/MS.MSDNQTR.2003 FEB.1033/cpref/html/frlrfsystemdata ole[color=blue][color=green][color=darkred]
> > > > dboledbparamete rclasstopic.htm )
> > > > on my machine.
> > > > You can name them any way you like but they are position dependent[/color][/color]
> and[color=green][color=darkred]
> > > > only require a name to access them in the collection.
> > > >
> > > > Ron Allen
> > > > <discussion@dis cussion.microso ft.com> wrote in message
> > > > news:eBE0Ufq2DH A.3468@TK2MSFTN GP11.phx.gbl...
> > > > > There are 2 issues here.
> > > > >
> > > > > 1. It programatically succeeds on the ExecuteNonQuery () call when[/color][/color]
> in[color=green][color=darkred]
> > > fact
> > > > > it does NOT succeed
> > > > >
> > > > > and
> > > > >
> > > > > 2. Named parameters are not processed correctly if they are not[/color][/color][/color]
in[color=blue][color=green][color=darkred]
> > > order
> > > > of
> > > > > the sql statement placement
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > "Miha Markic" <miha at rthand com> wrote in message
> > > > > news:%23qiaPSq2 DHA.2208@TK2MSF TNGP12.phx.gbl. ..
> > > > > > Hi,
> > > > > >
> > > > > > If you are using OleDb than markers for parameters are probably
> > > question
> > > > > > marks (?).
> > > > > > So, adding the parameters in the same order is the only way for[/color]
> > OleDb[color=darkred]
> > > to
> > > > > > recognize them.
> > > > > > Or is your scenario different?
> > > > > >
> > > > > > --
> > > > > > Miha Markic - RightHand .NET consulting & software development
> > > > > > miha at rthand com
> > > > > > www.rthand.com
> > > > > >
> > > > > > <discussion@dis cussion.microso ft.com> wrote in message
> > > > > > news:u8OyKKq2DH A.2792@TK2MSFTN GP09.phx.gbl...
> > > > > > > Hi,
> > > > > > >
> > > > > > > I was performing SQL UPDATE queries and I notice that they[/color]
> > SUCCEED[color=darkred]
> > > > on
> > > > > > the
> > > > > > > ExecuteNonQuery () call with NO exceptions raised BUT they fail[/color][/color]
> at[color=green][color=darkred]
> > > the
> > > > > > > Database. They say they succeed in the code but they fail at[/color][/color][/color]
the[color=blue][color=green][color=darkred]
> > > > > database.
> > > > > > >
> > > > > > > To fix this they Parameters.Add must be called in the ORDER[/color]
> > they[color=darkred]
> > > > are
> > > > > in
> > > > > > > the SQL STATEMENT.
> > > > > > >
> > > > > > > This is confusing and bad.
> > > > > > >
> > > > > > > How to repro.
> > > > > > > Construct a SQL query with the @ParamName .... out of[/color][/color][/color]
order[color=blue][color=green]
> > from[color=darkred]
> > > > the
> > > > > > > Parameter.Add(" @ParamName", var); calls.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Thanks.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

**Guest** · Nov 15 '05, 07:27 PM

Re: OleDb Parameters BUG or BAD DESIGN

They can push all they want but until the support officially ends its being
used.

I would love to use sql server and stored procedures but these dudes run
Access so theyre getting simple SQL queries as punishment :D

"Ron Allen" <rallen@_nospam _src-us.com> wrote in message
news:OOrf6Lr2DH A.1720@TK2MSFTN GP10.phx.gbl...[color=blue]
> Well, I think that OleDb isn't going to support them ever but I[/color]
haven't[color=blue]
> looked thouroughly at the Whidbey documents yet and I know that Database
> access is supposed to be improved. MS seems to be pushing people to go to
> MSDE instead of Access for local databases and I'd imagine that this will
> intensify when the 'Yukon' version of SQL server is released. FWIW I've
> just finished migrating our large in-house billing system to MSDE/SQL[/color]
server[color=blue]
> from Access and found about double the performance and much lower memory
> requirements on the client. Doing everything through StoredProcedure s is
> much easier and the nested select logic is much cleaner.
> The names appear to be there just to satisfy the IDBParameter[/color]
interface[color=blue]
> and, of course, to make them easy to access through the Parameters
> collection for the programmer. It would certainly make things easier if
> names were supported though.
>
> Ron Allen
>
> <discussion@dis cussion.microso ft.com> wrote in message
> news:%23%23yt5D r2DHA.4060@TK2M SFTNGP11.phx.gb l...[color=green]
> > Ok, fine but then why does it allow me to use names? I think it[/color][/color]
confuses[color=blue][color=green]
> > the issue.
> >
> > I can use these named parameters in the database itself. So this is a[/color][/color]
SQL[color=blue][color=green]
> > standard with named parameters? IF so, will this be in the longhorn API[/color]
> set[color=green]
> > to support named parameters?
> >
> >
> > "Ron Allen" <rallen@_nospam _src-us.com> wrote in message
> > news:%23wIef$q2 DHA.2000@TK2MSF TNGP11.phx.gbl. ..[color=darkred]
> > > For access them in the collection I mean in the Parameters collection[/color][/color][/color]
of[color=blue][color=green]
> > the[color=darkred]
> > > command i.e.,
> > > myCommand.Param eters["paramName"].Value = xx
> > > to access the parameter for modification. The names don't mean[/color][/color]
> anything[color=green]
> > to[color=darkred]
> > > the positioning of the parameter in the CommandText of the query.[/color][/color][/color]
These[color=blue][color=green][color=darkred]
> > > type of queries are normally written as
> > > Select myField from myTable Where (myField2 = ?) AND (myfield3 = ?)
> > > or
> > > Insert into myTable (myField1, myField2) VALUES (?, ?)
> > > where the parameter positions are indicated by the ? symbols.
> > >
> > > Ron Allen
> > > <discussion@dis cussion.microso ft.com> wrote in message
> > > news:uoOCEvq2DH A.2868@TK2MSFTN GP09.phx.gbl...
> > > > You say on one hand it doesnt support named parameters then on the[/color][/color]
> other[color=green][color=darkred]
> > > you
> > > > say "only require a name to access them in the collection." so[/color][/color][/color]
which[color=blue]
> is[color=green][color=darkred]
> > > it?
> > > > Yes or no?
> > > >
> > > >
> > > >
> > > >
> > > > "Ron Allen" <rallen@_nospam _src-us.com> wrote in message
> > > > news:uIe$Ptq2DH A.208@TK2MSFTNG P12.phx.gbl...
> > > > > I don't know why this call succeeds but the OleDb database[/color]
> > interface[color=darkred]
> > > > > doesn't support named parameters. See the remarks section of
> > > > > OleDbParameter Class (
> > > > >
> > > >
> > >[/color]
> >[/color]
>[/color]
ms-help://MS.VSCC.2003/MS.MSDNQTR.2003 FEB.1033/cpref/html/frlrfsystemdata ole[color=blue][color=green][color=darkred]
> > > > > dboledbparamete rclasstopic.htm )
> > > > > on my machine.
> > > > > You can name them any way you like but they are position[/color][/color][/color]
dependent[color=blue][color=green]
> > and[color=darkred]
> > > > > only require a name to access them in the collection.
> > > > >
> > > > > Ron Allen
> > > > > <discussion@dis cussion.microso ft.com> wrote in message
> > > > > news:eBE0Ufq2DH A.3468@TK2MSFTN GP11.phx.gbl...
> > > > > > There are 2 issues here.
> > > > > >
> > > > > > 1. It programatically succeeds on the ExecuteNonQuery () call[/color][/color][/color]
when[color=blue][color=green]
> > in[color=darkred]
> > > > fact
> > > > > > it does NOT succeed
> > > > > >
> > > > > > and
> > > > > >
> > > > > > 2. Named parameters are not processed correctly if they are not[/color][/color]
> in[color=green][color=darkred]
> > > > order
> > > > > of
> > > > > > the sql statement placement
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > "Miha Markic" <miha at rthand com> wrote in message
> > > > > > news:%23qiaPSq2 DHA.2208@TK2MSF TNGP12.phx.gbl. ..
> > > > > > > Hi,
> > > > > > >
> > > > > > > If you are using OleDb than markers for parameters are[/color][/color][/color]
probably[color=blue][color=green][color=darkred]
> > > > question
> > > > > > > marks (?).
> > > > > > > So, adding the parameters in the same order is the only way[/color][/color][/color]
for[color=blue][color=green][color=darkred]
> > > OleDb
> > > > to
> > > > > > > recognize them.
> > > > > > > Or is your scenario different?
> > > > > > >
> > > > > > > --
> > > > > > > Miha Markic - RightHand .NET consulting & software development
> > > > > > > miha at rthand com
> > > > > > > www.rthand.com
> > > > > > >
> > > > > > > <discussion@dis cussion.microso ft.com> wrote in message
> > > > > > > news:u8OyKKq2DH A.2792@TK2MSFTN GP09.phx.gbl...
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > I was performing SQL UPDATE queries and I notice that they
> > > SUCCEED
> > > > > on
> > > > > > > the
> > > > > > > > ExecuteNonQuery () call with NO exceptions raised BUT they[/color][/color][/color]
fail[color=blue][color=green]
> > at[color=darkred]
> > > > the
> > > > > > > > Database. They say they succeed in the code but they fail at[/color][/color]
> the[color=green][color=darkred]
> > > > > > database.
> > > > > > > >
> > > > > > > > To fix this they Parameters.Add must be called in the[/color][/color][/color]
ORDER[color=blue][color=green][color=darkred]
> > > they
> > > > > are
> > > > > > in
> > > > > > > > the SQL STATEMENT.
> > > > > > > >
> > > > > > > > This is confusing and bad.
> > > > > > > >
> > > > > > > > How to repro.
> > > > > > > > Construct a SQL query with the @ParamName .... out of[/color][/color]
> order[color=green][color=darkred]
> > > from
> > > > > the
> > > > > > > > Parameter.Add(" @ParamName", var); calls.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Thanks.
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

**Daniel O'Connell** · Nov 15 '05, 07:28 PM

Re: OleDb Parameters BUG or BAD DESIGN

<discussion@dis cussion.microso ft.com> wrote in message
news:eomuD3q2DH A.2952@TK2MSFTN GP09.phx.gbl...[color=blue]
> Ok, make it a FEATURE REQEST then :D
>
> The collection can be accessed by parameter name so why cant we have named
> parameters?
>[/color]
Mainly because, if memory serves, OleDb itself doesn't support it, its not
an issue with the .NET implementation but more with the native OleDb system.
To update OleDb natively would require a considerable amount of modification
in a fair number of drivers(and standards), not all of which are in MS's
control.

However, Ideally the .NET implementation should be capable of parsing the
sql and reordering the parameters collection to match the command passed in.
An enterprising developer could probably easily write a replacement that
does just that.
[color=blue]
>
>
>
> "Miha Markic" <miha at rthand com> wrote in message
> news:uYlfj1q2DH A.1736@TK2MSFTN GP09.phx.gbl...[color=green]
> > Hey discussion man,
> >
> > SQL *named* parameter markers are *not* supported via OleDb managed
> > provider.
> > Read this:
> > http://support.microsoft.com/default...b;en-us;316744
> >
> > --
> > Miha Markic - RightHand .NET consulting & software development
> > miha at rthand com
> > www.rthand.com
> >
> > <discussion@dis cussion.microso ft.com> wrote in message
> > news:uoOCEvq2DH A.2868@TK2MSFTN GP09.phx.gbl...[color=darkred]
> > > You say on one hand it doesnt support named parameters then on the[/color][/color][/color]
other[color=blue][color=green]
> > you[color=darkred]
> > > say "only require a name to access them in the collection." so which[/color][/color][/color]
is[color=blue][color=green]
> > it?[color=darkred]
> > > Yes or no?
> > >
> > >
> > >
> > >
> > > "Ron Allen" <rallen@_nospam _src-us.com> wrote in message
> > > news:uIe$Ptq2DH A.208@TK2MSFTNG P12.phx.gbl...
> > > > I don't know why this call succeeds but the OleDb database[/color][/color]
> interface[color=green][color=darkred]
> > > > doesn't support named parameters. See the remarks section of
> > > > OleDbParameter Class (
> > > >
> > >[/color]
> >[/color]
>[/color]
ms-help://MS.VSCC.2003/MS.MSDNQTR.2003 FEB.1033/cpref/html/frlrfsystemdata ole[color=blue][color=green][color=darkred]
> > > > dboledbparamete rclasstopic.htm )
> > > > on my machine.
> > > > You can name them any way you like but they are position dependent[/color][/color]
> and[color=green][color=darkred]
> > > > only require a name to access them in the collection.
> > > >
> > > > Ron Allen
> > > > <discussion@dis cussion.microso ft.com> wrote in message
> > > > news:eBE0Ufq2DH A.3468@TK2MSFTN GP11.phx.gbl...
> > > > > There are 2 issues here.
> > > > >
> > > > > 1. It programatically succeeds on the ExecuteNonQuery () call when[/color][/color]
> in[color=green][color=darkred]
> > > fact
> > > > > it does NOT succeed
> > > > >
> > > > > and
> > > > >
> > > > > 2. Named parameters are not processed correctly if they are not[/color][/color][/color]
in[color=blue][color=green][color=darkred]
> > > order
> > > > of
> > > > > the sql statement placement
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > "Miha Markic" <miha at rthand com> wrote in message
> > > > > news:%23qiaPSq2 DHA.2208@TK2MSF TNGP12.phx.gbl. ..
> > > > > > Hi,
> > > > > >
> > > > > > If you are using OleDb than markers for parameters are probably
> > > question
> > > > > > marks (?).
> > > > > > So, adding the parameters in the same order is the only way for[/color]
> > OleDb[color=darkred]
> > > to
> > > > > > recognize them.
> > > > > > Or is your scenario different?
> > > > > >
> > > > > > --
> > > > > > Miha Markic - RightHand .NET consulting & software development
> > > > > > miha at rthand com
> > > > > > www.rthand.com
> > > > > >
> > > > > > <discussion@dis cussion.microso ft.com> wrote in message
> > > > > > news:u8OyKKq2DH A.2792@TK2MSFTN GP09.phx.gbl...
> > > > > > > Hi,
> > > > > > >
> > > > > > > I was performing SQL UPDATE queries and I notice that they[/color]
> > SUCCEED[color=darkred]
> > > > on
> > > > > > the
> > > > > > > ExecuteNonQuery () call with NO exceptions raised BUT they fail[/color][/color]
> at[color=green][color=darkred]
> > > the
> > > > > > > Database. They say they succeed in the code but they fail at[/color][/color][/color]
the[color=blue][color=green][color=darkred]
> > > > > database.
> > > > > > >
> > > > > > > To fix this they Parameters.Add must be called in the ORDER[/color]
> > they[color=darkred]
> > > > are
> > > > > in
> > > > > > > the SQL STATEMENT.
> > > > > > >
> > > > > > > This is confusing and bad.
> > > > > > >
> > > > > > > How to repro.
> > > > > > > Construct a SQL query with the @ParamName .... out of[/color][/color][/color]
order[color=blue][color=green]
> > from[color=darkred]
> > > > the
> > > > > > > Parameter.Add(" @ParamName", var); calls.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Thanks.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >[/color]
> >
> >[/color]
>
>[/color]

OleDb Parameters BUG or BAD DESIGN

OleDb Parameters BUG or BAD DESIGN

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment