Nagios Support Forum

Anybody have any more ideas?

I'm wondering if it has something to do with the lack of "database" level in the script. For example our structure looks like this:
Server > Instance > Database > Table

The new script has the ability to specify everything but "database". And I realized --time2connect does not require the "-T TABLE" switch because I put in a nonsense variable there and it showed that the connection was fine.

ordwaycenter wrote:I'm wondering if it has something to do with the lack of "database" level in the script. For example our structure looks like this:
Server > Instance > Database > Table

The new script has the ability to specify everything but "database". And I realized --time2connect does not require the "-T TABLE" switch because I put in a nonsense variable there and it showed that the connection was fine.

what follows -T is the database, in the example given, master is a database name (the default MSSQL system database)

You should be replacing master with your database name

I see.

Nevertheless, it looks like both the old and new scripts aren't working right. Whenever I run a trace on the query attempts, nagios is giving the -T DATABASE information as "instance_name" in the query. Here's what it looks like under the new script (which I'm now using on the database that doesn't have an instance):

Nagios console command:
./check_mssql_database_update.py -H myserver.domain.local -U nagiosusername -P password -T MyDatabaseName --activetrans --warning 10 --critical 20

Trace result:
SQL:BatchStarting SELECT cntr_value FROM sysperfinfo WHERE counter_name='Active Transactions' AND instance_name='MyDatabaseName'; pymssql nagiosusername

Finally figured it out with help at:
http://www.experts-exchange.com/Network ... 04436.html

Turns out it needed server level permissions of "Connect SQL" and "View server state." Also needs database level permissions of "Connect" and "Select".

Please mark as solved.

Glad you finally figured out why it worked on one machine and not another