http://www.sysaid.com/Sysforums/posts/list/57.page JForum - http://www.jforum.net
I might be writing a Novel in the Notes textbox in for an SR then someone else updates the request and hits the apply button, then my Novel is gone.

Could something be done about this, and if there is something in the pipeline could you please advise?

Thank you for the work you are doing to make SysAid better to use each day.]]> http://www.sysaid.com/Sysforums/posts/preList/1201/5178.page http://www.sysaid.com/Sysforums/posts/preList/1201/5178.page GMT
This message is intended to prevent a situation in which two 'triggers' (could be users, escalation rules, email integration and everything else that can change a service request) modify the service request together.

For example, if you and another administrator go into a service request that has no subject and both wish to change the subject, the first one succeeds and the second one will get the message you are talking about.

In some cases, database corruption or misconfiguration could cause the system to show that message on every attempt to save. If this is the case on your environment, please go ahead and try to save a service request. After it shows the error message, open the ...\SysAidServer\root\WEB-INF\logs\sysaid.log file on the server and copy the lines that are relevant to the time of the modification attempt. Paste it back here and I'll try to figure out the problem.


Joseph.]]> http://www.sysaid.com/Sysforums/posts/preList/1201/5179.page http://www.sysaid.com/Sysforums/posts/preList/1201/5179.page GMT I think he is asking if there is a way you can change sysaid in the future to save the text that he has just been typing in before the message came up,
reload the updated record with the changes the other person/system made,
and then offer a way of appending/merging the text into the field he was in the middle of updating.

of course I may have misunderstood what uniti is asking!
]]> http://www.sysaid.com/Sysforums/posts/preList/1201/5186.page http://www.sysaid.com/Sysforums/posts/preList/1201/5186.page GMT [/quote]

I guess it could be what uniti meant.
uniti, would you can to clarify?]]> http://www.sysaid.com/Sysforums/posts/preList/1201/5187.page http://www.sysaid.com/Sysforums/posts/preList/1201/5187.page GMT
I am asking that if a new method could be used to hold the data I am updating so it can be saved after someone else has already updated the service request. I understand that having a web-based GUI is the main obstacle here with having concurrent database updates in Sysaid.

I would appreciate any ideas that could be suggested to be able to change Sysaid so we do not have this dilemma.]]> http://www.sysaid.com/Sysforums/posts/preList/1201/5215.page http://www.sysaid.com/Sysforums/posts/preList/1201/5215.page GMT
What you're asking is not simple because in computing... it's a physical law that only one process can access one data location at a time. The multitasking feature so overly advertised is achieved by shifting process through cpu's idle time. The effect is similar to how neon light appear to emits continuous light while actually it's strobing.

That's why in critical system, database works in a "all or nothing" mode. You can imagine if what happens to you happens to Bank's ATM machines.

I say simply dissallow people to edit SR that has been open somewhere else. They can view but editing should completely be lock by the system.

That said...
Uniti... you might want to consider solving this problem non-technically i.e. restructure your organization and process.
SysAid provide built-in mechanism to prevent simultaneous access to sr such as assigning admin, routing, escalating... and so on.

This is what I apply in my site. Even though it is possible to edit the field when an admin gets a pop up of this message he/she must leave that SR alone immediately cause it means somebody else is working on it. I don't like too many people working on the same problem either.

It is possible for group of admin to be forced to work on same sr, but only the assigned admin updates the SR. The colaboration is done through the messaging (read:e-mail) in that very sr.


But it's your call of course...


]]> http://www.sysaid.com/Sysforums/posts/preList/1201/5216.page http://www.sysaid.com/Sysforums/posts/preList/1201/5216.page GMT
This is not a solution. The solution has been invented together with the first network database systems. It is called "locking". Locking fields, records even tables during certain events (like editing).
Not hard to do: a flag attached to each record which is going to be tested before allowing editing and if it allows it, prevents others from doing the same action

I think the issue is related to the continous refreshing process.

Ilient has to fix that for sure. It is not something to remain in this "workaround" stage]]> http://www.sysaid.com/Sysforums/posts/preList/1201/5218.page http://www.sysaid.com/Sysforums/posts/preList/1201/5218.page GMT Not hard to do: a flag attached to each record which is going to be tested before allowing editing and if it allows it, prevents others from doing the same action.[/quote]
Yes.. yessssssss.
And SysAid already behave like this. That's why it ignored the second person's input.

