Concorrenza MS Access (MDB).

Question

Per un piccolo progetto ho bisogno di utilizzare un semplice database con requisiti molto leggeri:poche tabelle, non più di qualche migliaio di record in totale, 2 o 3 utenti.Sto lavorando in ambiente .NET.

Poiché in questo caso un server di database (anche quelle edizioni Express) sembra eccessivo, un database MDB molto semplice potrebbe soddisfare la maggior parte dei requisiti.Sono tuttavia preoccupato per la concorrenza.La mia idea è posizionare il file .mdb su una condivisione di rete e consentire agli utenti di accedere a questo file dai propri client basati su .NET.Il database è principalmente destinato alle operazioni di sola lettura, ma occasionalmente gli utenti dovranno anche aggiornare/eliminare i record.Se ciò non sarà possibile in quel momento (a causa del blocco del db o altro), posso trattenere gli aggiornamenti sul client ed elaborarli in un secondo momento.

La domanda stessa si svolge lungo questi punti:

• Come vengono gestite le letture simultanee in MDB?
• Come vengono gestiti gli aggiornamenti/eliminazioni simultanei in MDB?
• Esiste un concetto di blocco e come posso sfruttarlo in un'app .NET?
• Posizionare il file MDB su una condivisione di rete è un'idea buona o orribile?

Dato che lavoro in .NET, mi piacerebbe anche sapere come posso rilevare eventuali problemi di concorrenza e intraprendere le azioni appropriate.Ad esempio, quale eccezione dovrei rilevare e quale azione consiglieresti di intraprendere?

MODIFICARE:Potrebbe essere la mia cattiva descrizione del problema, ma la maggior parte delle risposte sembra consigliare di optare per un server DB completo.Comprendo le differenze e i vantaggi di avere un'installazione server e in effetti ho implementato un discreto numero di progetti su MSSQL e Oracle.In questa domanda, tuttavia, mi occupo solo di Access e dei suoi problemi di concorrenza, quindi per favore non suggerire un server DB.

Grazie per l'aiuto.

Answer 1

Questa è una vecchia domanda, ma nessuno ha mai avuto una risposta concreta.Ecco le domande:

1. Come vengono gestite le letture simultanee in MDB?
2. Come vengono gestiti gli aggiornamenti/eliminazioni simultanei in MDB?
3. Esiste un concetto di blocco e come posso sfruttarlo in un'app .NET?
4. Posizionare il file MDB su una condivisione di rete è un'idea buona o orribile?

Fondamentalmente alle prime due domande si può rispondere con una sola spiegazione.Un avvertimento chiave qui:le risposte che sto dando qui sono specifiche per Jet MDB (e le loro varianti) e non si applicano completamente al nuovo formato di file introdotto a partire da A2007, ovvero il formato ACCDB.Non ho esplorato a fondo le implicazioni della rimozione di Jet ULS dall'ACE e alcuni dei commenti seguenti potrebbero presupporre Jet ULS sotto il cofano.Per molte cose, però, puoi sostituire "file LACCDB" con "file LDB" e i risultati saranno gli stessi.

1-2) Letture/aggiornamenti/eliminazioni simultanei

Il motore di database Jet viene spesso definito database "file server" in quanto non esiste alcun demone sul lato server che gestisce l'I/O con i file di dati sul server.Ciò significa che tutti i client che utilizzano un Jet MDB leggono direttamente il file.

Questa è, ovviamente, una ricetta per il disastro se non è integrato un meccanismo per gestire l'accesso simultaneo al file.

Jet utilizza un file di blocco dei record, dove se il tuo MDB è "MyFile.MDB" il file di blocco dei record si troverà nella stessa cartella e sarà chiamato "MyFile.LDB".Il file LDB registra quali utenti Jet ULS hanno aperto il file MDB, da quale workstation è connesso l'utente e tutte le informazioni necessarie per la negoziazione dei problemi di concorrenza.

Ora, a coloro che si sono fatti le ossa con i motori di database client/server, questo può sembrare primitivo e pericoloso, ma al momento in cui fu sviluppato il motore di database Jet, il suo scopo era quello di essere utilizzato come motore di database desktop per piccoli gruppi di lavoro, ed era era in competizione con altri motori db desktop come xBase e Paradox, che utilizzavano entrambi file di blocco analoghi per gestire l'uso simultaneo di file di dati da più client.

