Förord

Att använda sig av databaser tillsammans med ASP är något som de flesta börjar titta på efter att man börjat förstå sambandet mellan asp och dynamiska hemsidor. Men det finns många fallgropar även här och för att försöka hjälpa er lite med några av de vanligaste så tänkte jag att vi skulle försöka unvika dessa genom att du läser dessa artiklar i felhantering.

Innehåll

  » Säkerställa att databasen ligger rätt
  » Dags att ansluta till databasen från ASP
  » Global.asa till undsättning
  » Checklista
  » Vanliga fel
  » Ett vanligt fel som beror på servern
  » Dags för lite databasanrop
  » Några grundläggande regler

De kluriga ansutningarna

Vanligtvis börjar problemet redan vid anslutningen av databasen. Det verkar inte spela någon roll hur många artiklar man skriver om detta, det slarvas i alla fall hela tiden och då givetvis beroende på okunnighet och felaktigt skrivna exempel på diverse artiklar och hemsidor. För att gå från grunden så tänkte jag nu skriva en lite checklista för vad du bör tänka på:

Säkerställa att databasen ligger rätt

Det första du måste tänka på när du placerar en accessdatabas på en webbserver är att den inte automatiskt blir tillgänglig att skriva i för alla. Du MÅSTE först se till att databasen får skrivrättigheter för alla användare, dvs GUEST eller IUSR_xxx. Klarar du inte detta själv så får du tala med din databasadministratör på webbhotellet eller din arbetsplats.

Nästa steg är att bestämma om det skall vara en DSN adress eller inte. Att använda DSN gör det lite enklare för det är mindre parametrar, men samtidigt är det så att om du är på ett webbhotell med många DSN-adresser på en och samma server kan namnslagningen ta längre tid än att uppge hela connectionsträngen själv.


När du nu har databasen i rätt skick, den får skrivas i och du har bestämt dig för hur du skall ansluta så gäller ytterligare regler. Kör du en Access97 databas så skall du inte använda Jet 4.0 utan 3.5 - skillnaden är connectionsträngen. Att köra Jet 3.5 på en Access 2000 databas går inte.

Dags att ansluta till databasen från ASP

Som jag tidigare skrev så uppstår ett nytt scenarie - nämligen att det beror på vilken databas man använder så skall även connectionsträngarna se olika ut. Vi börjar med den lättaste - en DSN anslutning till en accessdatabas, oavsett version 7 eller 2000.

Först instansierar vi ADO som är det vi använder för att kommunicera med vår databas. ADO kan sägas vara motsvarande ett protokoll, likt TCP-IP, IPX för det är ett sätt att forsla data till och från databasen. ADO's objekt instansieras genom att skriva följande sträng:


Set Con = Server.CreateObject("ADODB.Connection")


Det är nu olikheterna börjar. Du kanske funderar på varför och orsaken är att om man använder en DSN så kör man via ytterligare ett lager som heter ODBC. Det är egentligen ett sätt för dig som användare att göra systemet mer dynamiskt genom att du i din DSN-koppling själv kan välja vilken databas det rör sig om. Nu tittar vi i alla fall på dessa alternativ:

DSN-anslutning till samtliga databaser


Con.Open "DSN=test;UID=pelle;PWD=soft"


DSN-lös anslutning till Access 7


con.Open "Provider=MSDASQL;" & _
"Driver={Microsoft Access Driver (*.mdb)};" & _
"Dbq=c:\databas\mindatabas.mdb;" & _
"Uid=anvaendarid;" & _
"Pwd=losen;"


DSN-lös anslutning till Access 2000


con.Open "Provider=Microsoft.Jet.OLEDB.4.0;" & _
"Data Source=c:\databas\mindatabas.mdb;" & _
"User Id=anvaendarid;" & _
"Password=;"


DSN-lös anslutning till SQL Server


con.Open "Provider=MSDASQL;" & _
"Driver={SQL Server};" & _
"Server=minserver;" & _
"Database=mindatabas;" & _
"Uid=anvaendarid;" & _
"Pwd=losen;"


Som du ser ovan så är connectionsträngarna lite olika beroende på förutsättningar. Jag hoppas nu att ni hörsammar detta och använder de enligt er miljö. Vissa fall kan kräva annorlunda lösningar såsom client-sided recordset, men det går vi inte in på ännu.

Nästa vanliga fel som dyker upp här är att användare nyttjar kommandot Server.Mappath("databas.mdb") för att få tag på hela sökvägen till databasen. Jag rekommenderar att ni inte använder den för varje connection som ansluts på era sidor - det tar bara extra cpu-tid för servern att leta reda på den korrekta sökvägen. Gör det en gång för att få reda på vart den ligger:


