Avoid update without where clause

Hi every one,
Using SQL 7.0,
Without using transaction, is there a way that SQL void
(refuse) any update or delete if there is no where
clause ?
In order to avoid devastating lapse of memory :o\
Thanks !
DonaldNo, this is a case where your developers must use common sense, and look
over their scripts before executing them.
If it's any consolation, SQL Server also won't prevent you from tripping
over the power cord or using a sledgehammer against the CPU. ;-)
--
Aaron Bertrand
SQL Server MVP
http://www.aspfaq.com/
"Donald" <anonymous@.discussions.microsoft.com> wrote in message
news:1383601c443ff$12727930$a001280a@.phx.gbl...
> Hi every one,
> Using SQL 7.0,
> Without using transaction, is there a way that SQL void
> (refuse) any update or delete if there is no where
> clause ?
> In order to avoid devastating lapse of memory :o\
> Thanks !
> Donald|||Pretty much your only option is SET IMPLICIT_TRANSACTIONS. This is set =at the connection level
A snip from Books Online (within the SQL Server program group):
Transact-SQL Reference
SET IMPLICIT_TRANSACTIONS
Sets implicit transaction mode for the connection.
Syntax
SET IMPLICIT_TRANSACTIONS { ON | OFF }
Remarks
When ON, SET IMPLICIT_TRANSACTIONS sets the connection into implicit =transaction mode. When OFF, it returns the connection to autocommit =transaction mode.
When a connection is in implicit transaction mode and the connection is =not currently in a transaction, executing any of the following =statements starts a transaction:
-- Keith
"Donald" <anonymous@.discussions.microsoft.com> wrote in message =news:1383601c443ff$12727930$a001280a@.phx.gbl...
> Hi every one,
> > Using SQL 7.0,
> > Without using transaction, is there a way that SQL void
> (refuse) any update or delete if there is no where > clause ? > > In order to avoid devastating lapse of memory :o\
> > Thanks !
> > Donald|||Actually, I guess you could enforce this by preventing direct access to the
table and forcing access via stored procedures. Depending on how flexible
the where clause can be, you may need to read these articles;
http://www.sommarskog.se/dyn-search.html
http://www.sommarskog.se/dynamic_sql.html
--
Aaron Bertrand
SQL Server MVP
http://www.aspfaq.com/
"Donald" <anonymous@.discussions.microsoft.com> wrote in message
news:1383601c443ff$12727930$a001280a@.phx.gbl...
> Hi every one,
> Using SQL 7.0,
> Without using transaction, is there a way that SQL void
> (refuse) any update or delete if there is no where
> clause ?
> In order to avoid devastating lapse of memory :o\
> Thanks !
> Donald|||Would make a handy feature, but there's isn't anything like that build-in at
the moment.
You could achive this by using triggers, for example:
http://vyaskn.tripod.com/tracking_sql_statements_by_triggers.htm
but may not be completely safe.
--
HTH,
Vyas, MVP (SQL Server)
http://vyaskn.tripod.com/
Is .NET important for a database professional?
http://vyaskn.tripod.com/poll.htm
"Donald" <anonymous@.discussions.microsoft.com> wrote in message
news:1383601c443ff$12727930$a001280a@.phx.gbl...
Hi every one,
Using SQL 7.0,
Without using transaction, is there a way that SQL void
(refuse) any update or delete if there is no where
clause ?
In order to avoid devastating lapse of memory :o\
Thanks !
Donald|||Donald,
You could get into the habit of always executing things on the live
servers like this:
BEGIN TRAN
<your DML code>
<some select statements to verify your DML code>
When you are satisfied, issue a COMMIT TRAN, or if you cocked it up,
issue a ROLLBACK TRAN. I always do this when making changes to
production, even if they have been scripted and tested.
--
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
Donald wrote:
> Hi every one,
> Using SQL 7.0,
> Without using transaction, is there a way that SQL void
> (refuse) any update or delete if there is no where
> clause ?
> In order to avoid devastating lapse of memory :o\
> Thanks !
> Donald|||It didn't sound like he was worried about having to roll back the update or
delete, I think he was worried about preventing users from locking up the
server by trying to act on the whole table?
Maybe I read it wrong...
--
Aaron Bertrand
SQL Server MVP
http://www.aspfaq.com/
"Mark Allison" <marka@.no.tinned.meat.mvps.org> wrote in message
news:eaZ#8XAREHA.2032@.TK2MSFTNGP11.phx.gbl...
> Donald,
> You could get into the habit of always executing things on the live
> servers like this:
> BEGIN TRAN
> <your DML code>
> <some select statements to verify your DML code>
> When you are satisfied, issue a COMMIT TRAN, or if you cocked it up,
> issue a ROLLBACK TRAN. I always do this when making changes to
> production, even if they have been scripted and tested.
> --
> Mark Allison, SQL Server MVP
> http://www.markallison.co.uk
> Donald wrote:
> > Hi every one,
> >
> > Using SQL 7.0,
> >
> > Without using transaction, is there a way that SQL void
> > (refuse) any update or delete if there is no where
> > clause ?
> >
> > In order to avoid devastating lapse of memory :o\
> >
> > Thanks !
> >
> > Donald|||I agree with Mark completely
We are in the habit of always starting a query for delete with a BEGIN TRAN. Especially when doing the work in PRODUCTION - but regardless - on the TEST BOX it's needed so you can be satisfied with your query action
Then a SELECT statement to get us happy with the recordcount. Either "details" or a COUNT(*)
Then the DELETE statement
Then sometimes another SELECT statement to prove that all the records from the first SELECT really got deleted
Then we use a "-- ROLLBACK COMMIT" as the final line
This is commented out so that you have to DBLCLICK on the keyword that you want to use
Carefully review the RESULTS PANEL - check the counts. With the way "poor" joins can increase row presentation, this is extremely important - you might have more ROWS in the "FIRST SELECT" then in the actual DELETE row count
We even save these AD HOC queries just to CYA when the folks up top ask "what just happened'". Sometimes even save the QUERY DATA GRID to a NOTEPAD file for proof...|||Good answer, i like the sledgehammer example
Thank you
>--Original Message--
>No, this is a case where your developers must use common
sense, and look
>over their scripts before executing them.
>If it's any consolation, SQL Server also won't prevent
you from tripping
>over the power cord or using a sledgehammer against the
CPU. ;-)
>--
>Aaron Bertrand
>SQL Server MVP
>http://www.aspfaq.com/
>
>
>"Donald" <anonymous@.discussions.microsoft.com> wrote in
message
>news:1383601c443ff$12727930$a001280a@.phx.gbl...
>> Hi every one,
>> Using SQL 7.0,
>> Without using transaction, is there a way that SQL void
>> (refuse) any update or delete if there is no where
>> clause ?
>> In order to avoid devastating lapse of memory :o\
>> Thanks !
>> Donald
>
>.
>|||I just want to prevent massive update or delete from ME!
I often have to update tables in production to fix data
from stupid VB applications
I was just wondering if it was possible without using
transactions. But i know, i should use TRANS.
As Narayana said : Would make a handy feature
Thank you for your help
Donald
>--Original Message--
>It didn't sound like he was worried about having to roll
back the update or
>delete, I think he was worried about preventing users
from locking up the
>server by trying to act on the whole table?
>Maybe I read it wrong...
>--
>Aaron Bertrand
>SQL Server MVP
>http://www.aspfaq.com/
>
>
>"Mark Allison" <marka@.no.tinned.meat.mvps.org> wrote in
message
>news:eaZ#8XAREHA.2032@.TK2MSFTNGP11.phx.gbl...
>> Donald,
>> You could get into the habit of always executing things
on the live
>> servers like this:
>> BEGIN TRAN
>> <your DML code>
>> <some select statements to verify your DML code>
>> When you are satisfied, issue a COMMIT TRAN, or if you
cocked it up,
>> issue a ROLLBACK TRAN. I always do this when making
changes to
>> production, even if they have been scripted and tested.
>> --
>> Mark Allison, SQL Server MVP
>> http://www.markallison.co.uk
>> Donald wrote:
>> > Hi every one,
>> >
>> > Using SQL 7.0,
>> >
>> > Without using transaction, is there a way that SQL
void
>> > (refuse) any update or delete if there is no where
>> > clause ?
>> >
>> > In order to avoid devastating lapse of memory :o\
>> >
>> > Thanks !
>> >
>> > Donald
>
>.
>|||One way I achieved this in the past was to create triggers
on the table(s) in question and make sure the rowcount
wasn't over a certain threshold. Some tables might only
have 1 row updated at a time and never more than that,
others maybe 5 or 10. So I made the trigger check the
rowcount for this.
Van
>--Original Message--
>Hi every one,
>Using SQL 7.0,
>Without using transaction, is there a way that SQL void
>(refuse) any update or delete if there is no where
>clause ?
>In order to avoid devastating lapse of memory :o\
>Thanks !
>Donald
>.
>|||Very good points Steve! I agree with you completely too, and you put it
much better than I did.
--
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Steve Z wrote:
> I agree with Mark completely.
> We are in the habit of always starting a query for delete with a BEGIN TRAN. Especially when doing the work in PRODUCTION - but regardless - on the TEST BOX it's needed so you can be satisfied with your query action.
> Then a SELECT statement to get us happy with the recordcount. Either "details" or a COUNT(*).
> Then the DELETE statement.
> Then sometimes another SELECT statement to prove that all the records from the first SELECT really got deleted.
> Then we use a "-- ROLLBACK COMMIT" as the final line.
> This is commented out so that you have to DBLCLICK on the keyword that you want to use.
> Carefully review the RESULTS PANEL - check the counts. With the way "poor" joins can increase row presentation, this is extremely important - you might have more ROWS in the "FIRST SELECT" then in the actual DELETE row count.
> We even save these AD HOC queries just to CYA when the folks up top ask "what just happened'". Sometimes even save the QUERY DATA GRID to a NOTEPAD file for proof...