[quote=adrian_gazibar]I think the issue is related to the continous refreshing process.
Ilient has to fix that for sure. It is not something to remain in this "workaround" stage[/quote]
Precisely my point. Insisting this feature will have consequences which I personally think is unnecessary.
My solution however primitive is efective and needs no waiting. Even when measured by overhead the only extra keystrokes are the copy paste and saving.

Don't get me wrong.
Of course if Ilient somehow find a win-win solution to this I'll join you in celebration and will take advantage of it in a heart beat. All I'm saying is... the quality of your service should not be hurt by this.
]]> http://www.sysaid.com/Sysforums/posts/preList/1201/5219.page http://www.sysaid.com/Sysforums/posts/preList/1201/5219.page GMT I will ask our product manager to address this himself, and also create a feature request for this.]]> http://www.sysaid.com/Sysforums/posts/preList/1201/5227.page http://www.sysaid.com/Sysforums/posts/preList/1201/5227.page GMT
I have reviewed this issue and there is no right or wrong here - it is a matter of approach:
Some Helpdesk solutions or any other application open SR/records in view mode , and you need to click the edit icon to change. once you click the edit icon - the record is locked and nobody else can click the edit button - he will get a message - record is being edited by someone else - just like when you try to open a Word file or Excel file from a network and it is open by someone else - it opens in read-only mode.

SysAid opens all SR-s in edit mode by default - there is no special operation you need to perform to edit the data - this is the reason situations like this may happen.

I suggest the following :
In case SysAid encounters the above scenario - it will pop-up the same message, but keep all the data that you entered on the screen - the message will also instruct you that if you wish not to loose your changes you should copy them. in most cases re-entering the Service request will allow you to paste/update your changes.

I will see that this development is added to SysAid to make our life a bit easier in this specific aspect..... :oops:

Oded]]> http://www.sysaid.com/Sysforums/posts/preList/1201/5232.page http://www.sysaid.com/Sysforums/posts/preList/1201/5232.page GMT
I know this not a trivial one to solve programming wise ...]]> http://www.sysaid.com/Sysforums/posts/preList/1201/5244.page http://www.sysaid.com/Sysforums/posts/preList/1201/5244.page GMT That.... I think is the way to go. Pop up explaining why user can't access the sr and provide option just in case he/she just wanna read the sr.

[quote=Oded M]
I suggest the following :
In case SysAid encounters the above scenario - it will pop-up the same message, but keep all the data that you entered on the screen - the message will also instruct you that if you wish not to loose your changes you should copy them. in most cases re-entering the Service request will allow you to paste/update your changes.
[/quote]
I'm not sure I get this.
You want to provide something like outlook's draft on SysAid ?

If the copy pasting is manual, Tech Guy got an obviously good point.]]> http://www.sysaid.com/Sysforums/posts/preList/1201/5251.page http://www.sysaid.com/Sysforums/posts/preList/1201/5251.page GMT
I was more thinking along the line for the Notes having a redundant field in the database "holding area" for any data entered into the 'Add Note' box so when a note is entered in at the same time someone else has entered a note it will update the SR notes in a queue like fashion, keeping the database principle of only 1 data entry at a time and not losing any data being entered.

I'm not too sure if the same logic could be applied to the other fields e.g. Activity time, Resolution, Title, etc.]]> http://www.sysaid.com/Sysforums/posts/preList/1201/5364.page http://www.sysaid.com/Sysforums/posts/preList/1201/5364.page GMT
]]> http://www.sysaid.com/Sysforums/posts/preList/1201/5365.page http://www.sysaid.com/Sysforums/posts/preList/1201/5365.page GMT I still can't imagine a scenario where an sr needs more than one admin in charge. But I shall give credits to everybody.

Oded, if this is going to production, I want it provided as an option which can be turn on or off application wide. Something like those settings in admin's permission tab.

