Process Mapping Logo

Process Mapping - Forums

Sharing 19 years of knowledge and experience

 
Metastorm BPM forums
Sign up Latest Topics
 
 
 


Reply
  Author   Comment  
Rick

Avatar / Picture

Senior Veteran
Registered:
Posts: 259
Reply with quote  #1 
Hi,

This is a nasty problem in that it isn't clearly reported so it has been going on for a while without us noticing.

MBPM is on SQL Server. I have a user action which, on completion, should insert a record into an Oracle 11g database. I've got my connection set up and use it for select queries with no problem. I've got my valid insert statement and checked that it works outside of Metastorm.

When the user action is run it appears to complete successfully. The user thinks that the folder has been closed (it is the last action in the process). However, the action has not been committed; it has rolled-back and the user will later find the folder still sitting at the previous stage on their ToDo list.

Digging into the log reveals the following error message:

Description:Transaction was aborted due to query timeout


Has anyone come across this at all? Any suggestions on how to resolve it? I've unticked the 'Enable query timeout' option in the Oracle ODBC driver but this has made no difference.

Thanks,
Rick.

__________________

Another full day of doing nothing but rearranging zeros and ones. :)
You know it will be a good day when there is no human interaction on the schedule.

0
praxkan

Veteran
Registered:
Posts: 142
Reply with quote  #2 
Strangely enough we HAVE noticed this error, and similar behavior - on the designer !

"Deploy" seems to publish correctly to the engine (the code change is reflected in the engine context through portal), but write to eProcedure fails with a query timeout error. That means the retrieve next time around throws an error, even though you assume it worked because you see the changes through the portal [engine context].

0
Jerome

Avatar / Picture

Guru
Registered:
Posts: 5,507
Reply with quote  #3 
I certainly know that external database are nut under transaction control (as we had in v7), and even that the Metastorm database is not (although this may be foxed now). I think there are specific issues with ODBC connections as well. I'd go native if possible, although it means installing the Oracle client.
__________________
Post an example, and we will have a much better idea what the problem is. In about 90% of posts, the problem is one of communication. Examples bridge that gap.
0
Rick

Avatar / Picture

Senior Veteran
Registered:
Posts: 259
Reply with quote  #4 

Sorry to be thick, Jerome, but I don't understand what you mean.


__________________

Another full day of doing nothing but rearranging zeros and ones. :)
You know it will be a good day when there is no human interaction on the schedule.

0
Jerome

Avatar / Picture

Guru
Registered:
Posts: 5,507
Reply with quote  #5 
Ahem. Some 'helping' from my phone's auto-correct did not help either.

What I mean is that any SQL executes to any connection other than the default (aka, 'external database') does not come under the control of a single translation. Because if this, I believe it may not stop the action itself if the SQL execution fails (and vice-versa, see below). I believe this used to work properly in later versions of 7.5/6.

What is worse is that SQL failure within the Metastorm database (let alone external database) is no longer rolled back if an action fails. I believe this has been in place (the roll-back - ie all SQL is executed within a single transaction) from version 6.1.

It is not a good situation, but I do not know if it has been fixed. My load in reporting issues has increased to the point that I don't have any time to look at ones I know previously exist, but I will get around to them soon. I'll also post a list here for reference under 'faults'

__________________
Post an example, and we will have a much better idea what the problem is. In about 90% of posts, the problem is one of communication. Examples bridge that gap.
0
Rick

Avatar / Picture

Senior Veteran
Registered:
Posts: 259
Reply with quote  #6 

Sorry again, I didn't explain myself clearly. I understood the bit about not having proper transaction control. What I didn't understand was the reference to fixing the problem by 'going native'.

Will I have to wear a loin-cloth? ;-)


__________________

Another full day of doing nothing but rearranging zeros and ones. :)
You know it will be a good day when there is no human interaction on the schedule.

0
Jerome

Avatar / Picture

Guru
Registered:
Posts: 5,507
Reply with quote  #7 
using a native connection, not an ODBC one. To create a connection using a 'native' driver, you would need to install the Oracle Client and appropriate drivers, both on the development and engine machines.

Or .... you could start wearing a grass skirt, perhaps .... ?

__________________
Post an example, and we will have a much better idea what the problem is. In about 90% of posts, the problem is one of communication. Examples bridge that gap.
0
Rick

Avatar / Picture

Senior Veteran
Registered:
Posts: 259
Reply with quote  #8 
Thanks for the advice, Jerome. The connection using the Native driver works perfectly.

..... and the grass skirt is strangely - liberating....

;-)

__________________

Another full day of doing nothing but rearranging zeros and ones. :)
You know it will be a good day when there is no human interaction on the schedule.

0
Previous Topic | Next Topic
Print
Reply

Quick Navigation:


Create your own forum with Website Toolbox!