Access database mdb fil er låst efter ASP.Net programfejl

Ak ja, endnu en god grund til at holde sig langt væk fra Access-databaser... :)
Nej, du må undskylde at jeg ikke kan hjælpe dig, men så vidt jeg ved findes der simpelthen ikke en direkte løsning på dette problem (andet end at Microsoft retter denne åbenlyse fejl i .NET Framework). Når dette sker for mig (jeg arbejder en del med XML hvor det samme ofte kan ske), plejer jeg bare at dræbe aspnet_wp.exe via Task Manager, men det er jo ikke noget du har adgang til...

- Simon

når du arbejder med fil-connections, så sørg ALTID for at have en try/catch på, så du er sikker på at du kan få objektet lukket.

fx.
try {
    myConn.Open
  [...]
catch ex as System.Exception
  myConn.Close
  Throw New Exception(ex) 'smid en exception så du stadig kan se hvad der gik galt.
end try

Tak for rådet.
Men bare der var en udvej, som også virker, når man er glemsom.

Jamen det ER udvejen! Håndtering af Exceptions er en MEGET vigtig del af programmering. Hvis du åbner noget, skal du altid huske at lukke for den igen. Det samme gælder også for forbindelser til fx. MSSQL databaser!!! Der er grænser for hvor mange forbindelser du kan have åbne til en database, selvom det er en MSSQL eller en Oracle database. Godt nok timer forbindelsen ud efter noget tid, men det gør access-databaseforbindelsen nu også.

Har du 100.000 brugere i timen, og opstår der en fejl du ikke har tænkt på, i 0.1% af kaldende til databasen, så skal der ikke meget til at opbruge en servers hukommelse og tilgængelige forbindelser.

odegaard>> det er pænere at smide ens Close i Finally-blocken :), og hvorfor kaste en ny exception hvis man ikke skriver noget mere informativt... så er det måske bedre at kaste den eksisterende exception videre

Try {
  conn.Open
} Finally {
  conn.Close
}

Finally vil jo ALTID blive kørt

cyberfessor: Grunden til at jeg ikke smider den i finally, var netop for at kunne smide min exception, således at jeg stadig kan debugge. Og exception'en indeholder da alt hvad der er af information, så hvad ville være bedre at skrive?
Men i den sidste ende, så har du da ret i at man bør have den i finally.

odegaard>> man kunne skrive en ny besked, ala Throw New Exception("Der skete en fejl under åbning af databasen")

Hvis man bare kaster en ny exception indeholdende den man har fanget, så er det hurtigere bare at lade den exception der evt. bliver kastet blive fanget senere i hireakiret...

Man kan dog stadigvæk uden problemer have en/flere catch-blokke selvom man har en finally-block.

Try {
  conn.Open
} Catch (OleDbException exc) {
  Throw New DataException("Der skete en fejl under åbningen af databasen", exc);
}
Finally {
  conn.Close
}

Min pointe er jo netop at den original exception indeholder MEGET mere information end din egen tolkning: "Der skete en fejl under åbning af databasen"
Hvor hvilken slags fejl?!?? Og skal jeg så til at fange samtlige mulige exceptions?

odegaard>> hvis du kigger godt efter, så inkluderer jeg jo netop den exception jeg har fanget som InnerException i den nye jeg kaster.

Og ja, ideen er at man laver flere catch-blokke, alt efter hvilken slags exception der kan blive kastet. I dette tilfælde kan man læse sig til at OleDbException bliver kastet af OleDbConnection-klassen hvis der er noget der går galt... en optimal kode ville derfor nok være

Try {
  conn.Open
} Catch (OleDbException exc) {
  Throw New DataException("Der skete en fejl under åbningen af databasen", exc);
}
Catch (Exception exc) {
  Throw New Exception("Der skete en uventet fejl", exc);
}
Finally {
  conn.Close
}