Prevent DB upgrade / revert back (17/18)

Miklos_HollenderMiklos_Hollender Member Posts: 1,598
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?

Best Answers

  • Miklos_HollenderMiklos_Hollender Member Posts: 1,598
    Answer ✓
    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.

Answers

  • Slawek_GuzekSlawek_Guzek Member Posts: 1,690
    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.
    Slawek Guzek
    Dynamics NAV, MS SQL Server, Wherescape RED;
    PRINCE2 Practitioner - License GR657010572SG
    GDPR Certified Data Protection Officer - PECB License DPCDPO1025070-2018-03
  • Miklos_HollenderMiklos_Hollender Member Posts: 1,598
    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_GuzekSlawek_Guzek Member Posts: 1,690
    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.
    Slawek Guzek
    Dynamics NAV, MS SQL Server, Wherescape RED;
    PRINCE2 Practitioner - License GR657010572SG
    GDPR Certified Data Protection Officer - PECB License DPCDPO1025070-2018-03
  • Miklos_HollenderMiklos_Hollender Member Posts: 1,598
    Answer ✓
    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.
  • Miklos_HollenderMiklos_Hollender Member Posts: 1,598
    Well, it is technological from viewpoint as it physically prevents conversion.
Sign In or Register to comment.