Params im ADOQuery nicht angenommen.

[ahachmann]

Hallo,
Wie kann es sein, daß zwei Queryobjekte verschieden reagieren? Ich stehe vor der Wand.
Ich habe beide auf Prepared := true gesetzt, und will eine Abfrage starten.
Bei diesem Code läuft alles gut:

Delphi-Quellcode:

intResult := conDB.BeginTrans;
  try
    qrySQL.SQL.Clear;
    qrySQL.Prepared := True;
    intResult := qrySQL.SQL.Add(
    'INSERT INTO tubes (name,description,customer,number,length,diameter,picturepath) '+
    ' VALUES (:Pname,:Pdescription,:Pcustomer,:Pnumber,:Plength,:Pdiameter,:Ppicture)');
    qrySQL.Parameters.ParamByName('Pname').Value := name;
    qrySQL.Parameters.ParamByName('Pdescription').Value := description;
    qrySQL.Parameters.ParamByName('Pcustomer').Value := customer;
    qrySQL.Parameters.ParamByName('Pnumber').Value := strtoint(ext1);
    qrySQL.Parameters.ParamByName('Pdiameter').Value := strtofloat(ext2);
    qrySQL.Parameters.ParamByName('Plength').Value := strtofloat(ext3);
    qrySQL.Parameters.ParamByName('Ppicture').Value := strPicturePath;
    intResult := qrySQL.ExecSQL;
    bolRet := true;
    conDB.CommitTrans;
  except
    bolRet := false;
    conDB.RollbackTrans;
  end;
  funcInsertArticle := bolRet;

