Access 97 db til SQL Server

Du skal blot linke dine tabeller så de har samme navne som de orginale tabeller - så har du ikke nødig at lave nogen ændringer overhovedet i dine sql'er.

Lige en ting til, kan det passe at du ved at gå ind i tabellerne i Access ikke kan tilføje records mere, så det måske har noget at gøre med rettigheder i forbindelsen

Nixen - du har sikkert blot glemt at lave primær nøgler på tabellerne.

For at Access kan opdatere skal der være defineret en primærnøgle - eller du skal under linkningen fortælle hvilken kolonne (felt) der er unik.

Lav primærnøgler og link alle tabeller på ny. Mangler der en primær nøgle vil Access spørge om hvilken kolonne der er unik.

Okay, fik lige genlæst - hvis din bruger har ret til at indsætte, opdatere og slette data så gælder ovenstående. Du kan checke om brugeren har rettighederne via Enterprise Manager - typisk vil man tildele grupperne db_datareader og db_datawriter til en bruger.

Det har jeg gjort, i SQL databasen får de automatisk dbo. foran har det noget at sige, hvis ja, hvordan ændrer jeg det

trer - dit svar går det på subforms eller tabellerne, om man kan tilføje i Access.
Der var ikke defineret primær nøgler, så det er jeg i fuld gang med nu...

Højre klik på tabellen og vælg Rename eller omdøb. Du kan vist også klikke på tabellen og trykke F2.

Mht rettigheder - det er i SQL Server på tabellerne.  Du skal sikre at din bruger har datareader og datawriter rollerne i databasen. Hvis I har en Database Admin kan du bede ham checke det - ellers skal du gøre det selv ved at højreklikke på brugerkontoen i den database du vil anvende og tildele rollerne der.

Hvordan måler jeg performance, før og efter.
Hvordan optimerer jeg performance i en sql.

At måle performance kan du kun gøre ved at udføre dine SQL'er og tage tid på udførelsen før og efter. Forskellen i performance ved at benytte SQL Server som backend vil du i øvrigt primært se ved store datamængder - og ved at flere samtidige brugere kører ubesværet.

At optimere SQL for performance er lidt en videnskab - der findes nogle generelle tips som er dækkende for alle databasetyper (f.eks. korrekt brug af indeks) og der findes tips som er rettet mod enkelte databasetyper (f.eks. valg af SQL syntaks).

I dit tilfælde skal du primært optimere efter Access mht SQL syntaks da det er Access' databasemotor der behandler SQL'en, mens indeksoptimering etc skal ske efter SQL Server.

Jeg har skrevet en række artikler "Basal performance tuning, part 1-3"  som du kan finde her i artikelsektionen der fortæller om første niveau i performance tuning primært på SQL Server - se http://www.eksperten.dk/artikler/Databaser/MS-SQL/

Meget kort sagt; For alle join kriterier skal du lægge et indeks på kolonnerne der indgår. For alle where betingelser skal du lægge et indeks på kolonnerne der indgår. For alle sorteringer (ORDER BY / GROUP BY) skal du lægge et indeks på kolonnerne.

Jeg er dog ikke sikker på hvordan brugen af indeks er, når det er linkede tabeller man vil performance tune mod - en tanke jeg har er, at det muligvis kan betale sig at sætte indeks på i Access' registering af de linkede tabeller (ved nemlig ikke om Access foretager join'en lokalt eller sender den til SQL Server - tror mest det første). Det at lave lokale indeks i Access kan så give problemer mht indeks opdatering i flerbruger-systemer...

Mht SQL skal du begrænse brugen af OR og <> og NOT samt undgå unødige sorteringer (fx DISTINCT og UNION har implicit sortering - UNION ALL har ikke).

Noget helt andet som jeg lige vil spørge om; Har du tænkt på backup og transaktionslog på din SQL Server?

Backup og transaktionlog har jeg ikke skænket en tanke, er det noget du hurtigt kan sige hvordan eller?

Tager lige et kig på artiklerne du nævnte

Du skal snart lave et svar, du har fortjent dem 10 gange indtil videre.

Ok, jeg lægger dette her som et svar. 

Mht til backup og transaktionslog (tror jeg vil skrive en artikel om det på et tidspunkt, men du får en kort gennemgang her :-)

På SQL Server lægges alle opdateringer ned i transaktionsloggen. Når en opdatering er skrevet ned i loggen overføres den bagefter til selve tabellen. Det sikrer at data altid enten bliver skrevet i fuldt omfang eller fejler totalt.

Du kan så vælge at loggen kun skal indeholde aktuelle transaktioner - det kaldes "SIMPLE RECOVERY MODEL" (I SQL Server 7 kaldes den for "TRUNCATE LOG ON CHECKPOINT") eller at loggen skal indeholde samtlige transaktioner siden sidste backup kaldet "FULL RECOVERY MODEL".

FULL giver dig mulighed for efter et nedbrud eller en fejl at gendanne databasen til et vilkårligt tidspunkt uanset hvornår - men loggen skal være stor nok til at indeholde alle dataændringer siden sidste backup!

SIMPLE skal kun være stor nok til at indeholde den størst mulige transaktion der kan ske mod databasen - tilgengæld kan du så kun genskabe databasen på tidspunktet for sidste backup.

Du vælger SIMPLE eller FULL RECOVERY MODEL ved at højreklikke på databasen og finde OPTION fanen. (Sammested bør du lige checke at der IKKE er hakket af i AUTO-CLOSE - ellers får du rigtig dårlig performance).

På SQL Server bør du tage backup via dens indbyggede backup styring - du kan nemlig ikke bruge en filniveau-backup (sådan som MSBACKUP laver) af database filerne hvis databasen kører imens. Specielt er det nødvendigt at bruge dens indbyggede backup hvis du vælger at køre FULL RECOVERY MODEL da transaktionsloggen ellers ikke bliver tømt!

Nemmeste måde at sætte en backup op på er ved at bruge MAINTAINCE PLANS og sætte den til at lave en fuld backup af alle databaser hver dag. Du finder det via Enterprise Manager ved at højreklikke på en database, vælge All Tasks og så Maintaince plans.

Et godt tip er, at en SQL Server backup kan komprimeres utrolig meget. Så i folderen du sætter den skal gemme sine backupfiler kan du slå NTFS filkomprimering til.

Bemærk at transaktionsloggen og datafilen står til at vokse med procent - performance mæssigt er det bedre at sætte dem til fx 5 eller 10 megabytes udvidelse fast - og at sætte en max størrelse på begge filer. Ellers kan de vokse til diskens størelse hvorefter databasen crasher og du risikerer at miste data!

God fornøjelse :-)

Jeg takker mange gange.

Der er i hvert fald noget at arbejde på.