Strange behavior with SQL text field and ADO Parameter....a challenge for the experts (Aaron Bertran

D

Dan

I've run into an interesting problem, and seemed to have stumped 3
newsgroups and 2 other forums.

For some reason when I try to insert a record into a SQL table that has a
Text column, the returned autogenerated Identity is wrong (on the VB side).
This only occurs if the length of the value inserted for the text column is
= 8002.
Click to expand...

I've included a simple example below.

-----------------------------------------

/* Simple table with 1 identity column, and 1 text column) */
CREATE TABLE [dbo].[Foo] (
[FooID] [int] IDENTITY (1, 1) NOT NULL ,
[FooText] [text] COLLATE SQL_Latin1_General_CP1_CI_AS NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO

/* Identity column is clustered and set as the primary key */
ALTER TABLE [dbo].[Foo] WITH NOCHECK ADD
CONSTRAINT [PK_Foo] PRIMARY KEY CLUSTERED
(
[FooID]
) WITH FILLFACTOR = 90 ON [PRIMARY]
GO

' ********************************
' VB Code Below...References ADO
' ********************************
Private Sub Save_Foo()
Dim cn As New Connection, cmd As New Command

Call cn.Open("DSN=xxxx;UID=xxxx;pwd=xxxx") ' Enter your connectionstring
here

cmd.ActiveConnection = cn

cmd.CommandType = adCmdStoredProc
cmd.CommandText = "Foo_Insert"

cmd.Parameters.Append cmd.CreateParameter("FooID", adInteger, adParamOutput,
, 0)
cmd.Parameters.Append cmd.CreateParameter("FooText", adLongVarChar,
adParamInput, 8002, String(8002, "@"))

Call cmd.Execute

MsgBox "Returned FooID: " & cmd.Parameters("FooID").Value
End Sub


/* Stored Procedure */
Alter Procedure Foo_Insert
(
@FooID int output,
@FooText text
)
As

INSERT INTO Foo (FooText) VALUES (@FooText)

SET @FooID = @@IDENTITY

return

-----------------------------------------

When I run the code above the returned output parameter in VB is wrong. At
first it was always returning 60368600, then 60387816, and now the value is
0.

If I change the value and length of the 2nd parameter to be only 8001
characters long, it works fine (i.e. the output parameter is incremented
normally 1,2,3...etc.)

I don't believe the problem is on the SQL side because in both cases the
information was inserted correctly into the table, and when I step through
the stored procedure @@IDENTITY returns the correct value, the only problem
is VB assigns the wrong value to the output parameter.

I thought it might be the Parameter Type I was using for the Text field
(adLongVarChar), but I've tried others resulting in various errors.

I've tried referencing different versions of ADO (2.1, 2.5, and 2.7) and the
problem persists.

I've changed @@IDENTITY to SCOPE_IDENTITY(), and it still doesn't work
(note: the stored procedure seems to work fine, so this shouldn't have any
effect on it anyway).

I'm not sure if anyone else has actually tried to run the code (please do
so), so I can determine if it is something in our environment.

What I'm trying to do (insert a record into a table with a text field, and
return the auto-generated id via @@IDENTITY or SCOPE_IDENTITY() as an output
parameter) seems like a fairly common thing, and seems like it could be a
major bug in ADO.

Can anyone help me with this?

Thanks in advance.
Dan
 
B

Bob Barrows [MVP]

The first thing I see is the lack of SET NOCOUNT ON in your stored
procedure. Without that, your procedure is returning a resultset containing
an "x records affected by the insert statement" message.Ouput parameter
values are not returned until resultsets are consumed. Add SET NOCOUNT ON to
prevent the creation of the resultset.

Bob Barrows

I've run into an interesting problem, and seemed to have stumped 3
newsgroups and 2 other forums.

For some reason when I try to insert a record into a SQL table that
has a Text column, the returned autogenerated Identity is wrong (on
the VB side). This only occurs if the length of the value inserted
for the text column is
= 8002.
Click to expand...

