Summer Cleaning

When you've been blogging for several years, the articles you wrote long ago can become outdated and less relevant. This is a perfectly normal and natural process. "Here we must run as fast as we can, just to stay in place. And if you wish to go anywhere, you must run twice as fast as that."
That's why I'm doing a summer cleaning of my old articles and projects to keep them up-to-date with current realities.

In one of the latest versions of the Table Data Editor, functionality for importing and exporting table data was added. As the simplest and easiest format, I chose JSON. However, I quickly received requests to add Import/Export in Excel format as well. So, I also added the ability to export to and import from Excel.

However, I'd like to remind you that Configuration Packages are a more appropriate way to handle this, as they offer more flexible options for Import/Export. It doesn't make much sense to develop such deep configuration settings for Import/Export within the Table Data Editor itself.

The next interesting change involves a flaw in the Table Data Editor that has been present in the product since the very beginning. I'll remind you that I released the first version in 2021. The most intriguing part is that no one noticed the "elephant in the china shop," but there's a logical explanation for this. Firstly, this elephant almost never affected the results, and secondly, it occurred deep in the code, requiring someone to really dig into it. However, the power of open-source worked, and someone pointed out this issue to me.
The essence of the problem lies in the fact that, in many places during field validation, I used a pattern like this:

Did you notice the problem here? At first glance, everything seems fine—we populate the field value and then, if necessary, call the validation. However, this code doesn't account for the possibility that the field itself may contain logic that checks the previous value using Rec.Field <> xRec.Field. With this approach, that code won't execute correctly.
Why did I write it this way originally? It was simply more convenient for me to write the function like this at the time, and then this approach carried over to all other parts of the Table Data Editor. How critical was this issue? Well, it probably wasn't a common problem, and the fact that no one noticed it earlier confirms this. But at the same time, it could lead to unpredictable behavior.
I've now implemented the correct pattern, which looks something like this:

Lastly, I added a new branch called BC18-19-20-21-22-23, which is essentially the latest version of the Table Data Editor but adapted for older versions of Business Central. I noticed that there is a significant number of users who use this application with older versions of BC OnPrem, and this branch will allow those users to install the Table Data Editor on their version of Business Central.

This is one of my first articles, written in 2020, to demonstrate how to integrate a third-party API into Business Central. It's fairly basic, but some aspects are still relevant today. Therefore, I've updated the repository and compiled the application for BC24.

The Spotify API integration is a more advanced example of integrating a third-party application into Business Central using an API. When I wrote this article, there was no oAuth2 module available! At that time, I used a third-party module from a blogger who has since stopped maintaining it.
I’ve updated the application to BC24 and replaced the authorization module with the current oAuth2.

I will strive to keep my articles and applications up to date to avoid obsolescence. This is all thanks to your feedback, which helps me understand what interests you and how I can assist you. I'm always ready to hear your ideas and requests, so please don't hesitate to share them with me on the blog, LinkedIn, Twitter, Facebook, and so on.