Extra logging in SQL error log

Hi All,
Hoping someone can assist with this. Is there an SQL trace flag, or
other method, where I can get the SQL server error logs (2000 and
2005) to log database detachements, and changes in DB status (eg to
read only from online etc).
I thought about a trigger on sysdatabases (sys.databases) but am
highly skeptical of triggers on system tables.
Why am I doing this? I need to monitor the up time of individual
databases on an instance, and third party tools are not an option.
thanks in advance.Hi
If you are on SQL Server 2005 you can create TRIGGER on database level (see
BOL for details)
To see error log
ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/udb9/html/6908c21a-65e3-458f-a272-fee256d86448.htm
<snafu66@.hotmail.co.uk> wrote in message
news:1188442379.790535.109850@.m37g2000prh.googlegroups.com...
> Hi All,
> Hoping someone can assist with this. Is there an SQL trace flag, or
> other method, where I can get the SQL server error logs (2000 and
> 2005) to log database detachements, and changes in DB status (eg to
> read only from online etc).
> I thought about a trigger on sysdatabases (sys.databases) but am
> highly skeptical of triggers on system tables.
> Why am I doing this? I need to monitor the up time of individual
> databases on an instance, and third party tools are not an option.
> thanks in advance.
>

extending SSIS Container?

Has anyone investigated extending any of the SSIS Container classes?

I have been looking into it because we'd like to add a set of standard logging calls on events, standard startup procedures, etc. on any package that we execute.

I've been looking into the Sequence Container, For-Each, etc. They are all sealed classes. I'm not sure why MS has sealed them.

We're currently thinking of implementing our own version of the Sequence Container -- we'd really like to be able to extend the functionality of a standard container class, but we don't want to have to implement the actual container class itself.

Any insight appreciated.

Nope, it is not possible to extend these classes.

The managed classes in Dts.Runtime namespace allow you to manipulate the built-in containers in a package. They are sealed because they are not actually used at execution time, so subclassing them would not be useful.|||

Thanks Michael.

I'm not sure I understand how the containers are not used at execution time -- something like a For-Each loop container would be, wouldn't it?

I think what I'd really like to do is extend the SSIS Package class instead. But that is sealed as well. Perhaps we'll wind up using something like a decorator for the Package class.

|||When package schedules the tasks, SSIS uses its internal representation for For-Each container, but not the actual .NET class. I.e. even if you could subclass the container and override Execute() method, SSIS would not call your method.

We've received similar feedback several times. For now, you can use Execute Package task to achieve some of the functionality, but we know it does not provide all the functionality that might be needed.|||

jhikel wrote:

Has anyone investigated extending any of the SSIS Container classes?

I have been looking into it because we'd like to add a set of standard logging calls on events, standard startup procedures, etc. on any package that we execute.

I've been looking into the Sequence Container, For-Each, etc. They are all sealed classes. I'm not sure why MS has sealed them.

We're currently thinking of implementing our own version of the Sequence Container -- we'd really like to be able to extend the functionality of a standard container class, but we don't want to have to implement the actual container class itself.

Any insight appreciated.

frequently used logging configurations can be created as templates.sql