Discussion:
Stored Procedure mit Parameter direkt starten
(zu alt für eine Antwort)
Helmut Fischer
2006-08-08 08:57:48 UTC
Permalink
Hallo,

(wie) kann man eine stored procedure, welche einen Parameter erwartet OHNE
ADO-Command-Objekt starten?
Es geht um einen einfachen Weg diese "Parameterabfrage" am Bildschirm
anzuzeigen. (als Beispiel aus der Nordwind.adp gerne CustOrderHist)

Danke

Helle
SQL2000 / Access2003
Reiner Wolff
2006-08-08 10:45:09 UTC
Permalink
Moin Helmut,
Post by Helmut Fischer
(wie) kann man eine stored procedure, welche einen Parameter erwartet OHNE
ADO-Command-Objekt starten?
Starten kann man das jedenfalls auch über das Connection-Objekt:
strSQL = "Exec custOrderHist " & ParameterWert(eSemikolaGetrennt)
cnn.Execute strSQL

Greetinx aus Kiel
Reiner
--
Mit einer Gummiente bist Du nie allein.
("The Hitchhiker's Guide to the Galaxy")
Helmut Fischer
2006-08-08 12:16:37 UTC
Permalink
Hi Reiner,
Post by Reiner Wolff
Moin Helmut,
Post by Helmut Fischer
(wie) kann man eine stored procedure, welche einen Parameter erwartet OHNE
ADO-Command-Objekt starten?
strSQL = "Exec custOrderHist " & ParameterWert(eSemikolaGetrennt)
cnn.Execute strSQL
Greetinx aus Kiel
Reiner
--
Mit einer Gummiente bist Du nie allein.
("The Hitchhiker's Guide to the Galaxy")
Danke, aber dabei wird ja im Access-Frontend nichts angezeigt, diese Version
wäre somit eher für Aktionsabfragen geeignet.
Die Frage ging eher in die Richtung, "wie kann man Accessern ohne VBA /
ADO - Kenntnisse Parameterabfragen schmackhaft machen"
Mit DoCmd.OpenStoredProcedure bekommt man wohl (?!?) keinen Parameter
übergeben, oder ?

Gruss
Helle
Stefan Dase
2006-08-08 11:38:21 UTC
Permalink
Hallo Helmut,
Post by Helmut Fischer
(wie) kann man eine stored procedure, welche einen Parameter erwartet OHNE
ADO-Command-Objekt starten?
Es geht um einen einfachen Weg diese "Parameterabfrage" am Bildschirm
anzuzeigen. (als Beispiel aus der Nordwind.adp gerne CustOrderHist)
Mit ADPs habe ich bisher noch nicht gearbeitet. Aber bei MDBs kann man
in einer Pass-Through-Abfrage die SP direkt auf der Datenbank ansprechen
mittels

EXEC SP_Name(Parameter1, Parameter2, ...)

Vielleicht funktioniert es analog auch in der ADP?

HTH,
Stefan
Helmut Fischer
2006-08-08 12:23:43 UTC
Permalink
Hallo Stefan,

Pass-Through gibt es imho nur bei MDB.

Gruss
Helle
Post by Stefan Dase
Hallo Helmut,
Post by Helmut Fischer
(wie) kann man eine stored procedure, welche einen Parameter erwartet
OHNE ADO-Command-Objekt starten?
Es geht um einen einfachen Weg diese "Parameterabfrage" am Bildschirm
anzuzeigen. (als Beispiel aus der Nordwind.adp gerne CustOrderHist)
Mit ADPs habe ich bisher noch nicht gearbeitet. Aber bei MDBs kann man in
einer Pass-Through-Abfrage die SP direkt auf der Datenbank ansprechen
mittels
EXEC SP_Name(Parameter1, Parameter2, ...)
Vielleicht funktioniert es analog auch in der ADP?
HTH,
Stefan
Stefan Dase
2006-08-08 12:51:22 UTC
Permalink
Hallo Helmut,
Post by Helmut Fischer
Pass-Through gibt es imho nur bei MDB.
Das ist klar, da du ja direkt auf/mit dem Server arbeitest.

Ich dachte nur, dass man ein ähnliches Konstrukt als SQL-Anweisung
erstellen kann, und die Ergebnismenge dann als Recordset zurück erhält.
Scheint aber nicht der Fall zu sein.

