Domanda

Ho un problema al momento in cui i database di accesso multipli (stesso schema) 2003 sono utilizzati sui laptop.

Devo trovare un modo automatizzato per sincronizzare i dati in un database di accesso centrale.

I dati sui laptop vengono aggiunti solo per cui le operazioni di aggiornamento / eliminazione non costituiranno un problema.

Quali strumenti mi permetteranno di farlo facilmente? Quali fattori influenzeranno la decisione sullo strumento o sulla soluzione migliore?

È stato utile?

Soluzione

È possibile utilizzare la replica Jet integrata in Access, ma ti avvertirò, è piuttosto traballante. Inoltre confonderà il tuo PK su qualsiasi tabella su cui lo fai perché raccoglie numeri interi con segno casuale per cercare di evitare le collisioni chiave, quindi potresti finire con -1243482392912 come prossimo PK su un dato record. Questo è un PITA da digitare se stai facendo qualsiasi tipo di ricerca su di esso (come un ID cliente, numero di ordine, ecc.) Non puoi automatizzare la sincronizzazione di Access (forse puoi falsificare qualcosa di simile usando VBA. Ma comunque , che verrà eseguito solo all'apertura del database).

Il modo in cui consiglierei è di utilizzare SQL Server 2005/2008 sul tuo "centrale" database e utilizza SQL Server Express Editions come back-end sul tuo "remoto" database, quindi utilizzare le tabelle collegate in Access per connettersi a questi database SSEE e la replica per sincronizzarli. Impostare unisci replica o replica istantanea con il tuo " central " database come editore e database SSEE come abbonati. A differenza della replica di Access Jet, puoi controllare la numerazione PK, ma per te questo non sarà un problema poiché i tuoi abbonati non invieranno modifiche.

Oltre alla scalabilità che porterebbe SQL Server, puoi anche automatizzarlo usando Gestione sincronizzazione Windows (se hai cartelle sincronizzate, questa è la fastidiosa piccola scatola che si apre e le sincronizza quando accedi / disconnetti) e impostala in modo che si sincronizzi a un determinato intervallo, all'avvio, allo spegnimento o all'ora del giorno e / o quando il computer è inattivo o si sincronizza solo su richiesta. Anche se Access non viene eseguito per un mese, il suo set di dati può essere aggiornato ogni volta che gli utenti si connettono alla rete. Roba molto bella.

Altri suggerimenti

La replica degli accessi può essere scomoda e, poiché sono necessarie solo query di accodamento con qualche controllo, probabilmente sarebbe meglio scrivere qualcosa da soli. Se i dati raccolti da ciascun laptop non possono sovrapporsi, ciò potrebbe non essere troppo difficile.

Dovrai considerare le chiavi primarie. Potrebbe essere meglio incorporare il nome dell'utente o del laptop nella chiave per garantire che i record siano collegati correttamente.

Le risposte in questo thread sono piene di disinformazione su Jet Replication da parte di persone che ovviamente non l'hanno usato e stanno solo ripetendo cose che hanno sentito o stanno attribuendo problemi a Jet Replication che in realtà riflettono errori di progettazione dell'applicazione.

  

È possibile utilizzare Jet   replica integrata in Access, ma I   ti avvertirà, è piuttosto traballante.

Jet Replication non è flakey. È perfettamente affidabile se usato correttamente, proprio come qualsiasi altro strumento complesso. È vero che alcune cose che non causano problemi in un database non replicato possono portare a problemi quando replicate, ma ciò è logico a causa della natura di ciò che la replica da parte di qualsiasi motore di database comporta.

  

Confonderà anche il tuo PK   su qualunque tavolo lo faccia perché   seleziona numeri interi con segno casuale da provare   ed evitare le collisioni chiave, quindi potresti   finisci con -1243482392912 come tuo   prossimo PK su un dato record. È un   PITA da digitare se lo stai facendo   tipo di ricerca su di esso (come un cliente   ID, numero ordine, ecc.)

I PK Suronate Autonumber non devono mai essere esposti agli utenti in primo luogo. Sono numeri insignificanti usati per unire dischi dietro le quinte e se li stai esponendo agli utenti È UN ERRORE NEL PROGETTO DELLA TUA APPLICAZIONE.

Se hai bisogno di numeri di sequenza, dovrai farne uno tuo e affrontare il problema di come prevenire le collisioni tra le tue repliche. Ma questo è un problema per la replica in qualsiasi motore di database. SQL Server offre la possibilità di allocare blocchi di numeri di sequenza per singole repliche a livello di motore di database e questa è una funzionalità davvero interessante, ma comporta un costo amministrativo maggiore dal mantenimento di più istanze di SQL Server (con tutti i problemi di sicurezza e prestazioni ciò comporta). In Jet Replication, dovresti farlo nel codice, ma non è certo un problema complicato.

Un'altra alternativa sarebbe quella di utilizzare un PK composto, in cui una colonna indica la replica di origine.

Ma questo non è un difetto nell'implementazione della replica di Jet: è un problema per qualsiasi scenario di replica che richiede numeri di sequenza significativi.

  

Non puoi automatizzare Access   sincronizzazione (forse puoi fingere   qualcosa di simile usando VBA. ma   tuttavia, verrà eseguito solo quando   database aperto).

Questo è palesemente falso. Se si installa il sincronizzatore Jet è possibile pianificare le sincronizzazioni (sincronizzazioni dirette, indirette o Internet). Anche senza di esso, è possibile pianificare l'esecuzione periodica di un VBScript e la sincronizzazione. Questi sono solo due metodi per ottenere la sincronizzazione automatica Jet senza la necessità di aprire l'applicazione Access.

Una citazione dalla documentazione MS:

  

Usa Jet e Replication Objects

JRO non è davvero il modo migliore per gestire Jet Replication. Per uno, ha solo una funzione in cui manca a DAO stesso, cioè la capacità di avviare una sincronizzazione indiretta nel codice. Ma se hai intenzione di aggiungere una dipendenza alla tua app (JRO richiede un riferimento o può essere utilizzato tramite l'associazione tardiva), potresti anche aggiungere una dipendenza da una libreria davvero utile per controllare Jet Replication, e questa è la Sincronizzatore TSI , creato da Michael Kaplan, un tempo il principale esperto mondiale di Jet Replication (che da allora è passato all'internazionalizzazione come sua area di concentrazione). Offre il pieno controllo programmatico di quasi tutte le funzionalità di replica che Jet espone, tra cui la sincronizzazione di sincronizzazioni, l'avvio di tutti i tipi di sincronizzazione e il tanto necessario comando MoveReplica (l'unico modo legale per spostare o rinominare una replica senza interrompere la replica).

