is there a way to auto delete all the record that is more than 1 month old compare to the date field in that table.
No try using the sql job that will run at a stupilate time and that will delete the records
is there a way to auto delete all the record that is more than 1 month old compare to the date field in that table.
No try using the sql job that will run at a stupilate time and that will delete the records
Any ideas?
Do you have any antivirus software installed?
What is the service pack on SQL Server?|||I think we have Trend Server Protect on all the servers.
How do I check the service pack of SQL?
i have a web app connecting to a sql server using sql server
authentication. let's say, for example, my login/password is
dbUser/dbUser. the web app however, is using windows authentication.
so if I am logged into the network as 'DOMAIN\Eric', when I access my
web app, my web app knows that I am 'DOMAIN\Eric'. but to the sql
server db, I am user 'dbUser'.
now, i for each table i have, i need to implement an audit table to
record all updates, inserts, deletes that occur against it. i was
going to do so with triggers. this is all fine for selects, inserts,
and updates. for each table, i have an updatedby and an updatedate.
for example, let's say i have a table:
create table blah
(
id int,
col1 varchar(10),
updatedby varchar(30),
updatedate datetime
)
and corresponding audit table:
create audit_blah
(
id int,
blah_id int,
blah_col1 varchar(10),
blah_updatedby varchar(1),
blah_updatedate datetime
)
for update and insert triggers, i can know what to insert into the
updatedby column of audit_blah because it's in a corresponding row in
blah. my web app knows what user is accessing the application, and
can insert that name into blah. blah's trigger will then insert that
name into audit_blah.
however, in the case of a delete, i'm not passing in an 'updatedby',
because i'm deleting. in this situation, how can the trigger know
what user is deleting? the db only knows that sql user 'dbUser' is
deleting, but doesn't know that 'dbUser' is deleting on behalf of
'DOMAIN\Eric'. is there any way for my app to inform the trigger to
access my windows identity without having a corresponding row in the
table from which to pull that info?
obviously, i could have each of my app's users log into SQL server
through Windows authentication; then i could just use SYSTEM_USER.
but let's say, for performance's sake, it'd be better for me to use
one sql server login. (i believe one user works better for connection
pooling purposes.) is there a way to get around this?
(i'm hoping a built-in function exists that solves all my problems.)
suggestions? resources?
any help would be great appreciated.
happy turkeys.
EricHi
You may want to do soft deletes instead (possibly with a garbage collection
job!) or do the deletes through a stored procedure and log them differently.
John
"ecastillo" <encee5@.gmail.com> wrote in message
news:a2f0a8ac.0411252044.5dffaa2@.posting.google.co m...
> i'm in a bit of a bind at work. if anyone could help, i'd greatly
> appreciate it.
> i have a web app connecting to a sql server using sql server
> authentication. let's say, for example, my login/password is
> dbUser/dbUser. the web app however, is using windows authentication.
> so if I am logged into the network as 'DOMAIN\Eric', when I access my
> web app, my web app knows that I am 'DOMAIN\Eric'. but to the sql
> server db, I am user 'dbUser'.
> now, i for each table i have, i need to implement an audit table to
> record all updates, inserts, deletes that occur against it. i was
> going to do so with triggers. this is all fine for selects, inserts,
> and updates. for each table, i have an updatedby and an updatedate.
> for example, let's say i have a table:
> create table blah
> (
> id int,
> col1 varchar(10),
> updatedby varchar(30),
> updatedate datetime
> )
> and corresponding audit table:
> create audit_blah
> (
> id int,
> blah_id int,
> blah_col1 varchar(10),
> blah_updatedby varchar(1),
> blah_updatedate datetime
> )
> for update and insert triggers, i can know what to insert into the
> updatedby column of audit_blah because it's in a corresponding row in
> blah. my web app knows what user is accessing the application, and
> can insert that name into blah. blah's trigger will then insert that
> name into audit_blah.
> however, in the case of a delete, i'm not passing in an 'updatedby',
> because i'm deleting. in this situation, how can the trigger know
> what user is deleting? the db only knows that sql user 'dbUser' is
> deleting, but doesn't know that 'dbUser' is deleting on behalf of
> 'DOMAIN\Eric'. is there any way for my app to inform the trigger to
> access my windows identity without having a corresponding row in the
> table from which to pull that info?
> obviously, i could have each of my app's users log into SQL server
> through Windows authentication; then i could just use SYSTEM_USER.
> but let's say, for performance's sake, it'd be better for me to use
> one sql server login. (i believe one user works better for connection
> pooling purposes.) is there a way to get around this?
> (i'm hoping a built-in function exists that solves all my problems.)
> suggestions? resources?
> any help would be great appreciated.
> happy turkeys.
> Eric|||[posted and mailed, please reply in news]
ecastillo (encee5@.gmail.com) writes:
> however, in the case of a delete, i'm not passing in an 'updatedby',
> because i'm deleting. in this situation, how can the trigger know
> what user is deleting? the db only knows that sql user 'dbUser' is
> deleting, but doesn't know that 'dbUser' is deleting on behalf of
> 'DOMAIN\Eric'. is there any way for my app to inform the trigger to
> access my windows identity without having a corresponding row in the
> table from which to pull that info?
You could use SET CONTEXT_INFO. This command is somewhat tricky to use,
but it's workable. This commands sets the column context_info in
sysprocesses. The value is a binary value. Here is an example:
declare @.bin varbinary(30)
select @.bin = convert(varbinary(30), 'DOMAIN\Eric')
set context_info @.bin
go
select convert(varchar(30), context_info)
from master..sysprocesses where spid = @.@.spid
The web server would do the first part, the trigger the second part.
--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp
I would like to create an audit table that is created with a trigger that
reflects all the changes(insert, update and delete) that occur in table.
Say I have a table with
Subject_ID, visit_number, dob, weight, height, User_name, inputdate
The audit table would have .
Subject_ID, visit_number, dob, weight, height, User_name, inputdate,
edit_action, edit_reason.
Where the edit_action would be insert, update, delete; the edit_reason would
be the reason given for the edit.
Help with this would be great, since I am new to the world of triggers.
Thanks,
JeffJeff Magouirk (magouirkj@.njc.org) writes:
> I would like to create an audit table that is created with a trigger that
> reflects all the changes(insert, update and delete) that occur in table.
> Say I have a table with
> Subject_ID, visit_number, dob, weight, height, User_name,
> inputdate
> The audit table would have .
> Subject_ID, visit_number, dob, weight, height, User_name, inputdate,
> edit_action, edit_reason.
> Where the edit_action would be insert, update, delete; the edit_reason
> would be the reason given for the edit.
> Help with this would be great, since I am new to the world of triggers.
If you need to do to this on a broad scale, consider 3rd-party solutions.
Two that I usually recommend - although I've used none of them myself -
is SQLAudit from Red Matrix and Entegra from Lumigent. SQL Audit is
based on triggers, Entegra works from the transaction log.
But for a one-shot you could do:
CREATE TRIGGER tbl_audit_tri ON tbl FOR INSERT, UPDATE, DELETE
IF @.@.rowcount = 0
RETURN
IF EXISTS(SELECT * FROM inserted)
BEGIN
INSERT logtable (subject_id, ... edit_action)
SELECT subject_id, ...
CASE WHEN EXISTS (SELECT * FROM deleted)
THEN 'UPDATE'
ELSE 'INSERT'
FROM inserted
END
ELSE
BEGIN
INSERT logtable (subject_id, ... edit_action)
SELECT subject_id, ..., 'DELETE'
FROM delete
END
As you see I have left out edit_reason. This is because I don't know
what you mean with "edit_reason", and anyway it sounds like something
that can be quite difficult to get hold of from the trigger.
--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se
Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp
min of the app can selectively enable and disable auditing
min of the app can selectively enable and disable auditingAttach remote DB file,Sql Server