PreInsert - why call it more than once?

[ccordes]

Hi Bruce,

My problem with the look-ups  turned out to be in the preinsert embeds.
Since I do some calculating and housekeeping there, my values were getting re-initialized because preinsert is getting called when p_stage = (Net:InsertRecord + NET:WEB:StagePre).
My question is now Shouldn't the stage get bumped up after the initial loading and priming? Or is there a reason I'm not seeing for re-priming the records after entry has started?

Another thought - is there a safer place to do the housekeeping?

Chris

[Bruce]

>> Or is there a reason I'm not seeing for re-priming the records after entry has started?

This is the bit I'm not being able to duplicate. Could you maybe add some priming to your example, and then show where this is being called multiple times?

cheers
Bruce

[ccordes]

I almost am thinking that I'm losing my grip. When I tried my test app, it didn't happen. Then switched it to call the form not popped up and then it gets called twice.
Turn on debugview.
From the opening browse click on a cart to add a line item. You will see preinsert get called.Then hit the lookup and select an item. You should see another call to preinsert.

In doing this I tried making my form open as a popup and I've run into another error - the form won't even load. I get just a blank orange rectangle. So I'm thinking either there is a size/timing limitation on the popup (This is a pretty large form) or I've got some other kooky problem in that form.

Thanks,
Chris

[attachment deleted by admin]

[ccordes]

Not sure why, but, the second PreInsert is on a separate thread.
It is as if the page gets called again after the inventory lookup is called but it is on a different thread.
THAT is why I can't pin down where the change is occurring - because the second thread does a filetosessionqueue(Orders) and it is pretty random as to when it hits.

I'm pretty sure this isn't my code doing this, but the example seems to work. The example form has only 3 fields and 1 look-up where as my form has 2 lookups, a dropdown that is dependent on the second look-up, 50 fields on 2 tabs.

So while my form is doing its update stuff after the lookup, the extra thread is restarting the form on the same session id depending on the speed of the two threads, the orders buffer gets cleared at varying times.

I'm not sure that the example app would show this behavior if I put my Trace statements in.
Maybe safer to go back to 5... arghhh

[ccordes]

I seem to be talking to myself <he he he> I'm doing that alot the past couple of days.

The issue of the second PreInsert does show up in the example - Flat form with a pop-up look-up browse.
The problem of the values not holding up is only a problem if you are updating other values in your form.
The second Pre Insert is on a separate thread but uses the same session id. That means it grabs an empty instance of the table being updated and then does a FiletoSessionQ which is what does the damage.

I have attached a text file that has a debugview trace with comments to show what is going on.

This seems a little serious but I haven't been able to trace out where that second thread is getting started.
I will put my Trace statements in the example and post that if it shows anything interesting.

Chris

[attachment deleted by admin]

[ccordes]

Here is example 25 with the traces in places to show off what is happening.
On the linitem entry form I added a tab to display the session Queue values. They update when you pick an item and update again when you change the quantity. this gives time for them to display and then redisplay after the second thread clears them.

It goes by pretty quickly. You can also just enter an item id in the field and hit tab. That will display the sessionQ values. Than select one from the look up.

Chris

[attachment deleted by admin]

[Bruce]

thanks for the example Chris - I'll look into it.

cheers
Bruce

[ccordes]

Thanks, Bruce.
What I'd like to know as soon as you can is if you can duplicate it or if it is something screwy on my system.

Chris

[ccordes]

Ok. I've reverted to 5.37, ran the example and it looked like I was getting the same results. Then I rebuilt my app and it worked. Not really a surprise but I watched the debugview trace and the extra thread is still starting only that in 5, the thread starts at the INIT stage and not StagePre.
I have included the debug trace txt and comments.
I'm not sure where the extra thread starts, so I can't tell how it's stage is set. I'm sure you know and and can set it to init.

I hope this sheds some light on this.

Chris


[attachment deleted by admin]

[Bruce]

Unfortunately Chris I'm not getting the effect you're seeing.
However your example seemed to be "incomplete" - it had a different dictionary name to the app, and some data files were missing.

Also I'm using 6.09 here, so perhaps try with that when it's available and see if you get a different effect.

I've also updated the example 25 a bit so it's NT6 friendly (changed menu, divs on header & footer etc.)

cheers
Bruce

[ccordes]

Do you mean that you don't see the extra threads reloading the form, or you don't see the session values being cleared?
 I used your app and dictionary names and added cs to the front.
Should be csweb25.app, csinvoice.dct and a cslineitem.tps.
Did it not compile?
You will need to unzip it into your ...Web Server\ParentChildBrowse (25) folder. or a copy of that. Sorry for not mentioning that before.

Chris

[Bruce]

I was looking primarily for multiple calls to Pre-Insert which I couldn't see at all.
However I think possibly the "More Values" settings were not being set - that's something that got fixed in 6.09 - so maybe try with that (it's up now) and see if you still have a problem?

cheers
Bruce

[ccordes]

Did you look in code or debugveiw for the multiple calls?
They are easy to see in debugview, just watch the thread #'s prior to and after a lookup.
What is seeming to make the real difference is the stage being used when the second thread opens.