Overview
Through whatever reasons, the customers will want to work with one partner over another. It may be the lack of knowledge, lack of support, slow response, or whatever. The customer can freely choose who they want to work with in regards to Dynamics 365 Business Central (aka Dynamics NAV).
Of course for the Microsoft NAV partner that the customer is leaving in question, they do not like that. They want to keep the customer on and collect money without doing the work.
It also leads to hurt feelings from the partner in question. I would equate that feeling as being dumped by your significant other.
Nonetheless, one of the best “features” that’s not emphasized enough in the Dynamics 365 Business Central (aka Dynamics NAV) channel is that if the customer does not want to work with a particular company, they can freely choose another one without much problems.
You’re not dealing with Microsoft, you’re dealing with partners that work with Microsoft.
Old Trick to Prevent You from Leaving
There are a couple of dirty tricks that the industry employs to hold the customer hostage.
One of the oldest trick is through licensing. They sell you add-ons that are in the 30 million ranges that only THEIR company have access to.
Often times, the customers will not know they’re in a restricted add-on ranges, because quite frankly, when you’re getting into a new marriage, nothing can go wrong!
I’ve personally met with a few customers that ended up switching to a different ERP software because the previous partner wouldn’t release their code to other NAV partners.
What can you do? Threaten a lawsuit? Or did you read the print when you bought NAV from that company? If you did, did you understand what you were signing?
I fully understand why Microsoft does not want to get involved in these situations. The original selling partner will claim that their add-on is their secret IP and don’t want other people to “steal” it.
On the other hand, if the NAV partner suck or just don’t have the resource available, only the customer will suffer.
This topic should probably warrant a separate blog article since the question of Extensions comes into play. Basically any extensions can be treated like the objects in the 30 million ranges.
Dirty Trick to Prevent You from Leaving
If the customer refuses to purchase the partner’s add-on. The other way is to lock down the database.
How do we know this?
Recently, we worked with a new client that came to us because they didn’t like their previous partner. When we got our first modification request, I was horrified to find that we couldn’t modify any objects in the database.
This is even when I have the sysadmin role on SQL Server!
The error is:
The following SQL Server error or errors occurred when accessing the Object table: 50000,"42000",[Microsoft][SQL Server Native Client 11.0][SQL Server]You do not have permission to modify objects. SQL: UPDATE [NAV2016].[dbo].[Object] SET [Compiled]=0,[BLOB Reference]= NULL,[BLOB Size]=924,[Date]={ts '2018-10-11 00:00:00.000'},[Time]={ts '1754-01-01 17:37:53.955'} WHERE ([Type]=1 AND [Company Name]='' AND [ID]=2000000071)
Asking Around
Coincidentally, I was at a Dynamics 365 Business Central conference (Directions) where all of the best NAV experts are in one place for me to pick brains from.
When I showed this error around, everyone was stump and had no idea what’s causing this error. I even approach some of the Dynamics NAV MVPs and they asked the usual questions:
1. Are you sysadmin?
2. Do you have administrator on that computer?
No one had seen this error.
The Solution
Finally, Floyd Chan from Qixas Group gave me a hint that if he was devious, he would put code directly in SQL Server tables. More specifically, in the triggers.
Sure enough, checking the Triggers on the Object table in the SQL table, sure enough, we found this:
After removing the table trigger from the Object table, we were freely able to modify the database objects again.
Conclusion
Over the years, I’ve seen a lot of weird and questionable things.
This, to me, left a really bad taste in my mouth. Partners will go as far as locking down the database to prevent other developers on working with them.
I just want to put this out there so people will not have to suffer through this as well. Once is enough.
If this wasn’t figured out, I wonder what it would cost to have the original partner “unlock” the object table
There is good reason to do this if you have multiple Partners involved in a Project or if there was were incidents in the past where people imported objects in production without merging them to dev or staging first etc.
Its sort of a gated check in and used as that a good thing.
Used corectly it helps the customer keeping a sane code base by limiting access to object changes.
But i can undrstand your frustration if you see it for the first time.
How would it help if you have multiple partners working on the same database? Locking the database down wouldn’t solve anything. The better way would be to have the partners COMMUNICATE with each other and figure out what’s going on.
If you don’t want end users to modify the database, don’t install the development environment on their machine. Only let the Super user or administrator have access to the development environment.
There are plenty of ways to prevent “accidental” code changes. There’s absolutely no reason to lock down a DB for modification.
I have a hard time seeing this as a trick from the previous partner to prevent change of partner.
What was the code in these triggers? I have seen these kind of triggers when working with different approches to scm in c/side. It’s not forbidden to do things in SQL just because you run NAV on it.
The code in the trigger is encrypted. So we couldn’t see what was in it.
How would your approach to source code control affect this? Wouldn’t it be better to just setup different test databases for your source code control instead of just locking this down? Like I said, proper communication is all that’s needed.
If you don’t allow your end users own the code or to be able to modify the code, does your customer really own what they own?
One can argue “we’re saving them from themselves”, is it necessary to lock the database down in order to do this?
In pre 2013 versions it was easily to look down databases for other partners. Just put in a function in codunit 1 that runs code in an object in a partner range. But I have also seen addons that prevents you from starting the object designer even though you have permission super.
One thing that we are going to see more of is that partners put their business logic in azure functions. You don’t need dedicated addon range for that so functionality that used to be implemented in the partner range can now be protected by building outside of NAV.
When I started reading this post, I thought you were actually giving hints on how to do a dirty trick to keep your customers hostage…
I have to say I had mixed feelings about this post, because if I hadn’t read through the whole thing, I would have thought you were ill-fated here. Thankfully I didn’t stop reading half-way and I saw where you were getting at.
I really liked this hint, but maybe you should consider changing the title of this post to something like “How far partners go to keep customers hostage”, or something like that. For me, who don’t read your posts regularly (but have seen tons of them over my 13 years of NAV experience), it was somehow confusing where you were getting at.
If none of this is valuable, anyway, nice finding on this post.
Regards.
Alex just to say thanks, your article gave me a clue on how to solve a related issue – much appreciated.
Thank you for reading!