469,954 Members | 1,820 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,954 developers. It's quick & easy.

sqlTransaction Complete Problem-dataype change from image to varbi

Hi,

This is being called in a C# loop within an ado.net transaction from C# 1.1
code. It is used to write large file data to a SQL Server database in
chunks, rather than in one go.

I had the stored procedure below, which worked until the image datatype was
changed to varbinary(max).

Now I get the following error:

This SqlTransaction has completed; it is no longer usable

The stored procedure is here (NOTE this is the version that works with the
dataype set to image. If I change the datatype to varbinary(max), and
obviously change the field in the table as well, the code fails with the
error given above).

ALTER PROCEDURE [dbo].[FileUploadData_Upd]
@FileID Uniqueidentifier,
--@data varbinary(max),
@data image,
@append bit
AS

SET NOCOUNT ON
IF @append = 0
UPDATE dbo.FileUpload
SET Data = @data
WHERE FileId = @FileID;
IF @append = 1
UPDATE dbo.FileUpload
SET Data.write(@data,NULL,0)
Any help would be appreciated

--
Regards,

Phil Johnson (MCSD For .NET)
PJ Software Development
www.pjsoftwaredevelopment.com
Jan 23 '08 #1
15 2987
I should add, I have modified the datatype of the parameter in C# to be
varBinary:

SqlParameter paramData = cm.Parameters.Add("@data",
System.Data.SqlDbType.VarBinary);

And the isolation level of the transaction is ReadCommitted.

--
Regards,

Phillip Johnson (MCSD For .NET)
PJ Software Development
www.pjsoftwaredevelopment.com
"Phil Johnson" wrote:
Hi,

This is being called in a C# loop within an ado.net transaction from C# 1.1
code. It is used to write large file data to a SQL Server database in
chunks, rather than in one go.

I had the stored procedure below, which worked until the image datatype was
changed to varbinary(max).

Now I get the following error:

This SqlTransaction has completed; it is no longer usable

The stored procedure is here (NOTE this is the version that works with the
dataype set to image. If I change the datatype to varbinary(max), and
obviously change the field in the table as well, the code fails with the
error given above).

ALTER PROCEDURE [dbo].[FileUploadData_Upd]
@FileID Uniqueidentifier,
--@data varbinary(max),
@data image,
@append bit
AS

SET NOCOUNT ON
IF @append = 0
UPDATE dbo.FileUpload
SET Data = @data
WHERE FileId = @FileID;
IF @append = 1
UPDATE dbo.FileUpload
SET Data.write(@data,NULL,0)
Any help would be appreciated

--
Regards,

Phil Johnson (MCSD For .NET)
PJ Software Development
www.pjsoftwaredevelopment.com
Jan 24 '08 #2
Can you post the C# loop code at all?

Marc
Jan 24 '08 #3
Oops; forgot the throw! Very important... ;-p

catch {
tran.Rollback();
throw;
}

Marc
Jan 24 '08 #4
And just to show how TransactionScope makes life easier:

using (SqlCommand cmd = conn.CreateCommand())
using (TransactionScope tran = new TransactionScope()) {
// ...SNIP... (everything)
tran.Complete();
}
Jan 24 '08 #5
The one thing I'm not seeing in the code is anything to do with a
transaction...? Where is this transaction? Is it an ambient
(TransactionScope) transaction?

I altered my original SQL2000 code from here:
http://groups.google.co.uk/group/mic...4e7e3782e59a93

(with the changes as per the previous 2 posts), and it worked fine for
both SqlTransaction and TransactionScope?

So the transaction that appears to be closing itself: where is this
declared?
It is perhaps in a freaky orphan state, and the GC.Collect() is making
it call the finalize, hence tear down the transaction?

(in which case, don't let it get orphaned! If this is the problem, the
GC.Collect(), although unusual, has probably (by chance) just saved
you from a hard to track bug).

Marc
Jan 24 '08 #6
I suspect you're going to have to take pieces away until it
breaks...
Of course, I meant the other way around: start with something simple
that works, and keep adding pieces *in* until it breaks. It works fine
here...

Marc
Jan 24 '08 #7

Thanks for the help anyway Marc,

I will probably have to do as you say and start with the simplest form and
keep building up on it.

Its a sticky one... If I find out what is causing the problem I will add
another reply here.

Thanks again for your time

--
Regards,

Phillip Johnson (MCSD For .NET)
PJ Software Development
www.pjsoftwaredevelopment.com
"Marc Gravell" wrote:
I suspect you're going to have to take pieces away until it
breaks...

Of course, I meant the other way around: start with something simple
that works, and keep adding pieces *in* until it breaks. It works fine
here...

Marc
Jan 24 '08 #8
If I find out what is causing the problem I will add
another reply here.
Please do; I'm genuinely interested in what is going wrong - because
(obviously) this is something I need to do occasionally.