JRO è uno dei brutti figliastri della campagna interrotta ADO-Everywhere di Microsoft. Il suo scopo è fornire funzionalità specifiche di Jet per integrare ciò che è supportato in ADO stesso. Se non stai usando ADO (e non dovresti trovarti in un'app Access con un back-end Jet), allora non vuoi davvero usare JRO. Come ho detto sopra, aggiunge solo una funzione che non è già disponibile in DAO (ovvero l'avvio di una sincronizzazione indiretta). Non posso fare a meno di pensare che Microsoft fosse dispettosa creando una libreria autonoma per funzionalità specifiche di Jet e poi tralasciando intenzionalmente tutte le funzioni incredibilmente utili che avrebbero potuto supportare se avessero scelto.

Ora che ho eliminato le asserzioni errate nelle risposte sopra offerte, ecco la mia raccomandazione:

Poiché disponi di un'infrastruttura di sola aggiunta, fai ciò che @Remou ha raccomandato e imposta qualcosa per inviare manualmente i nuovi record ovunque essi debbano andare. Ed ha ragione che devi ancora affrontare il problema PK, proprio come faresti se avessi usato Jet Replication. Questo perché è richiesto dal requisito di aggiungere nuovi record in più posizioni ed è comune a tutte le applicazioni di replica / sincronizzazione.

