Lockings with Messages!?!?!?!?!

Caffa

Ever heard of the followling......

To simplify the Warehouse process, I've made some customizations in which I've placed several standard functions after oneother...
From a Sales Order, with one push on the button you can create a Warehouse Shipment, release it, and place the Warehouse Shipment Lines in the Pick Worksheet. Simple as that....

But....

In this process various tables are locked, and released. Unfortunately, one lock still remains: The creation of the Whse. Shipment results in a message ("Whse. Shipment xxx has been created.").
As long as this message is on the screen, the Table Whse. Item Tracking Line remains Locked!!!!!!!!
How is this possible?!?!?!

We've even tried it with a COMMIT before this message, but the lock remains....

Marco_Ferrari

Just to be sure, have you tried to delete or comment the message? It seems strange to be the message the problem....

Marco

Caffa

Yep...

Well, I've set a HideDialog function to TRUE, so the message won't appear anymore. This solves the locking problem, but still..... How is it possible that this message creates this problem?!

DenSter

Because the message is part of the transaction, and the system won't close the transaction until the user clicks the message away. As you said 'simple as that'

btw, how are things in Rotjeknor these days? I used to live there...

Caffa

Well, we've even tried a COMMIT before the message......

Also, when the steps are called one by one, there will also appear messages, which DON'T lock the tables. So in these situations the Transactions are already closed BEFORE the messages are clicked away, I think.

I still say: A message should NEVER lock a table!!

pdj

I think the reason is due to a special (un-documented?) feature of OnRun in codeunits. Try making two codeunits:

Main codeunit:

OnRun()
IF CONFIRM('Use OnRun?') THEN BEGIN
  Sub.RUN;
  Sub.RUN;
END ELSE BEGIN
  Sub.Something;
  Sub.Something;
END;

Sub codeunit:

OnRun()
Something;

Something()
MESSAGE('hi');
BEEP(100,100);
SLEEP(1000);

When you execute the main codeunit you migth expect it to do exactly the same. But it doesn't! It does like this:

Yes: Beep, Message, Beep, Message
No: Beep, Beep, Message, Message

I guess this means you can solve your problem by stop using the default OnRun trigger, but instead move the code to a function and call that directly instead.

Caffa

mm.. strange. What do you think about the following....

Selection := STRMENU(Text000);

CASE Selection OF
  1:
    BEGIN
      SubFloop.RUN;
      SubFloop.RUN;
    END;
  2:
    BEGIN
      CODEUNIT.RUN(CODEUNIT::SubFloop);
      CODEUNIT.RUN(CODEUNIT::SubFloop);
    END;
  3:
    BEGIN
      SubFloop.FunctieFloop;
      SubFloop.FunctieFloop;
    END;
END;

(Where Text000 = 
  Use "Variabel.RUN",
  Use "Codeunit.RUN  (Codeunit::...)",
  Use "Variabel.Function")

Case 2 and 3 result in
BEEP,BEEP,Message,Message

While Case 1 results in
BEEP,Message,BEEP,Message

In my eyes defenitely NOT a feature, but a BUG!!!!!

PS: Pdj, thanks for your input!

DenSter

Caffa wrote:

Well, we've even tried a COMMIT before the message......

Also, when the steps are called one by one, there will also appear messages, which DON'T lock the tables. So in these situations the Transactions are already closed BEFORE the messages are clicked away, I think.

I still say: A message should NEVER lock a table!!

There's a difference between a message and an error. When you have a whole bunch of messages, Navision saves them up in memory and displays them in order after the transaction is done (unless you're debugging). So by the time you see the first message, Navision has already executed all the code in that transaction.

When you have an error, it stops code execution at the line of code with the error. Both of these mean that the current transaction is not completed yet, and all table locks will still be in effect. This is the way that it is implemented in Navision. You can disagree with it all you want, but it's not going to change it Maybe someone at Microsoft reads these posts and agrees with you and it will be changed in the next release.