I've included a simple example below.

-----------------------------------------

/* Simple table with 1 identity column, and 1 text column) */
CREATE TABLE [dbo].[Foo] (
[FooID] [int] IDENTITY (1, 1) NOT NULL ,
[FooText] [text] COLLATE SQL_Latin1_General_CP1_CI_AS NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO

/* Identity column is clustered and set as the primary key */
ALTER TABLE [dbo].[Foo] WITH NOCHECK ADD
CONSTRAINT [PK_Foo] PRIMARY KEY CLUSTERED
(
[FooID]
) WITH FILLFACTOR = 90 ON [PRIMARY]
GO

' ********************************
' VB Code Below...References ADO
' ********************************
Private Sub Save_Foo()
Dim cn As New Connection, cmd As New Command

Call cn.Open("DSN=xxxx;UID=xxxx;pwd=xxxx") ' Enter your
connectionstring here

cmd.ActiveConnection = cn

cmd.CommandType = adCmdStoredProc
cmd.CommandText = "Foo_Insert"

cmd.Parameters.Append cmd.CreateParameter("FooID", adInteger,
adParamOutput, , 0)
cmd.Parameters.Append cmd.CreateParameter("FooText", adLongVarChar,
adParamInput, 8002, String(8002, "@"))

Call cmd.Execute

MsgBox "Returned FooID: " & cmd.Parameters("FooID").Value
End Sub


/* Stored Procedure */
Alter Procedure Foo_Insert
(
@FooID int output,
@FooText text
)
As

INSERT INTO Foo (FooText) VALUES (@FooText)

SET @FooID = @@IDENTITY

return

-----------------------------------------

When I run the code above the returned output parameter in VB is
wrong. At first it was always returning 60368600, then 60387816, and
now the value is 0.

If I change the value and length of the 2nd parameter to be only 8001
characters long, it works fine (i.e. the output parameter is
incremented normally 1,2,3...etc.)

I don't believe the problem is on the SQL side because in both cases
the information was inserted correctly into the table, and when I
step through the stored procedure @@IDENTITY returns the correct
value, the only problem is VB assigns the wrong value to the output
parameter.

I thought it might be the Parameter Type I was using for the Text
field (adLongVarChar), but I've tried others resulting in various
errors.

I've tried referencing different versions of ADO (2.1, 2.5, and 2.7)
and the problem persists.

I've changed @@IDENTITY to SCOPE_IDENTITY(), and it still doesn't work
(note: the stored procedure seems to work fine, so this shouldn't
have any effect on it anyway).

I'm not sure if anyone else has actually tried to run the code
(please do so), so I can determine if it is something in our
environment.

What I'm trying to do (insert a record into a table with a text
field, and return the auto-generated id via @@IDENTITY or
SCOPE_IDENTITY() as an output parameter) seems like a fairly common
thing, and seems like it could be a major bug in ADO.

Can anyone help me with this?

Thanks in advance.
Dan
Click to expand...
 
D

Dan

Tried it, but it still doesn't work (output parameter is 0 after execute
statement).

Also, remember it works fine if the 2nd parameter's length is < 8002.

Thanks,
Dan

Bob Barrows said:
The first thing I see is the lack of SET NOCOUNT ON in your stored
procedure. Without that, your procedure is returning a resultset containing
an "x records affected by the insert statement" message.Ouput parameter
values are not returned until resultsets are consumed. Add SET NOCOUNT ON to
prevent the creation of the resultset.

Bob Barrows

I've run into an interesting problem, and seemed to have stumped 3
newsgroups and 2 other forums.

For some reason when I try to insert a record into a SQL table that
has a Text column, the returned autogenerated Identity is wrong (on
the VB side). This only occurs if the length of the value inserted
for the text column is
= 8002.
Click to expand...

I've included a simple example below.

-----------------------------------------

