Accesso multiutente e sincronizzazione
Poiché Microsoft SQL Server Compact 3.5 (SQL Server Compact 3.5) supporta l'accesso multiutente, un utente può continuare a utilizzare il database mentre questo viene replicato. Possono pertanto verificarsi conflitti con le modifiche provenienti dal server di pubblicazione, ovvero conflitti di dati locali, che è necessario tenere in considerazione quando si sviluppano applicazioni che utilizzano SQL Server Compact 3.5. Alcuni scenari relativi a piattaforme a 64 bit, inoltre, non supportano l'accesso simultaneo a un file di database con versioni precedenti di SQL Server Compact. Per informazioni sui componenti a 64 bit, vedere Gestione di applicazioni di database a 64 bit.
Effetti dell'accesso multiutente
Quando si progetta un'applicazione che utilizza SQL Server Compact 3.5, è necessario tenere in considerazione gli effetti dell'accesso multiutente sul database. Nella tabella seguente vengono illustrate alcune funzionalità comuni incorporate in SQL Server Compact 3.5 e i problemi associati a ogni funzionalità.
| Funzionalità | Problema |
|---|---|
Blocco |
Durante la sincronizzazione, le modifiche provenienti dal server di pubblicazione potrebbero non venire applicate al database del Sottoscrittore a causa dei blocchi dei dati. Se sul Sottoscrittore vengono apportate modifiche a dati sui quali sono impostati blocchi di lunga durata, la sincronizzazione potrebbe non riuscire. Per evitare completamente il problema, aggiungere la logica all'applicazione per impedire a un utente di modificare i dati durante la sincronizzazione. |
Convalida |
Se si utilizza la convalida e si modifica il numero di righe del database di SQL Server Compact 3.5 durante la sincronizzazione, la convalida non riuscirà. Per evitare completamente il problema, aggiungere la logica all'applicazione per impedire a un utente di modificare i dati durante una sincronizzazione con la convalida. |
Reinizializzazione |
Durante la reinizializzazione di una sottoscrizione, tutte le tabelle utente e di sistema replicate vengono eliminate e ricreate dal livello di replica. Come avviene per le sottoscrizioni di SQL Server, le modifiche apportate dopo l'avvio della sincronizzazione vanno perdute quando ha luogo la reinizializzazione. Per evitare questa perdita di dati, aggiungere la logica all'applicazione per impedire a un utente di modificare i dati durante la reinizializzazione. |
Modifiche allo schema |
Tutte le operazioni DDL (modifiche allo schema) devono disporre dell'accesso esclusivo alla tabella. Una modifica allo schema non riuscirà se la tabella è utilizzata da un altro processo. |
Modifiche durante la sincronizzazione |
Se si verifica una modifica ai dati durante la sincronizzazione, tale modifica verrà inviata durante la sincronizzazione successiva. Se una sessione di sincronizzazione causa un conflitto locale, la riga viene risolta a livello di riga, anche se l'articolo viene rilevato a livello di colonna. |
Rilevamento e risoluzione di conflitti
Quando si lavora in un ambiente multiutente, durante la sincronizzazione possono verificarsi modifiche che provocano conflitti. SQL Server Compact 3.5 consente di rilevare i conflitti lato client, ma non di gestire la risoluzione dei conflitti. Le informazioni sui conflitti vengono invece passate al server di pubblicazione per essere risolte durante la sincronizzazione successiva.
La maggior parte dei conflitti viene risolta nel server di pubblicazione durante la sincronizzazione successiva. Tuttavia, se si verifica un conflitto di integrità referenziale, il server di pubblicazione richiederà una risincronizzazione automatica sul dispositivo. In tal caso, non verranno eseguite più di due risincronizzazioni.
Per ulteriori informazioni sul rilevamento e la risoluzione dei conflitti, vedere Rilevamento e risoluzione di conflitti di replica.
Utilizzo della proprietà SubscriberConflicts
Le modifiche apportate al database locale durante la sincronizzazione potrebbero provocare un conflitto locale. Se una riga del server di pubblicazione non può essere applicata nel Sottoscrittore, viene rilevato un conflitto nel Sottoscrittore e viene impostata la proprietà SubscriberConflicts. Con Sottoscrittori SQL Server, i conflitti vengono risolti nel Sottoscrittore stesso. Tuttavia, in SQL Server Compact 3.5 non è disponibile un riconciliatore. Tutti i conflitti devono quindi essere risolti nel server di pubblicazione. Quando si sviluppa un'applicazione, è possibile progettarla in modo da esaminare la proprietà SubscriberConflicts dopo ogni sincronizzazione. Se è impostata su un valore diverso da zero, è necessario risincronizzare i dati in modo che i conflitti possano essere risolti dal server di pubblicazione.
Vedere anche
Concetti
Sincronizzazione dei dati (SQL Server Compact)
Sincronizzazione di dati sincroni
Sincronizzazione di dati asincroni
Rilevamento e risoluzione di conflitti di replica