Comments
Sort by recent activity
Oh dear - sorry about that. Could you please send us the Incident Repositories log file? It get's stored whereever you configured the data store folder to be. The default location for this would be something like C:\Documents and Settings\All Users\Application Data\Red Gate\SQL Response
There should be a server.log file in there which should hopefull tell us more. I'll pm you my email address. / comments
Oh dear - sorry about that. Could you please send us the Incident Repositories log file? It get's stored whereever you configured the data store folder to be. The default location for this would...
I've just realised that the new build should (hopefull) fix the SQL connection error - but you also have that RPC error. Is the account that is running the Incident Repository an admin on the machine you're monitoring? / comments
I've just realised that the new build should (hopefull) fix the SQL connection error - but you also have that RPC error. Is the account that is running the Incident Repository an admin on the mach...
Hi - another poster on the forums also found this problem. We think it's an issue when using linked servers where for some reason you have to use a alias for the fully qualified table name which in a particular query we're not doing!
We've made a fix for this but we want to test it fully before sending it out. / comments
Hi - another poster on the forums also found this problem. We think it's an issue when using linked servers where for some reason you have to use a alias for the fully qualified table name which i...
Hi,
We've not seen this at all in testing here. Do you have some firewall software installed or use windows firewall? It's possible that could be blocking it?
EDIT: Oh - and to rule out the obvious I'm assuming you just used the default port of 8086 when installing and connecting? / comments
Hi,
We've not seen this at all in testing here. Do you have some firewall software installed or use windows firewall? It's possible that could be blocking it?
EDIT: Oh - and to rule out the obviou...
Hi,
This error is caused by SQL Response trying to connect to the server machine itself via WMI (rather than the SQL Server). This means that the account that is running the Incident Repository needs to be an administrator on the machine. Could you let us know if this is the case here please? / comments
Hi,
This error is caused by SQL Response trying to connect to the server machine itself via WMI (rather than the SQL Server). This means that the account that is running the Incident Repository ne...
Thanks for your kind words [image]
You're correct in what the behaviour is. Incidents of the same type and subject on the same day go into the same group. This group is then open/closed/deleted as a whole.
There was some debate here about what the behaviour should be and our thinking was that we would keep the group together, primarily to avoid too much "spam" appearing with the same event happening over and over. So closing a group is "thanks - don't bother me again today"
However this beta is very much about hearing people's thoughts so please let us know what you think. / comments
Thanks for your kind words
You're correct in what the behaviour is. Incidents of the same type and subject on the same day go into the same group. This group is then open/closed/deleted as a who...
Thanks for reporting it - we'll take a look into it. / comments
Thanks for reporting it - we'll take a look into it.
sgreene wrote:
The servers are all in the US mountain time zone, but we are in Arizona and don't observe daylight savings.
So that should only be an hour or two difference then. Could you check what time SQL Server reports when you run:
select getdate();
Thanks / comments
sgreene wrote:
The servers are all in the US mountain time zone, but we are in Arizona and don't observe daylight savings.
So that should only be an hour or two difference then. Could you che...
EnigmaGuru wrote:
Currently, I have a problem with the monitor logging "Job Did Not Start" for future jobs. These jobs are not scheduled to run until this evening but are getting logged as "Job Did Not Start" in the morning. This is annoying given that this accounts for the majority of the incidents and when it happens in the evening and I don't see it until after the time the job runs it proves to be completly inaccurate.
I suggest that you work off of a 24hr time to avoid confusion in reading the log, given this issue.
The times are read as 24hour format so we'll have to take a look at why those future failures are comming up. Thanks for reporting it. / comments
EnigmaGuru wrote:
Currently, I have a problem with the monitor logging "Job Did Not Start" for future jobs. These jobs are not scheduled to run until this evening but are getting logged as "Job...
sgreene wrote:
I'm getting incidents for jobs that are running successfully. It says the job did not start(agent not running). My Agent is running. The time stamp for the incident is also off. The latest incident is 11:58PM on 2/8/2008. It's only 9:14AM where I'm at.
Sam
Is the time on the server different (i.e. different timezone)? The incidents are reported as the server time rather than your local time. / comments
sgreene wrote:
I'm getting incidents for jobs that are running successfully. It says the job did not start(agent not running). My Agent is running. The time stamp for the incident is also off...