rajbhan
14th April 2008, 12:35
I have written a dll which contains a function to insert record in a temporary table,read the record,return the column value to progarm script and immediately delete the record from the temporary table.I am using no db.retry point at the top of the function and issuing only one commit.transaction after the record is being deleted from temp table.This dll is being called from various sections of program scripts incuding before.write or before.rewrite sections.So I have a parameter being passed to this dll indicating whether I must commit in the dll or not.

Now before saving a record from the main session(single occurance + main,main table tdsls909) this dll gets called from when.field.changes section and then from before.display section of a particular display field.

I have tried all combinations of my commit parameter for the above two calls so that the commit.transaction in the dll does not interfere with the commit.transaction of the std program.But still I get either error message "Transaction is on" in the before.choice sub-section of "choice.update.db" section or Error message "Error 206,Record is not locked on table tdsls909 in db_update" in the before.rewrite sub-section.

Is there any method I can successfully call the dll function from when.field.changes and before .display section and getting the record saved in the database without getting the error messages.Urgent help will be appreciated.Please find enclosed the dll and program script.

Thanks
Rajbhan

rahul.kolhe22
15th April 2008, 13:14
Hi,
Will u please tell what r u trying to do in the function tccomdllc003.decrypt.ccno written in dll.

baan1612
15th April 2008, 14:26
Hi,normally you get the error transaction is on when you dont commit in your dll and commit in your calling session and error206 when a commit has already taken place in the dll and you commit again in your calling session but it can't lock the record.Ideally the updates other than main table should be made in the 'after.update.db.commit' section of the program if thats possible in your case.

baan1612
15th April 2008, 14:30
And one thing more that you need to have a retry point when you update in the before.display section but not in the before.write/rewrite section but im not sure for the when.field.changes section..just try to shuffle with this.

rajbhan
16th April 2008, 06:56
In the dll I am inserting a record on a temporary table on which a trigger has been written at the database level which decrypts an encrypted credit card number passed to it by the client.I read this decrypted card number from the inserted record in the temporary table and delete the record from the table immediately thereafter.This decrypted credit card no. is then returned from the function to the calling program script.
This decryption function needs to be called from various places in the program script whereever decrypted value of credit card no. is to be used

rajbhan
16th April 2008, 07:00
My requirement is such that the function in the dll needs to be called from various sections in the program scripts such as when.field.changes,check.input,before.display etc.So it is not possible for me to to move the updates in after.update.commit section

manojsharma
16th April 2008, 07:17
Hi,

Can you please check the value of flag.commit...........

pvandyk
22nd April 2008, 00:33
Consider converting your DLL to a 3GL. In a sense it is a step "backwards" but it resolves your bshell issue. It doesn't seem to me that a DLL's primary function of easy re-usability is what you really need. A 3GL program's independence could be worth the extra hassle in this case.

As you know, your challenge is that a DLL call is included in the bshell process of the parent, calling session. Therefore, any commit in a DLL, unless the function is called in the after.update.db.commit as someone said earlier, has the potential to cause this kind of trouble.

A 3GL program - or even a subsession if you don't mind the extra overhead - will have its own bshell process, so the db.update, db.delete, and commit will be outside the parent session's bshell process and will not cause trouble to the parent session's Retry and Commit structure. You would need to use imports rather than passing values, but I think that could work for you.

With Regards,
pvandyk