MENU
  1. ホーム
  2. Python
  3. Impossibile connettersi a LocalDB (localdb)\MSSQLLocalDB: guida completa a ripristino, driver ODBC 18 ed errori di patching 0x80070643

Impossibile connettersi a LocalDB (localdb)\MSSQLLocalDB: guida completa a ripristino, driver ODBC 18 ed errori di patching 0x80070643

Python

LocalDB non si avvia, SSMS/Visual Studio non riescono a collegarsi a (localdb)\MSSQLLocalDB e gli aggiornamenti SQL danno errore? In questa guida trovi cause vere, comandi pronti e una sequenza di ripristino che funziona. Focus su LocalDB 16.x, driver ODBC 18 e patch che falliscono con 0x80070643.

Indice

Panoramica del problema

Su workstation con più edizioni/istanze di SQL Server (LocalDB 2019/2022, più Express e magari un MSSQLSERVER), può capitare che:

  • SQL Server Management Studio (SSMS) e/o Visual Studio non si connettano più a (localdb)\MSSQLLocalDB con l’errore Unable to connect to target server ‘(localdb)\MSSQLLocalDB’.
  • Il patching tramite Windows Update o CU manuali fallisca con codice 0x80070643 e con exit code come -2061893565 o -2061893606, spesso su istanze SQLEXPRESS, SQLEXPRESS01 o MSSQLSERVER.

Sintomi: come si presentano

  • In SSMS la connessione a (localdb)\MSSQLLocalDB fallisce immediatamente; talvolta sembra “cercare” la pipe e poi si ferma.
  • In Visual Studio (Server Explorer o durante il debug) appare un errore generico di provider o un timeout.
  • sqllocaldb info elenca l’istanza ma lo stato è Stopped o Unknown.
  • Durante l’installazione di KB (es. KB5035432 / KB5021522) o di una Cumulative Update, i log parlano di “failed to update shared features”.

Perché succede (cause probabili)

AreaDettaglio
Registrazione LocalDBChiavi di registro o file di configurazione corrotti dopo tentativi ripetuti di installazione/repair.
Servizio/istanza non avviataLocalDB parte on‑demand; se l’avvio fallisce o rimane in stato stopped, la named pipe non viene creata.
Permessi/UtenteIl profilo Windows corrente non ha più diritti su %LOCALAPPDATA%\Microsoft\Microsoft SQL Server Local DB\Instances.
Versione clientDriver OLE DB/ODBC 17 fuori allineamento rispetto al motore 16.x; con ODBC 18 le impostazioni di cifratura cambiano e la connessione fallisce se la stringa non è aggiornata.
Componenti condivisiUn mix di build (es. LocalDB 16.0.1115.1 e motore 16.0.1000.6) genera dipendenze incongruenti e patch non applicabili.

Soluzione rapida: ripristina LocalDB in 5 minuti

  1. Arresta ed elimina l’istanza (non rimuove i tuoi database .mdf; sono file separati):
    sqllocaldb stop MSSQLLocalDB sqllocaldb delete MSSQLLocalDB sqllocaldb create MSSQLLocalDB 16.0 sqllocaldb start MSSQLLocalDB Se la creazione fallisce: chiudi SSMS/Visual Studio, elimina tutte le sottocartelle in %LOCALAPPDATA%\Microsoft\Microsoft SQL Server Local DB\Instances\ e riprova i comandi.
  2. Controlla la named pipe (deve comparire nel dettaglio):
    sqllocaldb i MSSQLLocalDB verifica che l'output includa qualcosa come: \\.\pipe\LOCALDB#..._tsql\query
  3. Testa fuori da SSMS/VS con sqlcmd:
    sqlcmd -S "(localdb)\MSSQLLocalDB" -E -Q "SELECT @@VERSION" Se qui funziona ma in Visual Studio no, aggiorna la connection string nel progetto.

Procedura completa e ragionata

Verifica preliminare dello stato LocalDB

sqllocaldb info
sqllocaldb i MSSQLLocalDB
  • State = Running e c’è la Instance pipe name → prova con sqlcmd.
  • State = Stopped/Unknown → esegui la sequenza stop/delete/create/start vista sopra.
  • Controlla il log LocalDB in %LOCALAPPDATA%\Microsoft\Microsoft SQL Server Local DB\Instances\MSSQLLocalDB\ (file ERRORLOG e ERRORLOG.n) per messaggi di avvio bloccato, porte/pipe, o ACL negati.

Riparare permessi della cartella Instances