SysAid, least to me, is not just a tool like a calculator. It's a management platform. And the later, again least to me, has a higher priority than the former...

]]> http://www.sysaid.com/Sysforums/posts/preList/1201/5378.page http://www.sysaid.com/Sysforums/posts/preList/1201/5378.page GMT
A client is logged into Sysaid and looking at an SR that they have made for an update. They start typing in some notes to update the request for an ETA on a fix.

An admin at the same time is entering notes into the SR, while they are entering their notes the client completes updating the SR and then the admin loses the notes he was entering into the SR.

Scenario 2:

2 admins are in the system, 1 admin (The IT Manager) is going through SRs and closing any old SRs that he sees that should be closed, the other admin (Helpdesk Officer) is updating his assigned SRs, entering notes into the notes field on the same SR that the IT Manager just closed and then the notes that the Helpdesk Officer had entered did not save to the request.

Scenario 3:

1 admin presses the 'apply' button twice in the SR that they are working on. They may not lose their updated information but still get the message that someone else has updated their SR.

Scenario 4:

1 admin has Sysaid open in 2 browsers, enters in notes for an SR in 1 browser but doesn't hit apply, then has the SR opened in another browser and changes the status of the SR and hits 'Apply'. Then he goes back to the other browser to save his notes and then loses his notes.]]> http://www.sysaid.com/Sysforums/posts/preList/1201/5379.page http://www.sysaid.com/Sysforums/posts/preList/1201/5379.page GMT
No. 1 and 2 can be eliminated by policy. It's too long to go into so pm me if you're interested.

No. 3 is not even a problem right ? *soft smile*

No. 4 Let me guess.... going through the tab is annoying doesn't it ? Don't succumb to those tabs... custom them.. I got only one tab on my SR. *wicked smile*

Please forgive the persistence. My being so strong on the subject is driven by the fear that I might be wrong and miss an entirely better way of doing things...

So bear with me...
*smile*
And by all means spit on my flaw.

]]> http://www.sysaid.com/Sysforums/posts/preList/1201/5402.page http://www.sysaid.com/Sysforums/posts/preList/1201/5402.page GMT
1,2 & 4 should never happen. Concurrent editing should not be possible under any circumstances. The message telling you that you can not update should be triggered by the first attempt to update/change anything on a SR that is being edited by someone else. By 'first attempt' I mean keystroke, button press or selecting a different item from a dropdown list.

I would be furious if this happened. Also, small nit to pick, the text of the message should be "You cannot update this Service Request because someone else [b]is updating[/b] it.

3 should not be possible because the 'apply' button should be disabled unless a change has been made.

]]> http://www.sysaid.com/Sysforums/posts/preList/1201/5406.page http://www.sysaid.com/Sysforums/posts/preList/1201/5406.page GMT
Scenario 3 can happen when you double click the 'Apply' or 'OK' button, try it yourself. It doesn't happen everytime, depends on how you double click and if you do it before the page refreshes.

Scenario 4 has nothing to do with the tabs in Sysaid. It is referring to separate Browser Windows, e.g. you might bring up a Client's details and go to the Helpdesk tab and open an SR then update it after you have already updated the same SR in the main window, thus having the SR open at once in multiple browsers.

The Message Box:

[img]http://www.uniti.com.au/files/sysaid.jpg[/img]

The words 'You', 'this' and 'has already' need to be removed from the Forum title and a comma needs to be added after Service Request.
]]> http://www.sysaid.com/Sysforums/posts/preList/1201/5428.page http://www.sysaid.com/Sysforums/posts/preList/1201/5428.page GMT
Policy as in work area... or the process. A consensus. Workflow. Gameplan. Not software or features or function you can set and automagically runs.





]]> http://www.sysaid.com/Sysforums/posts/preList/1201/5438.page http://www.sysaid.com/Sysforums/posts/preList/1201/5438.page GMT
"You cannot update this Service Request because someone else has already updated it."

I even restarted the SysAid server just to make sure that nobody had a SR that they were in the middle of editing. However, if the same Admins create a new SR in the End User Portal, it works just fine. Any ideas?]]> http://www.sysaid.com/Sysforums/posts/preList/1201/5479.page http://www.sysaid.com/Sysforums/posts/preList/1201/5479.page GMT
"You cannot update this Service Request because someone else has already updated it."