pdj

DenSter> It seems you are missing the point. We are not talking about ERROR but the simple MESSAGE. Have you ever seen it documented that it can stop a transaction?

pdj

Caffa>
I just extended your code a bit to get all ways:

Selection := STRMENU(
  'Use "Variabel.RUN",'+
  'Use "Codeunit.RUN  (Codeunit::...)",'+
  'Use "Variabel.Function",'+
  'Use IF "Variabel.RUN" THEN,'+
  'Use IF CODEUNIT.RUN(CODEUNIT::SubFloop) THEN');

CASE Selection OF 
  1: 
    BEGIN 
      SubFloop.RUN; 
      SubFloop.RUN; 
    END; 
  2: 
    BEGIN 
      CODEUNIT.RUN(CODEUNIT::SubFloop);
      CODEUNIT.RUN(CODEUNIT::SubFloop);
    END; 
  3: 
    BEGIN 
      SubFloop.FunctieFloop; 
      SubFloop.FunctieFloop; 
    END; 
  4:
    BEGIN 
      IF SubFloop.RUN THEN;
      IF SubFloop.RUN THEN;
    END; 
  5:
    BEGIN 
      IF CODEUNIT.RUN(CODEUNIT::SubFloop) THEN;
      IF CODEUNIT.RUN(CODEUNIT::SubFloop) THEN;
    END; 
END;

Case 2 and 3 and 5 result in
BEEP,BEEP,Message,Message

While Case 1 and 4 results in
BEEP,Message,BEEP,Message

I agree that 1 and 4 should be considered a bug.

DenSter

pdj wrote:

DenSter> It seems you are missing the point. We are not talking about ERROR but the simple MESSAGE. Have you ever seen it documented that it can stop a transaction?

No, I'm not missing the point. I was just making sure we ARE talking about MESSAGE. Many users will use the word 'message' when inside the system it is an ERROR, and vice versa. I haven't seen any documentation about the blocking, but I know from experience that this happens sometimes.

By the way, I agree that it is strange that the system does it differently in all those different cases. To me it feels like some of it can be explained by the strange way Navision handles messages, but I would not know how exactly :oops:

DenSter

pdj wrote:

I agree that 1 and 4 should be considered a bug.

Let's back up here.....
The original code was:

MESSAGE('hi'); 
BEEP(100,100);

which means message first, and then after that a beep. So if I run this code twice in a row, I expect MESSAGE, BEEP, MESSAGE, BEEP

I would say that all reported cases are false.

pdj wrote:

Case 2 and 3 and 5 result in
BEEP,BEEP,Message,Message

While Case 1 and 4 results in
BEEP,Message,BEEP,Message

Am I losing my mind???? :shock:

RobertMo

actually:
cases 2,3,5: messages are buffered till the end. so that's way beep,beep,msg,msg

cases 1,4: first msg is buffered, then beep is heard, but just when it comes to second call of CU, the first msg is forced to be displayed, before the second call of CU is going to be executed. then the second msg is buffered and beep is heard. at the end bufferd msg (2nd) is displayed. ->beep,msg,beep,msg

obviously it has to do with CU when defined as variable and called with CU.RUN.

looks like the call of CU.RUN when CU defined as var forces msg buffer to clear before call...

pdj

DenSter wrote:

I would say that all reported cases are false.:

What do you mean by that?
I know that a "BEEP(100,100);" is pretty useless, but I use it instead of a db transaction. BEEPs are never buffered and are very suitable to simulate a transaction. You could try replacing the beep statement with

cust.find('-');
cust.modify;

If you then run the code you will notice that the cust table is locked until the message box is closed. (Try opening a second client on the same db and modify a cust) This was actually the original problem reported by Caffa.

DenSter wrote:

Am I losing my mind???? :shock:

I don't think so, but I can't give any promises 8)

Caffa

Well, I think DenSter IS losing his mind.....

By the way:

The problem DOESN'T occur in 2.60!!!!