Probleme care utilizează MS Access ca un front-end la o bază de date MySQL back-end?

Doi utilizatori au dorit să partajeze aceeași bază de date, inițial scrisă în MS Access, fără a se contrazice una cu cealaltă pe un singur fișier MDB.

Am mutat tabelele dintr-o bază de date MS Access în MySQL utilizând Toolkit pentru migrarea (care funcționează bine, apropo) și configurați accesul pentru a conecta la aceste tabele prin ODBC.

Până în prezent, am parcurs următoarele:

  • Nu puteți introduce / actualiza / șterge rândurile într-un tabel fără o cheie primară (nu este o surpriză acolo).
  • Câmpurile AutoNumber în MS Access trebuie să fie cheia primară sau vor ajunge doar ca coloane întregi în MySQL (natch, de ce nu ar fi PK?)
  • Tabelele au fost migrate la tipul de table InnoDB al MySQL, dar relațiile de acces nu au devenit constrângeri Cheie străină MySQL.

Odată ce baza de date este în uz, mă pot aștepta la alte probleme? În special atunci când ambii utilizatori lucrează în același tabel?

0
fr hi bn

5 răspunsuri

Dacă este vorba doar de doi utilizatori, atunci accesul ar trebui să se facă bine dacă puneți .mdb pe o unitate partajată.

Ați încercat mai întâi mai degrabă decât să presupuneți că va fi o problemă.

Cred că utilizatorii recomandați pentru accesul max pentru Access sunt 5 dar, ocazional, l-am împins peste asta și nu am reușit niciodată să fiu dezamăgit.

Pe de altă parte, am folosit o dată pe Access ca un front-end la MySQL într-un singur mediu de utilizator (eu). A fost o experienta unica neplacuta, nu imi pot imagina ca ar deveni mai frumoasa cu doi utilizatori.

0
adăugat

I know this doesn't answer your question directly, but it might be worth checking out the SQL Server 2005 migration tool for Access. I've never used the tool, but it might be worth using with SQL Server 2005 Express Edition to see if there are the same issues as you had with MySQL

0
adăugat

În general, depinde :)

Nu am avut multe probleme când partea de aplicație tocmai a actualizat datele prin formulare. Puteți primi avertismente / erori atunci când același rând a fost actualizat de mai mulți utilizatori; dar Access pare să-și actualizeze în permanență seturile de înregistrări live.

Problemele se pot întâmpla dacă Alice lucrează deja cu înregistrarea 365, iar Bob o actualizează, iar apoi Alice încearcă să o actualizeze cu schimbările ei. După cum îmi amintesc, Alice va primi un mesaj de eroare criptic. Ar fi mai ușor pentru utilizatori să prindeți aceste erori și cel puțin să le oferiți un mesaj de eroare mai prietenos.

Am avut mai multe probleme când editam înregistrări în codul VB prin RecordSets, mai ales atunci când am combinat cu editarea acelorași date pe formulare. Aceasta nu este neapărat o problemă cu mai mulți utilizatori; cu toate acestea, aveți aproape aceeași situație, deoarece aveți un singur utilizator cu mai multe conexiuni la aceleași date.

0
adăugat

Am avut o aplicație care a funcționat la fel: un frontend MS Access la un backend MySQL. A fost o durere atât de mare încât am ajuns să scriu în schimb un interfață Win32. Din partea de sus a capului meu, am întâlnit următoarele probleme:

  • Dezvoltarea legăturii ODBC pare să fi încetat de mult. Există diferite versiuni diferite care plutesc în jurul valorii de --- foarte confuze. Legătura ODBC nu suportă Unicode / UTF8 și îmi amintesc că există și alte probleme legate de acesta (deși unele ar putea fi depășite printr-o configurație atentă).
  • Probabil doriți să optimizați manual schema db pentru ao face compatibilă cu MS Access. Văd că ați aflat deja despre cheile de înlocuire necesare (adică, cheile primare int): -)
  • Ar trebui să rețineți că este posibil să fie necesar să utilizați interogări pass-through pentru a face manipulări SQL mai sofisticate ale bazei de date MySQL.
  • Aveți grijă să utilizați o mulțime de VBA, deoarece acest lucru tinde să vă corupe fișierul frontend. Este necesară comprimarea regulată a bazei de date (folosind meniul principal, Instrumente, utilitare de baze de date, comprimare și restaurare sau ceva de genul ăsta, folosesc versiunea olandeză) și crearea de copii li>
  • Accesul tinde să provoace o mulțime de trafic în rețea. Ca niște loturi foarte mari. Nu am reușit să găsesc o soluție pentru asta. Utilizarea unui monitor de rețea este recomandată dacă doriți să fiți atenți la asta!
  • Accesul insistă asupra stocării booleanelor ca 0 / -1. IMHO, 0 / + 1 face mai mult sens, și cred că este modul implicit de a face lucruri și în MySQL. Nu este o problemă enormă, dar dacă căsuțele dvs. de selectare nu funcționează, trebuie să verificați cu siguranță acest lucru.

O posibilă alternativă ar fi punerea backend-ului (cu datele) pe o unitate partajată. Îmi amintesc că acest lucru este bine documentat, de asemenea în ajutor. Poate doriți să aruncați o privire la câteva sfaturi generale despre împărțirea într-un frontend și un backend și < un cod href = "http://allenbrowne.com/ser-13.html" rel = "noreferrer"> care se reconectează automat la backend la pornire ; De asemenea, vă pot trimite un cod de eșantion mai multe sau postați-l aici.

În caz contrar, este posibil să doriți să luați în considerare și MS SQL. Nu am nici o experiență în acest sens, dar presupun că funcționează împreună cu MS Access mult mai bine!

0
adăugat

Gareth Simpson a opinat:

Dacă sunt doar doi utilizatori, atunci Accesați   ar trebui să facă bine dacă puneți   .mdb pe o unitate partajată.

Nu, nu. Nu există nicio aplicație de acces pentru mai mulți utilizatori, pentru care fiecare utilizator nu ar trebui să aibă o copie dedicată a capătului frontal. Asta înseamnă că fiecare utilizator ar trebui să aibă un MDB pe stația lor de lucru. De ce? Deoarece obiectele din front-end nu se împărtășesc bine (nu aproape la fel de bine ca și tabelele de date Jet, deși nu există nici unul dintre aceștia în acest scenariu, folosind MySQL ca și spate).

Gareth Simpson a continuat:

Cred că max   utilizatorii concurent pentru Acces este de 5, dar   uneori l-am împins peste asta   și nu vină niciodată dezlegat.

Nu, acest lucru este complet incorect. Limita teoretică pentru utilizatorii unui MDB este 255. Aceasta nu este realistă, desigur că odată ce ajungi la aproximativ 20 de utilizatori, trebuie să programați cu atenție aplicația dvs. de acces pentru a funcționa bine (deși lucrurile pe care trebuie să le faceți într-o aplicație Access- Aplicația Jet sunt aceleași lucruri pe care le-ați face pentru a face ca orice aplicație de baze de date a serverului să fie eficientă, de exemplu, pentru a recupera cele mai mici seturi de date utilizabile).

În acest caz, deoarece fiecare utilizator ar trebui să aibă o copie individuală a MDB-ului frontal, limitele multi-utilizator ale Access / Jet nu sunt deloc relevante.

0
adăugat
MySQL - comunitatea Română
MySQL - comunitatea Română
19 participanți

Comunitatea română a programatorilor MySQL.