Viele Grüße,
Stefan
Christa Kurschat
2006-08-08 13:15:44 UTC
Permalink
Hallo Stefan,
Post by Stefan Dase
Hallo Helmut,
Post by Helmut Fischer
Pass-Through gibt es imho nur bei MDB.
Das ist klar, da du ja direkt auf/mit dem Server arbeitest.
Ich dachte nur, dass man ein ähnliches Konstrukt als SQL-Anweisung
erstellen kann, und die Ergebnismenge dann als Recordset zurück erhält.
Scheint aber nicht der Fall zu sein.
Nein, nicht mit Stored Procedures.
Aber was spricht gegen eine Verwendung von Funktionen mit Tabellenrückgabe?
Die können direkt mit Select angesprochen werden.

Select * from dbo.MeineFunktion(p1,p2)

Andere Varinte wäre ein Formular in Tabellenansicht, daß die Prozedur als
Datenbasis hat.
Wieso muß es denn eine direkte Anzeige sein?

So ganz verstehe ich die Anforderung nicht.

Gruß
Christa
--
Access-FAQ: http://www.donkarl.com
SQL-Server-FAQ: www.sqlfaq.de
auch interessant: http://www.insidesql.de
Suchen in den Newsgroups:
http://groups.google.de/advanced_group_search?hl=de&lr=&ie=UTF-8
Helmut Fischer
2006-08-08 14:15:14 UTC
Permalink
Hallo Christa

"Christa Kurschat" <***@web.de> schrieb im Newsbeitrag news:***@TK2MSFTNGP05.phx.gbl...
...
Post by Christa Kurschat
Nein, nicht mit Stored Procedures.
Aber was spricht gegen eine Verwendung von Funktionen mit
Tabellenrückgabe?
Die können direkt mit Select angesprochen werden.
Select * from dbo.MeineFunktion(p1,p2)
Andere Varinte wäre ein Formular in Tabellenansicht, daß die Prozedur als
Datenbasis hat.
Wieso muß es denn eine direkte Anzeige sein?
So ganz verstehe ich die Anforderung nicht.
Gruß
Christa
--
Access-FAQ: http://www.donkarl.com
SQL-Server-FAQ: www.sqlfaq.de
auch interessant: http://www.insidesql.de
http://groups.google.de/advanced_group_search?hl=de&lr=&ie=UTF-8
ich war nur auf der Suche nach einfachsten Alternativen und die Variante
"Formular in Tabellenansicht mit Eingabeparameter" ist wohl wirklich das
Beste (sofern man möglichst wenig Programmieren möchte)

Danke

Helle
Helmut Fischer
2006-08-08 14:55:08 UTC
Permalink
nochemol Hallo Christa
"Christa Kurschat" <***@web.de> schrieb im Newsbeitrag news:***@TK2MSFTNGP05.phx.gbl...
...
Post by Christa Kurschat
Aber was spricht gegen eine Verwendung von Funktionen mit
Tabellenrückgabe?
Die können direkt mit Select angesprochen werden.
Select * from dbo.MeineFunktion(p1,p2)
damit hast Du Neugier und Ehrgeiz geweckt ;->

die Funktion bekomme ich hin, den genannten Aufruf per QA auch, eine View
mit festen Übergabeparametern auch
Aber wie habe ich in einer Access-Anwendung was davon, wie kommt der (die)
Parameter da rein?
Ein MiniVBA mit DoCmd.RunSQL bekomme ich aber nicht parametrisiert.

(ist jetzt wirklich nur neugieriges nachkarren ;-> )

Merci

Helle
Peter Doering
2006-08-08 20:03:34 UTC
Permalink
Hallo,
"Christa Kurschat" ...
...
Post by Christa Kurschat
Aber was spricht gegen eine Verwendung von Funktionen mit
Tabellenrückgabe?
Die können direkt mit Select angesprochen werden.
Select * from dbo.MeineFunktion(p1,p2)
die Funktion bekomme ich hin, den genannten Aufruf per QA auch, eine View
mit festen Übergabeparametern auch
Aber wie habe ich in einer Access-Anwendung was davon, wie kommt der (die)
Parameter da rein?
Ein MiniVBA mit DoCmd.RunSQL bekomme ich aber nicht parametrisiert.
Im Formular:

Dim strPar1 As String
Dim strPar2 As String
Dim strConnect As String

strConnect = "ODBC;" & _
"Driver=SQL Server;" & _
"Server=XYZ;" & _
"Database=Nordwind;" & _
"uid=sa;" & _
"pwd=topsecret"

strPar1 = "Hallo"
strPar2 = "Welt"

Me.RecordSource = "SELECT * FROM [" & strConnect & "]" & _
".dbo.MeineFunktion('" & strPar1 & "', '" & strPar2 &"')"

Die Recordsource sieht danach so aus:

SELECT * FROM [ODBC;Driver=SQL Server;Server=XYZ;Database=Nordwind;uid=sa;pwd=topsecret].dbo.MeineFunktion('Hallo', 'Welt')

Gruss - Peter
--
Ich beantworte keine Fragen per Email.
Mitglied im http://www.dbdev.org
FAQ: http://www.donkarl.com
Reiner Wolff
2006-08-08 21:33:44 UTC
Permalink
Moin Peter,
Post by Peter Doering
"Christa Kurschat" ...
Post by Christa Kurschat
Aber was spricht gegen eine Verwendung von Funktionen mit
Tabellenrückgabe?
Die können direkt mit Select angesprochen werden.
Select * from dbo.MeineFunktion(p1,p2)
die Funktion bekomme ich hin, den genannten Aufruf per QA auch, eine View
mit festen Übergabeparametern auch
Aber wie habe ich in einer Access-Anwendung was davon, wie kommt der (die)
Parameter da rein?
Ein MiniVBA mit DoCmd.RunSQL bekomme ich aber nicht parametrisiert.
[bisl Code gesnippt]
Post by Peter Doering
Me.RecordSource = "SELECT * FROM [" & strConnect & "]" & _
".dbo.MeineFunktion('" & strPar1 & "', '" & strPar2 &"')"
SELECT * FROM [ODBC;Driver=SQL Server;Server=XYZ;Database=Nordwind;uid=sa;pwd=topsecret].dbo.MeineFunktion('Hallo', 'Welt')
Ja, Ok, aber wo liegt darin der Vorteil?
Da dürfte es doch einfacher sein, direkt in der Entwurfsansicht des
Formulars die Datenherkunft auf
procName 'hallo', 'Welt'
zu setzen.
Access2003 kommt damit im Gegensatz zu Acc2000 ja klar.
Wozu soll der Umweg über eine Funktion mit einer Tabelle als Rückgabewert
da gut sein? Das macht imho die Sache nur unübersichtlicher.

Greetinx aus Kiel
Reiner
--
Wenn jemand von der EDV-Abteilung sagt, dass er gleich vorbeikommt,
melde dich vom System ab und geh einen Kaffee trinken.
Es ist für uns kein Problem, uns 700 Passwörter zu merken.
Peter Doering
2006-08-08 22:52:11 UTC
Permalink
Hallo Reiner,
Post by Reiner Wolff
Post by Peter Doering
"Christa Kurschat" ...
Post by Christa Kurschat
Aber was spricht gegen eine Verwendung von Funktionen mit
Tabellenrückgabe?
Die können direkt mit Select angesprochen werden.
Select * from dbo.MeineFunktion(p1,p2)
die Funktion bekomme ich hin, den genannten Aufruf per QA auch, eine View
mit festen Übergabeparametern auch
Aber wie habe ich in einer Access-Anwendung was davon, wie kommt der (die)
Parameter da rein?
Ein MiniVBA mit DoCmd.RunSQL bekomme ich aber nicht parametrisiert.
[bisl Code gesnippt]
Post by Peter Doering
Me.RecordSource = "SELECT * FROM [" & strConnect & "]" & _
".dbo.MeineFunktion('" & strPar1 & "', '" & strPar2 &"')"
SELECT * FROM [ODBC;Driver=SQL Server;Server=XYZ;Database=Nordwind;uid=sa;pwd=topsecret].dbo.MeineFunktion('Hallo', 'Welt')
Ja, Ok, aber wo liegt darin der Vorteil?
Da dürfte es doch einfacher sein, direkt in der Entwurfsansicht des
Formulars die Datenherkunft auf
procName 'hallo', 'Welt'
zu setzen.
Und woher weiss das Formular, auf welchem Server die Funktion liegt?
Und wenn es statisch 'hallo' 'Welt' waere, braeuchte man keine Parameter.
Da es Parameter sind, wirst du um die flexible Aufbereitung der
RecordSource nicht herumkommen. Dann stellt sich IMO nur die Frage, ob an
den paar Zeilen was optimiert werden kann und ich habe nicht den Anspruch,
dass das nicht moeglich waere ;-)
Post by Reiner Wolff
Wozu soll der Umweg über eine Funktion mit einer Tabelle als Rückgabewert
da gut sein? Das macht imho die Sache nur unübersichtlicher.
Aufgabenstellung war sinngemaess, ohne ADO aus einer SP mit Parametern ein
Recordset zurueckzubekommen.

