outra9e
21st August 2002, 17:10
Hi guys

I have a session, and when a record is saved, if I then go back and try to update a field I get the attached error message and the session closes.

Can anyone shed any light?

Cheers

jaapzwaan
21st August 2002, 17:51
Hi,

You get this error if you're trying to update (db.update) a record which is not read for update. You should do a "SELECT....FOR UPDATE" in stead of a simple "SELECT"

Regards,
Jaap

outra9e
21st August 2002, 17:53
Hi

I have no scripting donw on this field.

Should I add a field section in the script for this field? and if so, what scripting should I be putting in?

Cheers

nick_rogers
21st August 2002, 22:20
is the session a Baan standard session ? or something you created or customized the Baan standard session ?

morpheus
22nd August 2002, 08:07
Hello,
There is no need of adding any field section. There seems to be some problem with the syntax. Check the select statement, under which you are using the update function. It should be -

SELECT ............
FROM ......... FOR UPDATE
..........

Hope this helps.

morpheus
22nd August 2002, 08:10
Also, check whether you are using db.retry.point() before selecting the records.

outra9e
22nd August 2002, 10:41
I haven't got a select statement on this field.

I do use a db retry when I use the first free number funcion, but this first free number function is on a different field....

Here is some of the scripting, but as I say, I haven't done any scripting relating to the field which it will not let me update.

Cheers

|**************** field section **********************

field.tdsls901.bncdr:
before.input:
if update.status = add.set then
attr.input = false
endif
check.input:
check.first.free.number()

|******************* main table i/o section ***********

main.table.io:
before.write:
get.first.free.number()
before.delete:
skip.io("tdsls90002")

|*************** function section ***************

functions:

function check.first.free.number()
{
db.retry.point()
select tdsls901.bncdr
from tdsls901
where tdsls901.bncdr = :tdsls901.bncdr
selectdo
tdsls901.bncdr = tdsls900.number + 1
tdsls900.number = tdsls900.number + 1
commit.transaction()
endselect

}

function get.first.free.number()
{
db.retry.point()
select tdsls900.*
from tdsls900 for update
where tdsls900.constant = 1
selectdo
tdsls901.bncdr = tdsls900.number + 1
tdsls900.number = tdsls900.number + 1
db.update(ttdsls900, db.retry)
commit.transaction()
endselect
}
**********************************************

klesch
22nd August 2002, 10:57
You should not use commit.transaction() in main.table.io section. With other words: remove commit.transaction() from check.first.free.number().

outra9e
22nd August 2002, 11:17
Im sorry maybe I am being silly, I don't understand what you mean...

Could you show me where I am puting this in the code, and will it affect my first free number process at all?

Cheers

jaapzwaan
22nd August 2002, 11:23
Andy,

the function "check.first.free.number" opens and closes a database transaction (db.retry.point and commit.transaction),
whereas there is nothing written to the database, so remove these lines.

The function get.first.free.number does write to the database (db.update), but you want this update to be part of the bigger transaction of the main table write (right?). The 4GL engine (fka standard program) takes care of opening and closing this transaction, so the db.retry.point and commit transaction should be removed here as well.
for more information look here:http://www.baanboard.com/programmers_manual_baanerp_help_4gl_features_flow_of_standard_program

Regards,
Jaap Zwaan

morpheus
22nd August 2002, 11:27
Hello,
There seems to be some problem with the function check.first.free.number().
Are you trying to update the record in this table!? If yes, then where is FOR UPDATE clause for table tdsls901, and what about db.update for tdsls901!? If no, then why use db.retry.point() and commit.transaction()!?

Check out these things.

OmeLuuk
22nd August 2002, 13:12
You are in the main.table.io section, where the db.retry point is set in the STP, also the commit.transaction is handled in the STP. So you should not call a function where you use ...And continue reading again in this trhead: http://www.baanboard.com/baanboard/showthread.php?s=&threadid=5870&perpage=15&display=&highlight=commit.transaction&pagenumber=1

OmeLuuk
22nd August 2002, 13:22
|*************** function section ***************

functions:

function check.first.free.number()
{
| db.retry.point() |# Advised on baanboard
select tdsls901.bncdr
from tdsls901
where tdsls901.bncdr = :tdsls901.bncdr
selectdo
tdsls901.bncdr = tdsls900.number + 1
tdsls900.number = tdsls900.number + 1
| commit.transaction() |# Advised on baanboard
endselect
}

function get.first.free.number()
{
| db.retry.point() |# Advised on baanboard
select tdsls900.*
from tdsls900 for update
where tdsls900.constant = 1
selectdo
tdsls901.bncdr = tdsls900.number + 1
tdsls900.number = tdsls900.number + 1
db.update(ttdsls900, db.retry)
| commit.transaction() |# Advised on baanboard
endselect
}
**********************************************

outra9e
22nd August 2002, 16:25
Right guys

I have removed the db retry points and commit transactions and it is now letting me update that field, however when it updates and I save, it increases the number that was generated from the first free number session by 1. This then causes other problems, because if there is a sales order number <> 0 in the record, when it does this, it fails because u can only use a sales order number once.

How can I stop the first free number incrementing? I only want the record updated.

Any ideas?

Cheers

OmeLuuk
22nd August 2002, 16:38
check.input:
check.first.free.number()Make the number selection conditional... Have fun

