Running .Net is not a problem for us on the server side, most have 2.0 or higher currently, no real app issues we have to work around with it on the back end. SQL level accounts are not a problem either, although we try to use Windows authentication where possible for single sign on/ease of use. We currently have two or three SQL 2k5 servers and about half a dozen SQL 2K in production. I have yet to use SA to monitor more then the SQL services at the OS level, so would be interested to see how the check progresses. Thanks! Chad
>>> "Dirk Bulinckx" <[EMAIL PROTECTED]> 2/21/2008 3:51 PM >>> We're currently (re)looking at adding a SQL2005 check (similar to the SQL2000/SQL7 check in SA). Looking at how SQL2005 "works" we won't be able to use SQL DMO in all cases (seems that SQL2005 can only use DMO when in some kind of compatibility mode :-( ), so we will have to use the "new" SQL SMO. This does mean using the .NET 2.0 Framework -> do you see this as a problem? Also from an authentication point of view it can OR use the current logged-in NT user OR use SQL authentication. This means that IF we have such a check for SQL2005 and you want to run SA as service (system account) THEN you will have to use SQL authentication -> is this possible on YOUR SQL2005 installation? Dirk Bulinckx. To unsubscribe send a message with UNSUBSCRIBE as subject to [email protected] If you use auto-responders (like ou! t-of-the-office messages), then make sure that they are not send to the list nor to the individual members of the list that send a message. Doing this will get you removed from the list. To unsubscribe send a message with UNSUBSCRIBE as subject to [email protected] If you use auto-responders (like out-of-the-office messages), then make sure that they are not send to the list nor to the individual members of the list that send a message. Doing this will get you removed from the list.
