IF NOT RECORDLEVELLOCKING THEN - should we be using it.

Business Central/NAV Technical Forum
1

I am curious about opinions on this. Obviously if you are an ISV developing Add-Ons for many clients, or if you are on Native then this does not apply but…

We all know that moving from Native to SQL is a common process, but does anyone move the other way? My guess would be “pretty unlikely”. So if a client is on SQL, and you are developing customizations for them, is there any logic behind writing code so that it is optimized for both Native and SQL? Wouldn’t it make more sense to just optimize for SQL and be done with it? On the same topic is SETCURRENTEY (ignoring th SQL 2005 issue and hinting Read Waldo’s Blog or Mark’s Blog for more about that).

Basically I know we should be covering all options, but is it really the best solution for our clients if we are thinking about Native DB for a client that will never use it?

2

Well, David, I think you answered yourself - if you are developing a customization which has no chance of being reused anywhere else but in the environment you are in, to keep it simple by dropping useless code would be the right thing to do.

3

In light of my last post about LS Retail, I wanted to bump this for more opinions.

Thanks.

4

Okay, anonymous opinion here.

I would say program for an SQL database that may have index hinting turned on. That way single user performance on a native database will likely be Okay but multi-user will probably be full of deadlocks.

These deadlocks can be ‘fixed’ by putting a “IF NOT RECORDLEVELLOCKING THEN GLEntry.LOCKTABLE;” in every relevant spot. Ie use a “Giant Lock”. Multi-user performance will suck, but that’s Okay, that’s how you sell the SQL upgrade for larger stores.

The good thing about this is that it’s easy to test without a Native database; just turn index hinting on.