Sletning af poster tager lang tid

Det lyder voldsomt med 20 sek. Er der nogle voldsomme index på den tabel, eller evt. triggers som forårsager en del arbejde?

Alternativt kan du benytte TRUNCATE tabel1 (eller er det TRUNCATE TABLE tabel1). Som burde være hurtigere hvis man ønsker at tømme en tabel.

det er helt sikkert et spm. om indexer.

Har du defineret en primær nøgle på tabellen? vis os evt et createscript (højreklik på tabellen i Enterprise Manager, vælg kopier, derefter sæt ind her)

Har ikke lige adgang til basen lige nu; men tabellen er helt simpel. Et unikt ID og 10-12 tekst- og realfelter. Ingen triggers. Ingen ingenting.
Det jeg fiskede efter er, om der måske er en eller anden option i SQL, der ikke er slået til/fra el.lign.?

TRUNCATE TABLE

----

Det er ikke nogen naturlov at SQLServer er hurtigere end Access. Hvis din Access
database ligger lokalt og der kun er en samtidig bruger og der som i dette
tilfælde ikke er nogen specielle optimerings muligheder, så er der ikke nogen
grund til SQLServer skulle være specielt hurtigere end Access.

----

Mine gæt vil være:
  - indexer
  - meget fragmenteret database filer

Du skriver TEXT felter - mener du at I har brugt datatypen TEXT ?  Det svarer nemlig til at bruge MEMO i Access.

På SQL Server bliver blob felter (TEXT, NTEXT og IMAGE) lagret specielt og håndteret specielt, hvilket gør dem en smule sløvere end VARCHAR (som svarer til Access TEXT).

Rent hastighedsmæssigt - normalt er SQL Server væsentligt hurtigere end Access, jo mere komplekse opgaver, jo hurtigere er den forholdsmæssigt.

Jeg kunne godt tro, at I blot var blevet udsat for en voksende logfil (og at I har placeret logfilen sammen med datafilen samt systemdatabaserne og tempdb - hvad der er nemt at gøre da det er default, desværre).

På www.microsoft.com/sql kan I finde whitepapers mv der beskriver opsætning og konfiguration af sql server.

Vi må vist lige samle lidt op:
"Vi har installeret en ny SQL server 2000". Den er helt nyinstalleret. Altså ingen logfil. Ingen fragmentering. Ingenting!
Felterne er af type Varchar. Det hele er helt, helt simpelt.

Umiddelbart lyder det som om, det er filplaceringerne, der kunne være problemet.

Det lader ikke til, at der er settings, vi har overset.

I deler pointene for indsatsen. OK?

... men så må I lige smide nogle svar  ;o)

Jeg fylder lige lidt på min kommentar ovenfor:

Logfilen på sql server oprettes til hver database. Default er (vistnok) 1 MB log der vokser med 10%. Med Trucnate log on checkpoint skal loggen "kun" kunne indeholde den største enkelte transaktion. Dvs. med delete table skal loggen som minimum kunne indeholde hele tabellen.  Kan den ikke det, så vil loggen vokse - og mens den gør det, så svarer den pågældende db reelt set ikke. Det svarer lidt til når Windows pagefil vokser.

Løsningen er, at man altid sætter log/data filer til at vokse med fx 5, 10 eller 25 MB eller bedre, beregner den forventede størrelse på db'en og sætter filstørrelserne efter det fra starten af.

Log filer bør aldrig være placeret på samme diske/raid som datafiler og tempdb bør altid være på en disk for sig. System-db'er (master, msdb) kan fint være sammen med OS-filerne.  SQL Server bør sættes til en max memory så der er omkring 200 mb fri til OS, backup og overvågning etc & SQL Server query memory bør sænkes til 512 KB. Har man mindre end 1 GB ram bør man trimme OS så "unødvendige" services (messenger, alerter, computer browser, dist. link tracking etc) ikke startes.

Mht backup - sørg for altid at tage fuld backup af master og msdb ved enhver ændring - inkl. når du tager backup af en bruger-database. Rækkefølgen bør være "bruger-db", "master" og "msdb" - grunden er, at master har metadata for den enklete bruger-db mens msdb indeholder backup information.

Så kom der hul på bylden, hvad? Jeg tror, alle er enige om at du har fortjent hele potten. 1000 tak for dit svar. Vi kaster os over opsætningen mandag morgen. Super ;o))