Return code MS SQL

Er det ikke bare at have et ? til retur værdi og så hente den
efter data ?

Jeg lavede engang dette eksempel:

import java.sql.CallableStatement;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.Types;

public class UseSP {
    public static void main(String[] args) throws Exception {
        Class.forName("com.sybase.jdbc2.jdbc.SybDriver");
        Connection con = DriverManager.getConnection("jdbc:sybase:Tds:arnepc2:5000", "sa", "");
        con.setCatalog("Test");
        CallableStatement cstmt = con.prepareCall("{? = CALL TEST_MULTIOUT(?,?)}");
        cstmt.registerOutParameter(1, Types.INTEGER);
        cstmt.setInt(2, 5);
        cstmt.registerOutParameter(3, Types.INTEGER);
        cstmt.execute();
        while(cstmt.getMoreResults()) {
            ResultSet rs = cstmt.getResultSet();
            while(rs.next()) {
                System.out.println(rs.getInt(1) + " " + rs.getString(2));
            }
        }
        System.out.println("return value = " + cstmt.getInt(1));
        System.out.println("out parameter = " + cstmt.getInt(3));
        cstmt.close();
        con.close();
    }
}

Jeg er kommet lidt videre siden spørgsmålet!

Jeg har decompiled en del af RDBMS Adaptoren til BEA WLI 8.1.

Det viste sige, at linjen:

boolean hasResultSet = callableStatement.execute(); (i klassen AbstractStatement)

altid returnerer false, når der er en SP tilstede, der skaber midlertidige tabeller (!?)
callableStatement objekt reference er af typen java.sql.CallableStatement og kunne ikke blive decompiled, da den er (delvist) obfuscated(!)...Man er jo lidt nysgerring efter at se, hvorfor det går så galt!


Betragt følgende Stored Procedure:

CREATE PROCEDURE CustOrdersDetail @OrderID int
AS
SELECT ProductName,
    UnitPrice=ROUND(Od.UnitPrice, 2),
    Quantity,
    Discount=CONVERT(int, Discount * 100),
    ExtendedPrice=ROUND(CONVERT(money, Quantity * (1 - Discount) * Od.UnitPrice), 2)
FROM Products P, [Order Details] Od
WHERE Od.ProductID = P.ProductID and Od.OrderID = @OrderID
GO

Her er det ingen problemer med at fange alle de rækker, som bliver sendt tilbage.
Den integer, som MS SQL sender tilbage (return code) fanges ligeledes, og alt pakkes nydeligt ind i XML.

Se så her:

CREATE PROCEDURE CustOrdersOrders @CustomerID nchar(5)
AS
CREATE table #Customerz (cID varchar(28), customerName varchar(28), owner varchar(28), editor varchar(28), status varchar(100), editStatus int)
INSERT INTO #Customerz (cID, customerName, owner, editor, status, editStatus) values (@CustomerID,'erere', 'rttyi', 'eewssss', 'wewe', 3)
SELECT * FROM #Customerz
DROP Table #Customerz
GO

Her kommer det 'underlige': Kun return code fanges og pakkes ind i response XML.

Og HER vil jeg vædde på, at hasResultSet evaluerer false i Adaptor koden...Sandheden er derude!

Kan det virkelig passe, at BEA ikke har taget højde for dette (mon spørgsmålet stadig hører hjemme her!)

Altså kan adaptoren ikke finde ud af, at pakke resultsettet ind i XML, når der nu er tale om en SP, hvor der skabes temp tables.

Ved en SP med temp table får jeg følgende response:
<?xml version="1.0"?>
<ns0:Output xmlns:ns0="wlai/LocalTestDataDirect_Orders_response">
  <ns0:ReturnValue>0</ns0:ReturnValue>
  <ns0:Params/>
</ns0:Output>

Der 'mangler' altså alt det, som resultsettet indeholder. Der er ingen problemer i Query Analyzer.

Der er noget galt her.

Adapteren ved ikke noget som helst om at der er temporære tabeller.

Man sender en "udfør SP" kommando til SQLServer, den udfører SP og
returnerer resultset - kalderen har ingen mulighed for at vide
hvad den SP gør !

Kan det være et rettigheds problem ?

(du kører Query Analyzer med flere rettigheder end adapteren gør)

Adaptoren gør det, at den blot henter (burde den?) alt det der er i en given SP og sætter det ind i et XML dokument, som en sekvens af complex types.

Ifølge mit request skema(og det er skabt før nogen SP er kaldt) fås:

  <?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="wlai/LocalTestDataDirect_CustOrdersOrders_response" elementFormDefault="qualified" targetNamespace="wlai/LocalTestDataDirect_CustOrdersOrders_response">


  <xsd:element name="Output">
    <xsd:complexType>
      <xsd:sequence>
        <xsd:element name="ReturnValue" type="xsd:int" minOccurs="0"/>
        <xsd:element name="Params" minOccurs="0">
          <xsd:complexType>
            <xsd:sequence>
            </xsd:sequence>
          </xsd:complexType>
        </xsd:element>
        <xsd:element name="ResultSet" maxOccurs="unbounded" minOccurs="0">
          <xsd:complexType>
            <xsd:sequence>
              <xsd:element name="Row" maxOccurs="unbounded" type="xsd:string" minOccurs="0"/>
            </xsd:sequence>
          </xsd:complexType>
        </xsd:element>
      </xsd:sequence>
    </xsd:complexType>
  </xsd:element>

</xsd:schema>

Den er altså godt klar over, at der kommer at resultset, men de enkelte kolonner kender den måske ikke?

Der er ingen rettighedsproblemer.. Det er jeg sikker på.

Men ja, Adaptoren kender vel ikke de temp tebles...Hmmm...

Har du prøvet at lave et lille standalone JDBC program og kalde fra ?

Det kunne give et hint om hvorvidt det er et BEA eller et MS SQL
problem.

Ja, se her:

public static void getInfoFromLocalHost(java.sql.Connection con, String ID) {
        ResultSet res = null;
        CallableStatement cstmt = null;
        try {
            cstmt = con.prepareCall("{?=call Test.dbo.CustOrdersOrders(?)}");
            cstmt.registerOutParameter(1, Types.INTEGER);
            cstmt.setString(2, ID);
            boolean isIt = cstmt.execute();
            System.out.println("ResultSet?" + isIt);
            ResultSet rs = cstmt.getResultSet();
            while (rs.next()) {
                System.out.println("Data: " + rs.getString(1));
            }

        } catch (SQLException ex) {
            ex.printStackTrace();
        }

    }

Her er samme fejl. Adaptoren genererer den sammen ("{?=call Northwind.dbo.CustOrdersOrders(?)}");

Det virker som om den fortolker det som en function

Men det er pga. SQL Serveren altid sender en return code tilbage.

Har du prøvet at hente den return værdi inden du kører på result set ?

Hvis du undlader at droppe den temporære tabel - er der så data i den ?

Så bliver Resultsettet = null.. Hvis man henter den int.

Nå, der er åbenbart en bug i BEAs RDBMS Adaptor.

Har sendt en fejlbeskrivelse til dem!

Tak for din tid arne - du får 15 for den, hvis du vil ;-)

selvfølgelig

Hov.. Der fik du 30.. Helt fint. Du har fortjent dem taget din ekspertise i betragtning ;-)

????