Glengamoi (Forum) · AspHeute · .NET Heute (RSS-Suche) · AspxFiles (Wiki) · .NET Blogs
ASP German Homepage Homepage
 

Liste

.NET 2.0 (1)
.NET Allgemein (16)
.NET Fu (5)
ADO.NET (11)
Aprilscherz (3)
ASP Grundlagen (44)
ASP Tricks (83)
ASP.NET (44)
ASPIntranet.de (5)
C# (28)
Datenbank (44)
Dokumentation (4)
IIS 6.0 (1)
Komponenten (29)
Optimierung (10)
Server (21)
Sicherheit (34)
Tee Off (6)
VB.NET (6)
WAP (8)
Web Services (11)
XML (9)

RSS 2.0 - Die neuesten fünf Artikel auf AspHeute.com


 

Suchen





 

English Articles
Chinese Articles
Unsere Autoren
 
Link zu AspHeute
Impressum
Werben
Anfragen

Access Abfragen in ADO verwenden

Geschrieben von: Christoph Wille
Kategorie: Datenbank

Es gibt in Microsoft Access Datenbanken Abfragen (Query), die eine Mixtur aus SQL Server Views und Stored Procedures darstellen: Wenn man keine Parameter definiert, ist es mit einer View vergleichbar, auf die ein SELECT Statement abgesetzt werden kann. Hat man Parameter festgelegt, dann hat man ein "Äquivalent" zu Stored Procedures, obwohl bei weitem nicht so leistungsfähig. Und außerdem werden Abfragen in der Datenbank abgelegt, was bedeutet, man verteilt den Code nicht auf verschiedenste ASP Seiten.

Trotz dieser Vorteile verwenden Abfragen meist nur Access Programmierer, und ASP Programmierer lassen in den meisten Fällen die Finger davon. Um dies zu ändern, enthält dieser Artikel die Kochrezepte um parameterlose als auch mit Eingabeparametern versehene Abfragen von ADO aus zu nutzen.

Um das Thema in ein sinnvolles Beispiel zu gießen, habe ich meine Länderdatenbank ausgegraben, die nur die Tabelle tCountry mit 2 Spalten beeinhaltet: Ländercode (CountryCode) und Ländername (CountryName). Es sind alle Länder enthalten, man kann diese Tabelle also hervorragend für verschiedenste Arten von Formularen verwenden:

tCountry Tabelle

Parameterlose Abfragen

Abfragen, bei denen keine Parameter angegeben werden müssen, können auf 2 Arten abgefragt werden:

  • SELECT * FROM AbfrageName
  • Als Command Objekt mit Typ adCmdStoredProc

Zu SELECT gibt es nichts Neues zu sagen, da dies wie eine normales SQL SELECT Statement gehandhabt wird. Die Implementierung mit dem Command Objekt sieht hingegen anders aus. Um dies zu demonstrieren, habe ich die Abfrage Einfache Abfrage in die Datenbank hinzugefügt, die alle Länder nach Ländercode sortiert ausgibt (üblicherweise würde man nach Namen sortieren):

Einfache Abfrage

Wer schon SQL Server Stored Procedures programmiert hat, dem wird der folgende Code bekannt vorkommen:

<% Response.Expires = 0 %>
<!--METADATA NAME="Microsoft ActiveX Data Objects 2.5 Library" 
	TYPE="TypeLib" 
	UUID="{00000205-0000-0010-8000-00AA006D2EA4}"
-->
<%
   Dim cn, rs

   Set cn = CreateObject("ADODB.Connection")
   Set rs = CreateObject("ADODB.Recordset")
   
   ' Connection zur Datenbank aufbauen
   cn.Open "Provider=Microsoft.Jet.OLEDB.4.0;" & _
      "Data Source=" & Server.MapPath("cc.mdb") & ";"

   ' Recordset öffnen
   rs.Open "[Einfache Abfrage]", _
      cn, adOpenForwardOnly, adLockReadOnly, adCmdStoredProc

   ' Records anzeigen
   Do Until rs.EOF
   	Response.Write rs(0) & " " & rs(1) & "<br>" & vbCrLf
      rs.MoveNext
   Loop

   ' Recordset schließen
   rs.Close
   cn.Close
%>

Die ADO Konstanten habe ich über das METADATA Tag eingebunden, aber wo ist das von mir versprochene Command Objekt? Man kann es bei parameterlosen Abfragen durch Angabe des adCmdStoredProc Parameters bei der Open Methode des Recordsets einsparen.

Wenn eine Abfrage Leerzeichen oder Sonderzeichen enthält, muß man den Namen der Abfrage in eckige Klammern einschließen. Generell empfehle ich, von Leer- und Sonderzeichen abzusehen.

