AL Object ID Ninja

Zero-configuration, dead-simple, lightning fast, no-collision object ID assignment for multi-user repositories

  • No collisions, ever: Real-time, conflict-free ID assignment that always gives every developer a guaranteed unique object ID.
  • Lightning-fast: Get your conflict-free object IDs instantly, with IntelliSense integration.
  • Zero-configuration: No setup, no onboarding, no settings — you work exactly like before, and it silently keeps your IDs clean.
Learn more

From the blog

Deploying from Visual Studio, update

A few days ago I have published my PowerShell script that streamlines and automates deployment of control add-ins from Visual Studio. Over the past couple of days I have improved it a little bit, and fixed a few bugs, so here’s an updated version that is more resilient to your project structure, produces resource zips that NST not only extracts, but actually understands, and does a little more.

NAV TechDays 2015 wrap up

Another NAV TechDays is over, and this one was the best so far. 950 people from all over the world all passionate about NAV and technology and eager to learn and share and discuss the latest in NAV. It was amazing, Luc did a great job again, and I am looking forward to the next year, hoping this conference makes it beyond 1000 attendees.

This year I have delivered a yet another “Black Belt” session named “Client Add-ins Black Belt: bringing .NET and JavaScript together” and as promised, I deliver the session material here on my blog.

Out-of-transaction database writes

Ancient wisdom goes that you cannot have more than one write transaction going on at the same time in a single session in NAV.

This is absolutely true, in and out.

Some features, like Activity Log, will leave you wanting to be able to write to the database outside of the normally running transaction.

Wouldn’t it just be beautiful if you could:

  • Write to the database, and then persist the change to the database even if an error happens during the transaction? (without cough! TryFunction, cough! cough!);
  • Not cause any locks to remain at the target table for any longer than it takes to do the write itself, without having to call COMMIT on your “regular” transaction; and
  • Not use temporary tables, because a system error (however unlikely) could cause the data to not be persisted if crash happens before temporary table is flushed to the physical one.

Well, in fact, you can do this.

Read all...