Marc
Jan 24 '08 #9
I think it is the size of the buffer... I cut it back to 8040 rather than
8040000 and it started going throught the loop again and again rather than
quiting the second time through.

I was trying a 100MB file and it killed my machine though.... I will try
other sizes when I get back in the office tomorrow to try to find an optimum
size but early indications are that is going to get it.

Thanks again for your help, its greatly appreciated.

--
Regards,

Phillip Johnson (MCSD For .NET)
PJ Software Development
www.pjsoftwaredevelopment.com
"Marc Gravell" wrote:
If I find out what is causing the problem I will add
another reply here.

Please do; I'm genuinely interested in what is going wrong - because
(obviously) this is something I need to do occasionally.

Marc
Jan 24 '08 #10
Actually, I've got an idea that might solve both problems - I'm going
to try it on the train tomorrow ;-p

Marc
Jan 24 '08 #11
One other thought; for big files like this, you might consider storing
them outside of the db and simply referencing them via some kind of
relative path? Also: in SQL Server 2008 there is built in file-stream
support; but I haven't played with it yet so I don't know how exactly
it can be used...

Marc
Jan 25 '08 #12
Hi Marc,

Thanks for the code, I will give it a try.

Also, thanks for the suggestion re the large files being stored as files and
the path being stored in the database. I don't think we would go for it
because we use the full text searching in SQL Server, but it could be an
option if all else fails.

Enjoy the weekend :-)

--
Regards,

Phillip Johnson (MCSD For .NET)
PJ Software Development
www.pjsoftwaredevelopment.com
"Marc Gravell" wrote:
One other thought; for big files like this, you might consider storing
them outside of the db and simply referencing them via some kind of
relative path? Also: in SQL Server 2008 there is built in file-stream
support; but I haven't played with it yet so I don't know how exactly
it can be used...

Marc
Jan 25 '08 #13
I found out what the issue was on this one... when the datatype had been
changed, the stored procedure to write the file in chunks was modified to use
a newer call than Writetext and the Where statement was omitted.

This meant that for the appends, it was appending the buffer chunk to EVERY
file in the database, which was hundreds.

Thanks for all your help on this one though Marc.
--
Regards,

Phillip Johnson (MCSD For .NET)
PJ Software Development
www.pjsoftwaredevelopment.com
"Phil Johnson" wrote:
Hi,

This is being called in a C# loop within an ado.net transaction from C# 1.1
code. It is used to write large file data to a SQL Server database in
chunks, rather than in one go.

I had the stored procedure below, which worked until the image datatype was
changed to varbinary(max).

Now I get the following error:

This SqlTransaction has completed; it is no longer usable

The stored procedure is here (NOTE this is the version that works with the
dataype set to image. If I change the datatype to varbinary(max), and
obviously change the field in the table as well, the code fails with the
error given above).

ALTER PROCEDURE [dbo].[FileUploadData_Upd]
@FileID Uniqueidentifier,
--@data varbinary(max),
@data image,
@append bit
AS

SET NOCOUNT ON
IF @append = 0
UPDATE dbo.FileUpload
SET Data = @data
WHERE FileId = @FileID;
IF @append = 1
UPDATE dbo.FileUpload
SET Data.write(@data,NULL,0)
Any help would be appreciated

--
Regards,

Phil Johnson (MCSD For .NET)
PJ Software Development
www.pjsoftwaredevelopment.com
Jan 29 '08 #14
and the Where statement was omitted.
You're going to kick yourself, but I already pointed this out on the
24th:

Glad it started working, though...

<q>
SP: [note btw that you missed a WHERE clause from yours...]
</q>

Marc
Jan 29 '08 #15
hehe, I know, I've already kicked myself for not spotting it... it wasn't
something I thought had changed so hadn't looked in that area.... I thought I
just hadn't copied the whole sp when you mentioned it... ah well.. you live
and learn... I'm just glad its fixed!
--
Regards,

Phillip Johnson (MCSD For .NET)
PJ Software Development
www.pjsoftwaredevelopment.com
"Marc Gravell" wrote:
and the Where statement was omitted.
You're going to kick yourself, but I already pointed this out on the
24th:

Glad it started working, though...

<q>
SP: [note btw that you missed a WHERE clause from yours...]
</q>

Marc
Jan 29 '08 #16

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by mahajan.sanjeev | last post: by
2 posts views Thread by mahajan.sanjeev | last post: by
reply views Thread by mahajan.sanjeev | last post: by
reply views Thread by perspolis | last post: by
reply views Thread by Joe Rigley | last post: by
5 posts views Thread by Swami Muthuvelu | last post: by
3 posts views Thread by Neven Klofutar | last post: by
4 posts views Thread by perspolis | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.