MS Access (JET) è adatto all'accesso multiutente?

Question

Ho un prodotto progettato per essere un prodotto desktop che utilizza il file MS Access come DB.

Ora, alcuni utenti devono installarlo su alcuni PC (diciamo 2 o 3) e CONDIVIDERE il database.

Pensavo di posizionare il file MS Access in una cartella condivisa e accedervi dal PC, ma...il JET Engine è progettato per l'accesso di più utenti?

Qualche consiglio o cosa da tenere presente per farlo?

MODIFICARE:L'app è .net e utilizza il database come spazio di archiviazione (non utilizza il database come frontend)

Answer 1

C'è tanta disinformazione nelle risposte in questa discussione che non so da dove cominciare. Ho appena trascorso 4 punti reputazione votando le risposte con informazioni fuorvianti e sbagliato in loro.

1. il motore di database Jet (che è tutto ciò che è coinvolto qui, come il PO chiarito con una modifica) è di default multi-utente -. È stata costruita da zero per essere in questo modo

2. la condivisione di un archivio di dati Jet è molto affidabile quando la rete non è inferiore alla media. Questo non significa che una rete WAN e non wireless, perché la larghezza di banda deve essere sufficiente per Jet per mantenere il file LDB (per la chiusura multi-utente), il che significa che un ping da un'istanza del PC locale del motore di database Jet una volta al secondo (con impostazioni di default), e perché Jet non è possibile recuperare da una connessione caduto (che è abbastanza comune in un ambiente wireless).

3. la situazione in cui cade accesso è quando un'applicazione di Access front-end MDB è condivisa (che non è il caso di questo poster). La ragione non riesce è perché stai condividendo le cose che non possono essere condivisi in modo affidabile e non hanno motivo di essere condiviso. A causa del modo in cui gli oggetti di Access vengono memorizzati in un file MDB (l'intero progetto di Access è memorizzato in un singolo campo BLOB in un record in una delle tabelle di sistema), è molto incline alla corruzione se più utenti aprirlo. A mio avviso, la condivisione di un front-end di accesso (o un unsplit MDB con le tabelle e le forme / reports / ecc. Tutti in un MDB) è la fonte per il 99,99% di corruzione del file / Jet di Access.

La mia risposta semplice alla domanda del PO è che, sì, Jet sarebbe un grande archivio di dati per un app di quelle dimensioni. Tuttavia, se c'è qualche possibilità a tutti per la popolazione degli utenti di crescere al di sopra di 25, allora potrebbe essere meglio per iniziare da zero con un motore di database che è più solido a elevate popolazioni di utenti.

Answer 2

E 'perfettamente fattibile per fare questo; ma è necessario dividere il database in un front-end (con maschere, query, codice) e un back-end (solo dati). Ogni utente deve avere il front-end sul proprio computer, che collega al back-end comune.

Sarà lento come Jet genera una tonnellata di traffico di rete. Microsoft sta anche gradualmente deprecato Access come strumento di sviluppo. Access 2007, per esempio, ha un modello di sicurezza molto meno sofisticato di Access 2003.

Come un lungo tempo di accesso sviluppatore sto gradualmente allontanando da Access.

Answer 3

Non farlo ... il database Jet sostiene di essere in grado di supportare più utenti, ma è incredibilmente facile da utilizzare la procedura guidata upsize per convertire il file di accesso a un database SQL Express. Questo file di database potrebbe facilmente diventare bloccato da un utente o amministratore, e tutti gli utenti sarebbe in grado di utilizzare il database.

SQL Express è libero . Il vostro percorso di aggiornamento da lì a un'istanza completa di SQL Server o di qualche altro database commerciale è semplice.

Answer 4

Con 2 o 3 utenti su una rete locale affidabile si dovrebbe andare bene, fino a quando si torna la rete guida fino spesso.

Evitare i campi bit / bool nelle tabelle -. Jet ha alcuni problemi di corruzione brutto con accesso multiplo a loro

Anche tenere a mente che tutto il blocco in Access è ottimista:. Otterrete letture sporche di tanto in tanto

MS Access è stato progettato per i piccoli scenari di ufficio come questo:. Uso non critico ufficio luce che è possibile impostare con il minimo di programmazione

Si aspettano il file di dati per ottenere danneggiato ogni tanto -. Back up regolari

Answer 5

Il motore ACE / Jet è un grande pezzo di software ma, mentre era creazione per supportare più utenti, in realtà sostenendo più utenti in pratica non è uno dei suoi punti di forza. L'ultima goccia per me è dove quindi la sicurezza a livello di utente rimosso (ULS) dal motore: Suppongo che posso immaginare una situazione semplice database in cui tutti gli utenti avranno gli stessi privilegi (vale a dire l'accesso amministratore a tutti di database oggetti) ma IMO non sostiene più utenti così, rispetto, ad esempio, MS SQL Server.

Answer 6

