Hi All,
In a couple of weeks, after finishing my current project, I'll start a -for
me- quite challenging project, so I'm already starting to do some research.
Since I had a little bump in with Aaron some time ago, when I asked for an
easiest solution, I'll just ask for some pointers this time ;-)
There are 2 companies involved. One is a school. The other one does the
examination of the school's students. On both ends, the software will be
developed in VB .NET, with -for starters- MSDE as the datastore. When a
student starts a course, his/her data will be entered in the school's
database. This data has to be send to the examination institute. After the
student has taken an exam, the results have to be send back to the school.
On both ends, they need their own database, since only part of the data will
be shared among the companies. As I said, they will both be running MSDE
2000 and they are both connected to the internet through DSL (with fixed
IP-adresses).
All pointers to exchange data this way are welcome. I'm not new to SQL
Server/MSDE, but still bit of a novice. I've read something about the
'famous' port 1433. But as far as I've understood opening that one might not
be a good idea, security-wise. I've also read something about webservices
(or something like that).
I'm quite stuck here. Please help me out a bit.
Thanks,
Willem
I would tier your system and create a .Net web service on both ends to send
and consume data. Creating web services in .Net is rather easy and VS .Net
comes with some sample projects to start from.
Jim
"Willem van den Broek" <willem@.chsd.nl> wrote in message
news:%23qamZc8NEHA.268@.TK2MSFTNGP11.phx.gbl...
> Hi All,
> In a couple of weeks, after finishing my current project, I'll start
a -for
> me- quite challenging project, so I'm already starting to do some
research.
> Since I had a little bump in with Aaron some time ago, when I asked for an
> easiest solution, I'll just ask for some pointers this time ;-)
> There are 2 companies involved. One is a school. The other one does the
> examination of the school's students. On both ends, the software will be
> developed in VB .NET, with -for starters- MSDE as the datastore. When a
> student starts a course, his/her data will be entered in the school's
> database. This data has to be send to the examination institute. After the
> student has taken an exam, the results have to be send back to the school.
> On both ends, they need their own database, since only part of the data
will
> be shared among the companies. As I said, they will both be running MSDE
> 2000 and they are both connected to the internet through DSL (with fixed
> IP-adresses).
> All pointers to exchange data this way are welcome. I'm not new to SQL
> Server/MSDE, but still bit of a novice. I've read something about the
> 'famous' port 1433. But as far as I've understood opening that one might
not
> be a good idea, security-wise. I've also read something about webservices
> (or something like that).
> I'm quite stuck here. Please help me out a bit.
> Thanks,
> Willem
>
|||Thanks Jim. I was already afraid that would be the answer. I was hoping
there would be a solution without having to use IIS...
Willem
"J Young" <thorium48@.hotmail.com> schreef in bericht
news:OK2HMi9NEHA.3012@.tk2msftngp13.phx.gbl...
> I would tier your system and create a .Net web service on both ends to
send[vbcol=seagreen]
> and consume data. Creating web services in .Net is rather easy and VS .Net
> comes with some sample projects to start from.
> Jim
> "Willem van den Broek" <willem@.chsd.nl> wrote in message
> news:%23qamZc8NEHA.268@.TK2MSFTNGP11.phx.gbl...
> a -for
> research.
an[vbcol=seagreen]
the[vbcol=seagreen]
school.[vbcol=seagreen]
> will
> not
webservices
>
Showing posts with label current. Show all posts
Showing posts with label current. Show all posts
Monday, March 19, 2012
Monday, March 12, 2012
Excessive locking
I inherited a hell hole of a system.
This is how a key is generated in my current system:
--GET A NEW ORDERID
SET @.OrderId= (SELECT MAX(Orderid) + 1 AS LastID FROM LAST_ORDERID with
(TABLOCKX))
--UPDATE LAST ORDERID TABLE
UPDATE LAST_ORDERID SET OrderID = @.OrderID
SET @.ErrCount = @.ErrCount + @.@.Error
--END UPDATE LAST_ORDERID
Last_orderid has one column / one row, and is pretty useless IMO.
Past the idea of creating an identity column on Orderid in Orders
would
it be good practice to put this in a begin transaction, commit transaction
to reduce the lock time?
TIA
Looks like your identity in the Orders table is what's needed, but rejecting
that idea (racking my brain to think or a reason why)...
You could make the orderid in Last_OrderID an identity column and let it
create the rows. You will need another column to insert (use NULLbit) If
you use @.@.Scope_Identity you don't need the lock.
The additional storage space is minimal. You could even delete that table
every night if that is an issue (note: Do not use Truncate. It resets the
identity whereas delete does not).
Your DDL would look like:
Drop Table Last_orderid
Go
Create Table Last_orderid
orderid int identity (XXX, 1),
NULLbit bit
Go
--Where XXX is the next orderid at the time this script is run
Your query would look like:
Declare @.newOrderID int
Insert into Last_orderid (NULLbit) Select NULL
Set @.newOrderID = @.@.Scope_Identity
--Update Order Table
"__Stephen" <srussell@.transactiongraphics.com> wrote in message
news:ulVZ7%23K4FHA.1184@.TK2MSFTNGP12.phx.gbl...
>I inherited a hell hole of a system.
> This is how a key is generated in my current system:
> --GET A NEW ORDERID
> SET @.OrderId= (SELECT MAX(Orderid) + 1 AS LastID FROM LAST_ORDERID with
> (TABLOCKX))
> --UPDATE LAST ORDERID TABLE
> UPDATE LAST_ORDERID SET OrderID = @.OrderID
> SET @.ErrCount = @.ErrCount + @.@.Error
> --END UPDATE LAST_ORDERID
>
> Last_orderid has one column / one row, and is pretty useless IMO.
> Past the idea of creating an identity column on Orderid in Orders would
> it be good practice to put this in a begin transaction, commit transaction
> to reduce the lock time?
> TIA
>
>
>
>
>
|||Thanks Joe!
"Joe" <joe@.aol.com> wrote in message
news:u0Lx4fL4FHA.3444@.tk2msftngp13.phx.gbl...
> Looks like your identity in the Orders table is what's needed, but
> rejecting that idea (racking my brain to think or a reason why)...
I have found 28 SP's that insert into this table, and I'm real afraid that
in our years of code some people have written dynamic crap to do likewise.
I then have to follow this to about 15+ other tables in our system.
> You could make the orderid in Last_OrderID an identity column and let it
> create the rows. You will need another column to insert (use NULLbit) If
> you use @.@.Scope_Identity you don't need the lock.
Queston I have is when will that brainfart lock be released if no commit
tran is in the SP? At the end of the SP? If so that is what I need to
STOP. I am getting killed in an invoicing run that does similar locking,
but that SP is huge.
What I want to do is convert over to identity, but I have to walk softly,
and look for a real big stick. I am going to deal with one primay key
that is used in the invoicing run above. It's got a small impact for users
who could be affected.
> The additional storage space is minimal. You could even delete that table
> every night if that is an issue (note: Do not use Truncate. It resets the
> identity whereas delete does not).
> Your DDL would look like:
> Drop Table Last_orderid
> Go
> Create Table Last_orderid
> orderid int identity (XXX, 1),
> NULLbit bit
> Go
> --Where XXX is the next orderid at the time this script is run
>
> Your query would look like:
> Declare @.newOrderID int
> Insert into Last_orderid (NULLbit) Select NULL
> Set @.newOrderID = @.@.Scope_Identity
> --Update Order Table
>
> "__Stephen" <srussell@.transactiongraphics.com> wrote in message
> news:ulVZ7%23K4FHA.1184@.TK2MSFTNGP12.phx.gbl...
>
|||Put it in a transaction to assure correct behavior, it won't save any
time, though.
J.
On Thu, 3 Nov 2005 13:49:47 -0600, "__Stephen"
<srussell@.transactiongraphics.com> wrote:
>I inherited a hell hole of a system.
>This is how a key is generated in my current system:
>--GET A NEW ORDERID
>SET @.OrderId= (SELECT MAX(Orderid) + 1 AS LastID FROM LAST_ORDERID with
>(TABLOCKX))
>--UPDATE LAST ORDERID TABLE
>UPDATE LAST_ORDERID SET OrderID = @.OrderID
>SET @.ErrCount = @.ErrCount + @.@.Error
>--END UPDATE LAST_ORDERID
>
>Last_orderid has one column / one row, and is pretty useless IMO.
>Past the idea of creating an identity column on Orderid in Orders would
>it be good practice to put this in a begin transaction, commit transaction
>to reduce the lock time?
>TIA
>
>
>
>
>
|||"jxstern" <jxstern@.nowhere.xyz> wrote in message
news:n52lm19pmhronpc0iks5vr5pe17l8ar1h6@.4ax.com...
> Put it in a transaction to assure correct behavior, it won't save any
> time, though.
I only gave 1% of the SP for show. In all actuality an insert into my
Orders table follows this:
Lock NextKey#Table and return it's current value +1
Update NextKey#Table
Pull secondary business data for use later.
Insert into Orders Table using NextKey# from above.
Insert into OtherBizTable with NextKey and that other BizData
Insert into OrderDetails
Check ErrorStatus
if so Roll back and send email to people who care
otherwise commit
Now lock will disengage? < I think that I have locked ALL tables in use
through this SP because of this opening line>
SET @.OrderId= (SELECT MAX(Orderid) + 1 AS LastID FROM LAST_ORDERID with
(TABLOCKX))
So if I commit that transaction at the top, I won't lock all the way
through?
TIA
__Stephen
|||Are you asking if you should separately commit the couple of lines at
the top of the SP, instead of putting the whole thing in a
transaction?
You are aware that an SP does not automatically comprise a
transaction, you have to explicitly ask for it, so maybe there is no
transaction at all in your current code?
J.
On Fri, 4 Nov 2005 08:04:31 -0600, "__Stephen"
<srussell@.transactiongraphics.com> wrote:
>"jxstern" <jxstern@.nowhere.xyz> wrote in message
>news:n52lm19pmhronpc0iks5vr5pe17l8ar1h6@.4ax.com.. .
>I only gave 1% of the SP for show. In all actuality an insert into my
>Orders table follows this:
>Lock NextKey#Table and return it's current value +1
>Update NextKey#Table
>Pull secondary business data for use later.
>Insert into Orders Table using NextKey# from above.
>Insert into OtherBizTable with NextKey and that other BizData
>Insert into OrderDetails
>Check ErrorStatus
>if so Roll back and send email to people who care
>otherwise commit
>Now lock will disengage? < I think that I have locked ALL tables in use
>through this SP because of this opening line>
>SET @.OrderId= (SELECT MAX(Orderid) + 1 AS LastID FROM LAST_ORDERID with
>(TABLOCKX))
>So if I commit that transaction at the top, I won't lock all the way
>through?
>TIA
>__Stephen
>
>
This is how a key is generated in my current system:
--GET A NEW ORDERID
SET @.OrderId= (SELECT MAX(Orderid) + 1 AS LastID FROM LAST_ORDERID with
(TABLOCKX))
--UPDATE LAST ORDERID TABLE
UPDATE LAST_ORDERID SET OrderID = @.OrderID
SET @.ErrCount = @.ErrCount + @.@.Error
--END UPDATE LAST_ORDERID
Last_orderid has one column / one row, and is pretty useless IMO.
Past the idea of creating an identity column on Orderid in Orders
wouldit be good practice to put this in a begin transaction, commit transaction
to reduce the lock time?
TIA
Looks like your identity in the Orders table is what's needed, but rejecting
that idea (racking my brain to think or a reason why)...
You could make the orderid in Last_OrderID an identity column and let it
create the rows. You will need another column to insert (use NULLbit) If
you use @.@.Scope_Identity you don't need the lock.
The additional storage space is minimal. You could even delete that table
every night if that is an issue (note: Do not use Truncate. It resets the
identity whereas delete does not).
Your DDL would look like:
Drop Table Last_orderid
Go
Create Table Last_orderid
orderid int identity (XXX, 1),
NULLbit bit
Go
--Where XXX is the next orderid at the time this script is run
Your query would look like:
Declare @.newOrderID int
Insert into Last_orderid (NULLbit) Select NULL
Set @.newOrderID = @.@.Scope_Identity
--Update Order Table
"__Stephen" <srussell@.transactiongraphics.com> wrote in message
news:ulVZ7%23K4FHA.1184@.TK2MSFTNGP12.phx.gbl...
>I inherited a hell hole of a system.
> This is how a key is generated in my current system:
> --GET A NEW ORDERID
> SET @.OrderId= (SELECT MAX(Orderid) + 1 AS LastID FROM LAST_ORDERID with
> (TABLOCKX))
> --UPDATE LAST ORDERID TABLE
> UPDATE LAST_ORDERID SET OrderID = @.OrderID
> SET @.ErrCount = @.ErrCount + @.@.Error
> --END UPDATE LAST_ORDERID
>
> Last_orderid has one column / one row, and is pretty useless IMO.
> Past the idea of creating an identity column on Orderid in Orders
would> it be good practice to put this in a begin transaction, commit transaction
> to reduce the lock time?
> TIA
>
>
>
>
>
|||Thanks Joe!
"Joe" <joe@.aol.com> wrote in message
news:u0Lx4fL4FHA.3444@.tk2msftngp13.phx.gbl...
> Looks like your identity in the Orders table is what's needed, but
> rejecting that idea (racking my brain to think or a reason why)...
I have found 28 SP's that insert into this table, and I'm real afraid that
in our years of code some people have written dynamic crap to do likewise.
I then have to follow this to about 15+ other tables in our system.
> You could make the orderid in Last_OrderID an identity column and let it
> create the rows. You will need another column to insert (use NULLbit) If
> you use @.@.Scope_Identity you don't need the lock.
Queston I have is when will that brainfart lock be released if no commit
tran is in the SP? At the end of the SP? If so that is what I need to
STOP. I am getting killed in an invoicing run that does similar locking,
but that SP is huge.
What I want to do is convert over to identity, but I have to walk softly,
and look for a real big stick
. I am going to deal with one primay keythat is used in the invoicing run above. It's got a small impact for users
who could be affected.
> The additional storage space is minimal. You could even delete that table
> every night if that is an issue (note: Do not use Truncate. It resets the
> identity whereas delete does not).
> Your DDL would look like:
> Drop Table Last_orderid
> Go
> Create Table Last_orderid
> orderid int identity (XXX, 1),
> NULLbit bit
> Go
> --Where XXX is the next orderid at the time this script is run
>
> Your query would look like:
> Declare @.newOrderID int
> Insert into Last_orderid (NULLbit) Select NULL
> Set @.newOrderID = @.@.Scope_Identity
> --Update Order Table
>
> "__Stephen" <srussell@.transactiongraphics.com> wrote in message
> news:ulVZ7%23K4FHA.1184@.TK2MSFTNGP12.phx.gbl...
>
|||Put it in a transaction to assure correct behavior, it won't save any
time, though.
J.
On Thu, 3 Nov 2005 13:49:47 -0600, "__Stephen"
<srussell@.transactiongraphics.com> wrote:
>I inherited a hell hole of a system.
>This is how a key is generated in my current system:
>--GET A NEW ORDERID
>SET @.OrderId= (SELECT MAX(Orderid) + 1 AS LastID FROM LAST_ORDERID with
>(TABLOCKX))
>--UPDATE LAST ORDERID TABLE
>UPDATE LAST_ORDERID SET OrderID = @.OrderID
>SET @.ErrCount = @.ErrCount + @.@.Error
>--END UPDATE LAST_ORDERID
>
>Last_orderid has one column / one row, and is pretty useless IMO.
>Past the idea of creating an identity column on Orderid in Orders
would>it be good practice to put this in a begin transaction, commit transaction
>to reduce the lock time?
>TIA
>
>
>
>
>
|||"jxstern" <jxstern@.nowhere.xyz> wrote in message
news:n52lm19pmhronpc0iks5vr5pe17l8ar1h6@.4ax.com...
> Put it in a transaction to assure correct behavior, it won't save any
> time, though.
I only gave 1% of the SP for show. In all actuality an insert into my
Orders table follows this:
Lock NextKey#Table and return it's current value +1
Update NextKey#Table
Pull secondary business data for use later.
Insert into Orders Table using NextKey# from above.
Insert into OtherBizTable with NextKey and that other BizData
Insert into OrderDetails
Check ErrorStatus
if so Roll back and send email to people who care
otherwise commit
Now lock will disengage? < I think that I have locked ALL tables in use
through this SP because of this opening line>
SET @.OrderId= (SELECT MAX(Orderid) + 1 AS LastID FROM LAST_ORDERID with
(TABLOCKX))
So if I commit that transaction at the top, I won't lock all the way
through?
TIA
__Stephen
|||Are you asking if you should separately commit the couple of lines at
the top of the SP, instead of putting the whole thing in a
transaction?
You are aware that an SP does not automatically comprise a
transaction, you have to explicitly ask for it, so maybe there is no
transaction at all in your current code?
J.
On Fri, 4 Nov 2005 08:04:31 -0600, "__Stephen"
<srussell@.transactiongraphics.com> wrote:
>"jxstern" <jxstern@.nowhere.xyz> wrote in message
>news:n52lm19pmhronpc0iks5vr5pe17l8ar1h6@.4ax.com.. .
>I only gave 1% of the SP for show. In all actuality an insert into my
>Orders table follows this:
>Lock NextKey#Table and return it's current value +1
>Update NextKey#Table
>Pull secondary business data for use later.
>Insert into Orders Table using NextKey# from above.
>Insert into OtherBizTable with NextKey and that other BizData
>Insert into OrderDetails
>Check ErrorStatus
>if so Roll back and send email to people who care
>otherwise commit
>Now lock will disengage? < I think that I have locked ALL tables in use
>through this SP because of this opening line>
>SET @.OrderId= (SELECT MAX(Orderid) + 1 AS LastID FROM LAST_ORDERID with
>(TABLOCKX))
>So if I commit that transaction at the top, I won't lock all the way
>through?
>TIA
>__Stephen
>
>
Excessive locking
I inherited a hell hole of a system.
This is how a key is generated in my current system:
--GET A NEW ORDERID
SET @.OrderId= (SELECT MAX(Orderid) + 1 AS LastID FROM LAST_ORDERID with
(TABLOCKX))
--UPDATE LAST ORDERID TABLE
UPDATE LAST_ORDERID SET OrderID = @.OrderID
SET @.ErrCount = @.ErrCount + @.@.Error
--END UPDATE LAST_ORDERID
Last_orderid has one column / one row, and is pretty useless IMO.
Past the idea of creating an identity column on Orderid in Orders :) would
it be good practice to put this in a begin transaction, commit transaction
to reduce the lock time?
TIALooks like your identity in the Orders table is what's needed, but rejecting
that idea (racking my brain to think or a reason why)...
You could make the orderid in Last_OrderID an identity column and let it
create the rows. You will need another column to insert (use NULLbit) If
you use @.@.Scope_Identity you don't need the lock.
The additional storage space is minimal. You could even delete that table
every night if that is an issue (note: Do not use Truncate. It resets the
identity whereas delete does not).
Your DDL would look like:
Drop Table Last_orderid
Go
Create Table Last_orderid
orderid int identity (XXX, 1),
NULLbit bit
Go
--Where XXX is the next orderid at the time this script is run
Your query would look like:
Declare @.newOrderID int
Insert into Last_orderid (NULLbit) Select NULL
Set @.newOrderID = @.@.Scope_Identity
--Update Order Table
"__Stephen" <srussell@.transactiongraphics.com> wrote in message
news:ulVZ7%23K4FHA.1184@.TK2MSFTNGP12.phx.gbl...
>I inherited a hell hole of a system.
> This is how a key is generated in my current system:
> --GET A NEW ORDERID
> SET @.OrderId= (SELECT MAX(Orderid) + 1 AS LastID FROM LAST_ORDERID with
> (TABLOCKX))
> --UPDATE LAST ORDERID TABLE
> UPDATE LAST_ORDERID SET OrderID = @.OrderID
> SET @.ErrCount = @.ErrCount + @.@.Error
> --END UPDATE LAST_ORDERID
>
> Last_orderid has one column / one row, and is pretty useless IMO.
> Past the idea of creating an identity column on Orderid in Orders :) would
> it be good practice to put this in a begin transaction, commit transaction
> to reduce the lock time?
> TIA
>
>
>
>
>|||Thanks Joe!
"Joe" <joe@.aol.com> wrote in message
news:u0Lx4fL4FHA.3444@.tk2msftngp13.phx.gbl...
> Looks like your identity in the Orders table is what's needed, but
> rejecting that idea (racking my brain to think or a reason why)...
I have found 28 SP's that insert into this table, and I'm real afraid that
in our years of code some people have written dynamic crap to do likewise.
I then have to follow this to about 15+ other tables in our system.
> You could make the orderid in Last_OrderID an identity column and let it
> create the rows. You will need another column to insert (use NULLbit) If
> you use @.@.Scope_Identity you don't need the lock.
Queston I have is when will that brainfart lock be released if no commit
tran is in the SP? At the end of the SP? If so that is what I need to
STOP. I am getting killed in an invoicing run that does similar locking,
but that SP is huge.
What I want to do is convert over to identity, but I have to walk softly,
and look for a real big stick:). I am going to deal with one primay key
that is used in the invoicing run above. It's got a small impact for users
who could be affected.
> The additional storage space is minimal. You could even delete that table
> every night if that is an issue (note: Do not use Truncate. It resets the
> identity whereas delete does not).
> Your DDL would look like:
> Drop Table Last_orderid
> Go
> Create Table Last_orderid
> orderid int identity (XXX, 1),
> NULLbit bit
> Go
> --Where XXX is the next orderid at the time this script is run
>
> Your query would look like:
> Declare @.newOrderID int
> Insert into Last_orderid (NULLbit) Select NULL
> Set @.newOrderID = @.@.Scope_Identity
> --Update Order Table
>
> "__Stephen" <srussell@.transactiongraphics.com> wrote in message
> news:ulVZ7%23K4FHA.1184@.TK2MSFTNGP12.phx.gbl...
>>I inherited a hell hole of a system.
>> This is how a key is generated in my current system:
>> --GET A NEW ORDERID
>> SET @.OrderId= (SELECT MAX(Orderid) + 1 AS LastID FROM LAST_ORDERID with
>> (TABLOCKX))
>> --UPDATE LAST ORDERID TABLE
>> UPDATE LAST_ORDERID SET OrderID = @.OrderID
>> SET @.ErrCount = @.ErrCount + @.@.Error
>> --END UPDATE LAST_ORDERID
>>
>> Last_orderid has one column / one row, and is pretty useless IMO.
>> Past the idea of creating an identity column on Orderid in Orders :)
>> would it be good practice to put this in a begin transaction, commit
>> transaction to reduce the lock time?
>> TIA
>>
>>
>>
>>
>>
>|||Put it in a transaction to assure correct behavior, it won't save any
time, though.
J.
On Thu, 3 Nov 2005 13:49:47 -0600, "__Stephen"
<srussell@.transactiongraphics.com> wrote:
>I inherited a hell hole of a system.
>This is how a key is generated in my current system:
>--GET A NEW ORDERID
>SET @.OrderId= (SELECT MAX(Orderid) + 1 AS LastID FROM LAST_ORDERID with
>(TABLOCKX))
>--UPDATE LAST ORDERID TABLE
>UPDATE LAST_ORDERID SET OrderID = @.OrderID
>SET @.ErrCount = @.ErrCount + @.@.Error
>--END UPDATE LAST_ORDERID
>
>Last_orderid has one column / one row, and is pretty useless IMO.
>Past the idea of creating an identity column on Orderid in Orders :) would
>it be good practice to put this in a begin transaction, commit transaction
>to reduce the lock time?
>TIA
>
>
>
>
>|||"jxstern" <jxstern@.nowhere.xyz> wrote in message
news:n52lm19pmhronpc0iks5vr5pe17l8ar1h6@.4ax.com...
> Put it in a transaction to assure correct behavior, it won't save any
> time, though.
I only gave 1% of the SP for show. In all actuality an insert into my
Orders table follows this:
Lock NextKey#Table and return it's current value +1
Update NextKey#Table
Pull secondary business data for use later.
Insert into Orders Table using NextKey# from above.
Insert into OtherBizTable with NextKey and that other BizData
Insert into OrderDetails
Check ErrorStatus
if so Roll back and send email to people who care
otherwise commit
Now lock will disengage? < I think that I have locked ALL tables in use
through this SP because of this opening line>
SET @.OrderId= (SELECT MAX(Orderid) + 1 AS LastID FROM LAST_ORDERID with
(TABLOCKX))
So if I commit that transaction at the top, I won't lock all the way
through?
TIA
__Stephen|||Are you asking if you should separately commit the couple of lines at
the top of the SP, instead of putting the whole thing in a
transaction?
You are aware that an SP does not automatically comprise a
transaction, you have to explicitly ask for it, so maybe there is no
transaction at all in your current code?
J.
On Fri, 4 Nov 2005 08:04:31 -0600, "__Stephen"
<srussell@.transactiongraphics.com> wrote:
>"jxstern" <jxstern@.nowhere.xyz> wrote in message
>news:n52lm19pmhronpc0iks5vr5pe17l8ar1h6@.4ax.com...
>> Put it in a transaction to assure correct behavior, it won't save any
>> time, though.
>I only gave 1% of the SP for show. In all actuality an insert into my
>Orders table follows this:
>Lock NextKey#Table and return it's current value +1
>Update NextKey#Table
>Pull secondary business data for use later.
>Insert into Orders Table using NextKey# from above.
>Insert into OtherBizTable with NextKey and that other BizData
>Insert into OrderDetails
>Check ErrorStatus
>if so Roll back and send email to people who care
>otherwise commit
>Now lock will disengage? < I think that I have locked ALL tables in use
>through this SP because of this opening line>
>SET @.OrderId= (SELECT MAX(Orderid) + 1 AS LastID FROM LAST_ORDERID with
>(TABLOCKX))
>So if I commit that transaction at the top, I won't lock all the way
>through?
>TIA
>__Stephen
>
>
This is how a key is generated in my current system:
--GET A NEW ORDERID
SET @.OrderId= (SELECT MAX(Orderid) + 1 AS LastID FROM LAST_ORDERID with
(TABLOCKX))
--UPDATE LAST ORDERID TABLE
UPDATE LAST_ORDERID SET OrderID = @.OrderID
SET @.ErrCount = @.ErrCount + @.@.Error
--END UPDATE LAST_ORDERID
Last_orderid has one column / one row, and is pretty useless IMO.
Past the idea of creating an identity column on Orderid in Orders :) would
it be good practice to put this in a begin transaction, commit transaction
to reduce the lock time?
TIALooks like your identity in the Orders table is what's needed, but rejecting
that idea (racking my brain to think or a reason why)...
You could make the orderid in Last_OrderID an identity column and let it
create the rows. You will need another column to insert (use NULLbit) If
you use @.@.Scope_Identity you don't need the lock.
The additional storage space is minimal. You could even delete that table
every night if that is an issue (note: Do not use Truncate. It resets the
identity whereas delete does not).
Your DDL would look like:
Drop Table Last_orderid
Go
Create Table Last_orderid
orderid int identity (XXX, 1),
NULLbit bit
Go
--Where XXX is the next orderid at the time this script is run
Your query would look like:
Declare @.newOrderID int
Insert into Last_orderid (NULLbit) Select NULL
Set @.newOrderID = @.@.Scope_Identity
--Update Order Table
"__Stephen" <srussell@.transactiongraphics.com> wrote in message
news:ulVZ7%23K4FHA.1184@.TK2MSFTNGP12.phx.gbl...
>I inherited a hell hole of a system.
> This is how a key is generated in my current system:
> --GET A NEW ORDERID
> SET @.OrderId= (SELECT MAX(Orderid) + 1 AS LastID FROM LAST_ORDERID with
> (TABLOCKX))
> --UPDATE LAST ORDERID TABLE
> UPDATE LAST_ORDERID SET OrderID = @.OrderID
> SET @.ErrCount = @.ErrCount + @.@.Error
> --END UPDATE LAST_ORDERID
>
> Last_orderid has one column / one row, and is pretty useless IMO.
> Past the idea of creating an identity column on Orderid in Orders :) would
> it be good practice to put this in a begin transaction, commit transaction
> to reduce the lock time?
> TIA
>
>
>
>
>|||Thanks Joe!
"Joe" <joe@.aol.com> wrote in message
news:u0Lx4fL4FHA.3444@.tk2msftngp13.phx.gbl...
> Looks like your identity in the Orders table is what's needed, but
> rejecting that idea (racking my brain to think or a reason why)...
I have found 28 SP's that insert into this table, and I'm real afraid that
in our years of code some people have written dynamic crap to do likewise.
I then have to follow this to about 15+ other tables in our system.
> You could make the orderid in Last_OrderID an identity column and let it
> create the rows. You will need another column to insert (use NULLbit) If
> you use @.@.Scope_Identity you don't need the lock.
Queston I have is when will that brainfart lock be released if no commit
tran is in the SP? At the end of the SP? If so that is what I need to
STOP. I am getting killed in an invoicing run that does similar locking,
but that SP is huge.
What I want to do is convert over to identity, but I have to walk softly,
and look for a real big stick:). I am going to deal with one primay key
that is used in the invoicing run above. It's got a small impact for users
who could be affected.
> The additional storage space is minimal. You could even delete that table
> every night if that is an issue (note: Do not use Truncate. It resets the
> identity whereas delete does not).
> Your DDL would look like:
> Drop Table Last_orderid
> Go
> Create Table Last_orderid
> orderid int identity (XXX, 1),
> NULLbit bit
> Go
> --Where XXX is the next orderid at the time this script is run
>
> Your query would look like:
> Declare @.newOrderID int
> Insert into Last_orderid (NULLbit) Select NULL
> Set @.newOrderID = @.@.Scope_Identity
> --Update Order Table
>
> "__Stephen" <srussell@.transactiongraphics.com> wrote in message
> news:ulVZ7%23K4FHA.1184@.TK2MSFTNGP12.phx.gbl...
>>I inherited a hell hole of a system.
>> This is how a key is generated in my current system:
>> --GET A NEW ORDERID
>> SET @.OrderId= (SELECT MAX(Orderid) + 1 AS LastID FROM LAST_ORDERID with
>> (TABLOCKX))
>> --UPDATE LAST ORDERID TABLE
>> UPDATE LAST_ORDERID SET OrderID = @.OrderID
>> SET @.ErrCount = @.ErrCount + @.@.Error
>> --END UPDATE LAST_ORDERID
>>
>> Last_orderid has one column / one row, and is pretty useless IMO.
>> Past the idea of creating an identity column on Orderid in Orders :)
>> would it be good practice to put this in a begin transaction, commit
>> transaction to reduce the lock time?
>> TIA
>>
>>
>>
>>
>>
>|||Put it in a transaction to assure correct behavior, it won't save any
time, though.
J.
On Thu, 3 Nov 2005 13:49:47 -0600, "__Stephen"
<srussell@.transactiongraphics.com> wrote:
>I inherited a hell hole of a system.
>This is how a key is generated in my current system:
>--GET A NEW ORDERID
>SET @.OrderId= (SELECT MAX(Orderid) + 1 AS LastID FROM LAST_ORDERID with
>(TABLOCKX))
>--UPDATE LAST ORDERID TABLE
>UPDATE LAST_ORDERID SET OrderID = @.OrderID
>SET @.ErrCount = @.ErrCount + @.@.Error
>--END UPDATE LAST_ORDERID
>
>Last_orderid has one column / one row, and is pretty useless IMO.
>Past the idea of creating an identity column on Orderid in Orders :) would
>it be good practice to put this in a begin transaction, commit transaction
>to reduce the lock time?
>TIA
>
>
>
>
>|||"jxstern" <jxstern@.nowhere.xyz> wrote in message
news:n52lm19pmhronpc0iks5vr5pe17l8ar1h6@.4ax.com...
> Put it in a transaction to assure correct behavior, it won't save any
> time, though.
I only gave 1% of the SP for show. In all actuality an insert into my
Orders table follows this:
Lock NextKey#Table and return it's current value +1
Update NextKey#Table
Pull secondary business data for use later.
Insert into Orders Table using NextKey# from above.
Insert into OtherBizTable with NextKey and that other BizData
Insert into OrderDetails
Check ErrorStatus
if so Roll back and send email to people who care
otherwise commit
Now lock will disengage? < I think that I have locked ALL tables in use
through this SP because of this opening line>
SET @.OrderId= (SELECT MAX(Orderid) + 1 AS LastID FROM LAST_ORDERID with
(TABLOCKX))
So if I commit that transaction at the top, I won't lock all the way
through?
TIA
__Stephen|||Are you asking if you should separately commit the couple of lines at
the top of the SP, instead of putting the whole thing in a
transaction?
You are aware that an SP does not automatically comprise a
transaction, you have to explicitly ask for it, so maybe there is no
transaction at all in your current code?
J.
On Fri, 4 Nov 2005 08:04:31 -0600, "__Stephen"
<srussell@.transactiongraphics.com> wrote:
>"jxstern" <jxstern@.nowhere.xyz> wrote in message
>news:n52lm19pmhronpc0iks5vr5pe17l8ar1h6@.4ax.com...
>> Put it in a transaction to assure correct behavior, it won't save any
>> time, though.
>I only gave 1% of the SP for show. In all actuality an insert into my
>Orders table follows this:
>Lock NextKey#Table and return it's current value +1
>Update NextKey#Table
>Pull secondary business data for use later.
>Insert into Orders Table using NextKey# from above.
>Insert into OtherBizTable with NextKey and that other BizData
>Insert into OrderDetails
>Check ErrorStatus
>if so Roll back and send email to people who care
>otherwise commit
>Now lock will disengage? < I think that I have locked ALL tables in use
>through this SP because of this opening line>
>SET @.OrderId= (SELECT MAX(Orderid) + 1 AS LastID FROM LAST_ORDERID with
>(TABLOCKX))
>So if I commit that transaction at the top, I won't lock all the way
>through?
>TIA
>__Stephen
>
>
Excessive locking
I inherited a hell hole of a system.
This is how a key is generated in my current system:
--GET A NEW ORDERID
SET @.OrderId= (SELECT MAX(Orderid) + 1 AS LastID FROM LAST_ORDERID with
(TABLOCKX))
--UPDATE LAST ORDERID TABLE
UPDATE LAST_ORDERID SET OrderID = @.OrderID
SET @.ErrCount = @.ErrCount + @.@.Error
--END UPDATE LAST_ORDERID
Last_orderid has one column / one row, and is pretty useless IMO.
Past the idea of creating an identity column on Orderid in Orders would
it be good practice to put this in a begin transaction, commit transaction
to reduce the lock time?
TIALooks like your identity in the Orders table is what's needed, but rejecting
that idea (racking my brain to think or a reason why)...
You could make the orderid in Last_OrderID an identity column and let it
create the rows. You will need another column to insert (use NULLbit) If
you use @.@.Scope_Identity you don't need the lock.
The additional storage space is minimal. You could even delete that table
every night if that is an issue (note: Do not use Truncate. It resets the
identity whereas delete does not).
Your DDL would look like:
Drop Table Last_orderid
Go
Create Table Last_orderid
orderid int identity (XXX, 1),
NULLbit bit
Go
--Where XXX is the next orderid at the time this script is run
Your query would look like:
Declare @.newOrderID int
Insert into Last_orderid (NULLbit) Select NULL
Set @.newOrderID = @.@.Scope_Identity
--Update Order Table
"__Stephen" <srussell@.transactiongraphics.com> wrote in message
news:ulVZ7%23K4FHA.1184@.TK2MSFTNGP12.phx.gbl...
>I inherited a hell hole of a system.
> This is how a key is generated in my current system:
> --GET A NEW ORDERID
> SET @.OrderId= (SELECT MAX(Orderid) + 1 AS LastID FROM LAST_ORDERID with
> (TABLOCKX))
> --UPDATE LAST ORDERID TABLE
> UPDATE LAST_ORDERID SET OrderID = @.OrderID
> SET @.ErrCount = @.ErrCount + @.@.Error
> --END UPDATE LAST_ORDERID
>
> Last_orderid has one column / one row, and is pretty useless IMO.
> Past the idea of creating an identity column on Orderid in Orders would
> it be good practice to put this in a begin transaction, commit transaction
> to reduce the lock time?
> TIA
>
>
>
>
>|||Thanks Joe!
"Joe" <joe@.aol.com> wrote in message
news:u0Lx4fL4FHA.3444@.tk2msftngp13.phx.gbl...
> Looks like your identity in the Orders table is what's needed, but
> rejecting that idea (racking my brain to think or a reason why)...
I have found 28 SP's that insert into this table, and I'm real afraid that
in our years of code some people have written dynamic crap to do likewise.
I then have to follow this to about 15+ other tables in our system.
> You could make the orderid in Last_OrderID an identity column and let it
> create the rows. You will need another column to insert (use NULLbit) If
> you use @.@.Scope_Identity you don't need the lock.
Queston I have is when will that brainfart lock be released if no commit
tran is in the SP? At the end of the SP? If so that is what I need to
STOP. I am getting killed in an invoicing run that does similar locking,
but that SP is huge.
What I want to do is convert over to identity, but I have to walk softly,
and look for a real big stick. I am going to deal with one primay key
that is used in the invoicing run above. It's got a small impact for users
who could be affected.
> The additional storage space is minimal. You could even delete that table
> every night if that is an issue (note: Do not use Truncate. It resets the
> identity whereas delete does not).
> Your DDL would look like:
> Drop Table Last_orderid
> Go
> Create Table Last_orderid
> orderid int identity (XXX, 1),
> NULLbit bit
> Go
> --Where XXX is the next orderid at the time this script is run
>
> Your query would look like:
> Declare @.newOrderID int
> Insert into Last_orderid (NULLbit) Select NULL
> Set @.newOrderID = @.@.Scope_Identity
> --Update Order Table
>
> "__Stephen" <srussell@.transactiongraphics.com> wrote in message
> news:ulVZ7%23K4FHA.1184@.TK2MSFTNGP12.phx.gbl...
>|||Put it in a transaction to assure correct behavior, it won't save any
time, though.
J.
On Thu, 3 Nov 2005 13:49:47 -0600, "__Stephen"
<srussell@.transactiongraphics.com> wrote:
>I inherited a hell hole of a system.
>This is how a key is generated in my current system:
>--GET A NEW ORDERID
>SET @.OrderId= (SELECT MAX(Orderid) + 1 AS LastID FROM LAST_ORDERID with
>(TABLOCKX))
>--UPDATE LAST ORDERID TABLE
>UPDATE LAST_ORDERID SET OrderID = @.OrderID
>SET @.ErrCount = @.ErrCount + @.@.Error
>--END UPDATE LAST_ORDERID
>
>Last_orderid has one column / one row, and is pretty useless IMO.
>Past the idea of creating an identity column on Orderid in Orders would
>it be good practice to put this in a begin transaction, commit transaction
>to reduce the lock time?
>TIA
>
>
>
>
>|||"jxstern" <jxstern@.nowhere.xyz> wrote in message
news:n52lm19pmhronpc0iks5vr5pe17l8ar1h6@.
4ax.com...
> Put it in a transaction to assure correct behavior, it won't save any
> time, though.
I only gave 1% of the SP for show. In all actuality an insert into my
Orders table follows this:
Lock NextKey#Table and return it's current value +1
Update NextKey#Table
Pull secondary business data for use later.
Insert into Orders Table using NextKey# from above.
Insert into OtherBizTable with NextKey and that other BizData
Insert into OrderDetails
Check ErrorStatus
if so Roll back and send email to people who care
otherwise commit
Now lock will disengage? < I think that I have locked ALL tables in use
through this SP because of this opening line>
SET @.OrderId= (SELECT MAX(Orderid) + 1 AS LastID FROM LAST_ORDERID with
(TABLOCKX))
So if I commit that transaction at the top, I won't lock all the way
through?
TIA
__Stephen|||Are you asking if you should separately commit the couple of lines at
the top of the SP, instead of putting the whole thing in a
transaction?
You are aware that an SP does not automatically comprise a
transaction, you have to explicitly ask for it, so maybe there is no
transaction at all in your current code?
J.
On Fri, 4 Nov 2005 08:04:31 -0600, "__Stephen"
<srussell@.transactiongraphics.com> wrote:
>"jxstern" <jxstern@.nowhere.xyz> wrote in message
> news:n52lm19pmhronpc0iks5vr5pe17l8ar1h6@.
4ax.com...
>I only gave 1% of the SP for show. In all actuality an insert into my
>Orders table follows this:
>Lock NextKey#Table and return it's current value +1
>Update NextKey#Table
>Pull secondary business data for use later.
>Insert into Orders Table using NextKey# from above.
>Insert into OtherBizTable with NextKey and that other BizData
>Insert into OrderDetails
>Check ErrorStatus
>if so Roll back and send email to people who care
>otherwise commit
>Now lock will disengage? < I think that I have locked ALL tables in use
>through this SP because of this opening line>
>SET @.OrderId= (SELECT MAX(Orderid) + 1 AS LastID FROM LAST_ORDERID with
>(TABLOCKX))
>So if I commit that transaction at the top, I won't lock all the way
>through?
>TIA
>__Stephen
>
>
This is how a key is generated in my current system:
--GET A NEW ORDERID
SET @.OrderId= (SELECT MAX(Orderid) + 1 AS LastID FROM LAST_ORDERID with
(TABLOCKX))
--UPDATE LAST ORDERID TABLE
UPDATE LAST_ORDERID SET OrderID = @.OrderID
SET @.ErrCount = @.ErrCount + @.@.Error
--END UPDATE LAST_ORDERID
Last_orderid has one column / one row, and is pretty useless IMO.
Past the idea of creating an identity column on Orderid in Orders
wouldit be good practice to put this in a begin transaction, commit transaction
to reduce the lock time?
TIALooks like your identity in the Orders table is what's needed, but rejecting
that idea (racking my brain to think or a reason why)...
You could make the orderid in Last_OrderID an identity column and let it
create the rows. You will need another column to insert (use NULLbit) If
you use @.@.Scope_Identity you don't need the lock.
The additional storage space is minimal. You could even delete that table
every night if that is an issue (note: Do not use Truncate. It resets the
identity whereas delete does not).
Your DDL would look like:
Drop Table Last_orderid
Go
Create Table Last_orderid
orderid int identity (XXX, 1),
NULLbit bit
Go
--Where XXX is the next orderid at the time this script is run
Your query would look like:
Declare @.newOrderID int
Insert into Last_orderid (NULLbit) Select NULL
Set @.newOrderID = @.@.Scope_Identity
--Update Order Table
"__Stephen" <srussell@.transactiongraphics.com> wrote in message
news:ulVZ7%23K4FHA.1184@.TK2MSFTNGP12.phx.gbl...
>I inherited a hell hole of a system.
> This is how a key is generated in my current system:
> --GET A NEW ORDERID
> SET @.OrderId= (SELECT MAX(Orderid) + 1 AS LastID FROM LAST_ORDERID with
> (TABLOCKX))
> --UPDATE LAST ORDERID TABLE
> UPDATE LAST_ORDERID SET OrderID = @.OrderID
> SET @.ErrCount = @.ErrCount + @.@.Error
> --END UPDATE LAST_ORDERID
>
> Last_orderid has one column / one row, and is pretty useless IMO.
> Past the idea of creating an identity column on Orderid in Orders
would> it be good practice to put this in a begin transaction, commit transaction
> to reduce the lock time?
> TIA
>
>
>
>
>|||Thanks Joe!
"Joe" <joe@.aol.com> wrote in message
news:u0Lx4fL4FHA.3444@.tk2msftngp13.phx.gbl...
> Looks like your identity in the Orders table is what's needed, but
> rejecting that idea (racking my brain to think or a reason why)...
I have found 28 SP's that insert into this table, and I'm real afraid that
in our years of code some people have written dynamic crap to do likewise.
I then have to follow this to about 15+ other tables in our system.
> You could make the orderid in Last_OrderID an identity column and let it
> create the rows. You will need another column to insert (use NULLbit) If
> you use @.@.Scope_Identity you don't need the lock.
Queston I have is when will that brainfart lock be released if no commit
tran is in the SP? At the end of the SP? If so that is what I need to
STOP. I am getting killed in an invoicing run that does similar locking,
but that SP is huge.
What I want to do is convert over to identity, but I have to walk softly,
and look for a real big stick
. I am going to deal with one primay keythat is used in the invoicing run above. It's got a small impact for users
who could be affected.
> The additional storage space is minimal. You could even delete that table
> every night if that is an issue (note: Do not use Truncate. It resets the
> identity whereas delete does not).
> Your DDL would look like:
> Drop Table Last_orderid
> Go
> Create Table Last_orderid
> orderid int identity (XXX, 1),
> NULLbit bit
> Go
> --Where XXX is the next orderid at the time this script is run
>
> Your query would look like:
> Declare @.newOrderID int
> Insert into Last_orderid (NULLbit) Select NULL
> Set @.newOrderID = @.@.Scope_Identity
> --Update Order Table
>
> "__Stephen" <srussell@.transactiongraphics.com> wrote in message
> news:ulVZ7%23K4FHA.1184@.TK2MSFTNGP12.phx.gbl...
>|||Put it in a transaction to assure correct behavior, it won't save any
time, though.
J.
On Thu, 3 Nov 2005 13:49:47 -0600, "__Stephen"
<srussell@.transactiongraphics.com> wrote:
>I inherited a hell hole of a system.
>This is how a key is generated in my current system:
>--GET A NEW ORDERID
>SET @.OrderId= (SELECT MAX(Orderid) + 1 AS LastID FROM LAST_ORDERID with
>(TABLOCKX))
>--UPDATE LAST ORDERID TABLE
>UPDATE LAST_ORDERID SET OrderID = @.OrderID
>SET @.ErrCount = @.ErrCount + @.@.Error
>--END UPDATE LAST_ORDERID
>
>Last_orderid has one column / one row, and is pretty useless IMO.
>Past the idea of creating an identity column on Orderid in Orders
would>it be good practice to put this in a begin transaction, commit transaction
>to reduce the lock time?
>TIA
>
>
>
>
>|||"jxstern" <jxstern@.nowhere.xyz> wrote in message
news:n52lm19pmhronpc0iks5vr5pe17l8ar1h6@.
4ax.com...
> Put it in a transaction to assure correct behavior, it won't save any
> time, though.
I only gave 1% of the SP for show. In all actuality an insert into my
Orders table follows this:
Lock NextKey#Table and return it's current value +1
Update NextKey#Table
Pull secondary business data for use later.
Insert into Orders Table using NextKey# from above.
Insert into OtherBizTable with NextKey and that other BizData
Insert into OrderDetails
Check ErrorStatus
if so Roll back and send email to people who care
otherwise commit
Now lock will disengage? < I think that I have locked ALL tables in use
through this SP because of this opening line>
SET @.OrderId= (SELECT MAX(Orderid) + 1 AS LastID FROM LAST_ORDERID with
(TABLOCKX))
So if I commit that transaction at the top, I won't lock all the way
through?
TIA
__Stephen|||Are you asking if you should separately commit the couple of lines at
the top of the SP, instead of putting the whole thing in a
transaction?
You are aware that an SP does not automatically comprise a
transaction, you have to explicitly ask for it, so maybe there is no
transaction at all in your current code?
J.
On Fri, 4 Nov 2005 08:04:31 -0600, "__Stephen"
<srussell@.transactiongraphics.com> wrote:
>"jxstern" <jxstern@.nowhere.xyz> wrote in message
> news:n52lm19pmhronpc0iks5vr5pe17l8ar1h6@.
4ax.com...
>I only gave 1% of the SP for show. In all actuality an insert into my
>Orders table follows this:
>Lock NextKey#Table and return it's current value +1
>Update NextKey#Table
>Pull secondary business data for use later.
>Insert into Orders Table using NextKey# from above.
>Insert into OtherBizTable with NextKey and that other BizData
>Insert into OrderDetails
>Check ErrorStatus
>if so Roll back and send email to people who care
>otherwise commit
>Now lock will disengage? < I think that I have locked ALL tables in use
>through this SP because of this opening line>
>SET @.OrderId= (SELECT MAX(Orderid) + 1 AS LastID FROM LAST_ORDERID with
>(TABLOCKX))
>So if I commit that transaction at the top, I won't lock all the way
>through?
>TIA
>__Stephen
>
>
Wednesday, March 7, 2012
exception that does nothing?
Hi,
I want to have an exception do nothing. or rather, I just want my trigger to ignore this problem, terminate the current block, and go on to the next one.
here is my code:
EXCEPTION
WHEN NO_DATA_FOUND THEN
DBMS_OUTPUT.PUT_LINE (''); -- do nothing.
currently, im getting the error below. I think it has to do with the DBMS overflowing
ORA-20000: ORU-10027: buffer overflow, limit of 20000 bytes
ORA-06512: at "SYS.DBMS_OUTPUT", line 35
ORA-06512: at "SYS.DBMS_OUTPUT", line 198
ORA-06512: at "SYS.DBMS_OUTPUT", line 139
thanks.never mind, i believe i found out that you could just put 'null' instead of having dbms output, and the block terminates succesfully, without doing anything.
I want to have an exception do nothing. or rather, I just want my trigger to ignore this problem, terminate the current block, and go on to the next one.
here is my code:
EXCEPTION
WHEN NO_DATA_FOUND THEN
DBMS_OUTPUT.PUT_LINE (''); -- do nothing.
currently, im getting the error below. I think it has to do with the DBMS overflowing
ORA-20000: ORU-10027: buffer overflow, limit of 20000 bytes
ORA-06512: at "SYS.DBMS_OUTPUT", line 35
ORA-06512: at "SYS.DBMS_OUTPUT", line 198
ORA-06512: at "SYS.DBMS_OUTPUT", line 139
thanks.never mind, i believe i found out that you could just put 'null' instead of having dbms output, and the block terminates succesfully, without doing anything.
Subscribe to:
Posts (Atom)