I even restarted the SysAid server just to make sure that nobody had a SR that they were in the middle of editing. However, if the same Admins create a new SR in the End User Portal, it works just fine. Any ideas?[/quote]

Hello!

This might be happening because more then one administrator is trying to change the "new service request" form (which is SR#0) in the same time.
To overcome this issue, please ask your administrator to create the new service request, then click "apply" to give the SR a number and then the template to the service requests will be available to create another new service request.

Best regards.
Haim]]> http://www.sysaid.com/Sysforums/posts/preList/1201/5480.page http://www.sysaid.com/Sysforums/posts/preList/1201/5480.page GMT http://www.sysaid.com/Sysforums/posts/preList/1201/5481.page http://www.sysaid.com/Sysforums/posts/preList/1201/5481.page GMT
so, you open this one, and until you click apply, it's not given a SR number. or actually, it's number is zero.
if one of your co-workers also opens a SR, it's the same one. SR #0.


IMHO, this is ridicules. Sysaid: when someone opens a SR, give it a temporary, random number. when the person 'applies' then give it the next SR number in sequence.
going forward, please plan on more than one person working with sysaid, the application, at a time.
]]> http://www.sysaid.com/Sysforums/posts/preList/1201/5483.page http://www.sysaid.com/Sysforums/posts/preList/1201/5483.page GMT Why not lock each SR once opened by an individual. Be it Admin or end user. This will prevent any hiccups along the way.

If an end user cannot open the SR they knonw it is being worked on.

Just my $0.02 worth]]> http://www.sysaid.com/Sysforums/posts/preList/1201/5514.page http://www.sysaid.com/Sysforums/posts/preList/1201/5514.page GMT
Some Helpdesk solutions or any other application open SR/records in view mode , and you need to click the edit icon to change. once you click the edit icon - the record is locked and nobody else can click the edit button - he will get a message - record is being edited by someone else - just like when you try to open a Word file or Excel file from a network and it is open by someone else - it opens in read-only mode.
Oded[/quote]

Wow this has generated a lot of discussion,
Oded, this actually sounds the simplest solution, that an edit button is introduced that obtains a lock for editing the record which is released when you click apply. Otherwise everyone else just gets a read only view.


]]> http://www.sysaid.com/Sysforums/posts/preList/1201/5521.page http://www.sysaid.com/Sysforums/posts/preList/1201/5521.page GMT http://www.sysaid.com/Sysforums/posts/preList/1201/5621.page http://www.sysaid.com/Sysforums/posts/preList/1201/5621.page GMT
There isn't anything stored in SR #0 in the database. The problem you are experiencing is probably related to an incorrect form configuration. Please try to submit a service request from the admin portal (to provoke the error to show) and then post the ...\SysAidServer\root\WEB-INF\logs\sysaid.log here (or send it to me in a private message or by email to helpdesk@ilient.com, if you wish to prevent the publication of the log file).]]> http://www.sysaid.com/Sysforums/posts/preList/1201/5622.page http://www.sysaid.com/Sysforums/posts/preList/1201/5622.page GMT http://www.sysaid.com/Sysforums/posts/preList/1201/5627.page http://www.sysaid.com/Sysforums/posts/preList/1201/5627.page GMT
TJB627,
Let me know when/how you sent the log file.]]> http://www.sysaid.com/Sysforums/posts/preList/1201/5639.page http://www.sysaid.com/Sysforums/posts/preList/1201/5639.page GMT
I just emailed it to the helpdesk@ilient.com email address. Thank you for responding, I simply forgot about this issue until just now.]]> http://www.sysaid.com/Sysforums/posts/preList/1201/6756.page http://www.sysaid.com/Sysforums/posts/preList/1201/6756.page GMT
susang23]]> http://www.sysaid.com/Sysforums/posts/preList/1201/11512.page http://www.sysaid.com/Sysforums/posts/preList/1201/11512.page GMT Welcome to the SysAid community.

Is this user the only user which is getting this error?
Does it only happen when he try to attach a file?

in older versions of SysAid, the derby database had a 1MB limit for attachments, so if you are using derby database, and you installed SysAid before version 5.5 came out,please contact our support at helpdesk@SysAid.com so we will be able to examine your database.