Si, supporta l'accesso da più (vale a dire, un piccolo gruppo di lavoro di dimensioni, numero) di utenti su una condivisione di file di rete. Tuttavia, la quota di architettura file non è semplicemente ideale per supportare la scrittura simultanea su un file da parte di più utenti. Un sistema di database client / server (SQL Server, ecc) generalmente fornisce migliori prestazioni, sicurezza e affidabilità.

Answer 7

Come amministratore di sistema, si prega di non utilizzare Access per qualsiasi cosa multi-utente. Fai quello che suggerisce Jeff Fritz e utilizzare un database che è stato progettato per l'accesso multi-utente. Si potrebbe pensare che la tua piccola applicazione è solo destinato ad essere condiviso tra un paio di persone, ma vi garantisco che si avrà un centinaio di utenti e una cinquantina di nuove funzionalità per la fine dell'anno. E se queste sono tutte di accesso, piuttosto che VB / SQL Express, il tuo Ops si suddivideranno in casa tua una notte e tagliarti la gola.

L'accesso non è un'applicazione client-server, e offre molto poco in termini di backup / ripristino, o qualsiasi automazione di sorta. Per non parlare l'interfaccia e il DB sono molto strettamente accoppiati ... quindi se mai voglia di trasformare questo in una web app, o apportare modifiche gravi, il vostro mondo sarà pieno di dolore.

Answer 8

E 'stato fatto così tante volte da tanti ingegneri del software generico dove abbiamo visto un .mdb andare corrotto in una situazione multiutente. Se tanti esperti sviluppatori di Access specializzati possono farlo bene, come io sono propenso a credere, allora noi generalisti devono essere facendo qualcosa di sbagliato e che qualcosa deve essere abbastanza fondamentale ma non ovvia per tanti di noi di scappare dalla cosa urla 'Mai più!' Quindi, se ti consideri di essere uno sviluppatore di accesso specialista esperto (o si sa come trovare uno) poi andare per esso. Ma se sei un utente generico o informale alla ricerca di un back-end leggero, allora vi suggerisco di cercare altrove (SQL Server è buono IMO).

Answer 9

Se gli utenti possono aspettare il doppio del tempo per un'applicazione con la metà delle caratteristiche che vogliono, allora non utilizzare Access.

Answer 10

Jet non ha la logica di blocco sofisticato necessario per supportare scenari multiutente. Si può farla franca con l'utilizzo di esso se l'applicazione è per lo più si legge e bassa contesa.

siti web

ho visto supportano molti utenti, ma consiglierei SQL Express se non si ha un motivo valido per scegliere Jet.

Answer 11

Posso dirvi per esperienza dolorosa che Jet 3 / 3.5 non era affidabile. L'ho visto in crash frequentemente in condizioni di carico leggero e quando c'erano gli arresti si rischiato la corruzione dei dati. E 'usato per essere estremamente sensibile ad eventuali problemi di alimentazione, qualsiasi client schiantarsi contro di essa (anche l'interfaccia utente collegato al mdb), e gli eventuali problemi LAN. Ulteriori versioni recenti di Jet potrebbe essere migliore, ma il passaggio a SQL Server è chiaramente la strada da percorrere, a mio parere per altro che l'immissione dei dati banale con un piccolo numero di utenti. SQL Express è gratuito e non si perde nulla in realtà, soprattutto se siete interfaccia utente è in Net, piuttosto che di accesso.

EDIT:. Microsoft non pensa si dovrebbe fare affidamento su Jet 4 o

da: http://support.microsoft.com/kb/303528

Microsoft Jet non è indicato per l'utilizzo con applicazioni ad alto stress di server, applicazioni server ad alta concorrenza, o 24 ore al giorno, sette giorni alla settimana applicazioni server. Questo include applicazioni server, come ad esempio le applicazioni Web, applicazioni di commercio, le applicazioni transazionali e applicazioni server di messaggistica. Per questi tipi di applicazioni, la soluzione migliore è quella di passare ad un vero e proprio / sistema di database basato su server client, ad esempio Microsoft Data Engine (MSDE) o Microsoft SQL Server. Quando si utilizza Microsoft Jet in applicazioni ad alta stress come Microsoft Internet Information Server (IIS), è possibile che si verifichi uno dei seguenti problemi: danneggiamento del database problemi di stabilità, come ad esempio crash o bloccarsi IIS guasto improvviso o persistente incapacità del driver per connettersi a un database valido che richiede riavviare il servizio IIS

Answer 12

basta controllare se il file di blocco db (come ldb) è lì o no. Se è lì, qualcuno sta accedendo quel file. Se non è lì, al momento non c'è nessuno che l'accesso ai file e si può procedere. In caso contrario, attendere se tale file (ldb) non è più esistente.

Answer 13

Se usi un Terminal Server, le prestazioni sono davvero buone.Abbiamo più soluzioni fino a 50 utenti in un unico mdb di accesso.Lo sviluppo è davvero veloce e l'implementazione semplice.

I problemi:

• tutti possono copiare i dati mdb
• nessun diritto di accesso
• procedure di negozio limitate
• ottimizzare (comprimere e riparare) possibile solo senza utilizzare il database dei dati
• limite a 2 GB!