Hello Meng, 

Credentials are stored in SQL Server.. can you explain what you need changing?

What's the actual issue you are trying to solve?

Regards, 

DCrampton

HI DCrampton , i am thinking that in Database setup, we can change the sql login credentials for company/system/portal database, but what if we have to change the credentials for Vault/Store?

Hello Meng, 

the Vault and Store DB Owners are only used during the initial setup of the database.. after the initial configuration, there is no further need for it.  you can even disable the user in Management Studio.  updating a Sage Login User password must be done from within Sage 300 as there are processes that will update the #vaultUser stored in the Store DB.

hope this helps.

Regards,

DCrampton

"even disable the user in Management Studio"

Is this true? We can disable the store and vault SQL user after the initial setup? Creating and managing Sage300 users will work OK with this SQL user disabled?

We have clients that have their cyber security team question why an application needs a SQL user with sysadmin server role. If we can tell them its only for the initial setups it would put the team at ease.

Hello SergeB ..yes,  it is just for the initial setup that is all.. once the vault and store db's have been setup and configured to Sage, the user can be disabled.  

Regards, 

DCrampton

Thanks for that information.

Whats the process if we were to move to another SQL instance. Lets say we install and setup Sage300 2024 on a SQL2019 instance. Six months later we decide to move to a SQL2022 instance. 

DBSetup allows use to modify company connection strings but what about the store and vault strings?

I've tested this and it works. 

I was interested in seeing whats happenin and it seems that the ##S3_LOGIN_ADMIN##VAULT user has the following permissions:

• alter any login
• create login
• connect sql
• view any db

And you can see during SQL profiling that there are calls to EXECUTE AS LOGIN = '##S3_LOGIN_ADMIN##VAULT'; create user 'blah', so its actually that admin##vault user doing all the heavy lifting.

Thanks for that information.

I've tested this and it works. 

I was interested in seeing whats happenin and it seems that the ##S3_LOGIN_ADMIN##VAULT user has the following permissions:

• alter any login
• create login
• connect sql
• view any db

And you can see during SQL profiling that there are calls to EXECUTE AS LOGIN = '##S3_LOGIN_ADMIN##VAULT'; create user 'blah', so its actually that admin##vault user doing all the heavy lifting.

Thanks for that information.