Rückgabewert über SQL_Query

[monta]

So, mal ne hoffentlich leichte Frage.

Wie bringe ich den einer TSQL_Query bei, einen Rückgabewert einer StoredProc auch wieder auszuspucken?

Über Params gehts nicht, über Fields gehts auch nicht und Open, was teilweise bei Delphi auch ging, wird abgelehnt, da es ein Non-Select-Statement darstellt.

[jb]

Bei Firebird geht sowas:

select * from

du kannst es auch mit Tabellen verbinden
select key, t.tblwerte from Proc
join table t on t.key = key

Meintest du sowas ?



Die Query selbst wird dann ganz normal mit Open geöffnet

[af0815]

@monta
DB-System ?

Über Params gehts nicht, über Fields gehts auch nicht und Open, was teilweise bei Delphi auch ging, wird abgelehnt, da es ein Non-Select-Statement darstellt.

Was erwartest Du zurück?
Nach einem select (in einer SP) bekommst du ein nicht aktualisierbares recordsetobject, zusätzlich hat man schon die Möglichkeit in Params das result zu checken.

Eine query wird sich dir richtigerweise verweigern, das ganze ist eine Stored Procedure und muss auch so abgehandelt werden (mit execute). Verlass dich nicht darauf , das das Programm errät was du willst, sondern definiere gleich, das ganze als Stored Procedure und handle es auch so ab.

[jb]

Es macht hier und da schon Sinn, das eine SP Daten zurückliefert. Aber die kann man dann mit nem normalen select bekommen, und die Query ganz normal öffnen.

Das dürfte mWn bei allen DB-Systemen gehen, die auch SP's unterstützen

[monta]

sorry, ich war etwas kanpp heut Nacht.

Wie selects funktionieren ist mir schon klar, und in StoredProcs sind Selects, wenns nur um die daten geht meist überflüssig.

Aber das geht auch am Thema vorbei, sondern ich definier über returns in Firebird (2.0) den Rückgabewert als Ausgabeparameter:

Code: Alles auswählen

/*in der Declaration der SP:*/
returns (
    ZMAIN_ID integer)
 
/*und zur Rückgabe dann einfache Wertzuweisung*/
  ZMAIN_ID = :YMAIN_ID;

Was dazwischen passiert spielt ja keine große Rolle, der Rückgabewert ist auf jeden Fall aktiviert und wird auch ausgegeben, wenn ich die SP in IbExpert ausführe.
Nur diesem bracuh ich eben nach Programmaufruf wieder zurück, weil ich den Wert als Primärschlüssel für weitere Relationen benötige, weis aber nicht, wie ich ihn aus der TSQLQuery prinzipiell auslesen kann.

[af0815]

Was setzt du für Komponenten ein für den Zugriff auf Firebird ? Zeos ?

Unter D7/ADO bekommt man den 'return' als param[0] zurück. Ich gehe aber davon aus, das das ganze auch stark von der verwendeten Zugriffskomponente abhängig ist (Vor allen die Frage, wo).

Werd mal meinen Firbird hochfahren und mir ein Beispiel zimmern.

[af0815]

RETURN
The RETURN statement in MS SQL will return an output integer variable and stop execution. Firebird supports the EXIT statement, which will jump to the final END in stored procedures. However, there is no implicit output variable, so if you need to return a code (it's optional in MS SQL), you will need to declare an output variable in the procedure.

Ok, es ist komplett unterschiedlich zwischen Firebird und MS-SQL. Werde mal ein bischen herumprobieren, da ich mich sowieso wieder in den Firebird einarbeiten muss.

Wie selects funktionieren ist mir schon klar, und in StoredProcs sind Selects, wenns nur um die daten geht meist überflüssig.

Nicht bei 3-tier, bzw. wenn du mit einem 'big server - thin client' Konzept unterwegs bist. Spricht zwar etwas gegen RAD. Nach aussen arbeite ich immr mit Views und SP. Stell dir vor ein DAU macht ein

select * from langetabelle

auf eine Buchungstabelle mit 10 Millionen Datensätze OHNE gute where Klausel.

[monta]

Was setzt du für Komponenten ein für den Zugriff auf Firebird ? Zeos ?

Nein, die mitgelieferten aus dem Package SQLdb

Nicht bei 3-tier, bzw. wenn du mit einem 'big server - thin client' Konzept unterwegs bist. Spricht zwar etwas gegen RAD. Nach aussen arbeite ich immr mit Views und SP. Stell dir vor ein DAU macht ein

Das stimmt allerdings. Ich versuch auch möglichst viel, zumindest was Manipulationen angeht, eigentlich alles, auf den Server zu legen und mit Views zu arbeiten. Schon, weil eventuell auch mal ein anderer Client fällig werden könnte (Browserbasiert), und das dann wesentlich einfacher sein dürfte.