Best regards.
Haim
]]> http://www.sysaid.com/Sysforums/posts/preList/1201/11520.page http://www.sysaid.com/Sysforums/posts/preList/1201/11520.page GMT So where did you guys get to on this matter?

We have the same problem occurring when two admins from different locations edit the same ticket ending up with a winner and a loser....]]> http://www.sysaid.com/Sysforums/posts/preList/1201/15159.page http://www.sysaid.com/Sysforums/posts/preList/1201/15159.page GMT
If both admins are trying to update the same request at the same time, then the error will come up as intended.

To avoid the issue from happening, You can instruct your admins to assign the requests to them self when they are working on it so other admins will not see it in their queue.

Regards.]]> http://www.sysaid.com/Sysforums/posts/preList/1201/15174.page http://www.sysaid.com/Sysforums/posts/preList/1201/15174.page GMT [quote=Oded M]

I suggest the following :
In case SysAid encounters the above scenario - it will pop-up the same message, but keep all the data that you entered on the screen - the message will also instruct you that if you wish not to loose your changes you should copy them. in most cases re-entering the Service request will allow you to paste/update your changes.

I will see that this development is added to SysAid to make our life a bit easier in this specific aspect..... [/quote]

I'd be grateful if you guys would indicate where in your roadmap this is. ]]> http://www.sysaid.com/Sysforums/posts/preList/1201/15176.page http://www.sysaid.com/Sysforums/posts/preList/1201/15176.page GMT http://www.sysaid.com/Sysforums/posts/preList/1201/23661.page http://www.sysaid.com/Sysforums/posts/preList/1201/23661.page GMT
Or maybe one already exists - I cant find it though ]]> http://www.sysaid.com/Sysforums/posts/preList/1201/23662.page http://www.sysaid.com/Sysforums/posts/preList/1201/23662.page GMT How are you?

There may be various causes for this problem, so we have to address each issue individually. If you are experiencing this issue, please submit a service request with us.
In regards to adding a feature to lock service request, I urge you to submit it as a feature request at the [url=http://www.ilient.com/Sysforums/forums/show/101.page]FR forum[/url]

Thanks,
Jospeh.]]> http://www.sysaid.com/Sysforums/posts/preList/1201/23686.page http://www.sysaid.com/Sysforums/posts/preList/1201/23686.page GMT
I've also received this problem, but when email integration imports a user's reply while the admin is updating the case. Just thought I'd mention it in case this helps.
]]> http://www.sysaid.com/Sysforums/posts/preList/1201/23693.page http://www.sysaid.com/Sysforums/posts/preList/1201/23693.page GMT
What you are referring to is not a problem because in this case the SR was updated and this is why you receive this massage.

The real problem was that people received this massage when the SR wasn't updated.]]> http://www.sysaid.com/Sysforums/posts/preList/1201/23743.page http://www.sysaid.com/Sysforums/posts/preList/1201/23743.page GMT
just contacted support about this issue. we seem to be getting this when a admin is updating the case notes and it takes longer than a few minutes to enter. we have very little end user updating of the system so don't think its them the only other area it could be is the email intergration but why would that cause the error?

It happens way to often for it to be a coincidental that an email comes in for that particular SR just as an admin is updating it.

Chris]]> http://www.sysaid.com/Sysforums/posts/preList/1201/23901.page http://www.sysaid.com/Sysforums/posts/preList/1201/23901.page GMT
Having a temp area in the database that "queues" updates to Service Requests seems to be the most sensible idea as this is seamless to the users.]]> http://www.sysaid.com/Sysforums/posts/preList/1201/23920.page http://www.sysaid.com/Sysforums/posts/preList/1201/23920.page GMT only one person is here updating the record and we still get this error.

Any other ideas of what could be causing this error?]]> http://www.sysaid.com/Sysforums/posts/preList/1201/29059.page http://www.sysaid.com/Sysforums/posts/preList/1201/29059.page GMT
Edit: just seen post above so will re-phrase - was this meant to have been fixed in version 8?]]> http://www.sysaid.com/Sysforums/posts/preList/1201/29061.page http://www.sysaid.com/Sysforums/posts/preList/1201/29061.page GMT
This issue is not a known issue. How ever is having it please contact our support department and
open a service request at helpdesk@sysaid.com

