An Azure relational database service.
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 returnmasterand 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:
- In Object Explorer, right-click the target server’s Databases node.
- Select Refresh.
- If
LegacyDBremains, disconnect that Object Explorer node and restart SSMS. - Reconnect to the target server with Connect to database set to
master, using the same administrator identity used for the catalog query. - 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