[MySQL] Microsoft Access

[TheGhostInc]

De titel is enigszins dubbel, maar ik heb het volgende probleem:

Een complete "FrontEnd" voor een access database draait hier, maar die is echt gewoon niet vooruit te branden met een standaard access database.
Nu willen ze migreren naar MySQL (of msSQL), maar nu is mijn vraag, kan dit, kan msAccess werken met een MySQL database?
(En dan niet converteren ed. dat is wel te vinden op internet)

De frontend vervangen zou een paar maanden programmeerwerk opleveren, en is dus echt geen optie. Misschien op de langere termijn een keertje.

Wat is trouwens een alternatief voor Access op het gebied van de leuke forms.
(het werkt redelijk fijn, alleen zo TRAAG)

[Verwijderd]

Je kan een ODBC koppeling maken met de mysql databse (te downen via de mysql site).

Ik heb zelf een site en gebruik daarbij een Mysql database. De surfers zien alles middels php en ik zelf kijk met Access in de databse en doe daarmee ook alle handelingen ala wijzigingen, toevoegingen...je kent het wel

[Martin Sturm]

Je kunt via ODBC wel tabellen in MySQL benaderen vanuit Access. Alleen ik vraag me af of je programma dan nog wel helemaal werkt. MySQL heeft namelijk een mindere integratie dan Access. MsSQL is wellicht een beter alternatief . Ideaal zou zijn wanneer je je applicatie naar Visual Basic kan converteren, en dan gewoon via ODBC benaderen.. Heb je niet de overbodige Access rommel meer

[TheGhostInc]

Ideaal zou zijn wanneer je je applicatie naar Visual Basic kan converteren,

Is dit een beetje te doen, ik snap heel goed dat het hele programma het in VB ook doet , maar mij gaat het er meer om hoeveeltijd dit gaat kosten.
Is het een kwestie van 95% goed, en even wat fouten op sporen, of is het compleet opnieuw coden, met 5% copy/paste werk?

[mulder]

Dus je wilt een Access front-end op een mysql db. Dan ga je er dus van uit dat de access db langzaam is. Snap het niet echt, denk dat het front-end omzetten naar vb sneller is, en een goede blik op je datamodel.

[Glimi]

De moderne Access versies hebben ook een upsizing wizard. Daarmee kun je naar msSQL migreren zonder (al te veel) problemen. Je kan eerst de backend splitsen van je frontend (daar is zelfs ook een wizard voor) en dan je backend upsizen naar msSQL.

Qwerios

[TheGhostInc]

Access is niet langzaam.... standalone, maar draai het maar eens over een netwerk... als dikke
Groot probleem is het recordvergrendeling, dat gaat gewoon niet goed, en dat is echt backend.

Maar dit was alvast zeer nuttig, mijn dank is groot.

[sweetdude]

je zou het tijdelijk kunnen oplossen door op 1 pc de access database geopend te houden. Heb dit probleem van langzame grote dtabases nog al eens meegemaakt en dit is ook de oplossing van de MS helpdesk.

[Boss]

sweetdude schreef op 02 augustus 2002 @ 15:24:
je zou het tijdelijk kunnen oplossen door op 1 pc de access database geopend te houden. Heb dit probleem van langzame grote dtabases nog al eens meegemaakt en dit is ook de oplossing van de MS helpdesk.

Daar heb ik echt nog nooit van gehoord. Werkt dat echt? Weet je ook hoe het komt? Ik werk erg veel met Access en hoewel ik nooit echt trage db's heb meegemaakt, ben ik wel nieuwschierig naar deze methode...

[sweetdude]

zover ik weet komt dat omdat die pc dan de database geopend heeft en op de een of andere mannier werkt access dan sneller met recordvergrendeling op het moment dat een 2de pc (2de gebruiker) de database gaat openen en wijzigingen in gaat aanbrengen. Ik weet het de eerste keer dat ik het hoorde geloofde ik het ook niet maar het schijnt toch te werken.

[Vigory]