Thanks

Michael Nahmias
Account Manger]]> http://www.sysaid.com/Sysforums/posts/preList/1201/29340.page http://www.sysaid.com/Sysforums/posts/preList/1201/29340.page GMT Stange that you say its not a known issue if you look at the posts a number of people including myself have been in touch with support about it

Cheers
Chris Latta]]> http://www.sysaid.com/Sysforums/posts/preList/1201/29347.page http://www.sysaid.com/Sysforums/posts/preList/1201/29347.page GMT
I see why you would think that... This problem could be caused by different issues. We don't want to get log files posted on the forum, as they sometimes include information you wouldn't want to post publicly.
Submitting a service request with our support would allow us to address your specific case without exposing your company details publicly...

Thanks,
Joseph.]]> http://www.sysaid.com/Sysforums/posts/preList/1201/29541.page http://www.sysaid.com/Sysforums/posts/preList/1201/29541.page GMT
Everyone who uses sysaid is now copying the text into notepad before doing anything, bit sad dont you think?]]> http://www.sysaid.com/Sysforums/posts/preList/1201/29551.page http://www.sysaid.com/Sysforums/posts/preList/1201/29551.page GMT
Everyone who uses sysaid is now copying the text into notepad before doing anything, bit sad dont you think?[/quote]

It would be great a ticket is "locked" when an administrator is working with it.
so not anybody else can work on it at the same time, cause if someone does then later on we get the message "You cannot update this Service Request because someone else has already updated it"

This is a feature request as well: http://www.ilient.com/Sysforums/posts/list/6443.page

But so many old helpdesk systems we used in the past do have a ticket lock option, so i do not see why sysaid cannot implement it as well. ]]> http://www.sysaid.com/Sysforums/posts/preList/1201/29557.page http://www.sysaid.com/Sysforums/posts/preList/1201/29557.page GMT
Perhaps we have a different issue with our database or my methodology is bad, but when I assign a job to myself, I hit apply to save the change and allocate the job to me so another admin doesn't pick it up. I then leave the window open and fix the issue for the user, and then update the solution field, and every time without fail it gets the "You cannot update this Service Request because someone else has already updated it" message. I've learned as others have to just use notepad to type your text, and then paste it into the field, but this gets more than a little annoying every single time you respond to a job.

What is the correct workflow to stop this happening? Do you guys normally open the ticket, assign it to yourself, and then shut down the browser and open it again whenever you need to update a field? I'm used to always "applying" any fields I update or modify with other applications, but it seams in Sysaid, this can only be used once in a session, is that right?]]> http://www.sysaid.com/Sysforums/posts/preList/1201/29621.page http://www.sysaid.com/Sysforums/posts/preList/1201/29621.page GMT
I found that this is often caused by the service request being escalated while you're in it. When you try to save it, it tell you that it has been updated. It annoy me a lot too. I hope they will find some solution to this problem.]]> http://www.sysaid.com/Sysforums/posts/preList/1201/29623.page http://www.sysaid.com/Sysforums/posts/preList/1201/29623.page GMT
1. If another admin genuinely updates the ticket at the same time this happens
2. If an email is sent into the call while it is open on your screen
3. If an escalaltion rule runs while the SR is open on your screen
4. If an end user updates the ticket while an admin has it on their screen.


The fix - Notepad (not popular!)

Has anyone else found other situations where this happens? If so please post so Sysaid can get the data they need to fix this.


Thanks

John

Just wanted to add that we are still running 7.5 so this might have been fixed in the latest release.


]]> http://www.sysaid.com/Sysforums/posts/preList/1201/29630.page http://www.sysaid.com/Sysforums/posts/preList/1201/29630.page GMT
Thats my 2 cents on why I keep getting that message. Maybe some of you have a similar issue.]]> http://www.sysaid.com/Sysforums/posts/preList/1201/29982.page http://www.sysaid.com/Sysforums/posts/preList/1201/29982.page GMT
But it's happening when we open a new SR. Can anybody help me?]]> http://www.sysaid.com/Sysforums/posts/preList/1201/36914.page http://www.sysaid.com/Sysforums/posts/preList/1201/36914.page GMT