All'interno di un file di database Jet, i blocchi vengono applicati alle pagine di dati (che in Jet 4 erano aumentate a 4K, mentre in Jet 3.x e versioni precedenti erano 2K) o a livello di record se la tabella dati era stata originariamente creata per utilizzare il blocco a livello di record.Agli albori di Jet 4, molti ritenevano che il blocco a livello di record fosse piuttosto lento, in particolare quando si utilizzava il blocco pessimistico, quindi molti sviluppatori di Access non hanno mai usato altro che il blocco a livello di pagina (@David Fenton alza la mano!).

Infatti, quando si utilizza il blocco ottimistico, si evita la maggior parte dei problemi di concorrenza che deriverebbero dal blocco pessimistico.

Alcuni avvertimenti:

1. da DAO, il blocco a livello di record non è disponibile e ottieni sempre e solo il blocco a livello di pagina.

2. da DAO, ci sono una serie di opzioni per controllare il blocco ottimistico/pessimistico, in particolare l'argomento LockEdits del metodo OpenRecordset, ma che interagisce anche con alcune delle impostazioni specificate nell'argomento Opzioni OpenRecordset (ad esempio, l'opzione dbReadOnly non può essere utilizzata con Blocca modifiche).Oltre al blocco, ci sono anche opzioni per aggiornamenti coerenti/incoerenti e tutto ciò può interagire con le transazioni (ad esempio, le modifiche all'interno di una transazione non confermata non saranno visibili agli altri utenti e quindi non entreranno in conflitto con loro, ma può inserire blocchi di sola lettura sulle tabelle coinvolte).

Da ADO/OLEDB, queste strutture di controllo della concorrenza Jet verranno mappate sulle funzioni e sugli argomenti pertinenti presenti in ADO/OLEDB.Poiché utilizzo Jet solo da Access, interagisco con esso solo tramite DAO, quindi non posso consigliarti su come controllarli con ADO/OLEDB, ma il punto è che il motore di database Jet offre il controllo del blocco dei record quando si accede ad esso a livello di codice (invece che tramite l'interfaccia utente di Access): è semplicemente più complicato.

3) Serrature e .NET

Non posso offrire alcun consiglio qui, a parte il fatto che probabilmente utilizzeresti OLEDB come interfaccia dati, ma il punto è che la funzionalità/controllo di blocco è presente nel motore DB stesso, quindi probabilmente c'è un modo per controllarlo tramite OLEDB.Potrebbe non essere carino, però, poiché mi sembra che OLEDB sia progettato attorno ad architetture client/server e il blocco basato su file di Jet potrebbe non mapparlo in modo elegante.

4) MDB su una condivisione di rete

Jet è molto sensibile al minimo intoppo in qualsiasi connessione di rete.Per questo motivo, le reti con larghezza di banda ridotta possono aumentare la vulnerabilità dei database Jet aperti con una connessione lenta.

Questo perché parti importanti del file di database devono essere trasferite attraverso il cavo alla RAM del computer locale per l'elaborazione.Ora, molte persone sostengono erroneamente che l'intero file MDB viene trascinato attraverso il cavo o che intere tabelle vengono trascinate attraverso il cavo.Questo non è vero.Invece, Jet prima richiede gli indici (e non richiede più del necessario per soddisfare la query) e poi da quel risultato determina esattamente quali pagine di dati sono necessarie e quindi estrae solo quelle pagine.Questo è sorprendentemente efficiente e veloce.

Inoltre, Jet esegue una memorizzazione nella cache molto intelligente che può significare che una prima richiesta di dati può richiedere del tempo, ma le richieste successive per gli stessi dati avvengono quasi istantaneamente a causa della memorizzazione nella cache.

Ora, se non hai indicizzato bene le tue tabelle, potresti finire per estrarre l'intera tabella ed eseguirne una scansione completa.Allo stesso modo, se basi i criteri su funzioni lato client che non fanno parte del dialetto SQL di Jet, potresti finire per estrarre una tabella completa (l'ordinamento, ad esempio, Sostituisci (MyField, "A", "Z") potrebbe causare una scansione completa della tabella).Ma questo genere di cose sarà inefficiente anche con un'architettura client/server, quindi è solo una progettazione di schemi di buon senso indicizzare le cose correttamente e fare attenzione all'uso di UDF o funzioni non compatibili con Jet.In generale, le stesse cose che sono efficienti con client/server saranno efficienti con Jet (la differenza principale è che con Jet è meglio avere una connessione persistente per evitare il sovraccarico di ricreare il file LDB, che è significativo).

