ODBC und SQL-Prozeduren

[Fuerchau]

Das ist dann auch keine Fehlermeldung vom ODBC-Treiber sondern von VisualStudio SSDT.
Und wie der Name schon sagt, SQL-Server-Data-Tools, und somit von der SQL-Syntax an SQL-Server gebunden, auch hier sollte es (vielleicht) eine Passthrough-Methode geben, bzw. eine SQL-Ansicht möglich sein, die keine Syntaxprüfung durchführt.

Ich meine (zumindest früher) gabs sowas auch für IBM's DB2/400.

Alternativ kannst du die SQL's aber auch native durchführen, du hast nur leider keine Design-Unterstützung.

[Curious]

Ich habe jetzt mal eine Verbindung zwischen dem SQL-Server und der AS/400-DB2 hergestellt (Linked Server) und kann nun auch über den Weg SQL ausführen. Das klappt auch prima für SELECT, aber die Ausführung einer SQL-Prozedur ist leider immer noch nicht möglich.

Ich habe eine Prozedur ohne Parameter eingerichtet und kann diese problemlos mittels STRSQL aufrufen. Wenn ich sie per SQL verwenden will, erhalte ich die folgende Fehlermeldung:

Aufruf mit:

exec( 'call lib.sp_test2') at as400


OLE DB provider "DB2OLEDB" for linked server "as400" returned message "Routine TEST2 in LIB mit angegebenen Parametern nicht gefunden. SQLSTATE: 42884, SQLCODE: -440".
Msg 7215, Level 17, State 1, Line 1
Could not execute statement on remote server 'as400'.

---

Wenn ich meine Testprozedur mit einem Parameter benutze mit

exec ( 'call lib.test( ?)', '001') at as400 /* Parameter ist CHAR(3) */

oder

exec ( 'call lib.test( ?)', 1) at as400 /* Parameter ist INT */

dann kommt dieselbe Fehlermeldung. Also mache ich etwas grundsätzliches falsch. Nur sehe ich es nicht...

Habt Ihr einen Tipp für mich? Muss die SQL-Prozedur irgendwelchen Kriterien entsprechen? Ich habe die SQL-Prozedur direkt auf der AS/400-Maschine eingerichtet ( qsh -> cat SQL.txt | db2 -i ). Muss die Prozedur mittels Systembefehl irgendwie "registriert" werden oder ähnliches?

Und später möchte ich auch ein Result-Set zurückliefern, geht das in der Form überhaupt?

[Fuerchau]

Das Problem bei Prozeduren ist, die genaue Übergabe der Parameter passend zum Typ.
Was immer der SQL-Server da macht, i.d.R. ist '001' nicht char(3) sondern varchar(3).
Für SQL-Prozeduren sollte man nach Möglichkeit generischere Typen definieren um etwas allgemeiner zu arbeiten. Innerhalb der Prozedur kann man dann ggf. Prüfungen und/oder casts vornehmen.

exec ( 'call lib.test( cast( ? as char(3)) )', '001') at as400
exec ( 'call lib.test( cast( ? as int) )', 1) at as400

Das Problem ist ggf., dass der SQL-Server die Parameter nicht vom Host abfragt sondern an Hand der übergebenen Werte definiert, was aber nur eine Vermutung ist.
Problematischer sind dann noch Type wie decimal/numeric(n, m), die vom SQL-Server da wohl auch so nicht funktionieren.

Ob die Prozedur korrekt registriert ist, kann dir ein Aufruf per STRSQL bzw. über den OpsNav mit SQL-Befehle ausführen sagen.

Wenn dein SQL.txt entsprechenden "CREATE PROCEDURE ...." enthält sollte es funktionieren.
Bedenke nur im Wiederholungsfall sollte vorher ebenso ein "DROP" enthalten sein oder, falls dein Release das schon zulässt ein "CREATE OR REPLACE ...".

Möchtestet du ein Resultset von einer Prozedur, dann ist wiederum "select * from OpenQuery('Server', 'Call ...') dein Favorit.