Solved

process flow : stored procedure : sp_wf_rule_state_all

  • 7 March 2024
  • 4 replies
  • 50 views
athobie
Rank
Userlevel 4
Badge +11

Hi,

All Process flow in a environment don’t work. (before they work well)

We have this error in the windows logs :  

Error in DBAdapter.ExecuteNonQuery: The EXECUTE permission was denied on the object 'sp_wf_rule_state_all', database 'SX-INT-DEMO15', schema 'dbo'.

We give access to this stored procedure, but then we have this message :

Error in DBAdapter.ExecuteNonQuery: Cannot find the object 'sp_wf_rule_state_all', because it does not exist or you do not have permission.

 


Could you explain the meaning of this message or the resolution method ?

thanks and regards

icon

Best answer by Phil Seifert 8 March 2024, 08:54

View original

4 replies

Phil Seifert
Rank
Userlevel 7
Badge +21

Hi Anthony,

First, I would check the various settings for the properties of this stored procedure in the affected database.  For example, for a customer who has SU7, I have the following:

 

(no extended properties)

I guess the question is whether the account calling for this stored procedure is a member of the sealgroup in my case it should be the AsteaUser

 

Phil Seifert
Rank
Userlevel 7
Badge +21

Also, as a sanity check… restart the Workflow Task Executor Service and Astea Workflow Time Event Service.

athobie
Rank
Userlevel 4
Badge +11

Hi @Phil Seifert 

Thanks for your explanation.
We made this checks (grant access, restart services) yesterday and it was the same.

Is it possible that we have some changes in the SU7 to manage the process flow ?
(it’s strange because all PF worked well before)


Finally to resolve the issue, we changed the sql account to connect to the database, but we didn’t know the root cause.

Thanks and Regards

anthony
 

Phil Seifert
Rank
Userlevel 7
Badge +21

Hi Anthony,

This sounds like it was not an Alliance issue as much as SQL DB administration.  SU7 does not have anything which would modify permissions on the DB for a connection user.  It can only use the user defined by the connection string used.  Plus we have other environments running SU7 not having issues with the Process Flows so not likely SU7 resulted in this issue.

The mere fact you changed the user connecting to the DB indicates this was an issue at a lower level than just running the process flows which can only run on top in the application layer. Further, if there was a general problem with the user account connecting to the database, you would have much more problems than just the process flows in the application.

I am happy to hear you did find a way forward but can't really tell you what happened either.

Reply


Terms & ConditionsCookie settings