L'altra cosa da evitare è provare a utilizzare i dati Jet tramite una connessione WiFi.Sappiamo tutti quanto sia inaffidabile il WiFi e ci sono solo problemi nel provare a lavorare con i dati Jet tramite una connessione WiFi.

La linea di fondo:

Se utilizzi un MDB come archivio dati per servire i dati da un server Web, dovresti inserire i dati il ​​più vicino possibile alla RAM del server Web.Ciò significa che, ove possibile, su un volume disco collegato al server Web fisico.Laddove ciò non è possibile, desideri una connessione LAN veloce e affidabile.Le LAN GB nei data center sono piuttosto comuni al giorno d'oggi e mi sentirei molto a mio agio a lavorare con i dati Jet su questo tipo di connessione.

Per l'uso condiviso, ad esempio, più workstation client che eseguono un'app desktop VB.NET che condividono un singolo Jet MDB come archivio dati, è abbastanza sicuro avere il file di dati su un file server affidabile.Ove possibile, è una buona idea inserire i file Jet MDB su macchine che non servono a più scopi (ad esempio, il controller di dominio che esegue Exchange, SQL Server e funge da file server e server di stampa potrebbe non essere la posizione migliore) .App come Exchange possono interferire gravemente con la funzionalità del file server e di solito consiglierei di non inserire mai file MDB su un server multitasking come server Exchange a meno che non abbia un volume estremamente basso.

Altre considerazioni:

1. non tentare mai di distribuire un MDB su un file system replicato, a meno che tutti gli utenti non utilizzino la stessa replica.Cioè, se hai due server che replicano file tra loro, non pensare nemmeno di modificare il file MDB da entrambi i server.Ciò danneggerà il file quasi immediatamente.