outra9e
22nd August 2002, 16:45
Sorry if I seem silly, Omeluuk I do not understand what you are saying, why would I want to make the number selection conditional? I want Baan to just allow the user to update 1 field and not change the record. It is not performing a new insert so I do not understand why it is performing the function.

Do I need to add a condition to the main table i/o section telling it to skip i/o on an update?

Cheers

OmeLuuk
22nd August 2002, 17:27
Let me try to help you with my understanding:

You want to assign a free number each time you [ insert / modify ]* a [ new and/or existing ]* record.

The free number is generated at the moment the [ insert is done / insert is prepared ]*.

You [ do / do not ]* mind that numbers are not successive, especially when more than once a record is prepared, but not saved for some reason.

You [ do / do not ]* want to use the standard program transaction to perform the complete update transaction in one go (or not at all when any part fails).

* = underline correct answer

You understand the concept what went wrong in your programming in the past? It was like this, read it like a SQL statement:select * from table_1 for update where 1=1 | @1
selectdo table_1.a = table_1.a + 1
select * from table_1 for update where 1=1 |#1
selectdo table_1.a = table_1.a + 2
endselect | #2
selectdo table_1.a = table_1.a + 3
endselect | @2use this legend:
select * for update = db.retry.point() = begin of transaction
endselect = commit.transaction = end of transaction
@ means STP transaction
# means your own transaction

Now since you want all to happen between the @1 and @2 (yes there is code outside that transaction possible too), and nothing in separate transactions outside that main transaction (and certainly not as encapsulated transactions like #1 and #2 in the past).

What I meant with a conditional number: You do want only numbers to be generated when an insert is done? You do want no numbers to be taken when the record is modified without saving? What needs to be done when you press the Undo button? What if a user changes the data before they are saved, you want no other number than the previous already given but also not yet saved number?

You will need to think these scenarios over and then determine how you are going to code things.

ulrich.fuchs
22nd August 2002, 17:48
As for updating the first free number:
Baan standard sessions normally behave the way that the number is incremented AFTER the user saves the record. (That is: in the before.write subsection of the main.table.io.section). The user does not see which number will get assigned to it's record until he/she saves it (otherwise two concurrent users could get the same number or you get gaps in the numbers). That's perfectly normal for systems that have to handle a lot of concurrent users. So remove that check.free.number from the after.input.

As for the original problem with the commit.transaction():
(by the way, please keep the threads clean and open a new thread for a different subject...)

Check this out: It's the flow of standard program, and it gives you a very good advice when then Baan standard program does it's commit transaction. (Look for the "on.update.db()" pseudo code on that page:

http://www.baanboard.com/programmers_manual_baanerp_help_4gl_features_flow_of_standard_program

You will notice a db.retry.point, some section names and a commit.transaction here.

You may not interfere with that. So, in a section within that standard program transaction you may not use commit.transaction(), because the standard programm still want's to call it. In section outside of that standard programs transaction you have to do the commit.transaction for yourself, otherwise your record doesn't get updated.


Uli

outra9e
22nd August 2002, 17:48
Omeluuk...

The first free number function should only happen when a new record is inserted.

The first free number function only happens on a save (before.write).

Therefore what I essentially need to know is how to make that before.write conditional, eg when I am updating the record with an entry into the one field, I do not want the first free number function to happen, because the record already exists and all I am doing is modifying it. The first free number in this instance should not happen, because that record already has had the first free number assigned to it.

Incidently, removing the db retry points and commit transactions, caused an error of "record already exists" when I tried to enter a new record, so I have had to put them back in.

Thank you for your time on this.

Cheers

outra9e
22nd August 2002, 17:57
Ulrich

Thank you for this...

So, I have a...

main.table.io:
before.write:
get.first.free.number()


If I add this...

main.table.io:
before.write:
If not update.db() then get.first.free.number()
end if

Would this stop the first free number function from running when I update a record?

Incidently, I do not quite understand about not using commit.transaction, my session only seems to work correctly if I have that in place.

Maybe I am missing something very simple, but if it was a problem to have the db retry points and commit transactions where I do then I do not understand why mysession only works if I have them there?

Thanks once again

OmeLuuk
23rd August 2002, 09:39
:confused:... so I have had to put them back in. :eek: this is wrong, as of displayed before...
From several sides you have been explained why this cannot be done.

You may need to use the standard variable choice (command ID of active command) to call the function to pick a new ffno only when choice = 14 (see http://www.baanboard.com/programmers_manual_baanerp_help_4gl_features_4gl_choice_sections for all options). And there may be other ways to achieve your goal.

If you make some kind of program diagram, you should be able to determine when the new number should be generated, and when not. Then you can use the method of stepwise refinement to drill down to the level of sections and statements. That would be a better approach than trail and error followed now.

As already told before, the normal first free number selection can be of use for you. Check out how that is done. If you cannot invent, just steal. In that manner small companies got big and rich.:D

As for me, I resign from this thread. :(

outra9e
23rd August 2002, 11:07
Omeluuk and everyone else...

Thank you for your time on this thread, I am sorry if I did not quite get the jist but I hope it hasn't wasted your time.

I have found a work around that will not cause me too many problems and in fact aids the control process.

Once again many thanks and apologies :(

OmeLuuk
23rd August 2002, 15:17
;)