Dirty Trick to Keep Your Customers Hostage

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