2. Consiglierei di non archiviare alcun MDB su qualcosa di diverso da un file system Windows nativo servito tramite la rete Microsoft SMB nativa.Ciò significa niente Novell, niente Linux, niente SAMBA.La ragione principale di ciò è che apparentemente esistono hook di basso livello da Jet in alcune funzionalità di blocco di basso livello nel file system di Windows che non sono replicati al 100% su altri file systsm.Ora, sono molto conservatore su questo punto e molti sviluppatori Access competenti hanno riportato risultati eccellenti con file server Novell adeguatamente configurati (spesso sono necessarie alcune modifiche al blocco dei record, anche se al giorno d'oggi potrebbe essere meno rilevante: non lo so non so nemmeno se Novell esiste più!) e prestazioni eccezionali con file server basati su Linux che eseguono SAMBA.Sono cauto su questo punto e consiglierei a qualsiasi client di non farlo (questo include anche vari dispositivi SAN, poiché non molti di essi sono basati su Windows).

3. Non li eseguirei mai su nessun file system virtualizzato per gli stessi motivi.Tuttavia, ho un cliente che esegue la sua app di accesso per utente singolo con Parallels su un Mac Air ormai da diversi anni senza alcun problema.Ma è per utente singolo, quindi i problemi di blocco saranno relativamente minori.

Non so se questo risponde alle tue domande oppure no.È tutto basato sui miei 13 anni di utilizzo regolare di Jet come sviluppatore di Access e sullo studio dell'unico libro pubblicato su Jet, la Jet Database Engine Programmers Guide (solo per Jet 3.5).Non ho fornito alcuna vera citazione, ma se qualcuno ha bisogno di dettagli su qualcosa che ho detto, farò la ricerca, se posso.

Answer 2

Ho costruito una dozzina di applicazioni in modo di piccole imprese nell'accesso nel corso degli anni. La maggior parte hanno un massimo di 10-20 utenti su di loro alla volta. Le banche dati sono divisi tra un "app" e un database "dati". Le prestazioni sono decenti e senza problemi con concurrancy. Anche la corruzione è stato sostanzialmente inesistente poiché Access 2000 SP2.

C'è un sacco di gente che dice "Non bisogna mai utilizzare Access" - bene, se è fatto bene (cioè da uno sviluppatore professionista) L'accesso è un bel pacchetto di sviluppo bene e mi hanno fatto una buona vita a questo. I miei clienti sono molto contento di quello che ho costruito.

Answer 3

Ho scritto due prodotti commerciali che utilizzano un database di Access, che parte da una condivisione di rete, per di solito fino a 10 utenti. Se non abusarne, non c'è davvero nessun problema; ma come si può vedere molti sviluppatori non mai arrivare - e per la sua bassa della natura fine, ci sono un sacco di hack merda costruite su di esso. Nel caso di un prodotto, ho dovuto ridisegnare l'applicazione a causa di tutti i problemi descritti in dettaglio da altri; ma dopo che ho ripulito tutto, non ho mai avuto un problema di integrità del database di centinaia di installazioni.

La sua un grande vantaggio è il database singolo file, che è facile da eseguire il backup, il ripristino e copiare a un computer portatile di sezionare. Praticamente tutte le alternative, tra cui SQLite (anche se alcuni non ammetterlo), richiedono una qualche forma di DBA attenzione di tanto in tanto.

Nella maggior parte dei casi, Access fornisce blocchi di record, e blocchi di file per alcuni DDL (ad esempio le modifiche dello schema) per impostazione predefinita.

Ma Microsoft è praticamente obsoleto, e alcuni dei suoi colleghi Accumulerò disprezzo su di voi per il suo utilizzo.

(A questo punto io di solito anatra per copertura e urlare "INCOMING !!!".)

Answer 4

L'accesso è davvero un desktop, soluzione di singolo utente. In pratica, si ha un limite superiore di utente "uno".

E 'anche un motore locale. Cioè, quando si esegue una query, i dati è tirato attraverso la rete al motore JET locali per l'elaborazione. Un file ldb è posto sulla condivisione di rete per serrature di controllo.

Se si utilizza un motore lato server (MSSQL, MySQL, Sybase, 'Orable ecc) allora si inoltrano una richiesta di un motore che elabora e restituisce i risultati a voi. Serrature si svolgono internamente.

Questo ha enormi implicazioni per le prestazioni, la stabilità e l'integrità dei dati.

Se l'utente decide per premere il pulsante di reset, il databse di accesso ha una buona possibilità di essere danneggiato e dovrete eliminare il ldb.

Con un motore di database corretto (MSSQL, Sybase, 'Orable: Non mi piace backup di MySQL), allora si anche una funzionalità di backup adeguato. A meno che non si dispone di alcuni software per il backup whizzy inuse file, è possibile avrete alcun backup di voi i dati nel DB di accesso.

ho già detto le serrature in particolare perché un motore di db può gestire la concorrenza e la transazione molto più efficiente ed elegante di qualsiasi altro sistema basato su file.

Posso vedere con un progetto di Access come front-end per un motore di database, ma non investire in un'applicazione client completo con un backend di accesso.

Answer 5

Sono stato con Access, o più propriamente, Jet come back-end su una piccola, sito privato che non potrà mai crescere come si è limitata dalle dimensioni di una professione in questo piccolo paese. In tre anni non ho avuto alcun problema. Ci sono meno di 100 utenti, con circa trenta-quaranta che utilizzano ogni giorno. I tavoli hanno qualche migliaio di record.

Answer 6

Non ho molta esperienza con Access, ma questo link può essere utile a voi:

http://office.microsoft.com/en-us/access /HP052408601033.aspx

"Si può mettere l'intero database Access su un server di rete o in una cartella condivisa. Questo è il metodo più semplice da implementare. Tutti condividono i dati e utilizza le stesse maschere, report, query, macro e moduli. Utilizzare questa strategia, se si vuole a tutti di utilizzare il database di Access nello stesso modo o se non è in grado di supportare gli utenti di creare i propri oggetti. "

"Quando si apre un file di database di Access (.mdb) in modalità condivisa, Microsoft Access crea anche un file di informazioni di blocco (ldb) con lo stesso nome file (ad esempio, Northwind.ldb) e nella stessa cartella il file di database. questo file di informazioni di blocco memorizza il nome del computer (come MyPC) e il nome di protezione (come Admin) di ogni utente condivisa del database. Microsoft Access utilizza queste informazioni per controllare la concorrenza. Nella maggior parte dei casi, Microsoft Access elimina automaticamente il blocco file di informazioni quando l'ultimo utente chiude il file di database ".

Answer 7

L'accesso dovrebbe essere multi-utente - Penso che Microsoft consiglio per un massimo di 4 o 5 utenti, ma in pratica mi consiglia che non si utilizza mai un database di Access in cui v'è più di un singolo utente, anche se davvero non ha la scelta è accettabile per due o tre, dato certe condizioni.

Ho avuto esperienza di quattro o cinque sistemi che utilizzano un database di Access di back-end - tutti acquisiti da altri sviluppatori '' - e in tutti i casi li ho spostati a SQL Server come una priorità, dopo tutti gli aggiornamenti immediati e correzioni necessarie quando prendendo il contratto - generalmente appena ho potuto parlare il capo pagare il conto in esso. Intervallo di tempo per questo è di solito diversi mesi, così ho visto in esecuzione simultanea per un periodo di tempo ragionevole in diverse applicazioni.

In realtà è generalmente funzionerà passabile bene se il sistema non ha un sacco di concomitante inserti / update e non è molto utilizzato. I problemi pratici principali nella mia esperienza sono ..

1. E 'responsabile per la corruzione - lo fa solo. In genere questo non è troppo di un problema, come l'apertura del file e l'esecuzione di compattazione e riparazione risolvere i problemi, ma un buon regime di backup è assolutamente essenziale.

2. E 'lento. Ogni volta che ho aggiornato un sistema per SQL Server Ho ricevuto un sacco di complimenti per velocizzare il sistema da parte degli utenti.

3. Il file di database bloats a causa del modo che Access segna record come aggiornati o cancellati. Questo rallenta ulteriormente il sistema del file deve essere caricato attraverso la rete. Di conseguenza, un certo regime che comprime i dati, in genere su base giornaliera, è essenziale.

Tutto quanto sopra sono molto meno di un problema con i sistemi degli utenti singoli come le questioni di fondo che spingono questi sono molto meno evidenti.

Tutto sommato devo sottolineare che io consiglierei mai di accesso per qualsiasi sistema multi-utente. Tuttavia, se davvero troppo probabilmente otterrete via con esso fino a quando si tratta di un'applicazione usato leggermente e si fa istituire le procedure di backup e di manutenzione.

Answer 8

E 'già stato detto più volte di utilizzare un vero e proprio multi-utente, piattaforma di database gratuito. Ma una delle ragioni per le quali non è stato indicato. Questa ragione è, quanti esistenti, disordinato, fastidiosi, grandi database di Access hanno iniziato come "alcuni record, uno o due utenti max"? Mi permetto di dire tutti loro.

A meno che non ci sono solo due o tre dipendenti in tutta l'azienda, le probabilità sono che se si sviluppa una parte utile del software, che sta per essere eventualmente utilizzato da più di l'originale due o tre utenti, hanno più rispetto all'originale poche migliaia di record, e si espanderà nel corso degli anni per includere molte forme, molte più tavoli, e molti più dati. Non si può rifare le fondamenta di una casa una volta che la casa è costruita. Creare una base solida di oggi, ed è possibile espandere la casa al contenuto del vostro cuore. Lo stesso vale per il software.

Answer 9

Quando si va con una condivisione di rete Vorrei andare con un database di rete abilitata (mysql / Firebird / mssql) invece di accesso.

Per la situazione che descrive il vostro usando l'accesso non sarebbe un problema.

Ho usato accesso nelle situazioni più impegnative allora questo soprattutto quando si lavora con i siti web quando Access non è abusato oltre misura in realtà non è così male di un motore di database. (Non parliamo di forme e cose del genere solo tabelle e record)

Quando i vostri inserti facendo / aggiornamenti / eliminazioni da più utenti contemporaneamente, allora diventa un po 'pelosa. Questo è il punto in cui si inizia a pensare a motori di database reali.

Anche quando si desidera una bassa base di dati in testa che è thread-safe si può dare un'occhiata a VistaDB (più lento di accesso, non sempre libero, 100% NET)

Credo di accesso utilizza blocchi a livello di tabella con qualche tipo di queeing cose meccanismo dovrebbe funzionare bene. Se il vostro preoccupato si può sempre buttare un test di stress simulato a questo.

Answer 10

Penso che si può definire nella stringa di connessione NET. Ho cercato su google per JET, l'accesso e la registrazione di bloccaggio

Ecco un link che potrebbe aiutare.

Si prega di consultare la risposta accettata per i dettagli reali su come Access e Jet ottenere i dati.

Answer 11

Si prega di non utilizzare Access per uno scenario multi-utente.

Ho appena passato attraverso due settimane di dolore perché il mio predeccessor su un progetto scelto Access come back-end.

ragioni concrete:

• Non v'è alcuna cosa come LINQ-to-Access
• Accesso ha numerose stranezze come dipendenze l'ordine di aggiunta dei parametri ai comandi che vi porterà le età a debug
• Accesso non scala
• aggiornamenti del database sono un lavoro di routine, rispetto all'utilizzo di SQL Server