Problemi con l'utilizzo di MS Access come front-end per il back-end di un database MySQL?

StackOverflow https://stackoverflow.com/questions/5842

  •  08-06-2019
  •  | 
  •  

Domanda

Due utenti desideravano condividere lo stesso database, originariamente scritto in MS Access, senza entrare in conflitto tra loro su un singolo file MDB.

Ho spostato le tabelle da un semplice database MS Access a MySQL utilizzando il suo file Kit di strumenti per la migrazione (che funziona bene, tra l'altro) e imposta Access per collegarsi a quelle tabelle tramite ODBC.

Finora, mi sono imbattuto in quanto segue:

  • Non è possibile inserire/aggiornare/eliminare righe in una tabella senza una chiave primaria (nessuna sorpresa in questo).
  • I campi di numerazione automatica in MS Access devono essere la chiave primaria o finiranno semplicemente come colonne intere in MySQL (natch, perché non dovrebbe essere il PK?)
  • Le tabelle sono state migrate al tipo di tabella InnoDB di MySQL, ma le relazioni di accesso non sono diventate vincoli di chiave esterna di MySQL.

Una volta che il database è in uso, posso aspettarmi altri problemi?In particolare quando entrambi gli utenti lavorano nella stessa tabella?

È stato utile?

Soluzione

Avevo un'applicazione che funzionava allo stesso modo:un frontend MS Access a un backend MySQL.È stata una sofferenza così grande che ho finito per scrivere un frontend Win32.Dall'alto della mia testa, ho riscontrato i seguenti problemi:

  • Lo sviluppo del collegamento ODBC sembra essere cessato da tempo.Ci sono varie versioni differenti in giro --- molto confuse.Il collegamento ODBC non supporta Unicode/UTF8 e ricordo che c'erano anche altri problemi (anche se alcuni potevano essere risolti con un'attenta configurazione).
  • Probabilmente vorrai modificare manualmente il tuo schema database per renderlo compatibile con MS Access.Vedo che hai già scoperto le chiavi surrogate necessarie (ad esempio, le chiavi primarie int) :-)
  • Dovresti tenere presente che potrebbe essere necessario utilizzare query pass-through per eseguire manipolazioni SQL più sofisticate del database MySQL.
  • Fai attenzione all'utilizzo di molto VBA, poiché ciò tende a corrompere il file frontend.Comprimendo regolarmente il database (usando il menu principale, Strumenti | Utilità database | Comprimi e ripristina, o qualcosa del genere --- Sto usando la versione olandese) e creando molti di backup è necessario.
  • L'accesso tende a causare molto traffico di rete.Insomma, un sacco davvero enorme.Non sono riuscito a trovare una soluzione per questo.Si consiglia di utilizzare un monitor di rete se si desidera tenerlo d'occhio!
  • Access insiste nel memorizzare i valori booleani come 0/-1.IMHO, 0/+1 ha più senso e credo che sia il modo predefinito di fare le cose anche in MySQL.Non è un grosso problema, ma se le tue caselle di controllo non funzionano, dovresti assolutamente selezionarle.

Una possibile alternativa sarebbe quella di mettere il backend (con i dati) su un'unità condivisa.Ricordo che questo è ben documentato, anche nella guida.Potresti voler dare un'occhiata alcuni consigli generali sulla suddivisione in frontend e backend E codice che si riconnette automaticamente al backend all'avvio;Posso anche inviarti altro codice di esempio o pubblicarlo qui.

Altrimenti, potresti prendere in considerazione anche MS SQL.Non ho esperienza in merito, ma presumo che funzioni molto meglio insieme a MS Access!

Altri suggerimenti

So che questo argomento non è troppo nuovo, ma solo alcune spiegazioni aggiuntive:

Se desideri utilizzare MS Access in modo efficace, soprattutto con database multiutente più grandi, procedi come segue:

  • dividi il tuo MDB in file di applicazione frontend e backend (solo dati): avrai quindi due file MDB separati.

  • migrare tutte le tabelle con dati e struttura in un database esterno.Può essere:MySQL (funziona molto bene, senza limiti di dimensione del database, richiede alcune competenze in più poiché non è la tecnologia MS, ma è una buona scelta in molti casi - inoltre puoi scalare il tuo backend con più RAM e CPU aggiuntive, quindi tutto dipende dalle tue esigenze e capacità hardware);Oracle (se hai abbastanza soldi o qualche tipo di licenza aziendale) o Oracle 10g XE (se questo non è un problema, la dimensione del database è limitata a 4 GB e utilizzerà sempre 1 GB di RAM e 1 CPU), MS SQL Server 2008 (è un'ottima coppia per avere il frontend MS Access e il backend MS SQL Server in tutti i casi, ma devi pagare per la licenza!- i vantaggi sono:stretta integrazione, entrambe le tecnologie provengono dallo stesso fornitore;MS SQL Server è molto facile da mantenere efficace allo stesso tempo) o Express Edition (stessa storia di Oracle XE - quasi le stesse limitazioni).

  • ricollega il tuo frontend MS Access con il database backend.Se hai selezionato MS SQL Server per il backend, sarà facile come utilizzare la procedura guidata di MS Access.Per MySQL: devi utilizzare i driver ODBC (è semplice e funziona molto bene).Per Oracle: non utilizzare i driver ODBC di Microsoft.Questi di Oracle faranno il loro lavoro molto meglio (puoi confrontare il tempo necessario per eseguire la query SQL da MS Access a Oracle tramite i driver Oracle ODBC e MS Oracle ODBC).A questo punto avrai un solido database backend e un frontend MS Access completamente funzionale: file MDB.

  • compila il tuo frontend MDB in MDE: ti darà molta velocità.Inoltre, è l'unica forma ragionevole di distribuzione dell'applicazione MS Access agli utenti finali.

  • per il lavoro quotidiano: utilizza il file MDE con il frontend MS Access.Per ulteriore sviluppo frontend di MS Access utilizzare il file MDB.

  • non utilizzare componenti ActiveX scritti male per migliorare le capacità del frontend di MS Access.Meglio scriverli tu stesso o acquistare quelli adatti.

  • non credere ai miti secondo cui ci sono molti problemi con MS Access: questo è un ottimo prodotto che può aiutarti in molte occasioni.Il problema è che molte persone credono che sia un giocattolo o che MS Access sia generalmente semplice.Di solito generano molti errori e problemi da soli e per la loro mancanza di conoscenza ed esperienza.Per avere successo con MS Access è importante comprendere questo strumento: questa è la stessa regola, come con qualsiasi altra tecnologia disponibile sul mercato.

Posso dirti che sto utilizzando MS Access abbastanza avanzato con il backend MySQL e sono molto soddisfatto (come sviluppatore che mantiene questa applicazione).Amici miei, anche gli utenti sono soddisfatti poiché si sentono molto a proprio agio con la GUI (frontend), la velocità (MySQL), non hanno problemi con il blocco dei record o le prestazioni del database.

Inoltre, è importante leggere molto sulle buone pratiche e sulle esperienze di altre persone.Direi che in molti casi MS Access è una buona soluzione.Conosco molti sistemi dedicati e personalizzati che sono iniziati come esperimento sotto forma di database MS Access privato (file MDB) e poi si sono evoluti in:MS Access suddiviso (MDE - frontend, MDB - backend) e infine a:Frontend MS Access (MDE) e backend di database "serio" (principalmente MS SQL Server e MySQL).È anche importante che tu possa sempre utilizzare la tua soluzione MS Access come un prototipo funzionante: hai il backend pronto per l'uso nel tuo database (MySQL - supponiamo) e puoi riscrivere il frontend sulla tecnologia che preferisci (soluzione web?forse un'applicazione desktop C#: ciò di cui hai bisogno!).

Spero di aver aiutato alcuni di voi a considerare il lavoro con MS Access.

Saluti, Wawrzynhttp://dcserwis.pl

Gareth Simpson ha commentato:

Se sono solo due utenti, l'accesso dovrebbe fare bene se si inserisce .MDB su un disco condiviso.

Ehm, no.Non esiste un'applicazione di accesso multiutente per la quale ciascun utente non debba avere una copia dedicata del front-end.Ciò significa che ogni utente dovrebbe avere un MDB sulla propria workstation.Perché?Perché gli oggetti nei front-end non si condividono bene (non così bene come le tabelle di dati Jet, anche se in questo scenario non ce n'è nessuno che utilizzi MySQL come back-end).

Gareth Simpson ha continuato:

Credo che gli utenti concorrenti massimi consigliati per l'accesso siano 5, ma a volte l'ho spinto oltre e non sono mai rimasto sbalordito.

No, questo è completamente sbagliato.Il limite teorico per gli utenti di un MDB è 255.Ciò non è realistico, ovviamente, poiché una volta raggiunti circa 20 utenti devi programmare attentamente la tua app Access affinché funzioni bene (anche se le cose che devi fare in un'app Access-to-Jet sono lo stesso tipo di cose che faresti fare per rendere efficiente qualsiasi applicazione di database del server, ad esempio recuperando i set di dati utilizzabili più piccoli).

In questo caso, poiché ogni utente dovrebbe avere una copia individuale dell'MDB front-end, i limiti multiutente di Access/Jet semplicemente non sono affatto rilevanti.

So che questo non risponde direttamente alla tua domanda, ma potrebbe valere la pena dare un'occhiata a Strumento di migrazione di SQL Server 2005 per Access.Non ho mai utilizzato lo strumento, ma potrebbe valere la pena utilizzarlo con SQL Server 2005 Express Edition per vedere se ci sono gli stessi problemi riscontrati con MySQL

Non dimenticare di inserire un timbro di data/ora su ciascun record.a volte MS Access penserà che "un altro utente ha modificato o eliminato il record" e non ti consentirà di apportare una modifica!L'ho imparato a mie spese.

In generale dipende :)

Non ho avuto molti problemi quando il lato dell'applicazione ha semplicemente aggiornato i dati tramite i moduli.Puoi ricevere avvisi/errori quando la stessa riga è stata aggiornata da più di un utente;ma Access sembra aggiornare costantemente i suoi set di record live.

Possono verificarsi problemi se Alice sta già lavorando con il record 365 e Bob lo aggiorna, quindi Alice tenta di aggiornarlo con le sue modifiche.Se ricordo bene, Alice riceverà un messaggio di errore criptico.Sarebbe più semplice per gli utenti intercettare questi errori e almeno fornire loro un messaggio di errore più amichevole.

Ho avuto più problemi durante la modifica dei record nel codice VB tramite RecordSets, soprattutto se combinato con la modifica degli stessi dati sui moduli.Questo non è necessariamente un problema multiutente;tuttavia, hai quasi la stessa situazione perché hai un utente con più connessioni agli stessi dati.

Se si tratta solo di due utenti, Access dovrebbe funzionare correttamente se metti il ​​file .mdb su un'unità condivisa.

L'hai provato prima invece di dare per scontato che sarà un problema.

Credo che il numero massimo di utenti simultanei consigliati per Access sia 5, ma a volte l'ho superato e non mi sono mai sbloccato.

D'altra parte una volta ho utilizzato Access come front-end di MySQL in un ambiente a utente singolo (io).È stata un'esperienza singolarmente spiacevole, non riesco a immaginare che sarebbe diventata più bella con due utenti.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top