2 Phänomene bei eigenen SQL-Abfragen über Nachrichtensystem

[loddar]

Hallo,

wir sind gerade dabei, uns hier das eine oder andere SQL-Skript zu bauen, um AvERP etwas gesprächiger zu gestalten.
Dabei tauchen 2 merkwürdige Dinge auf - sowohl bei der 2010er-Version als auch bei der ganz frischen 2012:

1. Fehlermeldung bei SELECT
SELECTet man 2 Spalten ist alles ok.
SELECTet man lediglich nur 1 Spalte, kommt eine Fehlermeldung zurück.

Beispiel:
SELECT A.BBES_ID_LINKKEY,A.ID FROM BBESZ A
passt, jedoch bricht
SELECT A.ID FROM BBESZ A
mit folgender Fehlermeldung im SQL-Monitor ab:

/*---
EXECUTE2 DSQL
TR_HANDLE = 4
STMT_HANDLE = 143
PARAMS = [ ]
FIELDS = [ ]

SECONDS = 0,109

ERRCODE = 335544928
----*/
/*---
INTERPRET BUFFER =

ERRCODE = 26
----*/
/*---
INTERPRET BUFFER = Output parameters mismatch

ERRCODE = 49
----*/
/*---
INTERPRET BUFFER = At procedure 'P_BMSG_EMPFANGEN' line: 104, col: 1

ERRCODE = -1
----*/

2. Bei längeren SQL-Skripten ist uns aufgefallen, daß es Probleme gibt. So wie es aussieht, versteht AvERP Skripte über ca. 424 Zeichen nicht, zumindest ist es das Ergebnis / Vermutung der letzten Nacht. Kürzt man das Skript ein, so wandert die beanstandete Zeile / Spalte entsprechend nach vorne. Der Code / die Syntax ist jedoch aus unserer Sicht einwandfrei.

Hier kommt dann folgendes Statement:
/*---
EXECUTE STATEMENT
TR_HANDLE = 4
STMT_HANDLE = 73
PARAMS = [ Version 1 SQLd 2 SQLn 2
[HAUPTFORM] = 'FRMV_BMSG'
[ID] = 2825 ]
----*/
/*---
PREPARE STATEMENT
TR_HANDLE = 4
STMT_HANDLE = 303

EXECUTE PROCEDURE P_BMSG_EMPFANGEN

FIELDS = [ Version 1 SQLd 0 SQLn 345 ]
----*/
/*---
EXECUTE2 DSQL
TR_HANDLE = 4
STMT_HANDLE = 303
PARAMS = [ ]
FIELDS = [ ]

SECONDS = 0,577

ERRCODE = 335544569
----*/
/*---
INTERPRET BUFFER =

ERRCODE = 17
----*/
/*---
INTERPRET BUFFER = Dynamic SQL Error

ERRCODE = 21
----*/
/*---
INTERPRET BUFFER = SQL error code = -206

ERRCODE = 14
----*/
/*---
INTERPRET BUFFER = Column unknown

ERRCODE = 4
----*/
/*---
INTERPRET BUFFER = BETN

ERRCODE = 20
----*/
/*---
INTERPRET BUFFER = At line 43, column 9

ERRCODE = -1
----*/
/*---
EXECUTE STATEMENT
TR_HANDLE = 4
STMT_HANDLE = 128
PARAMS = [ ]
----*/
/*---
EXECUTE STATEMENT
TR_HANDLE = 4
STMT_HANDLE = 211
PARAMS = [ Version 1 SQLd 1 SQLn 1
V_BMSG.ID[ID] = 2825 ]
----*/

Hat das einer schon mal erlebt ?

Danke im voraus,
viele Grüße,
loddar.

[mmblnfrn]

Hi Loddar,

zu 2 hab ich eine Lösung:

Du hast da ja eine langes Select Statements. Mach daraus eine View:

Code: Alles auswählen

CREATE VIEW V_LODDAR1 SELECT ...

Dann musst du da wo das 424 Zeichen Limit besteht dieses Statement eingeben:

Code: Alles auswählen

SELECT * FROM V_LODDAR1;

Das mit dem Problem 1 schaue ich mir nochmal an.

Beste Grüße

[loddar]

Hallo Matthias,

danke für Deinen Tipp !

Ich habe nun mit Flamerobin eine View erstellt. Wenn ich diese ohne AvERP direkt in der Datenbank starte, geht alles einwandfrei - unser Skript ist fehlerfrei, so wie es scheint.
Sobald ich das jedoch über AvERP (Nachrichtenkonfiguration) selecte, gibts immer wieder die gleiche Fehlermeldung, wenn ich auf "Empfangen" drücke.
Beispiel SELECT id,bestnr FROM V_PIK_MISS_AB_LIEF; (die View funktioniert !).