Abfragen mit Parametern

Bei Abfragen, die Parameter entgegennehmen, muß man das Command Objekt verwenden, Abkürzungen sind nicht erlaubt. Um es anhand eines praktischen Beispiels zu demonstrieren, habe ich die Abfrage qParamQuery erstellt, die den Ländercode als Parameter verlangt, und dann das entsprechende Land zurückgibt:

Query    Parameters

Der zugehörige ASP Code sieht wie folgt aus:

<% Response.Expires = 0 %>
<!--METADATA NAME="Microsoft ActiveX Data Objects 2.5 Library" 
	TYPE="TypeLib" 
	UUID="{00000205-0000-0010-8000-00AA006D2EA4}"
-->
<%
	Dim cn, cmd, rs, param

	Set cn = CreateObject("ADODB.Connection")
	Set cmd = CreateObject("ADODB.Command")
   
	' Connection zur Datenbank aufbauen
	cn.Open "Provider=Microsoft.Jet.OLEDB.4.0;" & _
    		"Data Source=" & Server.MapPath("cc.mdb") & ";"

	Set cmd.ActiveConnection = cn
	cmd.CommandText = "qParamQuery"
	cmd.CommandType = adCmdStoredProc

	' Set rs = cmd.Execute(, Array("AT"))
	Set rs = cmd.Execute(, "AT")

	' Records anzeigen
	Do Until rs.EOF
		Response.Write rs(0) & " " & rs(1) & "<br>" & vbCrLf
		rs.MoveNext
	Loop

	' Recordset schließen
	rs.Close
	cn.Close
%>

Dem Command Objekt muß zuerst die ActiveConnection zugewiesen werden. Danach folgen CommandText sowie CommandType - dieser jedoch könnte auch erst im Execute Statement angegeben werden. Womit wir beim interessantesten Teil des Codes sind, nämlich wie Parameter übergeben werden.

Im Gegensatz zu SQL Server kann man die Parameters Collection nicht verwenden, sondern muß die Parameter als Array übergeben. Für einen Parameter ist dies nicht notwendig, allerdings wird auch kein Fehler ausgelöst wenn man es doch tut - man muß nur die auskommentierte Zeile ausprobieren.

Die Problematik, die sich aus der Array Übergabe ergibt ist die, daß zum Übergabezeitpunkt keine Kontrolle durchgeführt wird, ob die Parameter den richtigen Datentyp haben. Man muß sich also auf Laufzeitfehler einstellen, oder die VBScript Datentypen vorher strikter kontrollieren.

Schlußbemerkung

Für Access-Verhältnisse sind Abfragen ein leistungsfähiges Konzept, das es erlaubt, oft gebrauchte Views und parametrisierte Abfragen zentral abzulegen. Allerdings sind sie dennoch bei weiten nicht so leistungsfähig wie SQL Server Stored Procedures. Und ein weiteres Manko ist, daß die ADO Syntax sehr stark von der von Stored Procedures abweicht - dies kann einem viel Arbeit einbringen, wenn man auf SQL Server umsteigt.

Download des Codes

Klicken Sie hier, um den Download zu starten.

Verwandte Artikel

Einfügen eines Datensatzes mit dem INSERT Statement

Wenn Sie jetzt Fragen haben...

Wenn Sie Fragen rund um die in diesem Artikel vorgestellte Technologie haben, dann schauen Sie einfach bei uns in den Community Foren der deutschen .NET Community vorbei. Die Teilnehmer helfen Ihnen gerne, wenn Sie sich zur im Artikel vorgestellten Technologie weiterbilden möchten.

Haben Sie Fragen die sich direkt auf den Inhalt des Artikels beziehen, dann schreiben Sie dem Autor! Unsere Autoren freuen sich über Feedback zu ihren Artikeln. Ein einfacher Klick auf die Autor kontaktieren Schaltfläche (weiter unten) und schon haben Sie ein für diesen Artikel personalisiertes Anfrageformular.

 

Und zu guter Letzt möchten wir Sie bitten, den Artikel zu bewerten. Damit helfen Sie uns, die Qualität der Artikel zu verbessern - und anderen Lesern bei der Auswahl der Artikel, die sie lesen sollten.

Bewerten Sie diesen Artikel
 Sehr gut   Nicht genügend  
   1  2  3  4  5  
 

  
   Für Ausdruck optimierte Seite

©2000-2006 AspHeute.com
Alle Rechte vorbehalten. Der Inhalt dieser Seiten ist urheberrechtlich geschützt.
Eine Übernahme von Texten (auch nur auszugsweise) oder Graphiken bedarf unserer schriftlichen Zustimmung.