/* Simple table with 1 identity column, and 1 text column) */
CREATE TABLE [dbo].[Foo] (
[FooID] [int] IDENTITY (1, 1) NOT NULL ,
[FooText] [text] COLLATE SQL_Latin1_General_CP1_CI_AS NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO

/* Identity column is clustered and set as the primary key */
ALTER TABLE [dbo].[Foo] WITH NOCHECK ADD
CONSTRAINT [PK_Foo] PRIMARY KEY CLUSTERED
(
[FooID]
) WITH FILLFACTOR = 90 ON [PRIMARY]
GO

' ********************************
' VB Code Below...References ADO
' ********************************
Private Sub Save_Foo()
Dim cn As New Connection, cmd As New Command

Call cn.Open("DSN=xxxx;UID=xxxx;pwd=xxxx") ' Enter your
connectionstring here

cmd.ActiveConnection = cn

cmd.CommandType = adCmdStoredProc
cmd.CommandText = "Foo_Insert"

cmd.Parameters.Append cmd.CreateParameter("FooID", adInteger,
adParamOutput, , 0)
cmd.Parameters.Append cmd.CreateParameter("FooText", adLongVarChar,
adParamInput, 8002, String(8002, "@"))

Call cmd.Execute

MsgBox "Returned FooID: " & cmd.Parameters("FooID").Value
End Sub


/* Stored Procedure */
Alter Procedure Foo_Insert
(
@FooID int output,
@FooText text
)
As

INSERT INTO Foo (FooText) VALUES (@FooText)

SET @FooID = @@IDENTITY

return

-----------------------------------------

When I run the code above the returned output parameter in VB is
wrong. At first it was always returning 60368600, then 60387816, and
now the value is 0.

If I change the value and length of the 2nd parameter to be only 8001
characters long, it works fine (i.e. the output parameter is
incremented normally 1,2,3...etc.)

I don't believe the problem is on the SQL side because in both cases
the information was inserted correctly into the table, and when I
step through the stored procedure @@IDENTITY returns the correct
value, the only problem is VB assigns the wrong value to the output
parameter.

I thought it might be the Parameter Type I was using for the Text
field (adLongVarChar), but I've tried others resulting in various
errors.

I've tried referencing different versions of ADO (2.1, 2.5, and 2.7)
and the problem persists.

I've changed @@IDENTITY to SCOPE_IDENTITY(), and it still doesn't work
(note: the stored procedure seems to work fine, so this shouldn't
have any effect on it anyway).

I'm not sure if anyone else has actually tried to run the code
(please do so), so I can determine if it is something in our
environment.

What I'm trying to do (insert a record into a table with a text
field, and return the auto-generated id via @@IDENTITY or
SCOPE_IDENTITY() as an output parameter) seems like a fairly common
thing, and seems like it could be a major bug in ADO.

Can anyone help me with this?

Thanks in advance.
Dan
Click to expand...

--
Microsoft MVP -- ASP/ASP.NET
Please reply to the newsgroup. The email account listed in my From
header is my spam trap, so I don't check it very often. You will get a
quicker response by posting to the newsgroup.
Click to expand...
 
D

Dan

Someone was kind enough to point me to
http://support.microsoft.com/default.aspx?scid=kb;en-us;218751, which
basically says that it is a known bug and the only solution is to use the
SQLOLEDB provider.

It also says, "This problem was corrected in MDAC 2.6.". However, it still
doesn't seem to work without the use of the SQLOLEDB provider, so I'm not
sure how that can be considered "corrected".

Thanks,
Dan


Dan said:
I've run into an interesting problem, and seemed to have stumped 3
newsgroups and 2 other forums.

For some reason when I try to insert a record into a SQL table that has a
Text column, the returned autogenerated Identity is wrong (on the VB side).
This only occurs if the length of the value inserted for the text column is
= 8002.
Click to expand...

I've included a simple example below.

-----------------------------------------

