Hello,

I have a multi-occ session with code on the main.io: before.write: and when I click on the button insert, the code never gets executed at all. In the before.write, I have a seqn+1 for my new record be different, so, I get "Record already exist".

The extrange thing is that it was working before...

Any ideas?

Thanks,

Working before what? Was there a change of some sort or did it just stop working? My question is - do you check the database or just the current seqn+1? I found early on that as the user moves through the screen I have to do 2 checks - first the database and then the screen. For example - if there are 3 screens of records on a multi-occ session and on the first screen the user hit inserts, the current sequence is not the highest - so I go to the database, get last sequence+1. Then when they go to the second record(hit insert once) the last sequence is on the current form and not written to the database. So the question is - are you sure that seqn has the largest (or last) used seqn?

I will look for a code example.

I am not sure this helps, but this is typically how we do something like this:

field.tdcyc010.locf:
before.input:
if update.status = add.set then
read.serial.number()
search.last.used.seqn.on.screen()
tdcyc010.sern = serial.number + 1
display("tdcyc010.sern")
refresh()
update.occ()
endif



function read.serial.number()
{
serial.number = 0
select max(tdcyc010.sern):serial.number
from tdcyc010
where tdcyc010._index1 = {:tdcyc010.cycg,:tdcyc010.cwaf, :tdcyc010.cwat }
as set with 1 rows
selectdo
endselect
}
function search.last.used.seqn.on.screen()
{
for occ.no = 1 to (filled.occ - 1)
do.occ(occ.no,check.last.used.sern)
endfor
}

function check.last.used.sern()
{
if tdcyc010.sern > serial.number then
serial.number = tdcyc010.sern
endif
}



In this example sern is first display field on multi-occurence record with locf being the first true input field. When the user hits the insert button this if statement gets executed and the sern field is display right before first input field. We have multiple variations on this in different events - this was just the first example I found grep'ing sern.

Hello,

I have a multi-occ session with code on the main.io: before.write: and when I click on the button insert, the code never gets executed at all. In the before.write, I have a seqn+1 for my new record be different, so, I get "Record already exist".

The extrange thing is that it was working before...

Any ideas?

Thanks,

Hi,
I am not sure how it worked before. But to my understanding, the subsections like before.write of before.rewrite will be executed when you click "Save" button, and not when "Insert" button is clicked.

In order to increase serial number, before.input is the correct subsection to place your code. I think code posted by Mark can help you in that case.



Regards

Hello,

this is my code. Yes, when I clicked on save the code was executed then new srnb was displayed to my new record occurrance. Now this code is not executed. What I just found, I did a test with a different Purchase Order Line and does work! When I click on save, it goes trought the code.

Session has only one form with data.

|****************************** MAIN TABLE SECTION ***************************
main.table.io:
before.write:
if quantity.allowed() then
get.next.srnb()
else
skip.io("tcmcsd0005",1)
endif

function get.next.srnb()
{
tdpur987.srnb = 0
select a.srnb:tdpur987.srnb
from tdpur987 a
where a._index1 = {:tdpur987.orno,:tdpur987.pono}
selectdo
endselect
tdpur987.srnb = tdpur987.srnb + 1
if strip$(tdpur987.lino) = "Requested" and tdpur987.srnb > 1 then
tdpur987.lino = strip$(tdpur987.lino)&str$(tdpur987.srnb)
endif
}

Thanks again.

What is the primary index(or index1) on tdpur987?

Maybe I don't understand the code - but if the user enters 2 records and hits save and then both have quantity allowed true - wouldn't this routine return the same srnb for both user input records? And then you would get the record already exists error. I thought (and maybe I am wrong) that when you hit save all records are committed at one time. Not committed one record at a time, but one commit for all records. So the query to return the srnb would find the same max number +1 for the new srnb.