Hastighedsproblem access db sql statement på .net side

Indexeret felterne der bliver søgt på?

LIKE %del_af_søgeord% Kræver utroligt mange resurser, da der bliver lavet en full table scan hver gang.

Hej Michael - tak for forslaget. vi har forsøgsvist slettet forespørgslen helt, men desværre gav det ingen mærkbar forbedring.

Hvormeget data ligger der i hver af tabellerne?

Er det muligt at få en kopi af databasen, så man kan teste lidt på den?

Hej softspot - der ligger ca 50 ideer, 25 kommentarer og ca 150 likes. Kan desværre ikke sende db-kopi, da brugerne valideres, og da indholdet er internt for en off.myndighed. Access-databasen fylder sammenlagt 1245kb. vh E

Hvormange kategorier er der? Hvormange rækker indeholder den tabel?

Hvad indeholder tabellen "validering"? Hvormange rækker indeholder den tabel?

Det lyder altså ikke at meget data. Hvad vil det helt konkret sige, at det tager lang tid at vise siden (i sekunder)?

Der er mange steder hvor hastigheden kan påvirkes. Nogle eksempler (ud over databasen):

* koden der genererer indholdet
* siden der genereres (html, script)
* netværket
* serveren (ram, cpu, antal samtidige brugere, belastning i øvrigt)


Er det evt. muligt at vise koden, der genererer siden?

Hvor stor er den side der genereres (i Kb)?

Jeg er usikker på hvormeget Access-driveren optimerer på SQL, men jeg har på fornemmelsen, at det ikke er det store. Derfor er der måske noget at hente ved selv at optimere sin joins der laves, således der joines med færrest mulig rækker til følge og kriterier tjekkes fra simplest først til mest kompleks sidst. Evt. lave et subquery, hvor der kun joines med den mængde data der rent faktisk matcher kriterierne (dvs. subquery inden join).

Noget i stil med dette:


Jeg ved ikke om dette overhovedet fungerer, så det er bare nogle tanker ifht. tiltag man kan arbejde med for at forsøge at optimere selve forspørgslen.

NB: Da der er byttet rundt på rækkefølgen af parametrene i SQL-sætningen, vil den givetvis ikke fungere med den eksisterende kode, så der skal nok også rettes i koden.

Tak Softspot - det var en grundig omgang. Page reload-tiden er ca 30 sek.
vi vil gå igang med at implementere dine forslag. I mellemtiden fandt en kollega muligvis en fejl i .net koden. Det viser sig at forbindelsen til databasen bliver afbrudt ved hver reload. Noget tyder på at det har stor betydning.

Det er meget normalt at forbindelsen afbrydes når man har gjort det der skal gøres (divisen for databaseforbindelser er: forbind sent og frigiv tidligt).

Noget der kan give problemer er, hvis forbindelsen af en eller anden årsag ikke bliver lukket korrekt. Dette kan ske, hvis der opstår en uhåndteret fejl mens forbindelsen til databasen er etableret og den ikke lukkes ifm. fejlen. I skal sikre jer, at opslaget i databasen er omsluttet af enten try-catch-finally kode eller en "using" (i det mindste hvis det er C# - jeg ved ikke hvad den hedder i VB). En "using", i det mindste, vil sørge for at forbindelsen lukkes ned uanset om der opstår fejl eller ej. Med en try-catch-finally er der stadig risiko for at forbindelsen ikke lukkes, men det er da sandsynligt at det sker. Vis evt. koden for opslaget i databasen (eller send den til mig i en intern besked her på eksperten), så kan jeg se om det ser nogenlunde fornuftigt ud.

Jeres grundlæggende problem ligger givetvis i, at Access ikke er tiltænkt et flerbrugermiljø. Den er utrolig ineffektiv i det scenarium, da hele databasen indlæses (og låses), hver gang den bruges. Så den er resursetung for serveren at bruge og performer dårligt jo flere der kobler op til den. Et andet gratis alternativ er SQL Server Express (som også er helt gratis). Den performer meget bedre og er lavet til flerbrugermiljø. En anden fordel ved SQL Server Express er, at den let opgraderer til en fuld SQL Server, hvis det behov senere skulle opstå. Uden i øvrigt at vide, hvordan jere system er skruet sammen og hvor komplekst det er, vil jeg tro kode I allerede har, med få modifikationer, også vil fungere mod en SQL Server.

Glem Access og portér til MSSQL

Glem alt om de her åndssvage %...%, at lave dem er som at tigge om performanceproblemer. Det vidner om et dårligt design!!

Indexering vil IKKE hjælpe.

Opret Full Text Search eller split selv søgeord ud med en til mange, hvis I stadig ikke mener I kan undvære wildcardsøgninger.

Tak for svarene - har brugt flere af jeres råd og fået siden gjort væsentligt hurtigere. Vi ved godt at en flytning til SQL er fremtiden.