Azure SQL database copy showing original database name in SSMS

Christian Askey 0 Reputation points
2026-11-03T21:55:36.63+00:00

I've recently copied an Azure SQL database to a new logical SQL server and am having issues viewing the copied database in SSMS.

The original database is called LegacyDB, and the copied database is called ProductionDB.

The new server contains three databases:

  • ProductionDB

ReportingDB

AnalyticsDB

All three databases appear correctly in the Azure Portal and are online.

The issue

When I connect to the new SQL server using SSMS, the database explorer only displays LegacyDB, which is the name of the original database on the old server.

I can connect directly to ProductionDB, execute queries and retrieve the expected data without any issues. It's specifically the database explorer that isn't displaying the correct databases.

What I've tried

  • Creating new connections in both SSMS.
  • Connecting directly to the copied database rather than the server's master database.

Verifying the server name and database connection.

Running queries through Azure Portal Query Editor, which produces the same metadata results.

Could this be related to how Azure SQL handles database copies, and is there a way to fix the database explorer without recreating the database?

Azure SQL Database

1 answer

Sort by: Most helpful
  1. AI answer

    2026-11-03T21:56:50.9433333+00:00

    Connect to the target server’s master database as the SQL server administrator or Microsoft Entra administrator and query sys.databases; this distinguishes an Object Explorer display problem from restricted or incorrect server metadata without recreating the database.

    1. Check the target server’s authoritative catalog

    Since new SSMS connections and direct database connections did not change the result, run this against master on the new logical server, using an administrator account:

    SELECT
        @@SERVERNAME AS logical_server,
        DB_NAME() AS connected_database,
        name,
        database_id,
        state_desc,
        create_date
    FROM sys.databases
    ORDER BY name;
    

    In Azure SQL Database, sys.databases behaves differently depending on the connection context:

    • From master, it can return master and all user databases visible to the login.
    • From a user database, it returns only that database and master.
    • Database rows can also be hidden by metadata permissions. ^1^

    The expected administrator result is:

    • ProductionDB
    • ReportingDB
    • AnalyticsDB
    • master

    Also connect directly to ProductionDB and verify its current SQL name:

    SELECT
        @@SERVERNAME AS logical_server,
        DB_NAME() AS current_database,
        ORIGINAL_LOGIN() AS authenticated_login;
    

    DB_NAME() without an ID returns the name of the current database. ^2^

    2. Act on the result

    If sys.databases shows the three correct names

    The Azure SQL metadata is correct and the copy does not need to be recreated. A completed database copy is a fully functional, independent database; the target name supplied during the copy is the new database name. ^3^

    In SSMS:

    1. In Object Explorer, right-click the target server’s Databases node.
    2. Select Refresh.
    3. If LegacyDB remains, disconnect that Object Explorer node and restart SSMS.
    4. Reconnect to the target server with Connect to database set to master, using the same administrator identity used for the catalog query.
    5. Confirm the server node shows the target server’s fully qualified name and expected username. Object Explorer displays the connected server and database objects for that connection. ^4^

    If the query is correct but Object Explorer remains wrong after an SSMS restart, update SSMS and capture the SSMS version plus a screenshot of the server node before escalating it as an SSMS display issue.

    If an administrator sees the correct names but your normal login does not

    This is metadata visibility, not copy naming. A direct connection succeeds because the current database is always visible, even when the login cannot enumerate other databases through sys.databases. Visibility requires database ownership or suitable permissions; VIEW ANY DATABASE is normally granted through public, but it can be revoked or denied. ^1^

    Have the server administrator review grants and denies for the affected login rather than changing the databases. Grant only the visibility and access required by your security policy. Azure SQL access can be configured with a login in master plus users in each database, or with contained users scoped to individual databases. ^5^

    If the administrator’s sys.databases result itself shows LegacyDB

    That is not normal copy behavior, especially when Azure Resource Manager displays ProductionDB. Collect:

    • Target logical-server name
    • Output from both queries
    • Authentication type and login used
    • Copy completion time and operation details
    • Azure portal screenshot showing the target resource name
    • SSMS version

    Then open an Azure support request for an Azure SQL Database metadata mismatch. Do not delete or recreate the working database first; the conflicting control-plane and SQL catalog names need service-side investigation.


    References

    1. sys.databases (Transact-SQL)
    2. DB_NAME (Transact-SQL)
    3. Copy a transactionally consistent copy of a database in Azure SQL Database
    4. Quickstart: Connect and query an Azure SQL Database using SQL Server Management Studio (SSMS)
    5. Authorize database access to Azure SQL Database
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.