Prevent DB upgrade / revert back (17/18)

Miklos_Hollender

I know the old topics about $ndo$dbproperty. Is still just that one table if you accidentally moved (with the dev env) a 2017 db to 2018?

Can you prevent such a move? I don't know, maybe block write access to $ndo$dbpoperty or something?

Miklos_Hollender

We just found a potentially easier solution. We just create two new domain accounts for the two people who have development environment access. The new accounts cannot access the older database, the older accounts cannot access the new database. Also, ZUP Files are automatically saved in different folders and don't get overwritten.

Slawek_Guzek

I thought that you after some technical solution, not procedural. Anyway, imho it is better to have simpler solution in place, like separate AD accounts

Slawek_Guzek

you means if this is the only table which undergo structural and/or data changes when you convert the database to from 2017 to 2018?

I'd check Active Session table too.

Also there might be some triggers added/changed and if the whole process is not run as asingle transaction. Unfortunately my exprience wit eariler versions with problems when conversion has been interrupded half way through and you can't get to it either from old and nor from the new client suggests that it may not be. Accidental conversion stopped on accessing $ndo$dbpoperty may be 'lethal' in such case.

Miklos_Hollender

That is quite scary. I have one physical server running two live systems, 2017 and 2018 and even if we manage to stick to the discipline of never doing object changes direct on live at the end of the day we have to import objects and we are not very good at PowerSheel scripting so mostly it is going to be through the dev env. Which means the possibility of accidental conversion. What could I do to prevent this?

Slawek_Guzek

Start with

DENY ALTER ON [dbo].[$ndo$dbproperty] TO [public] 
DENY UPDATE ON [dbo].[$ndo$dbproperty] TO [public]

in some separate 2017 database (exrta copy of Cronus 2017) and then try to convert it to 2017, and see what happens. Perhaps denying update access to $ndo$dbpoperty will be enough.

If not just analyse with SQL Profiler what is going on when you do conversion, and when you importing fob, and then adjust permissions accordingly and then adjust SQL Server permissions. The goal would be to stop the first operation performed by NAV during conversion.

Miklos_Hollender

We just found a potentially easier solution. We just create two new domain accounts for the two people who have development environment access. The new accounts cannot access the older database, the older accounts cannot access the new database. Also, ZUP Files are automatically saved in different folders and don't get overwritten.

Slawek_Guzek

I thought that you after some technical solution, not procedural. Anyway, imho it is better to have simpler solution in place, like separate AD accounts

Miklos_Hollender

Well, it is technological from viewpoint as it physically prevents conversion.