It looks like a problem with the integrity of VBA coding rather than the problem with remedy. Might be you are trying to display the values before getting the RecordSet.
Thank you for your reply. Interesting thought. I wonder if you could be more specific.
Also, let me give a specific example of what is occurring, along with some screen shots.
Here is the Excel VBA code which I've verified does work correctly, at least in terms of branching to IE (Remedy IE interface) and requesting the correct eid (note the screen shots):
Dim strAddress, strEid As String
strEid = Application.VLookup(ActiveCell.Value, Worksheets("DataCRQ").Range("C2:D1000"), 2, False)
strAddress = strAddress & strEid
Here is the test scenario:
Look up Request_ID CRQ000000004570, then look up CRQ000000004460.
CRQ000000004570 is found and displayed correctly.
Then on a subsequent different lookup, instead of correctly selecting and displaying CRQ000000004460, CRQ000000004570 is selected and displayed once again.
Initial attempt to select CRQ000000004570 (note address line):
Initial attempt to select CRQ000000004570, after login (note address line):
Subsequent attempt to select CRQ000000004460 (note address line):
Subsequent attempt to select CRQ000000004460, after login (note address line):
I hope that helps. I will look forward to a reply. Thank you.
Can to try opening another change and see what happens?
I hope it is not the same change that is being opened.
Can you please check this and keep us posted?
1 of 1 people found this helpful
Could you pass the username and password along with the url, sample given below.
please let us know if it works.
1 of 1 people found this helpful
Passing a password in a URL violates just about every company security policy. Christopher can only complete the task with SSO Plugin, or a fixed user with a read only license, no privs (etc) to view the entry.
Karthick and John,
Thank you for your posts. You are both correct.
If a Username and Password is supplied, then the Lookup does indeed work correctly consistently, that is, a subsequent, different CRQ opens up the correct CRQ, not the previously opened CRQ.
However, as John noted, supplying a Username and Password is inconsistent with standard corporate security policy.
We do have access to a generic read-only Username and Password, however, at least at our installation, two different Users cannot be logged in at the same time; we get this message:
The following error(s) occurred while trying to process your request:
A current session exists for a different user - xxxxxx. Log off the existing session and try again.
Return to home page
This forces the User to logoff of the User's current Remedy session (using the User's personal Username), and then execute the lookup again which is impractical.
Ideally, it would be preferential to:
not have to supply any Username and Password with the url, and
not have to go through the login process again, especially if the User is already logged in, and
even if the User has to login again (typically on another IE Tab), the correct CRQ/INC/ISR/WRK item is displayed.
For some reason, the Lookup process gets lost or confused if the Username and Password is not included with the url.
Is it possible for the Remedy system to more effectively use the User’s current Remedy session credentials?
Thank you and Regards,
I would expect the URL, without a username and password, to correct load the CR/INC as expected if the user has already logged into Mid Tier in their browser. However, I guess that permissions could be a problem, ie a user does not have permission to view another incident? But that shouldn't manifest itself in a login screen.
1. To prevent A current session exists for a different user - xxxxxx.
you could create a user with restricted read license.. even a fixed license with admin access also works, but its dangerous to have an admin account for this purpose.
2. Is it possible for the Remedy system to more effectively use the User’s current Remedy session credentials?
Currently, for email ticket creation, there is a concept of using security key(which can be passed instead of user name and password). Check with the BMC support if they have any similar solution for url's as well.
Also, in browser settings there is a setting to remember passwords for site, enable that and run the url again.
w/r/t Point 1: We already do have a User with generic read-only access, and yet we still get the ARERR  message.
w/r/t Point 2: I will have to check with BMC and our internal IE Support Personnel.
- Still, I'm wondering: why would the URL work sometimes *without* the Username and Password? or in other words, why would supplying the Username and Password provide certainty on the search?
- You can tell from the screenshots' URL line that the correct CRQ is being requested. It's only after logging in that the request gets lost somehow.
- And in terms of credentials, I'm already logged in on another IE Tab, and by logging in again, I would think the correct credentials would be supplied yet again.
User a "restricted-read" instead of a "read-only".
Also, try the same with a different browser(firefox) and chk the outcome.
We do not have a "restricted-read" Username set up ... I'm wondering if you know this would work ...
- or if you yourself have a "restricted-read" Username, or if someone in the community has one, I wonder if you could try it with the hotlink and let us know the results? It would help in our business case justification in creating one.
Thank you and regards,