Jag har två stora problem med vår nya IIS 6.0 Windows 2003 Webedition Gissningsvis är det något problem med att någon öppnar accessfilen men sedan inte stänger den eller liknande. Hej.Samtliga websidor på min IIS 6.0 går EJ att nå då access.lockfile uppstår!
som aldrig har funnits tidigare (Win 2000 IIS 5.0).
Då access.lockfile uppstår (har inträffat 3 ggr på 5 mån) så kan ingen av websidorna på min server nås!
Varför uppkommer access.lockfile och varför stannar ALLA websidor?
(Det är illa nog att berörd sida som kör mot Accessdatabasen stannar men inte hela servern.)
Jag har ändrat rättigheterna på mappen samt databasen men jag kan tyvärr inte
återskapa felet då jag inte vet exakt vad som orsakar problemet.
Hjälp!!!! :-(Sv: Samtliga websidor på min IIS 6.0 går EJ att nå då access.lockfile uppstår!
En variant (som jag rekommenderar) är att ni satsar på mysql istället.Sv: Samtliga websidor på min IIS 6.0 går EJ att nå då access.lockfile uppstår!
Jag har också funnit att databasen inte stängs samt att rättigheterna måste sättas på fil och mapp för gästkontot. Jag har även funderat på mySql men har inte tid att justera alla asp-sidor för just mySql.
Jag skulle dock vilja veta varför alla sidor inte kan nås - trodde att IIS 6.0 skulle vara bättre på hantera webplatser.
Hittade dock fördjupning här!
-----------
as you all know, IIS manages application protection (in/out-of process),
which in turn manages connection pooling. A way to empty the pool, is by
unloading the application protection.
I have several ASP applications on a Win 2K server (IIS 5 web server) with
Access 2K back-end DB. Apparently, connections are not closed properly in
code (e.g. cn.Close set cn = nothing) because .ldb lockfiles remain.
I'm not sure that's true - I would suggest following-up in asp.general and
asp.db ...
http://www.iistoolshed.com/ - tools, scripts, and utilities for running IIS
http://mvp.support.microsoft.com/
http://www.microsoft.com/windowsserver2003/community/centers/iis/
--------
If ldb files are remaining, it is usually because the last user in the
database does not have the authority to delete them. If the application is
running in its own process, then the user is the IWAM account, not the IUSR
account, so you need to be sure that the IWAM account has Change permissions
for the folder containing the database file, in addition to the IUSR
account. If using Integrated authentication, then the users need to have
those Change permissions.
FWIW, I would not be too concerned about emptying the pool: ADO does a good
job of managing that on its own.