Mads Gram

Got the opportunity to go "under the hood" and provide some behind the scenes on how and why we have evolved AL over the years towards a more performant language. youtu.be/1xdpUmeun-s

If you are interested in writing performant AL code for Business Central, this is a great opportunity. You get a three for one deal here! AL code, compiler, and runtime experts in one session. As always when I'm involved, internals included! Wednesday at 14:00. #msdyn365bc

@KarolakNatalie We just fixed this, before it would loop forever. Found some tasks that had executed for more than 50k times.

Task scheduler learn.microsoft.com/en-us/dynamics… AL methods that throw nonretriable exceptions in background sessions #al-methods-that-throw-nonretriable-exceptions-in-background-sessions" target="_blank" rel="nofollow noopener">learn.microsoft.com/en-us/dynamics… Did you know? Stopping the main codeunit with Dialog.Error('') is considered a successful operation, so the failure codeunit isn't executed.

When to use scheduled tasks in AL: #when-to-use-scheduled-tasks-in-al" target="_blank" rel="nofollow noopener">learn.microsoft.com/en-us/dynamics…

@phenno1 @erpthoughts Yes, but also smart sql, where we merge the calcfields into the query. There was also some other scenarios regards table relations, but I cannot remember of the top of my head.

@PhDuck2 @erpthoughts I suppose you're talking on potential subsequent calcfields? Maybe I'm missing some other scenarios...

#bcalhelp, why does partial field feature load a number of added fields which I didn't mention in a code? Documentation says that it will load only PK, SystemId and audit fields learn.microsoft.com/en-us/dynamics…

@phenno1 @erpthoughts 2) To filter on flowfields, we might need the value of another field to be present. We could JIT load out when loading the flowfield. Both comes with trade-offs, eager adds a small extra cost (a few more fields) while JIT means it might fail due to the record having changed.

@phenno1 @erpthoughts 1) Please read the remarks part on the same docs. Which states the runtime might sometimes require more fields to be loaded. The full list depends on platform version.

@MansaYay @StefanMaron @waldo1001 The key element is what the NST does with tri-state: it places a READCOMMIITTED hint on the sql statement. How SQL server interprets that hint and executes it, that depends on your setup. With RCSI no shared locks are taken, relying on row versioning and snapshot info.

@StefanMaron @waldo1001 Just realized @PhDuck2 said ReadCommitted reads will use shared locks in the presentation but afaik that doesn't happen when reading with RCSI? Am I missing something or was this over-simplified in the presentation?

@waldo1001 🤔 ReadComitted is the recommended default!

@arthrvdv A succes metric for me is that people go away from the session with information enough to make an educated decision on that. I hope you will turn it on, but that is up to you to decide after. My blog post addresses it in a slightly more theoretical way: bcinternals.com/posts/tri-stat…

@PhDuck2 Looking forward to this session! It’s tempting to enable this in Feature Management today. For me, to be honest, quite difficult to understand the possible implications of this.

I would argue the perfect last session for your #BCTechDays conference is to join Torben Meyhoff and I, for our session: Tri-State Locking: Reducing locking in the runtime We will explain AL's locking scheme in-depth and explore recent improvements in the area.

@ajkauffmann @StefanMaron BC chaos mode? Sounds "fun".

Hmmm... Is this a new idea for BC? #BCTechDays

@erpthoughts The slide with lock escalation is even fixed this year :)

Unfortunately, I am not attending BC Tech Days this year, but this is definitely a session not to be missed.

@IAmRahulMathur @waldo1001 @ajkauffmann Lovely to hear! Please reach out if you find any issues with it :)

Very interesting session by @waldo1001 & @ajkauffmann where they talked about Tri-State locking. It’s a game changer. Time for some code refactoring ! #al #daysofknowledge #businesscentral

@KarolakNatalie I think you reading too much into it, "performed optimally" here doesn't have to refer to performance. It is non-optimal to read uncommitted when you anyways modify it just after. The modify may even fail if someone else inserted the row and don't end up committing the row.

@PhDuck2 Then the docs probably should not use "perform" here 🤷 learn.microsoft.com/en-us/dynamics…

#bcalhelp Performance question. MyRec.ReadIsolation := IsolationLevel::UpdLock; MyRec.Get(...); MyRec.Modify(); FindSet(true) does the same internally, but in a loop. Shouldn't we then use it then for Get + Modify as well, or is the performance gain too small?

@KarolakNatalie It might be that the code came in before I changed it. Until recently FindSet(true) did LockTable.

On the other hand, why does the standard use an explicit ReadIsolation instead of working with FindSet(true)?

@StefanMaron @Bettkellyk Can you please send me a simple repo app in DM and I will take a look.

@Bettkellyk @PhDuck2 It feels like I somehow managed to break something under the hood here.

Yak shaving at its finest again today. #msdyn365bc Did anyone have this error before? There is no call stack, but it happens only if I run the Code coverage. It also happens when not using UI but the AL Test Runner vs code extension.

@mortenbraemer We didn't see too many places where the feature would be necessary, so OnPrem first. If the community is eager for the feature, we will re-consider it. In the longer term we are thinking about allowing admins to allow persistent disable/enable on an environment.

@PhDuck2 Great feature to make retention policies faster with the opportunity to disable keys. OnPrem only or first?

Have you ever wondered how to swiftly delete data in #msdyn365bc? Most of the time, letting the runtime optimize is the way to go. In my latest blog post we explore how customizations can bring the performance down + an informal reveal of AlterKey :) bcinternals.com/posts/deleting…

@dan_flr We have been talking about introducing a TRUNCATE TABLE AL statement. However, the question is always how often do developers really need to empty the entire table?

@PhDuck2 I always use "DROP TABLE *" is that not correct?

@waldo1001 Can you check if your previous deadlocks were coming from SELECT statements with UPDLOCK, since these should now be reading with READCOMMITTED instead.

@PhDuck2 No hard evidence - but I have a strong feeling it's the TriState locking, since we applied "partial records" like .. uhm .. like maniacs.. ;-)

Evidence: #msdyn365bc v23 helps against deadlocks! More to do though.. #OnPrem