MS-SQL Procedure & Resultset???

[Kedariodakon]

Also sind diese Temp-Tabellen nicht einem bestimmten Benutzer zugeordnet und ich muß mich wieder um alles kümmern?

Warum dann #Temp tabellen nehmen stadt normale?


Bye

[Robert_G]

Weil sie nur im Cache gehalten werden und dadurch massiv schneller erstellt, zugegriffen und zerstört werden könne. "Richtige" Tabellen dafür zu nehmen wäre doch totaler Schwachfug. ;)

btw: temp. Tabelle sind ein großer Vorteil vom SQL Svr gegenüber Oracle (die dortigen Temporär - Spaces sind nicht direkt im Speicher. Sie ähneln eher Tabeleln, die nicht dauerhaft gespeichert werden können.)

[Leuselator]

Wenn verschiedene Benutzer die SP aufrufen, hast Du mit lokalen (ein # vor dem Namen - global 2 ## vor dem Namen) keine Last. Schwierig wird es, wenn die einzelnen Benutzer unterprivilegiert im DB-Zugriff sein sollen und nur die SP's in einem privilegierten User-Kontext laufen sollen (was Sinn macht), da dann alle User auf DB-Seite als ein Benutzer ankommen - daher mein Vorschlag. Für eine schnelle Abfrage aus dem Userkontext heraus ist "#TabellenName" ok.
Gruß

[Kedariodakon]

Ok nun konnte ich dank eurer hilfe meine Procedure Verbessern, bzw. bugfixen! :thumb:

Aber die Frage mit dem Recordset bleibt weiterhin!

Ich habe mal ein bischen getestet gestern Abend und bin zu folgendem Result gekommen :angel2:

Code:

CREATE PROCEDURE Test1 AS
BEGIN
  CREATE TABLE #TEMP ( Output varchar( 10 ) )
  SELECT * FROM #TEMP
END

Diese Procedure gibt mir die leere Tabelle #Temp zurück UND auch als Recordset!!!

Diese Procedure:

Code:

CREATE PROCEDURE Test2 AS
BEGIN
  CREATE TABLE #TEMP ( Output varchar( 10 ) )
  INSERT INTO #TEMP ( Output ) VALUES ( '123 Test' )
  SELECT * FROM #TEMP
END

ist ein klein wenig anders!
1. Sie heißt ein kleinwenig anders :zwinker:
2. Ich tu was in die Tabelle, denn eine leere Tabelle bringt mir ja nichts! :wink:

Aber schon gibt ein Fehler bei ADO und zwar, dass das Recordset net geöffnet wär...
Und ich glaub nicht so wirklich das das an dem Namen liegt, das hab ich durch Tests ausschließen können... :coder:

Aber das kuriose bei der Sache ist, ich kann auch in eine Tabelle was reintun, die ich gar nicht als Result haben will, schon bekomm ich kein Recordset und kann mir die Daten nur per Query hollen...

Was mach ich den falsch? benutz ich insert falsch?

BYE

[Kedariodakon]

HILFE :wall:

[Leuselator]

zeig mal Delphi-Code...

[Kedariodakon]

Was willst du da mit delphi code?

Aber bitte...

Delphi-Quellcode:

aTADODataSet.Recordset := aTADOCommand.Execute;

So alle Unklarheiten beseitigt? :zwinker:

Oder willst du auch noch wissen, wie der CommandText aussieht?
Aber wie gesagt, Test1 geht Test2 nicht...


Bye

[Kedariodakon]

Ich suche immernoch eine Antwort -/ Lösung :|


Bye

[shmia]

Hier meine Testprocedure:

SQL-Code:

CREATE PROCEDURE Test2 ( @ParameterQ varchar(20)) AS 
BEGIN 
  CREATE TABLE #TEMP99( Output varchar( 100 ) ) 
  INSERT INTO #TEMP99( Output ) VALUES ( '123 Test' ) 
  INSERT INTO #TEMP99( Output ) VALUES ( 'Hey, ist doch alles Oaki Doaki !!!' ) 
  INSERT INTO #TEMP99( Output ) VALUES ( @ParameterQ) 
  SELECT * FROM #TEMP99 
END

Hier die Delphi-Seite (ich verwende TADOStoredProc):

Delphi-Quellcode:

   ADOStoredProc1.Active := False;
   ADOStoredProc1.ProcedureName := 'Test2';
   ADOStoredProc1.Parameters.Refresh;
   ADOStoredProc1.Parameters.ParamValues['ParameterQ'] := 'Delphi-Praxis';
   ADOStoredProc1.Active := True;

Datasource mit ADOStoredProc1 verbinden; diese mit einem DBGrid; fertig. :bounce2:

[Kedariodakon]

Zitat:

Zitat von shmia

Hier meine Testprocedure:

SQL-Code:

CREATE PROCEDURE Test2 ( @ParameterQ varchar(20)) AS 
BEGIN 
  CREATE TABLE #TEMP99( Output varchar( 100 ) ) 
  INSERT INTO #TEMP99( Output ) VALUES ( '123 Test' ) 
  INSERT INTO #TEMP99( Output ) VALUES ( 'Hey, ist doch alles Oaki Doaki !!!' ) 
  INSERT INTO #TEMP99( Output ) VALUES ( @ParameterQ) 
  SELECT * FROM #TEMP99 
END

Hier die Delphi-Seite (ich verwende TADOStoredProc):

Delphi-Quellcode:

   ADOStoredProc1.Active := False;
   ADOStoredProc1.ProcedureName := 'Test2';
   ADOStoredProc1.Parameters.Refresh;
   ADOStoredProc1.Parameters.ParamValues['ParameterQ'] := 'Delphi-Praxis';
   ADOStoredProc1.Active := True;

Datasource mit ADOStoredProc1 verbinden; diese mit einem DBGrid; fertig. :bounce2:

Hmm bei gelegenheit test ichs mal...
Wollte aber nicht wirklich andere Komponenten mit einbaun...


Aber warum Bekomm ich das bei mir nicht als Recordset zurück?
Hab bisle experimentiert und habe am anfang der Procedure NOCOUNT An gemacht und nun kommt es als Recordset zurück...

Aber was bewirkt dieses NOCOUNT?


Bye