4
GP, Tabelle als Variable zurückgeben
Aus einer Tabelle sollen Zeilen mittels einer gespeicherten Prozedur ausgewählt und in einer Tabellenvariablen von dieser Prozedur zurückgegeben werden.
MS-Access-2000 Projekt, verbunden mit MS-SQL 2000 SERVER. In einem Formular des Access-Projektes sollen die Ergebnisse einer Abfrage in einem Listenfeld zur Verfügung stehen. Um ein hohes Tempo zu erzielen, wird diese Abfrage in einer gespeicherten Prozedur ausgeführt, dort werden auch die Selectionsparameter aus bestimmten anderen Tabellen ermittelt.. Zunächst hatte ich das Ergebnis der Abfrage in einer globalen temporären Tabelle ##Table gespeichert. Dabei nicht bedacht, daß diese bei allen angemeldeten Benutzern (meist 4 User gleichzeitig) im Netz sichtbar ist und somit ungewollt z.B. das Ergebnis der Abfrage des Users A in der Tabelle ##Table des Users B gespeichert wird und dort die Source des Listenfeldes ist. Versuche, mit lokalen Tabellen #Table zu arbeiten (das würde wohl das Problam auch lösen) sind daran gescheitert, daß #Table nicht vom Listenfeld gefunden wird. Nun hoffe ich, eine Variable - die als Tabelle definiert ist - zur Quelle des Listenfeldes zu machen und das diese dann nur vom jeweilig die gespeicherte Prozedur aufrufenden User "gesehen" wird.
Frage, wie definiere ich den Rückgabeparameter .... CreateParameter("TableName", ad (Table??) , adParamOutput ... ?? vor dem --> Execute der Prozedur und wie wird diese Tabelle in der gespeicherten Prozedur so deklariert, daß sie ein Rückgabewert als Tabelle wird ?
Falls jemand weiß, wie man die Aufgabe doch noch mit lokalen Tabellen #Table lösen kann, wäre das natürlich fast noch besser (?).
Vielen Dank im Voraus,
PCFJKG
MS-Access-2000 Projekt, verbunden mit MS-SQL 2000 SERVER. In einem Formular des Access-Projektes sollen die Ergebnisse einer Abfrage in einem Listenfeld zur Verfügung stehen. Um ein hohes Tempo zu erzielen, wird diese Abfrage in einer gespeicherten Prozedur ausgeführt, dort werden auch die Selectionsparameter aus bestimmten anderen Tabellen ermittelt.. Zunächst hatte ich das Ergebnis der Abfrage in einer globalen temporären Tabelle ##Table gespeichert. Dabei nicht bedacht, daß diese bei allen angemeldeten Benutzern (meist 4 User gleichzeitig) im Netz sichtbar ist und somit ungewollt z.B. das Ergebnis der Abfrage des Users A in der Tabelle ##Table des Users B gespeichert wird und dort die Source des Listenfeldes ist. Versuche, mit lokalen Tabellen #Table zu arbeiten (das würde wohl das Problam auch lösen) sind daran gescheitert, daß #Table nicht vom Listenfeld gefunden wird. Nun hoffe ich, eine Variable - die als Tabelle definiert ist - zur Quelle des Listenfeldes zu machen und das diese dann nur vom jeweilig die gespeicherte Prozedur aufrufenden User "gesehen" wird.
Frage, wie definiere ich den Rückgabeparameter .... CreateParameter("TableName", ad (Table??) , adParamOutput ... ?? vor dem --> Execute der Prozedur und wie wird diese Tabelle in der gespeicherten Prozedur so deklariert, daß sie ein Rückgabewert als Tabelle wird ?
Falls jemand weiß, wie man die Aufgabe doch noch mit lokalen Tabellen #Table lösen kann, wäre das natürlich fast noch besser (?).
Vielen Dank im Voraus,
PCFJKG
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 101000
Url: https://administrator.de/contentid/101000
Ausgedruckt am: 24.11.2024 um 04:11 Uhr
4 Kommentare
Neuester Kommentar
Moin PCFJKG,
--> #Tables haben nicht immer einen Namen, eher eine Namens-Pattern, einen Namensrumpf. Den exakten außerhalb der SP weisst Du nicht, Innerhalb der SP wird IMMER der richtig interpretiert, den Du angibst.
--> ##Tables gehen erst recht nicht ->hast Du ja selbst erläutert.
Bleiben CURSOR oder @variablen vom typ table.
Ich würde (wenn der Resultset nicht zu gross ist) über eine table-Variable gehen.
Also sinngemäß
In der SP selbst kanst Du dann nochmal ein
Da die @jezzinruhe angelegte und befüllte lokale Variable ebenso vom Datentyp "table" ist wie auch@DeinOutput kannst Du gegen Ende der SP ein "SET @deinoutput = @jezzinruhe" abfeuern und bekommst den Resultset zurück.
Das war schon alles.
Grüße
Biber
...daran gescheitert, daß #Table nicht vom Listenfeld gefunden wird.
Okay, das kann aber daran liegen, dass besagte 4 Benutzer denselben Namen "#Table" benutzen und MSSQL schlau wie Sau natürlich immer bei Bedarf eine Ziffer an den Tabellennamen "#Table" hängt. Blöd nur, wenn jemand auf genau diese Tabelle außerhalb der Stored Procedure zugreifen können soll.--> #Tables haben nicht immer einen Namen, eher eine Namens-Pattern, einen Namensrumpf. Den exakten außerhalb der SP weisst Du nicht, Innerhalb der SP wird IMMER der richtig interpretiert, den Du angibst.
--> ##Tables gehen erst recht nicht ->hast Du ja selbst erläutert.
Bleiben CURSOR oder @variablen vom typ table.
Ich würde (wenn der Resultset nicht zu gross ist) über eine table-Variable gehen.
Also sinngemäß
CREATE PROCEDURE dbo.WTFduTust (
@EinInPara NVARCHAR(50))
, @NochnInpara int
, @deinOutput table OUTPUT
AS
......DECLARE @jezzinruhe as (Column1, .....ColumnN) Primary key ...
machen und Deinen Resultset dort zwischenparken - Die Column-Angaben mit der gleichen syntax wi bei einem CREATE TABLE.Da die @jezzinruhe angelegte und befüllte lokale Variable ebenso vom Datentyp "table" ist wie auch@DeinOutput kannst Du gegen Ende der SP ein "SET @deinoutput = @jezzinruhe" abfeuern und bekommst den Resultset zurück.
Das war schon alles.
Grüße
Biber
Hallo Biber,
zunächst Dank für die Hilfe. Die Lösung mit der Table-Variablen scheint mir auch die "vernünftigste", scheitert momentan aber an der Deklaration. Mein Versuch in der SP lautet:
CREATE PROCEDURE "Test"
(
@eininpara NVARCHAR(50),
@nochninpara int,
@meinoutput TABLE OUTPUT
)
AS
DECLARE @mytablevar TABLE (Var1 int) /*usw*/
bringt ==> ADO-Fehler: Falsche Syntax in der Nähe des TABLE-Schlüsselwortes. Irgendetwas mache ich hier noch falsch (?). Noch eine Frage:
Mein Problem bei CreateParameter("TableName", ad (Table??) , adParamOutput ... ?? konnte ich auch noch nicht lösen, weil MS-ACCESS den adTable -Typ nicht kennt (adChar, adInt etc. schon), aber wie gebe ich beim Aufruf der GP den output-Parameter TABLE an ?
Ich verwende momentan z.B.:
Com.Parameters.Append Com.CreateParameter("BdsLand", adChar, adParamOutput, 2)
Com.Parameters.Append Com.CreateParameter("GeleseneZeile", adVarChar, adParamOutput, 90)
Com.CommandText = "P_Test"
Com.CommandType = adCmdStoredProc
Com.ActiveConnection = CurrentProject.Connection
Com.Execute
Aber der Versuch
Com.Parameters.Append TD.Com.CreateParameter("ÜbungsTabelle", ad ....) funktioniert nicht, da adTable nicht bekannt ist. Ich denke jedoch, daß ich diesen Ouotput-Parameter brauche, um die Table-Variable aus der SP außerhalb dieser verwenden zu können.
Ich würde mich freuen, wenn noch einmal Hilfe möglich wäre.
Danke und herzliche Grüße
PCFJKG
zunächst Dank für die Hilfe. Die Lösung mit der Table-Variablen scheint mir auch die "vernünftigste", scheitert momentan aber an der Deklaration. Mein Versuch in der SP lautet:
CREATE PROCEDURE "Test"
(
@eininpara NVARCHAR(50),
@nochninpara int,
@meinoutput TABLE OUTPUT
)
AS
DECLARE @mytablevar TABLE (Var1 int) /*usw*/
bringt ==> ADO-Fehler: Falsche Syntax in der Nähe des TABLE-Schlüsselwortes. Irgendetwas mache ich hier noch falsch (?). Noch eine Frage:
Mein Problem bei CreateParameter("TableName", ad (Table??) , adParamOutput ... ?? konnte ich auch noch nicht lösen, weil MS-ACCESS den adTable -Typ nicht kennt (adChar, adInt etc. schon), aber wie gebe ich beim Aufruf der GP den output-Parameter TABLE an ?
Ich verwende momentan z.B.:
Com.Parameters.Append Com.CreateParameter("BdsLand", adChar, adParamOutput, 2)
Com.Parameters.Append Com.CreateParameter("GeleseneZeile", adVarChar, adParamOutput, 90)
Com.CommandText = "P_Test"
Com.CommandType = adCmdStoredProc
Com.ActiveConnection = CurrentProject.Connection
Com.Execute
Aber der Versuch
Com.Parameters.Append TD.Com.CreateParameter("ÜbungsTabelle", ad ....) funktioniert nicht, da adTable nicht bekannt ist. Ich denke jedoch, daß ich diesen Ouotput-Parameter brauche, um die Table-Variable aus der SP außerhalb dieser verwenden zu können.
Ich würde mich freuen, wenn noch einmal Hilfe möglich wäre.
Danke und herzliche Grüße
PCFJKG
Moin PCFJKG,
hmm, das ist für mich jetzt nicht erkennbar, welches der beiden TABLE-Schlüsselworte angemosert wird.
Am wahrscheinlichsten erscheint es mit, wenn bei der Deklaration der OUTPUT-Variablen auch noch die Feldbeschreibung erwartet werden würde.
Aber abgesehen davon - vielleicht denke ich hier auch zu sehr um die Ecke.
Eventuell wäre es ja doch einfacher, doch noch mal den Gedanken mit EINER ##Table aufzuwärmen.
Angenommen, es gäbe in der Tat nur eine ##Table namens ##FuerAlle mit den ermittelten Listbox-Werten, die sich je User aber unterscheiden.
Könnten die nicht auseinandergehalten werden durch eine zusätzliche Spalte "Userid" in dieser tabelle und einer entsprechenden WHERE-Clause beim Auslesen.
Würde eine Menge Gewürge ersparen...
Grüße
Biber
hmm, das ist für mich jetzt nicht erkennbar, welches der beiden TABLE-Schlüsselworte angemosert wird.
Am wahrscheinlichsten erscheint es mit, wenn bei der Deklaration der OUTPUT-Variablen auch noch die Feldbeschreibung erwartet werden würde.
Aber abgesehen davon - vielleicht denke ich hier auch zu sehr um die Ecke.
Eventuell wäre es ja doch einfacher, doch noch mal den Gedanken mit EINER ##Table aufzuwärmen.
Angenommen, es gäbe in der Tat nur eine ##Table namens ##FuerAlle mit den ermittelten Listbox-Werten, die sich je User aber unterscheiden.
Könnten die nicht auseinandergehalten werden durch eine zusätzliche Spalte "Userid" in dieser tabelle und einer entsprechenden WHERE-Clause beim Auslesen.
Würde eine Menge Gewürge ersparen...
Grüße
Biber
Hallo Biber,
Dank für die Anwort. Die Lösung mit der ##Tabelle funktioniert (ich habe als zunächst einfachste Lösung unsere Usernamen an den Tabellennamen "angehängt".)
Da ich noch nicht mit einer Tabellenvariablen gearbeitet habe, würde mich die Lösung – auch für andere Situationen – prinzipiell interessieren, nichts desto trotz geht es erst einmal weiter.
Momentan versuche ich noch (man gibt ja ncht so schnell auf) mit einer #Table eine Lösung zu finden, z.B.
Alter PROCEDURE "P_Test"
(
@meinoutput nvarchar(255) OUTPUT
)
AS
IF OBJECT_ID('tempdb..#T_Test') IS NOT NULL DROP TABLE #T_Test
SELECT * INTO #T_Test FROM T_irgendeine
DECLARE Test_cursor CURSOR FOR SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = OBJECT_NAME(OBJECT_ID('tempdb..#T_Test'))
Dann vielleicht mit FETCH den Name lesen und mit @meinoutput zurückgeben... ?
Funktioniert noch nicht, Rückgabe ist derzeit NULL, mal sehen ob ich es hinbekomme.
Nocheinmal danke für die schnelle Antwort und herzliche Grüße nach Bremen,
PCFJKG
Dank für die Anwort. Die Lösung mit der ##Tabelle funktioniert (ich habe als zunächst einfachste Lösung unsere Usernamen an den Tabellennamen "angehängt".)
Da ich noch nicht mit einer Tabellenvariablen gearbeitet habe, würde mich die Lösung – auch für andere Situationen – prinzipiell interessieren, nichts desto trotz geht es erst einmal weiter.
Momentan versuche ich noch (man gibt ja ncht so schnell auf) mit einer #Table eine Lösung zu finden, z.B.
Alter PROCEDURE "P_Test"
(
@meinoutput nvarchar(255) OUTPUT
)
AS
IF OBJECT_ID('tempdb..#T_Test') IS NOT NULL DROP TABLE #T_Test
SELECT * INTO #T_Test FROM T_irgendeine
DECLARE Test_cursor CURSOR FOR SELECT TABLE_NAME FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = OBJECT_NAME(OBJECT_ID('tempdb..#T_Test'))
Dann vielleicht mit FETCH den Name lesen und mit @meinoutput zurückgeben... ?
Funktioniert noch nicht, Rückgabe ist derzeit NULL, mal sehen ob ich es hinbekomme.
Nocheinmal danke für die schnelle Antwort und herzliche Grüße nach Bremen,
PCFJKG
