I forbindelse med færdiggørelsen af en applikation jeg selv havde skrevet, skulle jeg lave en installer. Under selve udviklingen af applikationen havde jeg ikke skænket installer'en en tanke (noget som MSI holdet ellers anbefaler (jf. regel 5) - men det vidste jeg ikke da jeg begyndte). Under tidspres og på fuldstændig bar bund kastede jeg mig over opgaven.

Mit første sted at søge information var Visual Studio 2005 off-line hjælpen og MSDN. Det gav ikke umiddelbart pote - hverken med at træffe et hurtigt valg: ClickOnce eller Windows Installer deployment?!! ...og heller ikke med at komme igang. Jeg måtte vende ansigtet ud mod det store internet for at finde brugbar hjælp og her kom en artikel af Arnaldo Sandoval mig især til hjælp. Med den i hånden fik jeg strikket et setup-program på benene, og det har kørt lige siden.

Imidlertid vokser træerne ikke ind i himlen - som man siger. Derimod vokser software og dermed opdateringer. Med en sådan opdatering af applikationen i hånden, skulle msi'en genoversættes. Selve oversættelsen gik smertefrit, men da jeg skulle afprøve msi'en på en virtuel testmaskine begyndte problemerne at banke på. Jeg fik den meget lidt vejledende fejlbesked (tro mig, jeg er ikke den første hvilket en google-søgning efterfølgende afslørede): "The system administrator has set policies to prevent the installation". Jeg var administrator, så hvori lå problemet?!! Igen var det vanskeligt at finde en løsning på MSDN, så jeg måtte en tur forbi Google. Efter nogen søgning og læsning fandt jeg frem til, at problemet måtte bestå i, at jeg ikke havde ændret versionsnr. og dermed heller ikke givet setup'en en ny "ProductCode". Med disse to ændret løste problemet sig.

I forbindelse med et projekt skulle jeg få to SQL Server'ere til at kommunikere. Jeg havde en stored procedure hvori et postsæt skulle sammensættes af data fra tabeller på to SQL Server'ere. Det drejede sig om ordredata fra kildeserveren som skulle join'es med kundedata fra "remote"-serveren.

Begge servere befandt sig i samme lokalnet, så forbindelsen mellem dem burde være ligetil. Desværre kunne jeg ikke umiddelbart finde en kort og præcis beskrivelse på nettet som beskrev hvordan det skulle gøres. Det der gav mig hovedbrud var hvor jeg skulle angive ip adressen eller maskinnavnet, så kildeserveren kunne se destinationsserveren. Jeg havde en forestilling om, at feltet "Linked Server" (jævnfør fig. 2) var en slags alias for selve forbindelsen og at der skulle defineres en ip-adresse eller et servernavn andetsteds i konfigurationsboksen.

På SQLServerCentral fandt jeg imidlertid en artikel som bragte mig på sporet. Her følger mine erfaringer som forhåbentlig bringer dig på sporet hurtigere end mig.

Serverne 

1. SQL Server 2005 Express installeret på Windows 2003 Server Standard Edition. 
2. SQL Server 2000 installeret på Windows 2003 Server Standard Edition.

Fra server 1 skal jeg i en stored procedure join'e data fra server 2. Hertil skal jeg bruge linked servers.

Sådan gjorde jeg

Okay, lad os komme igang med det det handler om. Det er egentlig meget simpelt at sætte op. Jeg gjorde det via SQL Server 2005 Management Studio.

1. Find den serverregistrering hvorfra forbindelsen skal oprettes.
2. Åbn "Server Objects" -> "Linked Servers".
   
   Fig. 1
   
3. Højreklik på "Linked Servers" og vælg "New Linked Server...". Vinduet "New Linked Server" åbner.
4. I vinduet vælges "General" og i "Linked server" skrives navnet eller ip-adressen på den server vi skal have fat i. Bemærk, at hvis man skriver et navn, skal det være et navn på en server i netværket.
   
   
   Fig. 2
   
   
5. I "Servertype" vælges "SQL Server".
6. Vi skal herefter sætte sikkerhedsindstillingerne. Gå til "Security".
7. Under "Security" kan man vælge at tilføje et eller flere logins hvor lokale brugere mappes med brugere på den server der skal oprettes forbindelse til.
   
   
   Fig. 3
   
   Derudover kan man tilføje en slags fallback login hvis ingen i listen blev match'et.