Rilevamento e segnalazione dei conflitti RDA

La funzionalità RDA (Remote Data Access) di Microsoft SQL Server Compact 3.5 (SQL Server Compact 3.5) rende disponibile un meccanismo limitato di segnalazione dei conflitti per le righe che non possono essere aggiornate nel computer che esegue SQL Server durante un'operazione push.

Importante

Le righe in conflitto in RDA vengono definite rigorosamente come operazioni di inserimento, aggiornamento o eliminazione non riuscite a causa di un errore quando ne viene eseguito il push da SQL Server Compact 3.5 alla tabella di SQL Server. Le modifiche apportate ai dati da utenti diversi non vengono considerate conflitti se non provocano alcun errore.

Benché RDA non offra un sistema di risoluzione specifico, a differenza della replica, in SQL Server Compact 3.5 è disponibile una tabella degli errori in cui vengono acquisite tutte le righe in conflitto. È possibile specificare la tabella degli errori come parte del metodo Pull. Eventuali errori verificatisi durante il push vengono registrati in tale tabella. L'utilizzo della tabella degli errori consente di sviluppare applicazioni per gestire il rilevamento e la segnalazione dei conflitti.

Le modifiche apportate al database di SQL Server Compact 3.5 e di cui viene eseguito il push sul server vengono applicate in base all'ordine di ricezione. La tabella di SQL Server viene aggiornata in modo da riflettere le modifiche apportate dall'ultimo utente.

In RDA viene rilevato un conflitto quando non è possibile eseguire il push di una riga da SQL Server Compact 3.5 a SQL Server. RDA supporta solo il rilevamento a livello di riga. Il rilevamento o meno degli errori delle righe dipende quindi dalle opzioni selezionate in un metodo Push. Per rilevare conflitti in RDA, specificare TRACKINGON o TRACKINGON_INDEXES nel metodo Pull.

Per evitare conflitti ed errori quando si utilizzano le tabelle con rilevamento basato su RDA, filtrare in modo corretto le tabelle e utilizzare una connessione di rete stabile durante la propagazione dei dati.

Cause dei conflitti RDA

Le modifiche a una riga non possono essere applicate sul server per le ragioni seguenti:

• Le operazioni di inserimento, aggiornamento ed eliminazione vengono rilevate in modo specifico da RDA per ogni riga modificata nella tabella con rilevamento sul dispositivo. Se nel client viene quindi inserita una riga con lo stesso valore di chiave primaria di una riga inserita sul server nella stessa tabella, si verificherà un errore durante il push dal client poiché l'operazione di inserimento è già stata eseguita.
• Se i dati non sono stati partizionati correttamente per ogni utente, è possibile che un utente elimini una riga mentre un altro utente sta tentando di aggiornarla.
• È inoltre possibile che il push delle righe sul server non riesca e che si verifichino quindi errori in caso di interruzione di un push precedente. Si supponga ad esempio che un utente inizi il push dei dati sul server, che contiene operazioni di inserimento, e durante il push venga persa la connettività di rete. Nel client verrà visualizzato un messaggio di errore del push a causa della perdita di connettività di rete. Tuttavia, le modifiche sono state effettivamente applicate al server. Quando la connettività di rete viene ristabilita sul client e l'utente tenta di eseguire un secondo push degli stessi dati, non sarà possibile applicare alcune righe, poiché tali righe sono state inserite durante il push precedente. In questo caso, è consigliabile che l'applicazione ignori tutti gli errori inclusi nella tabella degli errori dovuti a una chiave primaria duplicata in base al secondo push.

Tabelle degli errori

RDA consente di rilevare i conflitti di dati, ovvero righe che non sono state applicate al server a causa di un errore, mediante la restituzione e l'archiviazione degli errori in una tabella degli errori nel database di SQL Server Compact 3.5, insieme alla riga che ha provocato l'errore. Questa tabella viene definita nel metodo Pull. Successivamente, eventuali errori verificatisi durante un'operazione push verranno archiviati nella tabella degli errori.

Quando si utilizza il metodo Push, se non è possibile applicare una riga al server a causa di un errore, ad esempio una chiave primaria duplicata, per risolvere la riga si farà riferimento al nome della tabella degli errori definita in origine nel metodo Pull. La proprietà ErrorTableName del metodo Pull consente di specificare il nome della tabella di archiviazione degli errori causati da operazioni push. La tabella degli errori viene creata immediatamente ma inizialmente non contiene righe. È possibile specificare ErrorTableName solo quando si specifica TRACKINGON o TRACKINGON_INDEXES nel metodo Pull.

Se si verifica un errore a causa dell'impossibilità di applicare una riga durante l'esecuzione del metodo Push, SQL Server Compact 3.5 inserisce nella tabella un record per ogni errore verificatosi. Oltre a tutte le colonne della tabella di base, vengono aggiunte tre colonne per identificare quando e perché si è verificato l'errore. La colonna s_ErrorDate consente di specificare la data e l'ora in cui si è verificato l'errore. La colonna s_OLEDBErrorNumber consente di specificare il valore HResult dell'errore verificatosi durante l'applicazione della riga al server. La colonna s_OLEDBErrorString è una stringa descrittiva dell'errore. Al termine dell'esecuzione del metodo Push e dopo il verificarsi di errori durante il tentativo di applicazione delle righe al server, un avviso (SSCE_WRN_RDAERRORROWSRETURNED, valore 28800) viene trasmesso all'applicazione, che potrà esaminare la tabella degli errori per determinarne la causa.

Gestione delle tabelle degli errori

Le tabelle degli errori vengono eliminate automaticamente se la tabella associata con rilevamento basato su RDA viene rimossa, anche se la tabella degli errori include ancora righe. È necessario che le righe considerate come conflitti vengano risolte dallo sviluppatore, poiché tali righe non possono essere applicate al server.

Per risolvere correttamente l'errore verificatosi durante il push originale dei dati sul server, potrebbe essere necessario aggiornare i dati sul dispositivo. È consigliabile memorizzare nella cache i dati della tabella degli errori, in modo che tali dati non vadano persi quando si rimuove la tabella con rilevamento. In alternativa, è possibile eseguire il pull dei dati aggiornati in una tabella con nome diverso da quello della tabella con rilevamento originale.

Risoluzione degli errori dopo un push di dati

L'errore, archiviato nella tabella degli errori insieme alla riga che lo ha provocato, include una descrizione della causa del mancato inserimento, aggiornamento o eliminazione della riga sul server. A seconda dell'errore, potrebbe risultare importante ottenere informazioni sullo stato attuale dei dati sul server. È necessario che l'applicazione sia progettata per la gestione di questa situazione, poiché l'eliminazione della tabella con rilevamento ha provocato l'eliminazione della tabella degli errori.

Errori e transazioni non batch

Durante transazioni non batch, ovvero se si imposta l'opzione BATCHINGOFF quando si utilizza il metodo Push, i conflitti vengono rilevati a livello di riga. La riga in conflitto viene restituita all'applicazione e archiviata in una tabella degli errori specifica. Se ad esempio l'applicazione tenta di eseguire il push di una riga non valida in SQL Server, tale riga verrà restituita all'applicazione e archiviata nella tabella degli errori insieme a un messaggio di errore relativo al tipo di conflitto.

Quando viene restituita alla tabella degli errori, la riga viene rimossa dalla tabella originale. Poiché lo stato originale della tabella viene modificato, la risoluzione del conflitto verificatosi risulta leggermente più difficile. È necessario progettare l'applicazione in modo da consentire all'utente di correggere i dati in conflitto. Tale soluzione potrebbe implicare la riesecuzione del pull della tabella dal server per risolvere correttamente il problema.

La rimozione della tabella sul dispositivo provocherà la rimozione della tabella degli errori. È necessario memorizzare nella cache le righe della tabella degli errori specificando un percorso temporaneo oppure eseguire il pull dei dati dal server a una tabella diversa. Poiché le righe responsabili dell'errore vengono rimosse dalla tabella nel database di SQL Server Compact 3.5, è importante che la tabella venga aggiornata nuovamente, in modo da includere i dati corretti del server. Se la riga che ha provocato l'errore è stata originariamente aggiornata, è necessario eseguire nuovamente un aggiornamento sulla stessa riga per evitare errori all'operazione push successiva. Se la riga è stata aggiornata, ma la riga sul server è stata eliminata, è necessario aggiungere nuovamente la riga alla tabella e rieseguirne il push per consentirne l'inserimento corretto.

Errori e transazioni batch

RDA supporta inoltre il push batch, mediante l'impostazione dell'opzione BATCHINGON quando si utilizza il metodo Push. Per l'elaborazione completa di tale tipo di push è necessario che non si verifichi alcun errore nelle righe. In caso di errore di una riga, l'intera transazione push non riuscirà e non verrà aggiornato alcun dato. Le righe in conflitto vengono copiate nella tabella degli errori. Questa è l'opzione consigliata, poiché offre un meccanismo leggermente più semplice per la risoluzione del conflitto. A differenza del push non batch, il database originale basato su Microsoft Windows CE rimane intatto. È necessario progettare l'applicazione in modo da consentire all'utente di correggere i dati in conflitto e di eseguirne nuovamente il merge nel database basato su Windows CE originale. Poiché la riga originale rimane intatta, a seconda dell'errore è possibile che non sia necessario rieseguire immediatamente il pull dei dati del server per determinare la risoluzione corretta della riga. Ad esempio, se l'errore della riga è stato causato da una violazione dell'integrità, è possibile aggiornare la riga sul dispositivo e richiamare il metodo Push per provare a eseguire il push dei dati sul server. Questa opzione contribuisce inoltre a semplificare la gestione, poiché la tabella degli errori viene pulita automaticamente prima di copiare una riga in conflitto. Nella tabella sono disponibili solo i conflitti relativi all'ultima operazione push.