Re: SqlDataAdapter1.SelectCommand.CommandType= CommandType.StoredProcedure

From: Klaus Eckert (a_at_eckert-k.de)
Date: 02/13/05 

Date: Sun, 13 Feb 2005 19:37:27 +0100

Hallo Elmar,

"Elmar Boye" <ElmarB@gmx.net> schrieb im Newsbeitrag
news:3777slF58d5agU1@individual.net...
> Hallo Klaus,
>
> Klaus Eckert <a@eckert-k.de> schrieb ...
>
> zunächst gilt für die SqlDataAdapter.XXXCommand Eigenschaften,
> dass dahinter immer ein SqlCommand steckt. Und alles folgende
> gilt für ein SqlCommand äquivalent.
>
>> bei der Einstellung SQLDataAdapter.CommandType.StoredProcedure
>> kann man beim EXEC PROC keine Parameter beifügen.
>
> das EXEC ist überflüssig und schädlich...
>
>> Statt dessen muss CommandType.Text eingestellt werden.
>
> ... wenn Du nur den qualifizierten Prozedurnamen (Besitzer.ProzedurName)
> im CommandText abstellst, so wäre das der richtige Weg,
> mit und ohne Parameter.
>
>> Meine Frage:
>> Hat CommandType.StoredProcedure Vorteile gegenüber CommandType.Text,
>
> CommandType.StoredProcedure wird intern als RPC Command abgesetzt,
> da das TDS Protokoll das intern unterscheiden kann. Näheres zu
> SQL RPC siehe SQL Server Dokumentation, u. a. beschrieben in
> "Architektur remote gespeicherter Prozeduren", wobei die
> Remote-Ausführungsmöglichkeiten zunächst keine Rolle spielen.
>
>> und wenn ja welche,
>
> Was allerdings in Bezug auf Durchsatz/Leistung für die Anwendung
> selten einen grossen Unterschied macht.
>
>> oder ist es vernünftig, generell CommandType.Text
>> einzustellen, auch wenn keine Parameter beigefügt werden?
>
> Nein - siehe oben.
> Bei CommandType.Text wird in den Fällen, wo keine Parameter vorkommen
> (Parameters.Count == 0), der SQL Befehl direkt übergeben.
>
> Sobald Parameter vorkommen, wird die interne Prozedur sp_executesql
> für die Ausführung und Parameterübergabe verwendet - bezüglich der
> Vorteile siehe die SQL Server Online-Dokumentation zu sp_executesql.
> Und prinzipiell ist es auch möglich Dein EXEC PROC damit zu verpacken
> - mit ein bissel Nachdenken kommst Du bestimmt selbst darauf,
> was aber ausser Umständen keinen Nutzen gibt.
>
> Wichtiger ist bei sp_executesql ist, dass die Anweisungen intern wie
> ein eigener Batch behandelt werden. Und so u. a. Variablen und lokale
> temporäre Tabellen, die in dem Batch erstellt werden, unmittelbar
> nach der Ausführung ungültig werden.
> Was in dem einen oder anderen Falle unerwünscht sein kann, dann
> (und am besten nur dann) muss man die Parameter direkt im CommandText
> expandieren.
>
> Gruss
> Elmar
Vielen Dank für Deine Antwort,

die ich leider nicht ganz verstanden habe.

M.E.widersprechen sich Deine Antworten 1 u.2.

1)

> ... wenn Du nur den qualifizierten Prozedurnamen (Besitzer.ProzedurName)

> im CommandText abstellst, so wäre das der richtige Weg,

> mit und ohne Parameter.

2)

> > oder ist es vernünftig, generell CommandType.Text

> > einzustellen, auch wenn keine Parameter beigefügt werden?

>

> Nein - siehe oben.

Um es noch mal klar zu sagen, ich spreche nur
von Procedur-Aufrufen mit den Fällen
mit oder ohne beigegefügte Parameter.

Bei Einstellung "CommandType.StoredProcedure" erhalte ich nach
Aufruf einer Proc mit Parameter die Fehlermeldung
"Die gespeicherte Procedur sp_ABC @Pro='ProjectA' konnte nicht

gefunden werden.".

Dagegen erfolgt der genannte Aufruf mit "CommandType.Text"

problemlos.

Vielleicht kannst Du das bitte noch einmal
kurz aufklären.

Gruß

Klaus

>

Relevant Pages

  • Re: SqlDataAdapter1.SelectCommand.CommandType= CommandType.StoredProcedure
    ... > kann man beim EXEC PROC keine Parameter beifügen. ... CommandType.StoredProcedure wird intern als RPC Command abgesetzt, ... SQL RPC siehe SQL Server Dokumentation, ... nach der Ausführung ungültig werden. ...
    (microsoft.public.de.german.entwickler.dotnet.datenbank)
  • Re: using nexted procs
    ... So I have a cataloged proc 'FJS.PDSE.PROC' that looks like this: ... //IEFRDER DD DUMMY //SYSUOUT DD SYSOUT=* ... //FFND05 EXEC DLIBATCH,DLIPGM=FFND05,DLIPSB=FFUNDGO ... Our goal was that when testing we would execute the production proc and override the DD names to the names of test files. ...
    (bit.listserv.ibm-main)
  • typo error...
    ... First Proc should be p1 and not p3 ... > exec p1 ... >> Over night we take a copy of various live SQL databases onto another SQL ... >> I connect to the live databases using linked servers. ...
    (microsoft.public.sqlserver.programming)
  • Re: Strangeness in PROC-land
    ... //STEP1 EXEC PGM=IEFBR14 ... It complains about the second PEND because you can not nest PROCs inside ... instream data inside a PROC. ... But the JCL error is on the second PEND ...
    (bit.listserv.ibm-main)
  • Re: SQL Variable USE.
    ... I then exec the proc like so: ... SQL server will decide where to put it on ... > it from the database level settings. ...
    (microsoft.public.sqlserver.programming)