Inloggning i SQL Server
Förord
Det första man måste göra för att jobba med databaser i SQL Server är att logga in i servern. Följdaktligen stöter man ofta på frågor om detta i diskussionforum och nyhetsgrupper, och jag tänkte här förklara hur det fungerar.
Servernamn
Det första man behöver för att logga in i SQL Server är nätverksnamnet på den server man vill logga in i. Man kan även använda ip-adressen till servern. Detta namn är det man anger när man väljer vilken server man vill logga in på i t ex Query Analyzer, eller så använder man det i en connection string för ett ADO Connection-objekt.
Default instance och namngivna instanser
I SQL Server 2000 infördes ett nytt begrepp, instans. Nu kan man ha flera installationer av SQL Server på en dator, vilket t ex kan vara användbart om man vill fullständigt skilja olika kunders data åt, eller om man behöver en testmiljö och en produktionsmiljö. Varje instans är en helt egen process, med egen minnesarea och egna databaser. Om en instans går ner så berör det inte övriga instanser. Naturligtvis måste dock alla instanser dela på maskinens resurser. När man installerar SQL Server 2000 får man välja om man vill installera som en 'default instance' eller en namngiven instans. Man kan bara ha en default instance på en maskin eftersom det är samma sak som att man ej anger instans, medan man kan ha upp till 16 namngivna instanser. Eftersom SQL Server 7 inte stödjer instanser kan den endast köras som default instance. Det går dock alldeles utmärkt att ha en installation av SQL Server 7 som default instance och samtidigt ha en eller flera installationer av SQL Server 2000 som namngivna instanser på en och samma maskin.För att ange en namngiven instans när man väljer server att logga in på lägger man till instansnamnet efter servernamnet, med ett backslash-tecken mellan dem. Min lokala SQL Server 2000-installation heter CARTMAN\DEV eftersom jag alltid kör SQL Server 2000 som namngivna instanser, och brukar namnge dem DEV, TEST och PROD.
Tips: Om man har ett system som man kontinuerligt utvecklar på, samtidigt som det finns i drift så är det bra att ha skiljda miljöer där man utvecklar, testar och slutligen driftsätter systemet. I utvecklingsmiljön (DEV) gäller inte så mycket regler, det är databasutvecklarna som själva bestämmer över den miljön. Naturligtvis är det ju bra om den liknar produktionsmiljön så mycket som möjligt så man inte behöver göra om något när man levererar det. Vill man ha en riktigt bra miljö, med möjligheter att göra ordentliga system- och acceptanstester innan produktionssättning bör man ha en testmiljö (TEST) vilken är så lik produktionsmiljön som möjligt, helst en exakt kopia av den. Har man inte råd till det kan man ha lite mindre resurser (CPU, RAM, hårddisk etc) men man bör se till att SQL Server och databaserna är installerade och konfigurerade som de är i produktionssystemet. I TEST-instansen kan man låta testare köra tester på applikationen samtidigt som utvecklarna arbetar vidare i DEV-instansen, utan att någon av dem påverkar systemet i PROD-miljön som används av applikationen i drift.
Nätverksprotokoll
SQL Server använder flera olika nätverksprotokoll för att kommunicera med sina klienter. Eller rättare sagt, SQL Server kan lyssna på flera olika nätverksprotokoll som klienterna kommunicerar med den på. Att beskriva dem och hur de fungerar ingående är är något som ligger utanför den här artikeln, men jag ska åtminstone kort nämna dem. På servern finns en applikation som heter Server Network Utility (finns i SQL Server-gruppen i Startmenyn), vilken man använder till att visa och konfigurera vilka protokoll servern lyssnar på. För att se vilket protokoll klienter använder för att kommunicera kan man köra en applikation som heter Client Network Utility, vilken installeras tillsammans med de övriga klientverktygen (Enterprise Manager, Query Analyzer etc) för SQL Server. Observera att servern lyssnar på alla de protokoll som visas i Server Network Utility, medan en klient bara kommunicerar på ett av de protokoll som visas i Client Network Utility (i den ordning de är listade). Man kan även specificera ett protokoll i inloggningsinställningarna (connection string, ODBC DSN-källa etc) om man inte vill använda det som är standard på klientmaskinen. Se dokumentation för respektive klient för mer info (Gert Draapers har även en liten FAQ om detta på http://sqldev.net/faq.htm).De vanligaste protokollen man använder är Named Pipes och TCP/IP. Har man dessa installerade på servern så kan man kommunicera med den från de flesta klientdatorer. Normalt används TCP/IP, men man bör ha bägge aktiverade eftersom det tidigare var standard med Names Pipes. Har man Macintosh-klienter i nätverket bör man även ha AppleTalk aktiverat. Använder man TCP/IP för att kommunicera med servern kan man ange ip-adressen till den istället för servernamn. Man bör även ange vilken port man vill kommunicera på, eftersom SQL Server 2000 kan lyssna på andra portar än 1433 vilket var standard i SQL Server 7. Har man flera instanser installerade lyssnar de alla på olika portar. Portnummer anges med ett kommatecken efter ip-adressen (ex. 192.168.0.10,1433).
Validering av inloggningen
Här har vi det som de flesta brukar ha problem med och fråga om. Hur många gånger har man inte sett frågor om ett felmeddelande i stil med "User 'sa' not associated with a trusted login"? SQL Server har två olika sätt att validera en inloggning och ge tillgång till servern; integrerad Windows-inloggning och SQL Server-inloggning. SQL Server kan konfigureras att endast använda integrerad Windows-inloggning, eller i mixed mode då bägge typerna används. Det går alltså inte att använda enbart SQL Server-inloggning. I Enterprise Manager kan man kontrollera om Windows mode eller mixed mode används. Högerklicka på servern, välj Properties och fliken Security.I integrerad Windows-inloggning loggar man in som den Windows-användare (eller användargrupp) som kör applikationen som inloggningen sker från. Om du t ex loggar in på en klientdator som SOUTHPARK\tweek (användaren tweek på domänen SOUTHPARK), startar Query Analyzer och sedan försöker logga in mot en SQL Server måste SOUTHPARK\tweek ha tillstånd att logga in där. Kör man en applikation som en tjänst, t ex en webbapplikation i IIS, måste den användare tjänsten kör som ha tillstånd att logga in. För IIS är det normalt en specialanvändare som heter IUSR_maskinnamn, men ska man låta en webbapplikation logga in i SQL Server med integrerad inloggning bör man köra den som någon annan användare för att inte ge alla webbapplikationer inloggningsrättighet i SQL Server. I vilket fall som helst är det viktiga att man inte behöver ange något lösenord för att logga in, har man blivit verifierad av Windows och har rätt att logga in i SQL Server är det tillräckligt.
För SQL Server-inloggning är det SQL Server själv som sköter verifieringen av användaren. Användarnamn och lösenord sparas i en tabell i SQL Server (krypterat förstås) och när man försöker logga in jämförs de uppgifter man anger mot dessa.
Felmeddelandet "User 'sa' not associated with a trusted login" då? Vad det säger är att man försökt logga in på en server som endast tillåter integrerad Windows-inloggning, men man angivit inloggningsuppgifter för ett SQL Server-inloggningskonto. SQL Server 2000 konfigureras vid en standardinstallation till att köra Windows Mode, till skillnad från SQL Server 7 som körde Mixed Mode som standard. Antingen får man ändra sin inloggning till en Windows-inloggning, eller så får man konfigurera SQL Server att köra mixed mode.
Inloggning och användare
Även när man verifierats och fått tillträde till servern med den inloggning man gjort så innebär det inte att man kan använda en eller flera av databaserna som finns på servern. Inloggningskonton måste mappas mot användare i databaser, vilket man dock kan göra samtidigt som man skapar ett inloggningskonto i SQL Server. Hur detta går till kommer i en senare artikel.
Logga in
Nu när vi vet allt om inloggning i SQL Server kan vi titta på två exempel på connection strings för att koppla sig mot sin databas, en för integrerad Windows-inloggning och en för SQL Server-inloggning.Windows: Provider=SQLOLEDB;Data Source=CARTMAN\DEV;Initial Catalog=Northwind;Trusted_Connection=Yes
Data source pekar alltså ut vilken server jag vill ansluta till, med en namngiven instans i detta fallet. Initial Catalog anger vilken databas jag vill hamna i efter inloggning, och slutligen anger jag att jag vill använda en integrerad Windows-inloggning för att verifieras.
SQL Server: Provider=SQLOLEDB;Data Source=192.168.0.10,3333;Initial Catalog=Northwind;User Id=sa;Password=verysecret
Här använder vi instansens ip-adress och port för att ange vilken SQL Server vi vill ansluta till. Vi anger också ett användarnamn (sa) och lösenord (det är inte mitt riktiga lösenord så det är inte lönt att försöka något ;) ). Vi behöver inte specificera att vi vill ansulta med SQL Server-inloggning, det förstår providern själv eftersom vi angivit ett användarnamn.
0 Kommentarer