Ma un avvertimento: se lo scenario del solo componente aggiuntivo cambia in futuro, verrai espulso e dovrai ricominciare da capo o scrivere un sacco di codice peloso per gestire le cancellazioni e gli aggiornamenti (non è facile - fidati io l'ho fatto!). Un vantaggio derivante dal solo utilizzo di Jet Replication (anche se è molto utile per le sincronizzazioni bidirezionali, ovvero le modifiche in più posizioni) è che gestirà lo scenario del solo componente aggiuntivo senza problemi e quindi gestirà facilmente la replica di tipo merge full un requisito in futuro.

Infine, un buon punto di partenza con Jet Replication è il Wiki Jet Replication . Le pagine Risorse, Buone pratiche e Cose da non credere sono probabilmente i posti migliori da cui iniziare.

Dovresti leggere Accesso Database Replica , dato che ci sono alcune informazioni disponibili.

Ma penso che per funzionare correttamente con la tua applicazione, dovrai implementare una soluzione personalizzata usando metodi e proprietà disponibili a tale scopo.

  

Utilizzare Jet and Replication Objects (JRO) se si richiede il controllo programmatico sullo scambio di dati e informazioni di progettazione tra i membri del set di repliche nei database di Microsoft Access (solo file .mdb). Ad esempio, è possibile utilizzare JRO per scrivere una procedura che sincronizzi automaticamente la replica di un utente con il resto del set quando l'utente apre il database. Per replicare un database a livello di codice, è necessario chiudere il database.

     

Se il database è stato creato con Microsoft Access 97 o precedente, è necessario utilizzare Data Access Objects (DAO) per replicarlo e sincronizzarlo a livello di programmazione.

     

È possibile creare e gestire un database replicato nelle versioni precedenti di Microsoft Access utilizzando i metodi e le proprietà DAO. Utilizzare DAO se è necessario il controllo programmatico sullo scambio di dati e informazioni di progettazione tra i membri del set di repliche. Ad esempio, è possibile utilizzare DAO per scrivere una procedura che sincronizzi automaticamente la replica di un utente con il resto del set quando l'utente apre il database.

     

È possibile utilizzare i seguenti metodi e proprietà per creare e gestire un database replicato:

     
      
  • Metodo MakeReplica
  •   Metodo
  • Sincronizza
  •   
  • ConflictTable proprietà
  •   
  • DesignMasterID proprietà
  •   
  • KeepLocal proprietà
  •   
  • replicabile proprietà
  •   
  • ReplicaID proprietà
  •   
  • proprietà ReplicationConflictFunction
  •   
     

Microsoft Jet fornisce questi metodi e proprietà aggiuntivi per la creazione e la gestione di repliche parziali (repliche che contengono un sottoinsieme dei record in una replica completa):

     
      
  • ReplicaFilter proprietà
  •   
  • PartialReplica proprietà
  •   
  • Metodo PopulatePartial
  •   

Dovresti assolutamente leggere i dati di sincronizzazione della documentazione .

Ho usato la replica in a00 per anni, fino a quando non sono stato costretto a passare a a07 (quando è andato via). Il problema più problematico che abbiamo riscontrato, a livello aziendale, era la gestione dei CONFLITTI . Se non gestiti in modo tempestivo o se ce ne sono troppi, gli utenti si sentono frustrati e i dati diventano inaffidabili.

La replica ha funzionato bene quando i nostri siti remoti non erano sempre connessi a Internet. Ciò ha permesso loro di lavorare con i propri dati e di sincronizzarsi quando potevano. Almeno due volte al giorno.

Installiamo un database separato sui computer remoti che gestiscono la sincronizzazione, quindi l'utente deve solo fare clic su un'icona sul desktop per evocare la sincronizzazione.

L'utente aveva un pulsante separato per inviare / estrarre i feed da un file FTP designato che si sarebbe aggiornato dai sistemi legacy.

Questo processo ha funzionato abbastanza bene, dato che avevamo 30 di questi "nodi" lavorare in tutto il paese, gestirne i dati e aggiornarli ai server FTP.

Se stai considerando seriamente questo percorso, fammi sapere e posso inviarti la mia documentazione.

Puoi scrivere il tuo software di sincronizzazione che si collega al laptop seleziona il diff dal suo db e lo inserisce nel master. Dipende dal tuo schema di dati quanto sarà facile questa operazione. (se hai molti tavoli con FK ... dovrai farlo in modo intelligente). Penso che sarà il più efficace se lo scrivi da solo.

L'automazione di questo tipo di comportamento si chiama replica e Accesss Supports apparentemente, ma non l'ho mai visto implementato.

Come suppongo che la maggior parte delle volte il laptop non sia collegato al DB principale, non è comunque una buona idea (replicare i dati).

se cercherete uno strumento di terze parti per farlo - cercate qualcosa che possa facilmente fare la diff tra le tabelle prima di copiarla e, naturalmente, può farlo in modo incrementale.

FWIW:

  1. AutoNumbers. Sono d'accordo con David: non dovrebbero mai essere esposti. Per rimuovere quella tentazione, uso un numero casuale Random.
  2. replica. L'ho usato ampiamente alcuni anni fa, con sincronizzazioni pianificate e utilizzando GUID come PK. Ho scoperto ripetutamente che eventuali singhiozzi sulla rete hanno danneggiato le repliche, con il risultato che ho dovuto recuperare i dati e riemettere repliche. Doloroso!
Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top