Für meinen ersten Punkt habe ich noch immer keine Lösung gefunden. Es ist auch auf der allerneuesten Installation (2013) nicht machbar.
Es kann doch nicht sein, daß das Forum mit Kommentaren à la "mit SQL und der offenen Datenbank kannst Du alles machen" voll ist und dann ein simpler einspaltiger SELECT nicht funktioniert.

Stellen wir uns einfach zu dämlich an oder nutzt das keiner ? Weiß einer von Synerpy vielleicht Bescheid ?

Danke & Gruß,
loddar.

[miboe]

Hallo Lothar,

natürlich funktioniert grundsätzlich alles in AvERP mit SQL, aber in Deinem konkreten ersten Fall wird es nicht mit dem einspaltigen SELECT gehen. Das liegt daran, dass die Prozedur, welche den eigentlichen Nachrichtenempfang macht, das SQL Statement ausführt und dessen Ergebnis als Basis für einen INSERT in die Tabelle BMSG verwendet. Und für diesen INSERT und die gesamte Logik vorne- und hintendran gelten bestimmte Regeln. Das verursacht dann den OUTPUT PARAMETER MISMATCH.

Die wichtigste davon erkennst Du, wenn Du Dir in einer Demodatenbank die dort vorhandenen Nachrichtenkonfigurationen anschaust: es werden immer ID und MASKENKEY aus der Quelltabelle selektiert. Im Nachrichtensystem wird dabei die ID für den Aufruf des betroffenen Datensatz verwendet und der MASKENKEY für die Anzeige im Betreff.

Noch ein kleiner Tip: verwende für sowas doch den IBexpert anstatt Flamerobin. Dort bekommst Du nämlich einigermassen aussagekräftige Fehlermeldungen und kannst direkt nachschauen, was Sache ist, wenn in einer Fehlermeldung ein Prozedurname fällt.

Zu der Sache mit der View wäre es hilfreich, wenn Du einfach mal den Quellcode der View postest. Ich vermute dass die beiden selektierten Parameter nicht mit den Variablen der P_BMSG_EMPFANGEN zusammen passen und deswegen eine Typumwandlung schief geht.

Gruß
Michael

[loddar]

Hallo Michael, Matthias,

ja klar, anbei die Views. 2 Dinge sollen gemeldet werden:
1. An Lieferanten übermittelte Bestellungen, wenn sich der von uns gesetzte Liefertermin nähert und noch keine Auftragsbestätigung eingegangen ist.
2. Offene und überfällige Positionen bei Teillieferungen von Lieferanten.

Wie gesagt, die Views funktionierten, nur die SELECTs nicht (s.o.).

Gruß,
loddar.

Code: Alles auswählen

CREATE VIEW V_PIK_MISS_AB_LIEF AS
SELECT 
  A.ID AS ID, A.MASKENKEY AS BESTNR, D.MASKENKEY AS POS, D.BESTMENGE AS BESTMENGE, 0 AS PLATZH, A.BETREFF AS BETREFF, A.BESTELLT AS BESTELLT, 
  A.BESTDATUM AS BESTDATUM, A.BESTKW AS BESTKW, A.ANSPRECHPARTNER AS ANSPRECHPARTNER, A.UZEICH AS UZEICH, A.GESPEICHERT AS GESPEICHERT, 
  B.LKUNR AS LKUNR, C.NAME AS CNAME, C.BEZ AS CBEZ, C.TELVOR AS CTELVOR, C.TELANSCH AS CANSCH
  --COUNT(*) 
FROM 
  BBES A,   -- Bestellung 
  BLIEF B,  -- Lieferant
  BADR C,    -- Lieferadresse
  BBESP D  
WHERE 
  A.BLIEF_ID_LIEFNR = B.ID
AND
  B.BADR_ID_ADRNR = C.ID
AND
  D.BBES_ID_LINKKEY = A.ID
AND
  A.BBESPD_GEL_KOMP = 'J' 
AND
  A.GEDRUCKT = 'J'
AND
  D.STORNO = 'N'
AND
  D.ID NOT IN (SELECT BBESP_ID FROM BLLCP)
AND
  (
    (A.ABDATUM IS NOT NULL AND A.ABDATUM > CAST ('now' AS DATE) - 3)
    OR
    (A.ABDATUM IS NULL)
    OR
    (A.ABLLTERMIN IS NOT NULL AND A.ABLLTERMIN > CAST ('now' AS DATE) - 3)
  )
