Access 97 db til SQL Server - igen

Det lugter af, at du er ramt ind i SQL Server 2000's query timeout. Den er som default 10 minutter.

Passer det med din oplevelse?

Hvis så, så kan du enten vælge at ændre den (gøres ved at højreklikke databasen i Enterprise Manager og vælge options og så finde den (mener det er fanen CONNECTIONS) ) eller blot sende en ny query afsted før timeout.

Hej Det virkede ikke at ændre opdateringsinterval.

Hvordan gør jeg det andet, skal jeg ind ihver eneste formular og ændre eller kan jeg nøjes med modulet main

Desværre, nu spørger du om mere end jeg kan klare i Access :-(

Men jeg kommer lige til at tænke på - er der mon noget "session timeout" du kan sætte i din forbindelse eller i Access ?  Hvis så, så kan det måske være løsningen.

Det virkede ikke, Hvordan sender jeg en ny query afsted før timeout...

Kan du refreshe med F5 eller lignende?

Nej må gå ud af formen og ind igen.

Så det er lidt noget øv

Kender du at bruge profileren?  De er en del af de administrative værktøjer til SQL Server.

Hvis du sætter en profiler trace op mod databasen så vil du kunne se hvad pokker der reelt set sker mellem klienten og databasen - og dermed vil du kunne fejlsøge lidt nemmere.

Du starter Profileren, og sætter en trace op hvor du sætter et filter op på aktuelle database id (kan findes via "select db_id(databasenavn)" i Query Analyser), og tilføjer events på T-SQL Statements.

Så starter du tracen, og prøver at se hvad der reelt set sker når klienten mister forbindelsen.  Al kommunikation mellem klient og server vil blive registeret i profileren, så du får ret mange data - og det belaster din server, så du stopper tracen igen.  Det er også en fordel hvis der ikke er mange andre på imens :-)

Måske skal du overveje at filtrere på klient session id ( spid - kan ses ved opslag i tabellen master.dbo.sysprocesses ) - bare for ikke at få for mange data...

Hej Trer, det vil jeg prøve.

Jeg vender lige tilbage mandag, om det har virket.

Det sidste du snakker om der, hvad indebærer det?

Mette

Tracen er simpelthen en log over alt hvad der sker mellem klienter og server, derfor er den god til tuning og fejlfinding.

Men når tracen kører skal SQL Server jo finde og sende alle de hændelser du beder den om at registere, og specielt hvis du tager enkelte statements med (som jeg ovenfor anbefaler) belaster det serveren og du får længere svartider.  Kører din server nær sin max belastning vil brugere kunne få timeouts og blive irriterede over svartiderne...

Hej

Tracen laver en exec sp_unprepare 60.
Hvad betyder det?

prepare og unprepare er optimering. Når man forbedrerer et sql statement til afvikling bliver det kompileret og en plan for dataadgang (dvs læsning og joins) laves.  Så er det meget hurtigere når sql'en reelt bliver kaldt - og den kan kaldes flere gange og samme kompilering kan genbruges.  Man kan så lave en unprepare for at spare plads i hukommelsen når man ikke skal bruge sql'en mere...

Det er i forbindelse med den jeg får odbc-call failed.
Hvad gør jeg?

Der går ca 7-8 sek, før den kommer, hvis det kan hjælpe

Desværre, den kan jeg ikke rigtig greje.  Jeg ville nok prøve at re-linke tabellerne og så prøve enten standard opsætning af odbc'en eller prøve at ændre odbc-optionerne.

Har prøvet det sidste 27 gange, æv æv.
Tak for hjælpen so far Trer.

Ok, ærgerligt at jeg ikke kunne hjælpe.  Held og lykke med at få løst problemet.

Jeg lukker...