Gruss - Peter
--
Ich beantworte keine Fragen per Email.
Mitglied im http://www.dbdev.org
FAQ: http://www.donkarl.com
Reiner Wolff
2006-08-09 05:23:02 UTC
Permalink
Moin Peter,
Post by Peter Doering
Post by Reiner Wolff
[bisl Code gesnippt]
Post by Peter Doering
Me.RecordSource = "SELECT * FROM [" & strConnect & "]" & _
".dbo.MeineFunktion('" & strPar1 & "', '" & strPar2 &"')"
SELECT * FROM [ODBC;Driver=SQL Server;Server=XYZ;Database=Nordwind;uid=sa;pwd=topsecret].dbo.MeineFunktion('Hallo', 'Welt')
Ja, Ok, aber wo liegt darin der Vorteil?
Da dürfte es doch einfacher sein, direkt in der Entwurfsansicht des
Formulars die Datenherkunft auf
procName 'hallo', 'Welt'
zu setzen.
Und woher weiss das Formular, auf welchem Server die Funktion liegt?
Ein ADP ist idR mit einer Datenbank auf einem SQL-Server verbunden.
Das Formular sucht diese SP dann einfach dort.
Oder hat Helmut das Problem, dass die SP auf einem anderen Server oder in
einer anderen Datenbank liegt?
Post by Peter Doering
Und wenn es statisch 'hallo' 'Welt' waere, braeuchte man keine Parameter.
Stimmt. Du hast damit angefangen ;-)
Post by Peter Doering
Da es Parameter sind, wirst du um die flexible Aufbereitung der
RecordSource nicht herumkommen.
Warum nicht?
Du kannst doch problemlos auch sowas aufrufen:
procName Steuerelement, Steuerelement2
oder
procName DLookup(...), DMax(...)

(Wobei ich die Domänenfunktionen nicht mag.)

Aber wieso muss ich da was in VBA machen?
Post by Peter Doering
Post by Reiner Wolff
Wozu soll der Umweg über eine Funktion mit einer Tabelle als Rückgabewert
da gut sein? Das macht imho die Sache nur unübersichtlicher.
Aufgabenstellung war sinngemaess, ohne ADO aus einer SP mit Parametern ein
Recordset zurueckzubekommen.
Ja, aber wozu soll der Umweg über eine Funktion mit einer Tabelle als
Rückgabewert da gut sein? Das macht imho die Sache nur unübersichtlicher.

;-)

Greetinx aus Kiel
Reiner
--
if (2.0 = = 1.999999963) printf("Pentium inside!\n")
Peter Doering
2006-08-09 10:50:43 UTC
Permalink
Hallo Reiner,
Post by Reiner Wolff
Post by Peter Doering
Und woher weiss das Formular, auf welchem Server die Funktion liegt?
Ein ADP ist idR mit einer Datenbank auf einem SQL-Server verbunden.
Das Formular sucht diese SP dann einfach dort.
Oder hat Helmut das Problem, dass die SP auf einem anderen Server oder in
einer anderen Datenbank liegt?
Ich bin bisher von mdb ausgegangen. ADP war ausser in dem Beispiel
(Nordwind.adp) nirgends erwaehnt.
Post by Reiner Wolff
Aber wieso muss ich da was in VBA machen?
Wenn's um ADP geht, ist der Rest eh hinfaellig.

Gruss - Peter

Peter Doering
2006-08-08 13:14:02 UTC
Permalink
Hallo,
Post by Helmut Fischer
(wie) kann man eine stored procedure, welche einen Parameter erwartet OHNE
ADO-Command-Objekt starten?
Es geht um einen einfachen Weg diese "Parameterabfrage" am Bildschirm
anzuzeigen. (als Beispiel aus der Nordwind.adp gerne CustOrderHist)
Du kannst folgendes Code-Schnipsel (auf _engl._ Northwind getestet) in der
Form_Open-Prozedur eines Endlosformulars testen:

Private Sub Form_Open(Cancel As Integer)
Dim strConn As String
Dim Qry As DAO.QueryDef
Dim Rst As DAO.Recordset

strConn = "ODBC;Driver=SQL Server;" & _
"Server=Doering2\SIS;Database=Northwind;" & _
"uid=du;pwd=topsecret"

Set Qry = CurrentDb.CreateQueryDef("tmp1")
With Qry
.Connect = strConn
.ReturnsRecords = True
.ODBCTimeout = 0
.SQL = "CustOrderHist 'ALFKI'"
.Close
End With
Set Qry = Nothing

Me.RecordSource = "tmp1"
End Sub

Die ausgegebenen Felder, also die du an die Steuerelemente binden musst,
heissen ProductName und Total.

Gruss - Peter
--
Ich beantworte keine Fragen per Email.
Mitglied im http://www.dbdev.org
FAQ: http://www.donkarl.com
Loading...