AND
  A.ID > 228;

--GROUP BY
--  ID, BESTNR, POS, D.BESTMENGE, A.BETREFF, A.BESTELLT, A.BESTDATUM, A.BESTKW, A.ANSPRECHPARTNER, A.UZEICH, A.GESPEICHERT, 
--  B.LKUNR, 
--  C.NAME, C.BEZ, C.TELVOR, C.TELANSCH
  --COUNT(*) 


--ORDER BY 
--  1 DESC, 2, 3;

Code: Alles auswählen

CREATE VIEW V_PIK_MISS_PART_LIEF AS
SELECT 
  A.ID AS ID, A.MASKENKEY AS BESTNR, D.MASKENKEY AS POS, D.BESTMENGE AS BESTMENGE, SUM(E.WE_MENGE) AS TEILMENGE, A.BETREFF AS BETREFF, A.BESTELLT AS BESTELLT, A.BESTDATUM AS BDATUM, A.BESTKW AS BKW, A.ANSPRECHPARTNER AS ANSPRECHPARTNER,  A.UZEICH AS UZEICHNER, A.GESPEICHERT AS GESPEICHERT, 
  B.LKUNR AS LKUNR, 
  C.NAME AS CNAME, C.BEZ AS CBEZ, C.TELVOR AS CTELVOR, C.TELANSCH AS CANSCHL
  --COUNT(*) 
FROM 
  BBES A,   -- Bestellung 
  BLIEF B,  -- Lieferant
  BADR C,    -- Lieferadresse
  BBESP D,
  BLLCP E  
WHERE 
  A.BLIEF_ID_LIEFNR = B.ID
AND
  B.BADR_ID_ADRNR = C.ID
AND
  D.BBES_ID_LINKKEY = A.ID
AND
  E.BBESP_ID = D.ID
AND
  A.BBESPD_GEL_KOMP = 'J' 
AND
  A.GEDRUCKT = 'J'
AND
  D.STORNO = 'N'
AND
  (
   (D.BESTMENGE > (SELECT SUM(WE_MENGE) FROM BLLCP WHERE BBESP_ID = D.ID))
   OR
   ((SELECT count(*) FROM BLLCP WHERE BBESP_ID = D.ID AND NACHLIEFERUNG='N') > 0)
  )
AND
  (
    (A.ABDATUM IS NOT NULL AND A.ABDATUM > CAST ('now' AS DATE) - 3)
    OR
    (A.ABDATUM IS NULL)
    OR
    (A.ABLLTERMIN IS NOT NULL AND A.ABLLTERMIN > CAST ('now' AS DATE) - 3)
  )
AND
  A.ID > 228
GROUP BY
  A.ID, BESTNR, POS, D.BESTMENGE, A.BETREFF, A.BESTELLT, A.BESTDATUM, A.BESTKW, A.ANSPRECHPARTNER, A.UZEICH, A.GESPEICHERT, 
  B.LKUNR, 
  C.NAME, C.BEZ, C.TELVOR, C.TELANSCH
  --COUNT(*) 

[mmblnfrn]

Hallo Michael,

soweit habe ich deinen Einwand verstanden. Ich habe mal dieses Beispiel aus der Demo-DB als Beispiel herangezogen.

Die ersten beiden Spalten heissen ID und MASKENKEY. Der Rest der Zeile wird in diesem Fall mit einem JOIN hinzugefügt.

Code: Alles auswählen

SELECT A.ID, B.MASKENKEY || '-' || F_LRTRIM(A.RG_POSNR) AS "MASKENKEY"
FROM BRRCP A
LEFT OUTER JOIN BRRC B ON A.BRRC_ID_RGNR = B.ID
LEFT OUTER JOIN BAUFPO C ON A.BAUFPO_ID_AUFNRPOS = C.ID
WHERE A.BRLS_ID_LSNR IS NULL AND
      A.LS_BUCHUNGSART IS NULL AND
      C.RG_LS_ERZ <> 'R' AND
      B.ZAHLART = 'V' AND
      B.RGGEDRUCKT = 'J' AND
      B.ZAHLDATUM IS NOT NULL

Dann müsste Lothar seine zwei Views entsprechend anpassen.

Code: Alles auswählen

-- loeschen des Views
DROP VIEW V_PIK_MISS_AB_LIEF;
-- korrigieren des Views
CREATE VIEW V_PIK_MISS_AB_LIEF AS 
SELECT
  A.ID AS ID, A.MASKENKEY AS MASKENKEY, D.MASKENKEY AS POS