Bei deisem nicht. Er sagt, daß er den Parameter PName nicht kenne. Selbst Wenn ich die Constante SQLSTOPPER direkt durch
den SQL-String ersetze macht er es nicht. (((((

Delphi-Quellcode:

  qryArticles.SQL.Clear;
  qryArticles.Prepared := true;
  intRes := qryArticles.SQL.Add(SQLSTOPPER);
  qryArticles.Parameters.ParamByName('Pname').Value := 'test';
  try
    intRes := qryArticles.ExecSQL;
  except
  end;

Das SQL-Statement ist in einer anderen Unit als Constante hinterlegt:

SQL-Code:

SELECT * 
FROM stopper 
WHERE article_id IN 
(Select stopper_id 
FROM r_tubestopper 
WHERE tube_id = 
(Select article_id 
From r_articleproduct 
where name = :Pname AND article_id IN (Select article_id FROM tubes))) UNION
SELECT * FROM stopper WHERE NOT EXISTS (SELECT * 
FROM stopper 
WHERE article_id IN 
(Select stopper_id 
FROM r_tubestopper 
WHERE tube_id = 
(Select article_id 
From r_articleproduct 
where name = :Pname AND article_id IN (Select article_id FROM tubes))))

Vielen Dank und sorry für das große Post.
Alexander

[Robert_G]

Vielleicht kommt die DB mit den UNIONS und 5 mio. Sub-scans nicht klar...
Bist du dir sicher, dass du einen Index-Scan über 3 bzw. 4 Level machen willst ?!?

Nachtrag: Hatte dein "Prepared:= True" übersehen.

[ahachmann]

Also das Statement läuft. Ich habe es vorher direkt in der DB getestet.
Das Statement selber bekomme ich mit meinem Wissensstand immo auch nicht besser hin.
Die Bedingungen sind auf jeden fall ein Muß. Könnte bestimme noch optimiert werden.

Habe es jetzt aber zu laufen bekommen, in dem ich die Parameter verschieden benannt habe.
irgendwie hat ihn es gestört, daß ich name zwei mal im Statement hatte. Ist das normal?

Naja, auf jeden Fall läuft es jetzt.
Aber Vielen Dank

[Robert_G]

Wenn ich dein letztes Statement durch meine Oacle-IDE formatieren lasse, sieht es so aus...

SQL-Code:

SELECT *
FROM   stopper
WHERE  article_id In
       (SELECT stopper_id
        FROM   r_tubestopper
        WHERE  tube_id = (SELECT article_id
                          FROM   r_articleproduct
                          WHERE  Name = :Pname And
                                 article_id In (SELECT article_id
                                                FROM   tubes)))
UNION
SELECT *
FROM   stopper
WHERE  Not Exists
 (SELECT *
        FROM   stopper
        WHERE  article_id In
               (SELECT stopper_id
                FROM   r_tubestopper
                WHERE  tube_id = (SELECT article_id
                                  FROM   r_articleproduct
                                  WHERE  Name = :Pname And
                                         article_id In (SELECT article_id
                                                        FROM   tubes))))

Das muss einfacher gehen...
Zum Problem: Vielleicht musst du den zweiten Parameter umbenennen. Wenn ich in PL/SQL einen dyn. SQL benutze muss ich sogar für jedes Auftauchen einer Bindvariable einen Wert angeben!

... War ich mal wieder zu langsam...

[ahachmann]

)
Aber trotzdem vielen Dank.
Hast mich übrigens motiviert doch nochmal zu optimieren.

SQL-Code:

SELECT * 
FROM stopper 
WHERE article_id IN 
   (Select stopper_id 
   FROM r_tubestopper 
   WHERE tube_id = (Select article_id 
         From r_articleproduct r, tubes t
         where r.name = 'test' AND r.article_id=t.article_id)



UNION
SELECT * FROM stopper WHERE NOT EXISTS (SELECT * 
FROM stopper 
WHERE article_id IN 
   (Select stopper_id 
    FROM r_tubestopper 
    WHERE tube_id = (Select article_id 
         From r_articleproduct, tubes
         where r.name = 'test' AND r.article_id=t.article_id)

Soo, das ist schon mal ein Scan weniger. Aber hier habe ich jetzt das Problem, daß PostGres es in dem Vergleich nicht mag, daß die Felder die im letzten Select verglichen werden gleich sind. Es heißt "ERROR: Column reference "article_id" is ambiguous".
Dürfen die Felder wirklich nicht gleich heissen? mit dem r.article_id sind die doch eindeutig. Wenn ich in der Relationstabelle das feld auf article setzte und das Statement entsprechend ändere, dann lüpt es.
Ne Idee?
Vielen Dank,
ALexander

[Robert_G]

Ich habe die Abfrage als Textdatei angehängt. (Ich will ja nicht das sich hier noch einer die Maus wund scrollt )
Ich habe nur schnell ein paar Klammern gesetzt und den Subselects ein paar Tabellenaliase gegönnt, müsste laufen.
Ich kann mir das ja mal heute Abend genau anschauen, jetzt habe ich leider keine Zeit dafür

Nachtrag: Um die Formatierung zu behalten musst du die Datei speichern (rechtsklick...).

[Leuselator]

Wenn ich das ganze durch meine eigene HumanBrainSqlEngine laufen lasse, kommt das heraus:

SQL-Code:

    SELECT A.*

      FROM stopper A

INNER JOIN r_tubestopper B
        ON B.stopper_id = A.article_id

INNER JOIN r_articleproduct C
        ON C.article_id = B.tube_id
       AND C.name = 'test'

INNER JOIN tubes D
        ON D.article_id = C.article_id   

UNION

    SELECT A.* 
      FROM stopper A
 WHERE NOT EXISTS (    SELECT article_id  -- bloß keinen * hier!
                         FROM stopper A

                   INNER JOIN r_tubestopper B
                           ON B.stopper_id = A.article_id

                   INNER JOIN r_articleproduct C
                           ON C.article_id = B.tube_id 
                          AND C.name = 'test'

                   INNER JOIN tubes D
                           ON D.article_id = Carticle_id
                   )

[Edit]Das Folgende wird sich später als voreilig von mir erweisen:[/Edit]
und wenn ich mir das dann so ansehe, liefert diese Abfrage auf sehr umständliche Art und Weise das gleiche Ergebnis wie:

SQL-Code:

    SELECT * 
      FROM stopper

korrigiert mich, wenn ich das falsch sehe...

Weiter: in Deinem "Where Not Exists"-Statement, solltest Du unbedingt den Stern "*" durch eine konkrete Spalte ersetzen - bringt mehr Speed.

*sichgarnichtberuhigenkann*

Gruß

[Robert_G]

Buahhaha http://www.og4all.de/sip/Totlach.gif

Mann natürlich, erst alle bei denen es referenz. Einträge gibt, und dann alle wo es keine gibt...
Ich habe ehrlich gesagt noch nicht mal genau hingeguckt... (das gibt 100 Minuspunkte auf dem Beitragszähler)

[ahachmann]

Da muß ich Dich korregieren.
Auf Grund der Problemstellung mit der ich das Programm erstelle entsteht folgende Abhängigkeit.
Ich habe ein Produkt Röhrchen und Stopfen für Röhrchen.
ein Produkt und ein Artikel (röhrchen oder Stopfen) werden in der n*m tabelle r_articleproduct in relation gebracht.
Auf ein Röhrchen passen nur bestimmte Stopfen (Durchmesser) die in der r_tubestopper Relation dargestellt werden.
So, ist in einem Produkt ein Röhrchen vorhanden, dann drüfen nur noch die Stopfen gezeigt werden, die auf grund der r_tubestopper relation zu dem in dem Produkt gehörigen Röhrchen passen.
Ist kein Röhrchen im Produkt (r_articlesproduct) dann müssen alle Stopfen gezeigt werden (das ist die Union Abfrage);

Somit ist es definitiv nicht "Select * From Stopper";

Zum * im Union. Da hast Du natürlich recht.
Vielen Dank und gruß
Alexander

[ahachmann]

Zitat von GeorgeWNewbie:

Buahhaha http://www.og4all.de/sip/Totlach.gif

Mann natürlich, erst alle bei denen es referenz. Einträge gibt, und dann alle wo es keine gibt...
Ich habe ehrlich gesagt noch nicht mal genau hingeguckt... (das gibt 100 Minuspunkte auf dem Beitragszähler)

aber auch 150 + für Deine Geduld und Hilfsbereitschaft.
Hat sich jetzt alles geklärt. Die Frage mit dem Error hat sich erledigt, da ich im SELECT nach article_id und nicht r.article_id gefragt habe.

Alos vielen Dank