{{tag>category:"OpenInsight 32-Bit" author:"John Bouley" author:"Gerald Lovel"}}

[[https://www.revelation.com/the-works|Join The Works program to have access to the most current content, and to be able to ask questions and get answers from Revelation staff and the Revelation community]]


==== OI Transact routines. (OpenInsight 32-Bit) ====
=== At 04 APR 2006 09:43:16AM John Bouley wrote: ===
 
 
<QUOTE>
I recently updated a posting routine to use the Transact sub in OI. My first problem was the TRANSACT volume was corrupt. Once I fixed that it actually worked but with some strange peculiarities.

First when I issue a Control_On(multiple_tables_@fm_delim,0) I receive a "SSP282" error "the table 'CUSTOMERS' does not have control features on". If I rerun the procedure it works correctly.

Second, if I open a CUSTOMER in another window which has a lock and run the posting routine which also obtains the lock and updates the record. With transact I am able to lock and update the same customer. Without transact the posting can not receive the lock.



Comments?

Thanks in advance,

John
</QUOTE>
----

=== At 04 APR 2006 09:55AM John Bouley wrote:  ===

<QUOTE>Ok, I think I solved the first problem. If I use control_on(...,1) and control_off(...,1) instead of control_on(...,0) & control_off(...,0) I dont receive the SSP error.



The record locking issue does remain.



Thank you,

John Bouley

</QUOTE>

----

=== At 04 APR 2006 10:27AM Gerald Lovel wrote:  ===

<QUOTE>John,

Are you using coordinated locking or exclusive locks?  If this doesn't cure the problem, drop me a line for alternatives.



Gerald

glovel@atlaswares.com

</QUOTE>

----

=== At 04 APR 2006 12:06PM John Bouley wrote:  ===

<QUOTE>Right... I am using exclusive... After further testing I found the problem only occurred when the record lock was being held by the same OI Engine. A user has a customer on their screen then they used the Window menu and decided to post a batch of Invoices containing that customer. If another user had the lock it was recognised.

</QUOTE>

----

=== At 05 APR 2006 10:48AM Gerald Lovel wrote:  ===

<QUOTE>John,



When executed for exclusive locks, the LOCK statement returns different status() values for locks by the same station or by other stations.  I can sort of understand why the CONTROL process may ignore locks held by the same station, as I ignore these locks in some of my own posting routines.  In other words, if a posting process is spawned from an entry window which holds a record lock, generally I want the posting to proceed without registering a lock error.



Could your posting process test for the customer record lock before starting the transaction, so that transaction control would not occur when the lock is present?  This might not work if your posting is executed in mfs context, of course.



And speaking of posting processes which execute in mfs context, you may wish to address me directly regarding alternatives to the CONTROL process which would provide transaction processing capabilities without these issues.  (I am just not able to get into all the details of such an alternative within the scope of this forum.)



Gerald

glovel@atlaswares.com



</QUOTE>


[[https://www.revelation.com/revweb/oecgi4p.php/O4W_HANDOFF?DESTN=O4W_RUN_FORM&INQID=WORKS_READ&SUMMARY=1&KEY=44A1B776E6AFBBCC85257146004B5F57|View this thread on the Works forum...]]