--        ^^                 ^^^^^^^^                               
....

[UliS]

Ich fürchte mit den Aliasen wird sich Nichts bessern.
Die qualifizierte Fehlermeldung sagt ... String truncation
in P_BMSG_EMPFANGEN, sprich da werden zuviele Zeichen in einen String geschrieben..
Blick in P_BMSG_EMPFANGEN -- wie Michael schreibt am einfachsten mit IB-Expert - wohl dem, der noch eine ältere Version hat, die nicht für AvERP-Datenbanken die Enterprise-Lizenz verlangt:

Blick in P_BMSG_EMPFANGEN zeigt, das dort Operation auf dem zu sendenen SQL-Statement in einer lokalen Variablen BMSQSQL_SQL mit deklarierter Länge VARCHAR(1000) abgelegt wird, das SELECT von der View ist sicher in 1000 Zeichen unterzubringen... Die Definition der View sicher größer...

[loddar]

Mensch danke - wenn ich Euch nicht hätte.

Die erste View funktioniert nach entsprechender Rechtevergabe, direkt per Flamerobin (ja, ich werde dann wohl auch IBE umsteigen die Tage...) und auch per Nachrichtensystem. Sehr komfortabel.

Leider kriege ich die 2. View nicht zum laufen.

Wenn ich den SQL-Code direkt mit Flamerobin abspule, gibts keine Fehlermeldung. Packe ich den Code in eine View und SELECTe wir ich gelernt habe nicht nur ID, sondern auch MASKENKEY, gibts leider noch ne arithmetische Fehlermeldung. Hat da jemand noch ne Idee ? Dann würde ich auch Ruhe geben

Nochmals - vielen Dank bis hierher,
loddar.

Code: Alles auswählen

SELECT 
  A.ID AS ID, A.MASKENKEY AS MASKENKEY, 
  D.MASKENKEY AS POS, D.BESTMENGE AS BESTMENGE, 
  D.BESTMENGE - D.BESTMENGE AS PLATZH,    -- = 0
  A.BETREFF AS BETREFF, A.BESTELLT AS BESTELLT, 
  A.BESTDATUM AS BESTDATUM, A.BESTKW AS BESTKW, 
  A.ANSPRECHPARTNER AS ANSPRECHPARTNER, 
  A.UZEICH AS UZEICH, A.GESPEICHERT AS GESPEICHERT, 
  B.LKUNR AS LKUNR, 
  C.NAME AS CNAME, C.BEZ AS CBEZ, C.TELVOR AS CTELVOR, 
  C.TELANSCH AS CANSCH
FROM 
  BBES A,   -- Bestellung 
  BLIEF B,  -- Lieferant
  BADR C,    -- Lieferadresse
  BBESP D  
WHERE 
  A.BLIEF_ID_LIEFNR = B.ID
AND
  B.BADR_ID_ADRNR = C.ID
AND
  D.BBES_ID_LINKKEY = A.ID
AND
  A.BBESPD_GEL_KOMP = 'J' 
AND
  A.GEDRUCKT = 'J'
AND
  D.STORNO = 'N'
AND
  D.ID NOT IN (SELECT BBESP_ID FROM BLLCP)
AND
  (
    (A.ABDATUM IS NOT NULL AND A.ABDATUM > (CURRENT_DATE-3))
    OR
    (A.ABDATUM IS NULL)
    OR
    (A.ABLLTERMIN IS NOT NULL AND A.ABLLTERMIN > (CURRENT_DATE-3))
  )
AND
  A.ID > 228

läuft durch.

Die entsprechende View nicht...

Code: Alles auswählen

SELECT ID, MASKENKEY FROM V_PIK_MISS_AB_LIEF

bringt:

IBPP SQLException
SQL Message : -802
Arithmetic or division by zero has occured.
Engine Code: 335544321 : Arithmetic exception, numeric overflow, or string truncation, string right truncation.

?

[UliS]

Mit den Aliasen durcheinandergekommen??

Suche ich oben im Text die View V_PIK_MISS_AB_LIEF
finde ich
A.MASKENKEY AS BESTNR nich MASKENKEY

Sagt Kollege FlameRobin Division / 0
statt "Maskenkey kenn ich nich"

[loddar]

Hallo Uli,

das war seinerzeit ein Fehler, den Michael schon entdeckt und angesagt hatte. Ich hatte ihn behoben. Mein letzter Post beinhaltet die aktuelle - problembehaftete - View. Dort gibt es schön ID und MASKENKEY.

Gruß,
loddar.