Transact SubRoutine

OPTO_Shane · 5:06AM

Hi Everyone,

We’ve recently begun seeing SYS1000 errors in the RTP27 OI procedure when calling the Transact subroutine.
This issue has started occurring suddenly on a few sites that previously had no problems executing this code.
The Transact call is implemented according to documentation, so we believe programmer error can be ruled out.

We traced the issue to the FS variable being blank after the DELETE() function call in the Frameworks procedure
Audit_Manager_MFS. The snippet is below (we’ve added the IF LEN() check ourselves as a temporary safeguard):


Remove_Arev_Table_Name:
  FileName = Field(HANDLE, @TM, 1)
  Real_Handle = Field(HANDLE, @TM, 2)
  FS = DELETE(BFS, 1, 1, 1)
  NEXTFS = FS<1, 1, 1>
  @FILE.ERROR = ""
  If len(NEXTFS) then
    CALL @NEXTFS(CODE, FS, Real_Handle, NAME, FMC, RECORD, STATUS)
  end  
return

Our question is:

Is FS being blank after DELETE() indicative of an underlying issue in the environment or data, and something that warrants deeper investigation?

Or would it be reasonable to leave the IF LEN() guard in place and move on with our lives?

Any insights or experiences with similar issues would be greatly appreciated.

Kind Regards,
Shane

DonBakke · 5:22AM

Shane - If FS is empty (or "blank" to use your terminology) then a SYS1000 error is definitely expected. The actual error would be:

The Len() is a good safeguard, but it is masking the underlying problem: FS should not be blank. You noted that this happens when calling the Transact subroutine. This could be the source of the interference. The Transact subroutine temporarily adds the PROTECT.MFS to the table that is being managed via transaction processing. I wonder if this is confusing the Audit_Manager_MFS.

OPTO_Shane · 7:26AM

Hi Don.

Thanks for your quick reply. We've just realized after a bit of MFS research that it won't be an option to add our "if len()" as it will always hit the Frameworks MFS fist.

Do you have any insight as to what could be installing the Audit_Manager_MFS on the tables dynamically? We've done some tracing through a working system and we don't even enter Audit_Manager_MFS there. The MFS is also absent from the SYSTABLES records and we haven't installed the MFS manually through DBW_AUDIT_MANAGER.

The problem systems are hitting OMNI.SCRIPT in particular if that rings any bells?

Kind Regards
Shane

DonBakke · 11:34AM

Hi Shane.

I have no idea what is happening. Nothing in FrameWorks that I'm aware of would dynamically add that MFS. OMNI.SCRIPT is a special MFS primitive that must be called directly, which means it isn't something that OpenInsight would normally call in any of its regular transactional actions.

I gather from your comment that you aren't even using the Audit Manager. It was a good idea for you to check SYSTABLES, but you might also want to look at your DBT file and search for any reference to AUDIT_MANAGER_MFS. It might only appear at the end of the file and not be linked to any specific table. If so, then it will get called when your application starts up.

Transact SubRoutine

Comments