[access] snelheid gelinkte tables

[Paxlie]

Dag mensen,

kwam ik weer met volgende vraag. Ik heb een database, echter, deze bestaat eigenlijk uit meerdere databases die al in gebruik zijn. Deze databases kan ik niet gelijk aanspreken, maar moet ik linken, om dubbele waardes te voorkomen.

Nu is mij het opgevallen dat dit snelheid er gigantisch uithaalt. Weet iemand hier oplossingen voor, of is dit gewoon gigantisch langzaam?

En nee, de gelinkte databases bevatten niet 398648 entries en staan op dezelfde harde schijf als diegene waarvandaan ik dit type.......

[Verwijderd]

Mijn ervaring met Access databases is dat ze altijd sloom zijn...

[Verwijderd]

sja, misschien overstappen van dbms ?

[Paxlie]

Ik weet dat het per definitie sloom is

Het probleem is alleen dat ik het MOET maken in Access....
Dus was mijn vraag meer van, hoe gaan we dit zo snel mogelijk krijgen?

[Verwijderd]

Andere oplossing is repliceren naar je "verzamel" database.

En dan alleen de juiste gegevens. Probleem is natuurlijk wel dat je moet controleren of je alle gegevens hebt en dat je goede replicatie scriptjes moet schrijven.

Maar je gaf zelf al aan dat het op 1 machine draait dus dat valt weer mee.

Wellicht helpt dit je verder

[Paxlie]

Uiteindelijk gaat het van meerdere machines afkomen, dat was alleen om aan te geven dat het niet aan de connectie lag

Maar hoe bedoel je repliceren? Met repliceer-scriptjes? Jij zegt dus eigenlijk dat ik gewoon de database moet kopieren, als ik het goed begrijp. Dat gaat volgens mij ook problemen opleveren, aangezienje dan bij terugkoppelen mogelijke dubbele velden gaat krijgen als er meerdere mensen met dat ding gaan werken.

Kweet ut, Access zuigt echt qua snelheid, maar die snelheid zou ik alsnog zo hoog mogelijk willen houden.

[Verwijderd]

Access is, wanneer gebruikt voor het doel waarvoor het is ontworpen, allerminst langzaam.
Bovendien zuigt het niet.

Een paar dingen moet je weten om de zaak snel te houden (blijkbaar heb je niet voldoende gelezen over de manier waarop access werkt)

ten eerste moet je je realiseren dat de client in dit geval ook de server is.
dat heeft grote consequenties als je bijvoorbeeld een multiuser applicatie gaat maken die over een netwerk moet kunnen communiceren.
Omdat access zowel de client als de server is zal bij het maken van een query op de database wel eerst de hele tabel over het netwerk moeten alvorens de selectie kan worden gemaakt.
Dit kan bijzonder veel db traffic opleveren als je veel formulieren gebruikt met besturingselementen (dropdowns list/treeviews, listboxen etc) die een querie als bron hebben.
Als de brontabel (of tabellen) groot zijn is dit natuurlijk een enorme performance vreter.

echter als je bijvoorbeeld een access database gebruikt in combinatie met asp (als iis en de database op dezelfde server staan) dan kan access zeer behoorlijk presteren.

een en ander is natuurlijk ook voor een groot deel afhankelijk van het database design.

[Paxlie]

waarom precies ASP
waarom zit er in Access dan de functionaliteit om een applicatie te maken op grond van de eigen database. Ik snap niet echt waarom dat zo moeilijk is om snel te houden. Alles staat GVD lokaal hier op 1 schijf (nog) en tog duurt het af en toe echt gewoon een paar seconden voor hij uberhaupt iets op het scherm tovert.

Het is niet zo dat ik geen ASP kan/wil, maar de mensen hier hebben het graag in Access en daarom wil ik het graag wel snel houden. Er is hier namelijk ook een urenregistratie systeem wat er soms wel 2 uur over doet om alles door te voeren en te berekenen
Dat is dus echt gewoon voor je pc

[Verwijderd]

was maar een voorbeeldje.
in een asp pagina gebruik je geen controls gebound aan een querie.
daardoor ben je je als ontwikkelaar veel meer bewust van de hoeveelheid queries die je uitvoert op de database.
dat heeft tot gevolg dat er minder data wordt opgehaald (de mens is van nature lui)

[Paxlie]

jah, ok
maar door goed gebruik van queries los je dat probleem tog ook op?
Daar ligt het probleem volgens mij namelijk niet, volgens mij zit het probleem meer in Access zelf
en waarschijnlijk zoals je al zei in het client&server gebeuren

Toch lijkt het mij niet onmogelijk om Access loei-snel te krijgen, want een andere ontwikkelomgeving lukt het ook, dus is het een kwestie van andere dingen. Volgens mij ligt het voor een groot gedeelte dus aan Access

[Verwijderd]

heb je dat getest of is dat je vrouwelijke intuitie ?
het verschil in een kleinschalige applicatie (daar is access voor bedoeld namelijk....als desktop engine) is misschien wel meetbaar maar niet merkbaar.
je moet de telefoongids niet in access querien.
net zomin als een huishoudboekje in oracle dat weet ieder kind.

(het punt met gekoppelde tabellen is bovendien nog eens dat die door de jet engine worden afgehandeld. wat dat voor consequenties heeft mag jij me vertellen ;-)

[Paxlie]

Kan je weinig vertellen over de JET engine, behalve dat die wel suckent is. Die trekt echt gigantisch de performance omlaag .

Verder heb ik wel wat ervaring met Access, alleen toen maakte het echt niet uit wat de performance was. Hier zullen uiteindelijk ook niet veel records komen, op 1 tabel na. Deze zal uiteindelijk echt helemaal vol met records zitten. De rest wordt allemaal uit andere tabellen.

Aangezien die JET engine dus gewoon compleet is, vroeg ik mij eigenlijk af of er niet andere methoden waren om de tabellen in Access te krijgen, zonder gebruik te maken van de JET-engine

[kenneth]

MSDE?

[Verwijderd]

Paxlie : je lult maar wat.

[Paxlie]

Keej, ik heb het ff snel uitgezocht met hulp van wat mensen en dit is wat ik er wijzer van ben geworden:

Jet-engine == db-engine
Access == GUI
ASP == GUI

Beide GUI gebruiken dezelfde engine, dan is ASP tog sneller, dit snap ik dus niet helemaal. Als je mij dat kan uitleggen, zou ik dat heel erg aardig van je vinden en je had idd gelijk over me vorige posting. Ik had nog niet genoeg gesearched toen.