User profile for broughtie

Ah, hidden in plain sight. Thanks. / comments

Ah, hidden in plain sight. Thanks.

0 votes

Ok, having access to the logs is nice, but even that info isn't helping me get email sent. Here is the error in the log: 10:43:42.971|Error |AlertRepository |8 |Error sending test email|System.Net.Mail.SmtpException: Transaction failed. The server response was: 5.7.1 <kevin.broughton@elmlocating.com>: Sender address rejected: Access denied at System.Net.Mail.RecipientCommand.CheckResponse(SmtpStatusCode statusCode, String response) at System.Net.Mail.SmtpTransport.SendMail(MailAddress sender, MailAddressCollection recipients, String deliveryNotify, SmtpFailedRecipientException& exception) at System.Net.Mail.SmtpClient.Send(MailMessage message) at e.a(a , RepositoryConfiguration , Boolean ) at e.a(String , RepositoryConfiguration , String& ) I've checked and rechecked my settings for SMTP Host, Port, Account User Name, Password, Send From Name, and Test Email address and they are all correct. I have other server software using the same email values fine, in addition the same values work in MS Outlook without problem. Based on the error message above, where do you suppose the problem lies? P.S. I also have SQL Backup and I'm using the exact same email values in SQL Response as I am in SQL Backup. I copied and pasted all of them except the password which I retyped into both programs. SQL Backup can sent a test email, SQL Response still can't. / comments

0 votes

I'm getting this same error and it also appears to be happening on frequently run jobs. I just download and installed SQL Response yesterday and I'm running version 1.0.0.1596. / comments

I'm getting this same error and it also appears to be happening on frequently run jobs. I just download and installed SQL Response yesterday and I'm running version 1.0.0.1596.

0 votes

I also have seen a negative job duration in SQL Response, but that isn't what reality reflects in the SQL Agent logs. Haven't seen in this thread the reason for the negative duration. / comments

I also have seen a negative job duration in SQL Response, but that isn't what reality reflects in the SQL Agent logs. Haven't seen in this thread the reason for the negative duration.

0 votes

I would concur that if users are required to close out incidents, you would want to record at a minimum the user name of the person who closed out the issue, the close time, and make available a note field. Also, to follow the thought logically, it would make sense to allow a user to close a group of events by highlighting them and providing the opportunity to enter a note that would attach to every incident in the group as well as mark the username and time of the closing. / comments

I would concur that if users are required to close out incidents, you would want to record at a minimum the user name of the person who closed out the issue, the close time, and make available a no...

0 votes

I currently use SQL Sentry to monitor our SQL servers, and although the product has a number of nice features, the section that monitors SQL Agent jobs is the part I use the most and if RedGate SQL Response if powerful enough, I'd probably dump SQL Sentry for SQL Response. If if only managing a single server, I still see the ability to configure incidents as one of the most important features. In the current beta of SQL Response, its a bit of a mystery what "incidents" are even being monitored. It would be nice to be able to pull up a list of all possible incidents and be able to configure each one (turn on /off, set default monitoring thresholds, etc). Specific to the topic of this thread, I thing every incident type need to be configurable for each object covered by that incident type. For example, lets look at the "Long Running Query" incident. Lets say I have three jobs setup in SQL Agent that execute some code. Job 1 runs continuously and never ends, Job 2 runs for about 3 seconds every 10 minutes, and Job 3 runs for about 15 minutes once a day. Now for each of these jobs, I'm going to want to configure individually how "Long Running Query" is defined. Job 1 shouldn't even be included in this incident type, Job 2 should be considered long running if it runs for more than 30 seconds, and Job 3 shoudl be considered long running if it runs for more than 20 minutes. Now no one is going to want to have to configure each incident for every object as part of the setup since that would be daunting in many environments, and the is where the concept of default values for an incident type come into play. Perhaps I can define "long running query" to be anything that take more than 10% of the average execution time. Or maybe anything that runs for more than 30 seconds. These defaults might cover 90% of my objects, and I could then go into individual objects and make specific adjustments for those objects that differ from the default. / comments

I currently use SQL Sentry to monitor our SQL servers, and although the product has a number of nice features, the section that monitors SQL Agent jobs is the part I use the most and if RedGate SQL...

0 votes

I would agree that the software must necessarily provide the ability specify a different Windows loing for each server as an option. We don't use SQL Server authentication, although I imagine there are other who are still forced to by vendors, legacy code, or poor judgement. / comments

I would agree that the software must necessarily provide the ability specify a different Windows loing for each server as an option. We don't use SQL Server authentication, although I imagine ther...

0 votes

If there were no jobs, then the Agent Not Running incident would have not much value. Getting the "Job failed to start" incident is good and does provide a minimum level of alerting the Agent is perhaps not running, but take the following scenario: Somehow Agent is disabled/turned off at 2pm. You're next scheduled job is 1am. The "Job failed to start" incident would fire at 1am and it would be possible to respond and fix it, however, why should I have to wait until 1am and get woken up, when I could have found out Agent wasn't working 11 hours earlier and easily fixed it while I was at my computer. / comments

If there were no jobs, then the Agent Not Running incident would have not much value. Getting the "Job failed to start" incident is good and does provide a minimum level of alerting the Agent is p...

0 votes

I would also concur that adding an "Agent not running" incident would be a nice addition to the feature set. / comments

I would also concur that adding an "Agent not running" incident would be a nice addition to the feature set.

0 votes

As someone who already owns a number of tools in the "Toolbelt", I hope you'll consider upgrade pricing for existing owners. Also, will there be any early-bird pricing. Also, since the toolbelt incldues developer licensed vs server licensed products, are there discounts for additional server licenses of the toolbelt products? Should the there be a Developer toolbelt and a Server toolbelt? However it works out, I'm glad to see you offering a super bundle since I want everything you make! Not a dud in the bunch; once you upgrade SQL Prompt 2.0 that is. [image] / comments

As someone who already owns a number of tools in the "Toolbelt", I hope you'll consider upgrade pricing for existing owners. Also, will there be any early-bird pricing. Also, since the toolbelt i...

0 votes

How can we help you today?

broughtie

Comments