Max brugere på en Access er 50 samtidigt, så det burde ikke være det.

Men men... det lyder som om at db-connections ikke lukkes korrekt i og med de stadig "eksisterer" i apppool. Normalt vil "efterladte", altså dem som ikke er lukket korrekt automatisk ryddes op, men nu at der pludselig er 5 mere, kan betyde at det ikke kan nåes.

Hvis antallet peaker på 50 så nytter ram ingenting, men du kan jo kigge på ram-forbruget og se hvordan det ser ud :)

Access er jo ikke en rigtig relationel db som du selv skriver og den kan altså være ekstrem følsom overfor adgang, det er jo sådan at når en bruger tilgår databasen oprettes der en shadow/ temp kopi som så bagefter skal merges sammen med originalen.

Har du prøvet at lade være med at resette IIS? og så bare se om det løser sig selv? Hvis det ikke løses af sig selv kan det måske være noget deadlock...

Vend tilbage med information på spørgsmålene, så er vi kommet problemet lidt nærmere :)

jeg har forsøgt at lade den stå meget længe, men det er mit indtryk at det ikke løser sig selv ved at lade den være.
den har faktsik stået natten over for at se om den stoppede, uden at det løste problemet.

Det ville give rigtig meget mening hvis det var det, der var fejlen. og hvorfor den ikke kommer samme sted, men popper op på forskellige sider.
Men der er rigtig mange sider som skal gennemgås for at se om der er "døde" forbindelser.
Er der noget jeg kan gøre for automatisk at rydde op i connections?

Jeg mener der er et max. på 255 samtidige brugere og ikke 50, som anført i et tidligere indlæg.
Jeg har for ca 3 uger siden sat en Access db op på vores intranet med ca 800 arbejdsstationer uden problemer. Det siger sig selv, at der ikke er 800 samtidige brugere og hvor mange der er, ved jeg ikke. Men det kører uden problemer.

Hvordan er db sat op? Bruger du frontend og backend.

mugs-> http://en.wikipedia.org/ (...) , læs under Users :) Muligt det er en fejl, men 50 på en Access er stadig 45 for meget.

hlt-> Hvad er løsningen programmeret i? ASP?, PHP?, .NET?

"Men der er rigtig mange sider som skal gennemgås for at se om der er "døde" forbindelser."
-> Hvis det bare er udviklet med en smule fornuft så vil der højest være et par enkelte steder hvor database connections åbnes og lukkes.

Uden at se noget kode er det meget svært at komme med bedre anvisninger. Smid noget kode evt. :)


"Er der noget jeg kan gøre for automatisk at rydde op i connections? "
-> Nej, medmindre du vil lave et dumt hack som genstarter IIS'en

"men popper op på forskellige sider."
-> Ja det er typisk ved den slags, det siger ikke så meget... på et eller andet tidspunkt skal filmen jo knække :)


Rettelse til mit tidligere.. istedet for
"Hvis det ikke løses af sig selv kan det måske være noget deadlock..."!
skulle der naturligvis stå
"Hvis det løses af sig selv kan det måske være noget deadlock..."!

Hej,
Det er kodet i asp. Det er kodet på den måde at der i hver fil er lavet en include som indholder kode til at åbne databasen. Forbindelsen lukkes så i hver fil. Eller det burde den ihvertfald gøre. Noget kunne tyde på at den ikke gør det. Det er måske nok ikke optimalt, men jeg ved ikke helt hvad man så kan gøre.

hmmm... prøv at poste noget kode der tilgår includen med db-adgang, så kan vi da se hvad det er for noget.

Hej,
Mugs:
Nej jeg bruger ikke frontend og backend. Ved ikke hvordan det skal sættes op. Og kan man gøre det på en eksisterende database med indhold?

Janus_007:
Lidt DB kode
--------------
Set database = Server.CreateObject("ADODB.Connection")
database.open = "Provider = Microsoft.Jet.OLEDB.4.0; Data Source = " & Server.MapPath("/fpdb/intraDB.mdb")

strSQL = "select * from tbl_company"
Set rs = Server.CreateObject("ADODB.Recordset")
rs.Open strSQL,database

While NOT rs.EOF
......
rs.MoveNext

rs.close
set rs = nothing
database.close
Set database = nothing

-------------------

