I have a weird issue that seems to have started following an SMTP issue we experienced. A little background: earlier this week the server that hosts the Service Desk application (Windows 2k, SD 4.5SP6) started experiencing extremely high CPU utilization. After searching the ITRC forums it appeared that it may have been the result of an email getting hung up. Nothing in the SD configuration would indicate a problem with SD itself, so I contacted our exchange folks. Lo and behold, they found they had an open relay and over 500K messages in queue. They resolved the issue, but since then I've been experiencing this odd issue with Service Calls that I automatically generate for cyclic maintenance activities (I use cron and Perl to run the jobs). At a command line prompt, I execute the SD_Event command:
However, the Service Call never appears!! I'm baffled. Could this be an issue with our SQL server? What table would I look at to see if the rows are being entered?
I'm also seeing this error occassionally, which completely confounds me as this occurs on new creation of a Service Call:
[EVENT_4404] VALUE_LIST="username=system#password=servicedesk#mapping=SD_Event_Checklists#className=Newmont_MBSA_Sync#modus=insert#SourceID=3786#PriAss=5-Informational#" SERVER=172.31.2.2 PORT=30980 SERVER_RESPONSE=ERROR: Item cannot be saved, because another user has changed it after you opened it. LANGUAGE=GB TRY=1 LOGFILE=C:\Program Files\Hewlett-Packard\OpenView\service desk 4.5\event\bin\GSC Checklist Events\sd_event.log ERROR_LOGFILE=C:\Program Files\Hewlett-Packard\OpenView\service desk 4.5\event\bin\GSC Checklist Events\sd_event_error.log TIMESTAMP= 4/14/2006 17:42:02 SEND=true
Any help will be greatly appreciated as I am currently really lost. If anyone needs to see the cron or perl files, I'd be happy to attach them.
Okay, we found the issue, we think. The app server and the SQL server had different GMT time zones set on them, one that compensates for Daylight Savings and one that doesn't, so there was an hour differential between the two. So why didn't this issue present itself earlier? We *think* that it is due to the fact that we rebooted the app server as part of the activities associated with the email issue. This reset the already established database connection, and rows could no longer be written because of the timestamp differential...we think.
I don't know whether your solution has been successful completely or not. But here's a suggestion. Check the sd_event_error.log for the corresponding timestamp on sd_event.log of a ticket that is not logged. This will tell you what is the issue. The error line will explain it more clearly.
Hope this helps...
Modesty is good!! But remember, all your life other people will try and take your achievements away from you, don't make it easy for them.
Thanks for the reply. The SD_EVENT_ERROR.log was of very little use. For the most part, using command line the events would show they were successful, but the database would never add the row. No error through Service Desk, no error in SQL. I'm still leaning to the time differential as being the root of the problem
Whilst I have only done a little using sd_event ages ago and I might be off the track? I noticed you have a sourceId = 3805 and I am not sure where this number is coming from.
Maybe you are already aware of this but if there is already a record with sourceId 3805 and another event tries to create a new one with the same value in sourceId then it will not create a new one but will modify the existing.
This behaviour would depend on your data exchange import mapping, SD_Event_Checklists. Usually SourceId is set as the unique key for sd_event imports with the whole purpose being to prevent creation of new records when you want to do updates to an existing record.
Thanks for the reply. We actually have a script that increments a number in a separate SourceID.txt file that SD_Event uses to pass the source_id. This way every event created through our automation does have a unique source ID.
Forgive me if I cover stuff you have already checked.
1) Has the SD-Event been service packed to the same level. Can you try the SD_Event on another PC?
2) Is the import mapping using a template that if providing all the required fields that are not provided by the sd_event?
Also, it is a good idea to create an integration account rather than using system and just give that integration account the roles it needs. An integration account doesn't consume a license and is better than having the system account and password in scripts. But that doesn't really help your problem - sorry.
I don't know if you've read through the entire thread yet, but we did figure out what was causing the problem. It turned out to be a time sync issue, a very odd one. We had our SQL server and our App server on 2 different GMT time zone settings, one that adjusted for daylight savings, one that didn't. It was just casually found, I happened to notice flipping between servers that the times were different.
What I think happened was that the app server adjusted for daylight savings and the SQL server did not about a week prior to this issue. However, since the database connection already existed, no impact was experienced. When I rebooted the app server, the database connection was re-established, and then it couldn't time sync because of the time differential. This is pure speculation on my part, but I have no other.