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=20
=20
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:
--=20
Keith
"Donald" <anonymous@.discussions.microsoft.com> wrote in message =
news:1383601c443ff$12727930$a001280a@.phx
.gbl...
> Hi every one,
>=20
> Using SQL 7.0,
>=20
> Without using transaction, is there a way that SQL void
> (refuse) any update or delete if there is no where=20
> clause ? =20
>=20
> In order to avoid devastating lapse of memory :o\
>=20
> Thanks !
>=20
> 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_s...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...[vbcol=seagreen]
> 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:
>|||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 TES
T 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 "detai
ls" or a COUNT(*).
Then the DELETE statement.
Then sometimes another SELECT statement to prove that all the records from t
he 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 w
ant 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 "wha
t just happened'". Sometimes even save the QUERY DATA GRID to a NOTEPAD fi
le 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...
>
>.
>|||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...
on the live[vbcol=seagreen]
cocked it up,[vbcol=seagreen]
changes to[vbcol=seagreen]
void[vbcol=seagreen]
>
>.
>