I have a .net program which usually create temp table in SQL Server 2005 and
populate it from com contrlol to apply later to the main table.But sometimes
I need to delete some of previously inserted rows to replace them with maybe
more and adjusted ones.
I did this by deleting suspicious rows and going back on com control to
inserting rows.
I did found that I am missing some rows.
It seems that deletion does not synchronized with consequenced insertions.
Is it neccessary to do explicit transaction or this is one of 2005
optimizations on temp tables?Hi
I am not really clear how you are doing this, maybe you would like to post
some sample code? If the com control has it's own connection then you may no
t
be using the same temporary table!
John
"UncleSam89" wrote:
> I have a .net program which usually create temp table in SQL Server 2005 a
nd
> populate it from com contrlol to apply later to the main table.But sometim
es
> I need to delete some of previously inserted rows to replace them with may
be
> more and adjusted ones.
> I did this by deleting suspicious rows and going back on com control to
> inserting rows.
> I did found that I am missing some rows.
> It seems that deletion does not synchronized with consequenced insertions.
> Is it neccessary to do explicit transaction or this is one of 2005
> optimizations on temp tables?|||It seems that it was my own bug
sorry
"John Bell" wrote:
[vbcol=seagreen]
> Hi
> I am not really clear how you are doing this, maybe you would like to post
> some sample code? If the com control has it's own connection then you may
not
> be using the same temporary table!
> John
> "UncleSam89" wrote:
>
Showing posts with label contrlol. Show all posts
Showing posts with label contrlol. Show all posts
Monday, February 13, 2012
About implicit transactions in temp table
I have a .net program which usually create temp table in SQL Server 2005 and
populate it from com contrlol to apply later to the main table.But sometimes
I need to delete some of previously inserted rows to replace them with maybe
more and adjusted ones.
I did this by deleting suspicious rows and going back on com control to
inserting rows.
I did found that I am missing some rows.
It seems that deletion does not synchronized with consequenced insertions.
Is it neccessary to do explicit transaction or this is one of 2005
optimizations on temp tables?Hi
I am not really clear how you are doing this, maybe you would like to post
some sample code? If the com control has it's own connection then you may not
be using the same temporary table!
John
"UncleSam89" wrote:
> I have a .net program which usually create temp table in SQL Server 2005 and
> populate it from com contrlol to apply later to the main table.But sometimes
> I need to delete some of previously inserted rows to replace them with maybe
> more and adjusted ones.
> I did this by deleting suspicious rows and going back on com control to
> inserting rows.
> I did found that I am missing some rows.
> It seems that deletion does not synchronized with consequenced insertions.
> Is it neccessary to do explicit transaction or this is one of 2005
> optimizations on temp tables?|||It seems that it was my own bug
sorry
"John Bell" wrote:
> Hi
> I am not really clear how you are doing this, maybe you would like to post
> some sample code? If the com control has it's own connection then you may not
> be using the same temporary table!
> John
> "UncleSam89" wrote:
> > I have a .net program which usually create temp table in SQL Server 2005 and
> > populate it from com contrlol to apply later to the main table.But sometimes
> > I need to delete some of previously inserted rows to replace them with maybe
> > more and adjusted ones.
> > I did this by deleting suspicious rows and going back on com control to
> > inserting rows.
> > I did found that I am missing some rows.
> > It seems that deletion does not synchronized with consequenced insertions.
> > Is it neccessary to do explicit transaction or this is one of 2005
> > optimizations on temp tables?
populate it from com contrlol to apply later to the main table.But sometimes
I need to delete some of previously inserted rows to replace them with maybe
more and adjusted ones.
I did this by deleting suspicious rows and going back on com control to
inserting rows.
I did found that I am missing some rows.
It seems that deletion does not synchronized with consequenced insertions.
Is it neccessary to do explicit transaction or this is one of 2005
optimizations on temp tables?Hi
I am not really clear how you are doing this, maybe you would like to post
some sample code? If the com control has it's own connection then you may not
be using the same temporary table!
John
"UncleSam89" wrote:
> I have a .net program which usually create temp table in SQL Server 2005 and
> populate it from com contrlol to apply later to the main table.But sometimes
> I need to delete some of previously inserted rows to replace them with maybe
> more and adjusted ones.
> I did this by deleting suspicious rows and going back on com control to
> inserting rows.
> I did found that I am missing some rows.
> It seems that deletion does not synchronized with consequenced insertions.
> Is it neccessary to do explicit transaction or this is one of 2005
> optimizations on temp tables?|||It seems that it was my own bug
sorry
"John Bell" wrote:
> Hi
> I am not really clear how you are doing this, maybe you would like to post
> some sample code? If the com control has it's own connection then you may not
> be using the same temporary table!
> John
> "UncleSam89" wrote:
> > I have a .net program which usually create temp table in SQL Server 2005 and
> > populate it from com contrlol to apply later to the main table.But sometimes
> > I need to delete some of previously inserted rows to replace them with maybe
> > more and adjusted ones.
> > I did this by deleting suspicious rows and going back on com control to
> > inserting rows.
> > I did found that I am missing some rows.
> > It seems that deletion does not synchronized with consequenced insertions.
> > Is it neccessary to do explicit transaction or this is one of 2005
> > optimizations on temp tables?
Subscribe to:
Posts (Atom)