Det er den måde som alle de eksempler jeg har set på nettet bruger. Så jeg tror ikke at det er koden der er noget galt med. Men hvis det er som du siger, så er der måske en eller flere forbindelser der ikke bliver lukket ned. Og så var det bare om der var en smart måde at lukke en forbindelse uden at jeg skal til at gennemgå samtlige sider i intranettet.
og der er mange. Systemet har kørt i over 5 år uden problemer(stort set ;-)) og nu begynder det så at drille.

hlt > Du kna sagtens sætte din db op i back- og frontend med eksisterende data.

I 2003 ligger der en guide under Funktioner > Databasefunktioner > Databaseopdeling.

Men det er nu nemmere at gøre det selv:

1. Tag først en kopie af db og læg den laaaaangt væk som en backup.
2. Tag en ny kopi og læg den på et drev der kan læses af alle arbejdsstationer. Navngiv denne db Backend
3. Tag endnu en kopi og læg den på din lokale arbejdsstation. Det eneste krav er, at den kan læse Backend. Denne lokale kopi navngiver du Frontend.
3. Tilbage til Backend. Slet ALLE forespørgsler, formularer, rapporter etc. så du udelukkende har tabellerne. Luk Backend.
4. Åbn Frontend i databasevinduet og SLET ALLE tabeller. Gå i menuen Filer > Hent eksterne data > Sammenkæd. Du browser ned igennem bibliotekerne og finder backend. Marker alle tabeller og klik på Sammenkæd / Ok.
5. Nu vil Frontend sammenkæde tabellerne fra Backend. Du ser det på den lille pil tilvenstre for ikonet for tabellerne.

Når frontend åbnes vil den etablere forbindelse til backend og vise data. ALLE ændringer i data i Frontend eller Backend baserne vil nu blive afspejlet i den anden base. NÅr Frontend lukkes afbrydes forbindelsen til Backend.

Distribuer nu din Frontend til alle brugerne. Dette bevirker, at du sparer netværkstrafik, idet du kun skal transportere data over netværket og ikke de tunge formularer m.v.
Desuden kan du evt. skræddersy frontend til de enkelte brugere der måske skal have forskellige rettigheder til at læse / skrive data.

Det lyder måske lidt indviklet, men har du prøvet at iopdele en db een gang, vil du se, at det er en ganske simpel operation.

Mugs:
Det lyder spændende at gøre det på den måde. Og hvis det kan løse problemet med connection der ikke bliver lukket så er det da værd at forsøge.

Intranettet kører fra den enkelte klient via VPN til en server. Her brugere alle klienter så deres browser til intranettet.
kan det så stadig lade sig gøre at lave det på den måde du siger, og  i så fald hvordan?

Jeg har ikke så meget forstand på netværk / intranet, at jeg kan råde dig i den retning.

Men hvorfor ikke prøve med nogle få klienter og se, hvordan det kører. Som tidligere skrevet, har jeg for ca 6 uger siden launchet et system med ca 800 klienter, og det kører stadig uden problemer. Jeg kan se, at det i formiddags var blevet åbnet 664 gange, selvfølgelig ikke på een gang.

Den løsning har intet med problemet at gøre. Plus server.mappath ikke fungerer længere... nej stop stop... hold dig nu på rette kurs. Det som mugs taler om er intet andet end opdeling imellem database og webserver og har intet med connections at gøre.

mugs-> hvorfor råder du hlt til dette?
- At du har launchet et system med Access og 800 brugere er intet mindre end vanvid, selvom du skriver "ikke på en gang", jeg håber naturligvis det bedste for dig. Men lad være med at tro serverstruktur har noget med det her at gøre.

Fejlen som hlt er ude for skyldes nogle connections som ikke lukkes korrekt ned, måske pga. af fejl. Ting som vi slet ikke er kommet til endnu.

Vanvid er vel så meget sagt, systemet kører upåklageligt!

Mangler stadig et svar på hvorfor du råder hlt til noget som ikke rigtigt har med sagen at gøre?

hej,
Jeg er gået igang med at gennemgå alle sider. Samtidig laver jeg det jeg kan om til .net. Der er meget bedre fejlhåndtering, så derfor er det nok den vej jeg skal.
Umiddelbart kan jeg ikke se at der er nogen steder hvor connections ikke bliver lukket.
Men tak for hjælpen. Er der nogen af jer der smider et svar, så jeg kan lukke spørgsmålet?

Hvis der ikke er nogen der vil smide et svar må jeg selv gøre det, så det kan blive lukket. tak for hjælpen alle sammen