NAV2013 Users/Security

Rob_Hansen

So...I've worked with NAV for 13 years now, but am not sure on the setup sequence for the following scenario now that users and security setups are administered through the RTC. Hopefully someone can clarify what i'm sure is something obvious i'm missing.

My scenario is that I have a full NAV backup (FBK) file that I want to restore onto our server. So...through the NAV 2013 development environment I create a new database and set all the usual options. I then restore the FBK into this database. In prior versions of NAV (right up to NAV 2009 R2) I would then go into security on the tools menu and add my user account to the database as a super user and all would be good. In NAV 2013 I can't do this as security admin is no longer in the classic client (I mean, development environment). So...how do I do this? When I try to open the new database using the RTC, I am unable to as I am "not authorized to sign in" (i.e. I have not been set up as a valid user). I can't run the User table directly from the development environment (since it triggers it through the RTC and the same error is raised).

I'm hoping I don't have to go through some SQL Management Studio steps here...I'm sure it's an option but something this basic should not require us to work outside of the NAV development environment. If it does, Microsoft should look at adding back some of the security admin features to the development environment for something like this scenario.

Rob_Hansen

Okay...so I found a post by waldo about using SQL to clear data in a few tables (user, access control, user property) to enable access to the database. That worked fine and wasn't a big deal...but I still think the NAV development environment should be a more full-featured tool for administration related to NAV. (That's my gripe for the day)

Aleksandr112

And also there is no synchronize function in 2013.

about your post i think maybe it was done to increase security:
if you not authorized to that particular DB -so it's ok that you can't access it.
imagine if u get same fbk file that was made from DB u not authorized - but after restore it to new DB u can access database data - it's not secure.

Luc_VanDyck

Aleksandr112 wrote:

imagine if u get same fbk file that was made from DB u not authorized - but after restore it to new DB u can access database data - it's not secure.

That's not a valid argument. Backup files should not be stored on a publicly accessible resource. If there is no other way, then encrypt your backup file.