Se il profilo ha perso i diritti sulla cartella LocalDB, reimposta le ACL (sostituisci DOMAIN\Utente con il tuo account):

cd "%LOCALAPPDATA%\Microsoft\Microsoft SQL Server Local DB"
icacls "Instances" /grant "%USERNAME%":(OI)(CI)F /T

Riprova ad avviare l’istanza:

sqllocaldb start MSSQLLocalDB

Aggiorna i driver client (ODBC 18/OLE DB e SMO)

Con ODBC 18 la cifratura è attiva di default. Se la tua stringa è rimasta “vecchia”, potresti ricevere errori di handshake TLS o di certificato. Adotta una delle seguenti stringhe:

  • Connessione veloce in dev (certificato non convalidato, adatta a LocalDB):
    Server=(localdb)\MSSQLLocalDB;Integrated Security=true;Encrypt=yes;TrustServerCertificate=yes;
  • Connessione più rigorosa (se usi un certificato valido):
    Server=(localdb)\MSSQLLocalDB;Integrated Security=true;Encrypt=yes;TrustServerCertificate=no;

Per ADO.NET (SqlClient) il principio è lo stesso. In applicazioni legacy con ODBC 17, valuta di rimuoverlo dopo aver installato il 18 per evitare side-by-side non necessari.

Correggere la cache delle connessioni in SSMS/Visual Studio

  • In SSMS, elimina la connessione salvata a (localdb)\MSSQLLocalDB e ricreala.
  • In Visual Studio, aggiorna la connection string in appsettings.json / app.config e rimuovi eventuali DSN ODBC locali non più usati.
  • Chiudi tutti i processi che tengono aperta la pipe: devenv.exe, SSMS.exe, test runner, worker di migrazione.

Quando ci sono più istanze (Express + LocalDB)

LocalDB usa named pipe per utente; SQL Express usa servizi Windows (MSSQL$SQLEXPRESS, MSSQLSERVER), TCP dinamico o 1433 e Browser. Non c’è “conflitto di porte” con LocalDB, ma possono esistere conflitti su componenti condivisi (client, VSS Writer, DQS, ODBC/OLE DB, SMO). Se patch/repair falliscono, passa alla sezione “Errori di patching”.

Errori di patching / Windows Update 0x80070643

Questo codice segnala un fallimento MSI durante l’aggiornamento. Spesso i log riportano “failed to update shared features”. Le cause tipiche includono:

AreaDettaglio
Installer cache corrottaCartella C:\Program Files\Microsoft SQL Server\160\Setup Bootstrap\ con pacchetti incompleti o mismatch.
Componenti condivisi bloccatiServizi come SQL Writer, VSS o Windows Update in stato incoerente durante la patch.
Mix di build RTM + CULocalDB e motore con numeri di build diversi (RTM vs CU recenti) → dipendenze non soddisfatte.

Leggere i log giusti

  • Summary: C:\Program Files\Microsoft SQL Server\160\Setup Bootstrap\Log\Summary.txt
  • Dettaglio ultimo tentativo: file Detail.txt nella stessa cartella del Summary corrispondente alla data del tentativo.
  • Cerca stringhe come Return code 0x80070643, Exit code -2061893565, Shared components, msierr, Rollback.

Ripristino componenti condivisi via Setup (repair mirato)

Esegui la riparazione per ciascuna istanza problematica; cambia INSTANCENAME a seconda dei casi (MSSQLSERVER, SQLEXPRESS, SQLEXPRESS01):

setup.exe /Action=Repair /InstanceName=MSSQLSERVER /IACCEPTSQLSERVERLICENSETERMS=YES
setup.exe /Action=Repair /InstanceName=SQLEXPRESS /IACCEPTSQLSERVERLICENSETERMS=YES

Se il setup propone la riparazione delle Shared Features, accettala: è lì che si inceppa nella maggior parte dei casi.

Reset completo dei servizi di update prima di riprovare

Apri un prompt elevato (Administrator) e arresta i servizi interessati, poi rinomina cache e riparti:

net stop wuauserv
net stop bits
net stop msiserver
net stop vss
net stop sqlwriter

ren "C:\Windows\SoftwareDistribution" SoftwareDistribution.old
ren "C:\Windows\System32\catroot2" catroot2.old
rem Cache dei pacchetti MSI/SQL
for /d %%G in ("%ProgramData%\Package Cache{*") do @echo. & rem Verifica manualmente le cartelle SQL e rinominale

net start vss
net start msiserver
net start bits
net start wuauserv </code></pre>

