Starts in:
0 DAY
10 HRS
56 MIN
51 SEC
Starts in:
0 D
10 H
56 M
51 S
Open Closed

Seeding data in production ( Azure ) , what is the best practice? #1435


User avatar
0
okains created

I have tried running DBMigrator with the correct connection string to my azure sql db. However I get a login failed for user xxxxxxx error. This is the same user account that I am using to connect to the azure db using SQL Enterprise Manager, locally. So I know the credentials are correct, the firewall port is open and Azure has whitelisted my IP address.

Any ideas on how to get this to work for the initial seed?

Thanks,

Karim


7 Answer(s)
  • User Avatar
    0
    liangshiwei created
    Support Team Fullstack Developer

    Hi,

    It says ,login failed for user xxxxxxx error, I think the problem is clear, you should double check.

    And I check check it remotely shiwei.liang@volosoft.com

  • User Avatar
    0
    okains created

    Hi,

    Double check what? My username / password?

    As mentioned in my question, the credentials are correct. I can connect to the azure DB using SQL Enterprise Manager, remotely from my pc, with no issues.

    This is the same user account that I am using to connect to the azure db using SQL Enterprise Manager, locally. So I know the credentials are correct, the firewall port is open and Azure has whitelisted my IP address.

    Is there more config that I need for this? Maybe the connection string isn't set correctly? I have set the connection string in appsettings.json as follows:

    "ConnectionStrings": { // "Default": "Server=localhost;Database=AbpDevOps;Trusted_Connection=True", "Default": "Server=tcp:clevermm.database.windows.net,1433;Initial Catalog=AbpDevOps;Persist Security Info=False;User ID=XXXXXXXX;Password=XXXXXXXX;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;"

    Here is a screenshot of the exception:

    
    
  • User Avatar
    0
    liangshiwei created
    Support Team Fullstack Developer

    Maybe the user don't have permissons.

    • open Management Studio
    • connect to the database server the database is on and look for the Security node in Object Explorer.
    • Expand the Security node and look for the name of the user in the list of Logins.
    • If the user is there, you will need to grant that user appropriate permissions to the database (read, execute SPs, etc.).
    • If the user isn't there you will need to add them.

    Permission can also be added by group so you should check for groups that the user belongs to as well.

  • User Avatar
    0
    okains created

    OK, as mentioned in my question, and in my response:

    As mentioned in my question, the credentials are correct. I can connect to the azure DB using SQL Enterprise Manager, remotely from my pc, with no issues.

    This is the same user account that I am using to connect to the azure db using SQL Enterprise Manager, locally. So I know the credentials are correct, the firewall port is open and Azure has whitelisted my IP address.

    So the user has permissions. Is there anything else that I am missing here that would prevent me from running the migrator locally to see this remote azure db?

    Would this best handled in a DevOps pipeline? I was thinking that I could just quickly run the DBMigrator project with the remote connection string and be done with it.

  • User Avatar
    0
    liangshiwei created
    Support Team Fullstack Developer

    Hi,

    If you just want see seeding data, you can inject the IDataSeeder interface, see https://github.com/abpframework/abp/blob/2a22ebdd343cdeff094968c6e554086a5b602d65/templates/module/aspnet-core/host/MyCompanyName.MyProjectName.IdentityServer/MyProjectNameIdentityServerModule.cs#L220

    But if you need to create database schema, use .DBMigrator is best way.

    Is there anything else that I am missing here that would prevent me from running the migrator locally to see this remote azure db?

    You can use Management Studio login as cleverdbadmin and try to create database/table. if everything is ok. you can try simple connection string. e.g: Server=....;Database=....;UserId=...;Password=.....

  • User Avatar
    0
    ServiceBot created
    Support Team Automatic process manager

    This question has been automatically marked as stale because it has not had recent activity.

  • User Avatar
    1
    okains created

    An update on this:

    I was able to work around this by using a less complex password. I had initially used long random passwords that contained many special characters. These would work when connecting remotely to an Azure SQL DB using SSMS, but would not work using DBMigrator against an Azure SQL DB.

    I reduced the length and complexity of the passwords that I use, kept them to UpperCase/LowerCase/Numbers/[*!"] and DBMigrator now runs.

    Hope that helps someone else get past this.

Made with ❤️ on ABP v9.1.0-preview. Updated on November 20, 2024, 13:06