HI Sai,

I have a couple of suggestions....first is that a typo or is that the correct variable in the first screen shot as it says Req.fields(STATUT).  is that the correct name or should it be STATUS as in the second screen shot it is test.fields(CY_STATUS).  I would check that their spellings are indeed correct.   What can explain one possible issue is if these are in error, the system remembers where a user was at the last point in ALM and if the error was encountered then until the situation is cleared the user gets put back into that situation each successive log into ALM.  I have seen issues where this occurs and each successive log in after encountering the error have yielded the same results since the user was placed back at the same point and regenerates the error, but if able to navigate away from that situatuin, to say something like the defect module where the error isn't present in the code and they log out and back in they will not encounter the error again until they are back in the situation where the errant code exists.

The second thing I would suggest is to go into site admin, into the site projects tab, and select the project in question, run the maintenance routines:  right click and select maintenance>Verify Project and see if any issues are reported.  If all is good you can then right click the project and select maintenance>realign repository and see if that helps. I have had this correct issues in the past where added customizations and their dynamic and static pointers have gotten skewed and this realigns then and has fixed issues for the selected project as it only adjusts this particular project.  Remember it is always recommended to have a back up routine in place and to make sure backups of the project repository and the associated DB project schema before performing any maintenance as a precautionary measure.

Hope these suggestions help,

Dan

Hi @Dan,

Thanks a lot for your reply.

Actually, STATUT is a variable name and it stores the string value of Status field Labeled corresponding database column name. Same is the case with other variables defined in ModuleName_Fields(xxx) without parameters.

Please find below code:

Dim STATUT

STATUT = userfield("Status","REQ")

Function userfield(label,tablename)
  sql = "Select SF_COLUMN_NAME as thecolumn FROM SYSTEM_FIELD WHERE SF_USER_LABEL='" & label & "' "
  sql = sql & "AND SF_TABLE_NAME='" & tablename & "'"
  set req = requestRecordset(sql)
  if req.Recordcount > 0 then
    result = req.FieldValue("thecolumn")
  else
    msgbox "Error for the field " & label
    result=""
  end if
  userfield = result
end Function

We have noticed that by mistake someone changed value of DISABLE_COMMAND_INTERFACE  site admin parameter value from N to Y,So after changing DISABLE_COMMAND_INTERFACE  site admin parameter value from Y to N,  issue got resolved.

Setting DISABLE_COMMAND_INTERFACE   value to N means, all Non Admin users will be able to execute commands via Workflow without any issues just like Admin users.

Strange thing in my case is, when DISABLE_COMMAND_INTERFACE  parameter is Y,how come first user who logged in with non admin credentials able to execute workflow commands without any issue, and second user who is using same non admin credentials failed to execute SQL commands via workflow?

What would have caused this difference? Ideally both the first and second user who are using non admin credentials should have failed to execute the SQL commands in workflow script when DISABLE_COMMAND_INTERFACE  parameter is Y.

Please advise.

Regards,Srihari