John Mitchell-245523 (7/7/2011)

---

I actually agree with Joe on this, although not with the argument that it should be avoided because it's not standard SQL. That isn't a concern of...

The default trace location can be found issuing this:

SELECT value

FROM :: fn_trace_getinfo(default)

WHERE traceid = 1

AND property = 2

To see the first available entry in the trace you can run this:

select...

tommyh (7/7/2011)

---

Hrmm interesting... you do know thats not the same link as the one that you have in your signature? ... though they address 2 different things... so...

... unless you're a Joe Celko fan 😉

Usually the IN predicate is implemented spooling the literals to a temporary internal table, if the input is large enough. Otherwise it is implemented as a set of OR predicates....

Well, I don't know if this is the best way... for sure it is one way.

I can only say that I had to do the same thing some years ago...

Glad I could help.

Post back here if you experience other issues.

Gianluca

GilaMonster (7/7/2011)

---

It'll be in the default trace, but that could have rolled over (it's only 5 files of 20MB). If the activity is such that the drop has been cleared...

I think I don't understand your question. Can you clarify?

This is a totally different issue, isn't it?

Where exactly you want to encrypt the password? On the app side?

The password is...

I think the default trace contains all the information you need:

http://sivasql.blogspot.com/2010/07/how-to-find-who-dropped-database-is.html

Hope this helps

Gianluca

See if this helps:

http://chopeen.blogspot.com/2007/05/alter-table-failed-because-unique.html

This is the template I would use:

-- =============================================

-- Author: <Author,,Name>

-- Create date: <Create Date,,>

-- Description: <Description,,>

-- =============================================

CREATE PROCEDURE <ProcedureName, sysname, >

AS

BEGIN

SET...

You ran into a deadlock.

You could:

1) Make sure this maintenance task runs when there is no other activity on the server

2) Increase deadlock priority

3) Trace the deadlock and find+fix the...

You could use a logon trigger:

CREATE TRIGGER [TR_LOGON_MyApplication]

ON ALL SERVER

FOR LOGON

AS

BEGIN

DECLARE @program_name nvarchar(128)

DECLARE @host_name nvarchar(128)

SELECT @program_name =...

No, I'm sorry. I don't have that paper. The original work...