<p>Dopo il reset, evita Windows Update: <strong>lancia la CU manuale</strong> (eseguibile della cumulative update per SQL Server 2022) e verifica l’esito nei log.</p>

<h3>Disinstallazione pulita (ultima ratio, ma spesso risolutiva)</h3>
<ol>
  <li>Dal Pannello di controllo rimuovi tutte le istanze e i componenti “Microsoft SQL Server 2022” e “SQL Server 2019 LocalDB”.</li>
  <li>Esegui lo <strong>strumento di rimozione</strong> (SQL Server Removal Tool) per eliminare residui in registry, servizi e WMI.</li>
  <li>Riavvia.</li>
  <li>Installa ex‑novo <strong>SQL Server 2022 Express</strong> (CU corrente) con opzione <em>Download Media → Express with Advanced Services</em>.</li>
  <li>Installa separatamente <strong>LocalDB 16.x</strong> solo se necessaria.</li>
</ol>
<p><em>Nota</em>: la disinstallazione non elimina automaticamente i tuoi database utente; fai comunque un backup dei file <code>.mdf</code>/<code>.ldf</code> prima di procedere.</p>

<h3>Prerequisiti di sistema da verificare</h3>
<ul>
  <li>.NET Framework 4.8.1 presente e integro.</li>
  <li>Microsoft Visual C++ 2015‑2022 Redistributable x64/x86 aggiornato.</li>
  <li>Nessun antivirus di terze parti che blocchi <code>kernelbase.dll</code> o interferisca con il setup (prova un <em>avvio pulito</em> di Windows se sospetti interferenze).</li>
</ul>

<hr>

<h2>Passi immediati consigliati (priorità)</h2>
<table>
  <thead>
    <tr>
      <th>Priorità</th>
      <th>Azione</th>
      <th>Obiettivo</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>★★★</td>
      <td>Usa <code>sqllocaldb delete/create</code> per ristabilire LocalDB</td>
      <td>Riprendere subito i progetti universitari</td>
    </tr>
    <tr>
      <td>★★☆</td>
      <td>Installa ODBC Driver 18 e testa con <code>sqlcmd</code></td>
      <td>Escludere problemi lato client</td>
    </tr>
    <tr>
      <td>★★☆</td>
      <td>Tenta la CU manuale su una sola istanza (<code>MSSQLSERVER</code>) con <code>setup.exe /action=repair</code></td>
      <td>Capire se il patching fallisce per librerie comuni</td>
    </tr>
    <tr>
      <td>★☆☆</td>
      <td>Se persiste, pianifica disinstallazione completa e reinstallazione “pulita”</td>
      <td>Eliminare conflitti strutturali</td>
    </tr>
  </tbody>
</table>

<h2>Diagnostica aggiuntiva e comandi utili</h2>
<h3>Elenco versioni LocalDB installate</h3>
<pre><code>sqllocaldb versions
</code></pre>

<h3>Chi sta usando la pipe LocalDB?</h3>
<p>Se sospetti un handle bloccato, chiudi Visual Studio/SSMS, quindi:</p>
<pre><code>taskkill /F /IM sqlservr.exe
</code></pre>
<p>(Solo per l’istanza LocalDB in sessione utente; non uccidere servizi di produzione.)</p>

<h3>Verificare servizi di SQL Express</h3>
<pre><code>sc query type= service state= all | findstr /I "MSSQL SQLAgent"
</code></pre>

<h3>Controllare spazio disco e cartelle temp</h3>
<p>Patching e avvii LocalDB possono fallire con temp pieni. Verifica e pulisci:</p>
<pre><code>cleanmgr /sageset:1 &amp; cleanmgr /sagerun:1
</code></pre>

<h3>Script “tutto‑in‑uno” per resettare LocalDB utente</h3>
<p>Esegui da PowerShell <em>non amministrativo</em> (LocalDB è per‑utente), chiudendo prima SSMS/VS:</p>
<pre><code>$name = "MSSQLLocalDB"
try { sqllocaldb stop  $name -s *>$null } catch {}
try { sqllocaldb delete $name -s *>$null } catch {}
$inst = Join-Path $env:LOCALAPPDATA "Microsoft\Microsoft SQL Server Local DB\Instances"
if (Test-Path $inst) { Get-ChildItem $inst | Remove-Item -Recurse -Force }
sqllocaldb create $name 16.0
sqllocaldb start  $name
sqllocaldb i $name
</code></pre>

<hr>