/* Simple table with 1 identity column, and 1 text column) */
CREATE TABLE [dbo].[Foo] (
[FooID] [int] IDENTITY (1, 1) NOT NULL ,
[FooText] [text] COLLATE SQL_Latin1_General_CP1_CI_AS NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO

/* Identity column is clustered and set as the primary key */
ALTER TABLE [dbo].[Foo] WITH NOCHECK ADD
CONSTRAINT [PK_Foo] PRIMARY KEY CLUSTERED
(
[FooID]
) WITH FILLFACTOR = 90 ON [PRIMARY]
GO

' ********************************
' VB Code Below...References ADO
' ********************************
Private Sub Save_Foo()
Dim cn As New Connection, cmd As New Command

Call cn.Open("DSN=xxxx;UID=xxxx;pwd=xxxx") ' Enter your connectionstring
here

cmd.ActiveConnection = cn

cmd.CommandType = adCmdStoredProc
cmd.CommandText = "Foo_Insert"

cmd.Parameters.Append cmd.CreateParameter("FooID", adInteger, adParamOutput,
, 0)
cmd.Parameters.Append cmd.CreateParameter("FooText", adLongVarChar,
adParamInput, 8002, String(8002, "@"))

Call cmd.Execute

MsgBox "Returned FooID: " & cmd.Parameters("FooID").Value
End Sub


/* Stored Procedure */
Alter Procedure Foo_Insert
(
@FooID int output,
@FooText text
)
As

INSERT INTO Foo (FooText) VALUES (@FooText)

SET @FooID = @@IDENTITY

return

-----------------------------------------

When I run the code above the returned output parameter in VB is wrong. At
first it was always returning 60368600, then 60387816, and now the value is
0.

If I change the value and length of the 2nd parameter to be only 8001
characters long, it works fine (i.e. the output parameter is incremented
normally 1,2,3...etc.)

I don't believe the problem is on the SQL side because in both cases the
information was inserted correctly into the table, and when I step through
the stored procedure @@IDENTITY returns the correct value, the only problem
is VB assigns the wrong value to the output parameter.

I thought it might be the Parameter Type I was using for the Text field
(adLongVarChar), but I've tried others resulting in various errors.

I've tried referencing different versions of ADO (2.1, 2.5, and 2.7) and the
problem persists.

I've changed @@IDENTITY to SCOPE_IDENTITY(), and it still doesn't work
(note: the stored procedure seems to work fine, so this shouldn't have any
effect on it anyway).

I'm not sure if anyone else has actually tried to run the code (please do
so), so I can determine if it is something in our environment.

What I'm trying to do (insert a record into a table with a text field, and
return the auto-generated id via @@IDENTITY or SCOPE_IDENTITY() as an output
parameter) seems like a fairly common thing, and seems like it could be a
major bug in ADO.

Can anyone help me with this?

Thanks in advance.
Dan
Click to expand...
 
A

Aaron [SQL Server MVP]

It also says, "This problem was corrected in MDAC 2.6.". However, it
still
doesn't seem to work without the use of the SQLOLEDB provider, so I'm not
sure how that can be considered "corrected".
Click to expand...

Because ODBC has been deprecated, so you should be botching all of your DSNs
anyway?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

VERY strange issue with SQL 2000 + ADO Command object 4
Error with Command.Append 0
Output parameters for dynamic SQL 2
VFP9 and SQL 2005 using VFP remote view Cannot insert the value NULL into column 0
Problem with IDENTITY 0
Problem with the Legacy ASP files and the Sql Server Express 12
Download the JAVA , .NET and SQL Server interview with answers 0
Concurrency / LINQDataSource / FormView / Stored Procedures 9

Members online

No members online now.
Total: 36 (members: 0, guests: 36)
Robots: 443

Forum statistics

Threads
473,770
Messages
2,569,584
Members
45,075
Latest member
MakersCBDBloodSupport

Latest Threads

Top