Response.Write Server.MapPath("mindatabas.mdb")
Response.End


Troligtvis kan då sökvägen bli:


d:\clients\pellesoft.nu\databas\mindatabas.mdb

Global.asa till undsättning

Nyttja då detta genom att en gång för alla lägg hela connectionsträngen i en variant av sessionsvariabel som heter application via din global.asa. För er som inte vet vad global.asa är så kan det motsvaras din dators autoexec.bat - den körs varje gång datorn startar, men även varje gång en användare kommer till din sida.

Du valde tidigare ett av dessa anslutningssträngar och det kan du nu omsätta till en sträng som kan nyttjas på vilken sida du än är. Vi tar som exempel att vi använder Access 2000- lösningen, databasen ligger i exemplet som jag visade med server.mappath:


Application_OnLoad()

Application.Lock
Application("DSN") = "Provider=Microsoft.Jet.OLEDB.4.0;" & _
"Data Source=d:\clients\pellesoft.nu\" & _
"databas\mindatabas.mdb;" & _
"User Id=kalle;" & _
"Password=;"
Application.UnLock

End Application


Det som nu har hänt är att ett objekt som heter Application("DSN") innehåller din korrekta connectionsträng. Var än du är, på vilken sida det än är så skriver du för att öppna din databas:


Set Con = Server.CreateObject("ADODB.Connection")
Con.Open Application("DSN")


Medge, det var väl ett smidigt sätt - och det kan faktiskt inte gå fel sedan. Tänk även på att du behöver bara ändra på ett enda ställe för att kunna byta databas, till och med från Access till MySQL eller vad det kan tänkas vara.

Checklista

För att göra en kort checklista av detta som vi nu lärt oss, så blir den som följer:

• Kontrollera att databasen är skrivbar
  
• Bestäm vilken connectionsträng som skall användas
  
• Ta reda på sökvägen till databasen (om det är access)
  
• Skriv om möjligt en connectionsträng i global.asa
  

Om du följer ovanstående punkter så kommer du klara dig långt. Använder du program och exempel som andra har gjort - titta då igenom dessa förutsättningar så kommer det gå mycket smidigare för dig att sätta upp allting så det fungerar enkelt och smidigt.

Vanliga fel

Nedan ser du några av de vanligaste felen som görs när man försöker ansluta till en databas:

• - fel provider används, Jet 4.0 finns inte i installationen
  
• - databasens sökväg är felaktig
  
• - exklusiv låsning av databas
  
• - du kan inte skriva till databasen (update/insert/delete)
  

Tips! För att se olika connectionsträngar för olika databaser, titta på artikeln Connectionsträngar så kommer du snabbt hitta den variant du behöver för att kunna ansluta till nästan vad som helst med ADO.

Ett vanligt fel som beror på servern

Många frågar om detta kryptiska fel och det är lika bra att ta upp det här så du aldrig glömmer bort det nu när du läser det:


Microsoft OLE DB Provider for ODBC Drivers (0x80004005)
[Microsoft][Drivrutin för ODBC Microsoft Access]Allmänt fel Det går inte att öppna registernyckeln

eller den egelska felkoden:

Temporary (volatile) Jet DSN for process 0x86c Thread 0xb10 DBC 0x1554fa4 Jet'


Det vanligaste felet här är att du har en Access 2000 databas men faktiskt inte har Jet 4.0 installerad. För att installera Jet 4.0 så går du till systemdokument/servicepacks här på pellesoft. Där finns denna länk. Det är nämligen så att från MDAC 2.5 så finns inte längre Jet motorn med utan levereras i ett separat paket.

För er som i Visual Basic använder Access2000 och skall distribuera ert program. Se till att Jet 4.0 kommer med i er Package & Deployment Wizard. Samma fel beter sig nämligen där om det är nya Windows maskiner som kanske till och med bara har MDAC 2.7 installerade.

Dags för lite databasanrop

När du nu lärt dig hur du sätter upp förutsättningarna för att köra en databas från din ASP sida så är det dags att börja fundera på hur man tar ut information från databasen. I förra artikeln pratade jag om att få tomma sessioner, tomma variabler och liknande. De flesta gör dessa fel i början och felen kan te sig lite konstiga - men snart förstår du varför jag tog upp det innan:


set rst=con.execute("select * from tabell " & _
where id = " & session("id"))



Teknisk information (för supportpersonal)

Feltyp:
Microsoft OLE DB Provider for ODBC Drivers (0x80040E14)
[Microsoft][ODBC SQL Server Driver][SQL Server]Line 1: Incorrect syntax near '='.
/xxx.asp, line 6



Allting ser ju bra ut enligt koden men felet är kryptiskt. Egentligen är det inte speciellt svårt att förstå vad som gått fel, speciellt inte om vi gör en annan infallsvinkel på detta problem. Vi börjar istället med att bygga upp sql-strängen fritt innan den körs. Eftersom vi fick fel - så skriver vi ut sql-satsen på skärmen och tittar på vad som kan vara fel:


SQL = "select * from tabell where id = " & _
& session("id")
Response.Write SQL
Response.End



select * from tabell where id =


Det står inget efter id =, där är givetvis felet. Genom att bygga ihop sql-satsen, då speciellt vid select, update och insert så kan du skriva ut den, se dess innehåll och tolka vad som kan vara fel. Det är inte heller helt ovanligt att ' eller " placerats fel vilket resulterar i en felaktig syntax när frågan skall skickas till databasen.

Tänk även på följande. Som du ser så står det i felhanteringen att det berör ODBC, OLE DB och SQL Server. Står något namn som detta med - är det alltså ett fel beroende på att din sql-fråga inte är korrekt på ett eller annat sätt.

Några grundläggande regler

Nu har vi varit inne på att öppna databaser på olika sätt, till och med ställt några frågor som har gått fel och förhoppningsvis har du nu lärt dig några av dessa fel så du lättare kan känna igen dom när de uppstår. Innan vi avslutar denna del så tänkte jag även ta upp några viktiga saker - mer av prestadan än att kunna göra fel på det.

• Regel 1.
  
  Det räcker att använda en connectionsträng till en asp-sida, även om du skall fylla flera recordset med information på olika ställen.
  
  
set con=server.createobject("adodb.connection")
con.open application("dsn")

set rs1 = con.execute("select * from tabell1")
set rs2 = con.execute("select * from tabell2")

  
  
• Regel 2.
  
  Stäng och frigör alltid alla objekt som du skapat på din sida. Om du inte gör det så ligger de öppna på webbservern och tar internminne och onödig plats på servern. Se till att du klipper strängen. En regel är att överrallt där du skriver Set x = ... skall du även ta bort.
  
  
set rs1 = nothing
set rs2 = nothing
set con = nothing

  
  
• Regel 3.
  
  Om du försöker använda kommandot rst.Recordcount och alltid får -1 i retur även fast det finns fler poster (gäller även fel för .MovePrevious m.fl.) så måste du öppna din tabell på annorlunda sätt). Arbetar du på detta sätt så tänk även på att inkludera adovbs.inc - så konstanterna kommer med.
  
  
rst.Open "select * from tabell", Connect, adOpenStatic, adLockOptimistic
response.write rst.recordcount

  
  
• Regel 4.
  
  När du skriver data eller skickar in data så kan du undlätta för dig. Att skicka in en sträng i ett fält som är numeriskt, eller skicka in ett numeriskt fält i en sträng är ju struligt att hålla reda på, genom att innesluta alla fält med ' så undviker du detta problem.
  
  
sql = "'" & artikelid & "', " & _
"'" & artikelnamn & "', " & _
"'" & request("saldo") & "' " & _
"where artikelid = " & artikelid

sql = replace(sql, "''", "null")
con.execute "artikelupd " & sql

  
  Gäller det datum och Access, så skall datum inneslutas med # # - annars blir det fel, SQL server behöver ' '.
  
  
sql = "update artikel set foersaljningsdatum = "# & now & "# where artikelid = 2"

  
  
  
• Regel 5.
  
  Undvik att använda dig av rs.Edit rs.AddNew och liknande. Då måste nämligen Jet motorn arbeta med tillsammans med SQL-motorn (även i Access). Detta gör att det går långsammare. Använd om möjligt rena sql-frågor. Det finns många artiklar om hur man skriver SQL - både här och på nätet så ta och börja med att lära er lite, det kommer ge er mycket glädje i framtiden.
  
  » Grundkurs i SQL
  » MySQL Teknisk referens
  » SQL Referens
  » Using SQL Server
  » Freelancing SQL
  
  
• Regel 6.
  
  Testa era sql-satser innan ni lägger in dom i programmet. Det är mycket enklare att avhjälpa felen om ni vet att sql-satsen är korrekt först. Några editorer för just SQL finns att hämta här:
  
  » urSQL
  » Diverse editorer
  
  Obs! Har ni tips på fler bra fristående SQL-editorer så skicka ett mail till mig.
  
  

Hoppas ni nu har fått några aha-upplevelser och tar med er detta i er fortsatta programmering med ASP och databaser.

0 Kommentarer

Skriv en kommentar på artikeln

Ditt betyg på artikeln

UtmärktLäsvärdIntressantMindre braDålig

Kommentar: