Marcus Nordlund Developer

In codeunit 149005 "BCPT Line" , there is the function:

 internal procedure AddLogEntry(var BCPTLine: Record "BCPT Line"; Operation: Text; ExecutionSuccess: Boolean; Message: Text; NumSQLStatements: Integer; StartTime: DateTime; EndTime: Datetime)

I would like that we put a handled integration event in the beginning of this function.

OnBeforeAddLogEntry(BCPTLine, Operation, ExecutionSuccess, Message, handled);

    if Handled then

      exit;

Code:

  [IntegrationEvent(false, false)]

  local procedure OnBeforeSendSuccessEmail(ActionEventSubscriber: Record "NBAAEM Action Event Subscriber"; var Handled: Boolean)

  begin

  end;

Reason:

Many of us run BCPT flow with random data to get a better representation of the data that is used.

The problem with doing that is sometimes some items/customers/vendors have very special setting that makes a confirmation or message popup. In order to tackle that we do message/confirmation handlers.

But since this does not always occur we get an error for every time we didn't use the handler. An event like this can give us the possibility to skip that error if we want it.

I have seen some argument that is up to the developer to create clean test cases where the handlers are always used. To some extent that is valid. But the other side of the coin is that we have to do a lot of code cloning to make those test distinct. But the worst part is that will pollute the the actual performance test. Because now we have to filter out the records which has these particular settings. Settings that wasn't meant to be filtered upon. This will lead to that the slowest functions are those that prepares the data in the test and that makes the performance test quite useless since we can't measure the realistic flows.

1. Issue

When you modify symbols (add/delete) in .alpackages folder the AL Explorer doesn't update which can lead to confusement since the developer thinks that AL exlorer shows the CURRENT Symbols in the .alpackage folder.

2. To Reproduce

Steps to reproduce the behavior:

1. Delete all symbols in .alpackages
2. Download symbols (AL: Download Symbol) from environment (ex. Prod) that contains dependency symbols ( I did this for an OnPrem installation but it shouldn't matter).
3. Restart Visual Studio code
4. Let it build environment
5. Open AL Explorer, go to a source code for an object that you have changed in the second environment.
6. Delete all symbols in .alpackages
7. Download symbols from second environment (dev) where you have made changes to the object
8. Open AL Explorer and go to the source of the object and it still shows the source for the object in the first environment

3. Expected/wanted behavior

I would expect that AL Explorer reindexes the symbols once there are file changes the .alpackages folder or AT LEAST reindexes the symbols when it runs AL: Download Symbols

4. Actual behavior

AL Explorer caches/indexes the source code when the repo is opened and it doesn't get refreshed when you choose AL Download Symbols OR do updates to the folder.

Before tri-state locking we could trouble shoot lock timeouts via telemetry by combining events 'RT0012 - Database lock timeout' and 'RT0013 - Database lock snapshot'.

When we do this we get the information from the victim process and the blocker/perpetrator process.

The information contains the AL-stacktrace which we can act on.

Now with Tri-State Locking we get considerably lower lock timeouts than before BUT we also get less information once the lock timeouts occur.

For example last 1,5 month with our customer with ~600 users we got 1204 lock timeouts but only 389, 30% of them contained stack trace from the blocker!

It is very frustrating for both us and the customer that we can't see what is causing 70% of the lock timeouts.

A suggestion in yammer (https://www.yammer.com/dynamicsnavdev/threads/3284151762870272) is that you should add the sqlServerSessionId or, even better transactionId to telemetry event 'RT0005 - Operation exceeded time threshold (SQL query)' and make sure these exists in RT0012|RT0013 so we can better troubleshoot what is going on when a Lock Timeout occurs.