Nome tabella di SQL Server che inizia con # nel database utente, non in tempdb, non in una tabella temporanea

In qualche modo, decenni fa, una tabella è stata creata nel nostro database che inizia con a #. Viene visualizzato in Esplora oggetti nel database dell'app, non in tempdb. Per qualche motivo, Azure non importerà il database in questo modo.

Non possiamo rilasciarlo, rinominarlo o interagire con esso. Ho provato Elimina da Esplora oggetti, Script Drop , Rinomina dalla GUI e nessuno di loro ha funzionato.

Siamo su SQL 2008 R2.

drop table [*app*].[dbo]."#OBSOLETE";

Database name '*app*' ignored, referencing object in tempdb.
Msg 3701, Level 11, State 5, Line 1
Cannot drop the table '#OBSOLETE', because it does not exist or you do not 
have permission.

exec sp_rename "dbo.#OBSOLETE", "dbo.obsolete"

Msg 15225, Level 11, State 1, Procedure sp_rename, Line 338
No item by the name of 'dbo.#OBSOLETE' could be found in the current database '*app*', given that @itemtype was input as '(null)'.

Come uccidere questo oggetto in modo da poterlo migrare in Azure?

Dato:

1. sp_rename utilizza i nomi degli oggetti anziché gli ID degli oggetti,
2. non possiamo usare il nome dell'oggetto poiché inizia con a #e viene interpretato come con significato speciale e viene gestito in modo diverso,
3. tutte le altre opzioni sono state esaurite

Dovresti provare a modificare la tabella del catalogo di sistema sottostante direttamente tramite una connessione DAC (Console dedicata) :

1. Prendi il object_iddi quel tavolo.
2. Riavvia l'istanza in modalità utente singolo. Questo per poter aggiornare direttamente le tabelle di sistema (cioè non è un requisito per l'utilizzo della connessione DAC).

3. Connettiti tramite la connessione dell'Admin Console dedicata. È possibile farlo in una sessione interattiva SQLCMD eseguendo quanto segue in una finestra del prompt dei comandi:

   C:\> SQLCMD -A -E

   oppure, connettiti direttamente al DB usando:

   C:\> SQLCMD -A -E -d {database_name}

4. In quel DB, prova qualcosa di simile al seguente:

   UPDATE sys.objects$ {enter}
   SET [name] = N'obsolete' {enter}
   WHERE [object_id] = {ye_olde_object_id}; {enter}
   GO {enter}

   Non eseguirà l'istruzione finché non si inserisce il file GO {enter}.

Prestare attenzione quando si modificano direttamente le tabelle del catalogo di sistema e non prendere confidenza con l'idea di farlo. Questo è qualcosa che dovrebbe essere fatto solo se non c'è assolutamente nessun altro modo di risolvere un problema (come nel caso qui). Probabilmente ci sono diversi motivi per evitare di apportare modifiche dirette, ma i due che inizialmente vengono in mente sono:

• Proprio come i modelli di dati che creiamo, ci sono probabilmente regole e flussi di lavoro su come funzionano le cose di cui non siamo a conoscenza (ad es. Denormalizzazione, regole di "business" che governano lo stato dei dati attraverso varie tabelle, ecc.)

• Molto probabilmente apportare modifiche dirette annulla la responsabilità di Microsoft di assisterti in caso di problemi e di avere un contratto di supporto (non ho visto i termini degli Accordi di supporto, ma ho difficoltà a credere che tale linguaggio non sarebbe in Là)

  @Paul Randal ha confermato in un commento una mia risposta correlata : "la modifica manuale di una tabella di sistema imposta irrevocabilmente un flag nella pagina di avvio del database che contrassegna il database come modificato in questo modo e CSS potrebbe decidere di non aiutare se in seguito hai problemi con quel database. "