Glimi schreef op 02 augustus 2002 @ 14:56:
De moderne Access versies hebben ook een upsizing wizard. Daarmee kun je naar msSQL migreren zonder (al te veel) problemen. Je kan eerst de backend splitsen van je frontend (daar is zelfs ook een wizard voor) en dan je backend upsizen naar msSQL.

Dat heb ik ook een keer voor een klant gemaakt. Je krijgt dan een .adp file (i.p.v. .mdb). Ik kan uit ervaring vertellen dat je erg veel problemen mee krijgt en bugvrij is het ook niet. Het beste kan je volgens mij in VB of Delphi de applicatie opnieuw bouwen met mySQL of MS SQL backend.

[TheGhostInc]

sweetdude schreef op 04 augustus 2002 @ 18:31:
zover ik weet komt dat omdat die pc dan de database geopend heeft en op de een of andere mannier werkt access dan sneller met recordvergrendeling op het moment dat een 2de pc (2de gebruiker) de database gaat openen en wijzigingen in gaat aanbrengen. Ik weet het de eerste keer dat ik het hoorde geloofde ik het ook niet maar het schijnt toch te werken.

Het schijnt idd. in sommige situaties te werken.
Dit heeft vooral te maken als je continu korte verbindingen met de database hebt, want dan is het sluiten van de database en het openen telkens een tijdrovende bezigheid.
Maar in dit geval staat de database ook continu open, en hoe meer mensen erin zitten hoe trager hij wordt.
(en nee, dat is niet omdat de machine het niet trekt, maar op een gegeven moment gewoon tien of meer seconden moeten wachten voordat er even een dropdown box is gevuld is *NIET* acceptabel. Een dual PIII 500 met een sloot geheugen zou geen problemen moeten geven)

[TheGhostInc]

Vigory schreef op 04 augustus 2002 @ 23:07:
[...]
Dat heb ik ook een keer voor een klant gemaakt. Je krijgt dan een .adp file (i.p.v. .mdb). Ik kan uit ervaring vertellen dat je erg veel problemen mee krijgt en bugvrij is het ook niet. Het beste kan je volgens mij in VB of Delphi de applicatie opnieuw bouwen met mySQL of MS SQL backend.

aah, daar hebik iets aan

Ik ga deze week een poging wagen, ik laat het in dit topic nog wel even horen of het goed is gegaan. (tenzij iemand daar een bezwaar tegen heeft )

[TheGhostInc]

Allereerst de resultaten:
Het basispakket MySQL + de ODBC driver werken prima, aangezien er geen specifieke toestanden gebruikt worden werkt dit perfect. Mbv. een extra tooltje (MyAccess) kon ik de tabellen ook nog eens makkelijk overzetten.
Eventueel kan dat ook handmatig, het werkte allemaal als een trein.... en toen...

Toen kwamen de benchmarks, let niet op het profesionele karakter van deze benchmark
(met mijn horloge MET seconde teller bepaald hoelang een vensters erover deed te laden)
Oorspronkelijk (standalone Access): 7 seconden
Enkele tabel op remote server: 7 seconden
Alle tabellen op remote server: 18 seconden

Nu valt het op dat zowel de remote als de client gewoon lange tijd full-load staan (celli 500 en 466), de database server (MySQL/Linux/celli500) heeft zeer veel moeite de queries een beetje vlot af te handelen, Access lijkt nogal veel lompe queries te sturen.
(van de 18 seconden is dan gewoon 10 seconden query tijd)
Daarnaast heeft de client met Access ook nogeens heel veel tijd nodig om de gegevens te verwerken.

Ook was bij een herbereking van wat velden de Client gedurende een minuut of 3 Full-load aan het rekenen, hierbij was de netwerkload hoog (20-30mbit/s).

Heeft iemand hier ervaring mee, kan het gewoon een instelling zijn van de ODBC driver?

* TheGhostInc weet nu niet of het probleem van meerdere gebruikers is opgelost, maar traag is het nu zeker