<h2>Stringhe di connessione pronte per ODBC 18/SqlClient</h2>
<table>
  <thead>
    <tr>
      <th>Scenario</th>
      <th>Connection string</th>
      <th>Note</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Dev veloce (LocalDB)</td>
      <td><code>Server=(localdb)\MSSQLLocalDB;Integrated Security=true;Encrypt=yes;TrustServerCertificate=yes;</code></td>
      <td>Evita errori di certificato con ODBC 18 (cifratura on per default).</td>
    </tr>
    <tr>
      <td>EF Core</td>
      <td><code>Server=(localdb)\MSSQLLocalDB;Database=MyDb;Trusted_Connection=True;Encrypt=True;TrustServerCertificate=True;</code></td>
      <td>Aggiungi <code>MultipleActiveResultSets=True</code> se necessario.</td>
    </tr>
    <tr>
      <td>SSMS</td>
      <td>Server name: <code>(localdb)\MSSQLLocalDB</code>, Auth: <em>Windows Authentication</em></td>
      <td>Non servono credenziali; LocalDB gira con il tuo utente.</td>
    </tr>
  </tbody>
</table>

<h2>FAQ pratiche</h2>
<h3>LocalDB è “un servizio”?</h3>
<p>No. È un processo <code>sqlservr.exe</code> per‑utente che si avvia on‑demand e comunica via named pipe. Non usa TCP 1433 né SQL Browser.</p>

<h3>Rimuovere e ricreare LocalDB cancella i miei database?</h3>
<p>No. I tuoi file <code>.mdf</code>/<code>.ldf</code> stanno dove li hai creati (per default nella cartella dati del progetto). Conservane sempre una copia prima di interventi di manutenzione.</p>

<h3>Posso avere LocalDB 16.x e SQL Express 2019 sulla stessa macchina?</h3>
<p>Sì, ma attenzione ai <em>shared components</em>. Mantieni un solo ramo di versione dove possibile e applica CU coerenti.</p>

<h3>Perché con ODBC 17 funzionava e ora con ODBC 18 no?</h3>
<p>Perché ODBC 18 abilita <em>Encrypt</em> per default. Adegua la stringa con <code>Encrypt=yes;TrustServerCertificate=yes</code> (in dev) o configura certificati validi.</p>

<h3>Che differenza c’è tra <code>MSSQLSERVER</code> e <code>SQLEXPRESS</code>?</h3>
<p><code>MSSQLSERVER</code> è l’istanza <em>predefinita</em> (senza nome), <code>SQLEXPRESS</code> è un’istanza <em>nominala</em> tipica di Express. LocalDB è ancora un’altra cosa, isolata per utente.</p>

<hr>

<h2>Guida decisionale rapida</h2>
<ol>
  <li><strong>Errore solo su LocalDB?</strong> → Esegui <code>stop/delete/create/start</code>, verifica pipe e prova <code>sqlcmd</code>.</li>
  <li><strong>Funziona da <code>sqlcmd</code> ma non da VS?</strong> → Aggiorna connection string (Encrypt/TrustServerCertificate), cancella profili di connessione.</li>
  <li><strong>Patch falliscono?</strong> → Repair via <code>setup.exe</code> sulle istanze coinvolte → se non basta, reset dei servizi di update → se ancora KO, disinstallazione pulita e reinstallazione con CU corrente.</li>
  <li><strong>Ancora problemi?</strong> → Passa alla sezione “Supporto specialistico”: prepara log e diagnostica.</li>
</ol>

<h2>Conflitti comuni e come evitarli</h2>
<table>
  <thead>
    <tr>
      <th>Conflitto</th>
      <th>Riconoscimento</th>
      <th>Rimedio</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>LocalDB non crea la pipe</td>
      <td><code>sqllocaldb i</code> non mostra <code>\\.\pipe\LOCALDB#...</code></td>
      <td>Ricrea l’istanza; controlla ACL su <code>Instances</code>; chiudi processi che tengono un handle sporco.</td>
    </tr>
    <tr>
      <td>ODBC 18 handshake TLS</td>
      <td>Errore di cifratura/certificato</td>
      <td>Aggiungi <code>Encrypt=yes;TrustServerCertificate=yes</code> in dev.</td>
    </tr>
    <tr>
      <td>Patching shared features</td>
      <td>Setup si ferma su componenti condivisi</td>
      <td><code>setup.exe /Action=Repair</code> per istanza, reset servizi, CU manuale.</td>
    </tr>
    <tr>
      <td>Mix RTM + CU</td>
      <td>Versioni motore diverse</td>
      <td>Disinstalla e reinstalla con CU corrente; mantieni un solo ramo.</td>
    </tr>
  </tbody>
