Hello,

We have an interface to an external system. Every change on the customer table and its related tables (Baan V) are to be posted to the interface-table, with a new sequencenumber.

In the DAL of tccom112, in the after.save, we made sure data is written in the interface.

The problem is the following:
DAL tdsls400 (sales order headers) makes update to tccom112 (when for instance the discount perc. is changed). tccom112 calls the interface dll. The interface routine generated a first free number (tcmcs.dll0050....).
Because the first free number generation routine causes a commit.transaction, the lock on tdsls400 is removed, causing an error 206 (record not locked) after the before.save.object hook of tdsls400.

I had the idea, of writing all business partner numbers in an array and save them at the moment the dal tccom112 is terminated. But what event (hook)should I use? Since the tcmcs0050 uses a "normal" commit.transaction, the after.commit.transaction hook of tccom112 is not called. After.program is not recognised in a dal. I need the counterpart of before.open.object.set!! (or the hook for after.program)

Did you try to use -

after.update.db.commit:
Use this section to program actions that must be executed immediately after a commit.transaction() call, if the database is updated.

after.update.db.commit is for use in a programmscript, I am talking about the DAL.

May be this can help you

Syntax

function extern void after.commit.transaction()

Description

Use this to update other database tables after an update of the current table has been committed to the database.
This object hook replaces the after.update.db.commit event section in a UI script. If there is a DAL for an object set, this hook is called to perform the required actions. Any after.update.db.commit sections in the UI script are ignored. So, if a UI script contains a after.update.db.commit section for the main table, you must replace it by an after.commit.transaction() hooks in the DAL.

This hook is called only by the STP and CDAS. It is not called by Data Access Methods or commit.transaction().

tcmcsdll0050 does not use commit.transaction itself. It uses a separate 3gl program (tcmcs0250) to update and commit the first free number. Locks in the main process (such as the lock on tdsls400) are not removed with this construction.

My conclusion is that dll tcmcsdll0050 is not causing the error 206.
The problems is somewhere else.
May be you can post your code?

I use the Function tcmcs.dll0050.check.and.generate.order.number. This calls tcmcs.dll0050.fix.default.number, which makes a commit.transaction.

Or should I use another function in tcmcs.dll0050? rewrite.first.free.number? Perhaps the external script you referred to is only used when using cached first free numbers?

@v_chandra: as you wrote:
"This hook is called only by the STP and CDAS. It is not called by Data Access Methods or commit.transaction()."

That's the problem...

Perhaps the external script you referred to is only used when using cached first free numbers?
Indeed, that's true.
However, when not using the cached first free numbers, only a db.update on tcmcs050 is done. NO commit.transaction in the dll!

The problem is somewhere else.

I searched a moment how tdsls400 updates tccom112.
In dal tdsls400 - before.save.object, tdsls.dll4000.rewrite.bp.balance is called.
That dll calls dal of tccom113 to update the customer balance.
In dal tccom113, tccom112 is updated (field tccom112.hcru).

In this whole process, no commit.transaction is used.
Instead, the 4GL engine handles the commits.

By the way: why are you using an array, to store all the changes. Why not directly update, the interface table?

It is correct the way you describe it. The modification I made, is in DAL tccom112. In this DAL, in after.save.object, the modifications are written to the interface. The interface uses a table with a sequencenumber, which is generated using tcmcs.dll0050. As described previously, tcmcs.dll0050 makes a commit, and this commit also commits any changes to tdsls400 and removes the lock, causing the (stp) commit.transaction on tdsls400 to try to update a Record that is not locked anymore:

Data changed in tdsls400 with Gen.Table.Maint. => Changes made to data in tccom113 by DAL-Functionality => Changes made to data in tccom112 by DAL-Functionality => tccom112 after.save=> [Customising] write to interface => tcmcs0050.check.and.generate.order.number(..) => calls tcmcs.dll0050.fix.default.number(..) which commits(!) [end customizing] => tdsls400.after.save => after leaving tdsls400 after.save, the error occurs.

Thanks for your quick replies!!

The array I used, was because it would help if I could write the interface table at the moment tccom112 DAL is being closed, because then the commit does not interfere with the tdsls400 commit. But I do not know the correct event for this. It was a workaround I tried, but without success.

I'm confused. :(
did you add a commit.transaction to tcmcs.dll0050?
Can you give the code where the commit is done?

Let me add something.

In multiple dal's (tdsls400, tdpur400 etc. etc.), in before.save.object, the same call to tcmcsdll0050 is used. And that is working fine for years already.

You use the same construction. So, it should be possible to use that dll. Furthermore, I searched for a commit.transaction in the dll. But there is no one.

So, that's why I think the problem is not in dll tcmcsdll0050.

I'm not supprised you are confused, so am I right now...

I relooked at the code, and noticed that I am entering tcmcs0050.check.and.generate.order.number with action=check.and.generate, NOT with generate only. In this case, as you said, no commit is being done, where "only.generate" makes a commit in fix.default.number.
So the problem, as you stated previously, is definitely not in the first free number part, I'll have to look into the rest of the interface to see what's going on there. It must be something in the interface, since as I removed the call to write interface data, no problem occurred.

Thank's for your help, I'll get back to it when I located the problem.

How about you post us your code; like this we all can have a look and maybe help locating the error.