</table>

<h2>Check list prima di aprire SSMS/VS</h2>
<ul>
  <li><code>sqllocaldb i MSSQLLocalDB</code> → <em>State=Running</em> e pipe presente?</li>
  <li><code>sqlcmd -S "(localdb)\MSSQLLocalDB" -E -Q "SELECT @@VERSION"</code> restituisce la versione?</li>
  <li>Driver ODBC 18 installato e connection string aggiornata?</li>
  <li>Spazio su disco &gt; 2 GB su <code>%TEMP%</code> e su <code>C:\</code>?</li>
</ul>

<h2>Preparare la richiesta per supporto specialistico</h2>
<p>Se decidi di aprire un thread su Microsoft Q&amp;A (tag <em>sql-server-database-engine</em>), allega sempre:</p>
<ol>
  <li><strong>Summary log</strong>: <code>C:\Program Files\Microsoft SQL Server\160\Setup Bootstrap\Log\Summary.txt</code></li>
  <li><strong>Detail.txt</strong> dell’ultimo tentativo (stessa directory del Summary)</li>
  <li><strong>Output</strong> di:
    <pre><code>sqllocaldb info
sqllocaldb i MSSQLLocalDB

File CAB generato dallo strumento SQL Server Diagnostics (componente sqlpackage / modalità diagnostics).

Queste informazioni permettono agli ingegneri di individuare subito punti di rottura in MSI, dipendenze mancanti e mismatch di build.

Best practice per non ricaderci

  • Un solo ramo: mantieni tutto su 16.x (SQL 2022) o tutto su 15.x (SQL 2019). Evita mix RTM + CU distanti.
  • Driver aggiornati: ODBC 18, OLE DB e SMO coerenti con il motore; rimuovi versioni obsolete non necessarie.
  • Backup dei file .mdf/.ldf prima di repair o disinstallazioni.
  • Ambiente pulito: chiudi SSMS/VS durante patch/repair; esegui come amministratore quando richiesto.
  • CU periodiche: applica gli aggiornamenti cumulativi mensili per restare allineato.

Ricapitolando

  • LocalDB: nella stragrande maggioranza dei casi è un’istanza corrotta o un client fuori sync. La ricostruzione con sqllocaldb delete/create risolve rapidamente.
  • Aggiornamenti: gli errori 0x80070643 indicano fallimenti MSI: controlla cache MSI, componenti condivisi e coerenza di versione; se i build sono mismatch, la reinstallazione pulita è spesso la via più rapida.
  • Prevenzione: non mescolare rami (tutto 16.x o tutto 15.x) e resta aggiornato con le CU. Aggiorna le connection string per ODBC 18.

Seguendo la sequenza proposta tornerai a usare LocalDB e a compilare i tuoi progetti C# senza dover cambiare macchina. Buon lavoro!

Appendice: esempi di errori e lettura rapida dei log

  • LocalDB: shared memory provider: No process is on the other end of the pipe → La pipe non esiste o è stata chiusa: ricrea l’istanza e chiudi strumenti che la tengono in uso.
  • Patch: Failed to enable shared features → Repair delle Shared Features dal setup.exe, poi CU manuale.
  • ODBC 18: Client unable to establish connection con riferimento a TLS → Aggiungi Encrypt=yes;TrustServerCertificate=yes o configura certificati.

Fields utili nei log (cerca nel Detail.txt):

  • Component name che fallisce (es. SQL Writer, Client Connectivity, Setup Support Files).
  • Package path mancante (riferimento a Package Cache).
  • Return value 3 in MSI (punto esatto del fallimento).

Appendice: checklist post‑ripristino

  1. Avvia SSMS → connessione a (localdb)\MSSQLLocalDB con Windows Authentication.
  2. In Visual Studio, esegui una migrazione EF Core o apri Server Explorer → verifica database visibile.
  3. Esegui un SELECT @@VERSION e un CREATE DATABASE di prova: sqlcmd -S "(localdb)\MSSQLLocalDB" -E -Q "CREATE DATABASE Ping; SELECT name FROM sys.databases;"
  4. Se usi test runner/worker, prova a eseguire un test che apre la connessione con la stringa aggiornata.
Python
0x80070643 LocalDB MSSQLLocalDB ODBC Driver 18 SQL Express SQL Server SSMS Troubleshooting Visual Studio Windows Update
Indice