Fremdschlüssel löschen.

[Walter Landwehr]

Hallo, ich will in einer Firebird 2.5 Tabelle einen Fremdschlüssel löschen.
Mein SQL sieht so aus.

Delphi-Quellcode:

ALTER TABLE TBL_RECHNUNG DROP CONSTRAINT FK_TBL_RECHNUNG

Aber der Schlüssel wird nicht gelöscht. Dies soll zur Laufzeit geschehen.
Mit IBExpert geht das.

Kann mir da einer helfen.

[hoika]

Hallo,
fehlendes Commit?
Tabellen bei einem anderen User offen?

Fehlermeldung? Exception?

[TigerLilly]

Ich kenne FB nicht so gut, also liege ich vielleicht daneben:
DROP CONSTRAINT vs DROP INDEX? Oft erzeugt das Anlegen eines Constraints den Index automatisch, das Entfernen des Constraints entfernt aber den Index nicht.

[hoika]

Hallo,
FB legt den passenden Index bei Constraints an und löscht ihn auch wieder.

[Walter Landwehr]

Danke an alle, habe es gelöst indem ich den SQL Befehl im Script gepackt habe.

[himitsu]

Zitat:

Zitat von Walter Landwehr (Beitrag 1394900)

Danke an alle, habe es gelöst indem ich den SQL Befehl im Script gepackt habe.

Was war denn nun der Fehler?

Eine Fehlermeldung/Exception oder keine Meldung, aber der Constraint blieb dennoch zurück?


Bei PgDAC hab ich z.B. ein Problem, wenn in der Query-Komponente solche Befehle ausgeführt werden, die kein Result liefern, bzw. SELECT mit Methoden in der Rückgabe, die aber ein Result liefern.
Da wird das Query dann doppelt ausgeführt und es kommt eine Fehlermeldung, wie z.B. "CONSTRAINT FK_TBL_RECHNUNG exisitert nicht" im zweiten Durchlauf, was auch klar ist, da de Erste das schon gemacht hatte.
Der User und das Programm (Exceptionbehandlung) denken dann es ging nicht, aber das stimmt eben nur Halb.

In der Script-Komponente passiert das nicht, da die eh kein Result erwartet.

[Delphi.Narium]

Mein Vorgehen ist eigentlich grob immer so in der Art:

Delphi-Quellcode:

// qry ist irgendeine Komponente zur Ausführung von SQLs.
qry.Close;
qry.SQL.Text := 'Eine Zeichenfolge, die irgendwo herkommt';
if AnsiLowerCase(copy(qry.SQL.Text,1,6)) = 'select' then begin
  qry.Open;
end else begin
  qry.ExecSQL;
end;

Natürlich gibt es immer 'ne Fehlerbehandlung, geht hier halt nur ums sinnmäße Prinzip. Dabei ist es dann egal, ob TADOQuery, TQuery, 'ner Query der Zeos-Komponenten oder was weiß der Geier sonst noch.

Open und dann kein Select da drin, das ist immer eher "ungünstig" und ohne sinnvolle Fehlerbehandlung kaum zu managen. Je nach DB ist dann auch noch die Art der Fehlermeldung unterschiedlich und kaum einheitlich händelbar.

[jobo]

Zitat:

Zitat von himitsu (Beitrag 1394903)

..
Was war denn nun der Fehler?
..
Bei PgDAC hab ich z.B. ein Problem, wenn in der Query-Komponente solche Befehle ausgeführt werden, die kein Result liefern, bzw. SELECT mit Methoden in der Rückgabe, die aber ein Result liefern.
Da wird das Query dann doppelt ausgeführt und es kommt eine Fehlermeldung, wie z.B. "CONSTRAINT FK_TBL_RECHNUNG exisitert nicht" im zweiten Durchlauf, was auch klar ist, da de Erste das schon gemacht hatte.

Und was ist da der Fehler? Versteh ich das richtig, dass Du innerhalb eines Select mit mglw > 1 Rückgabezeilen eine Funktion ausführst. Die Operation wird dann so oft wiederholt, wie sie aufgerufen wird, also pro Rückgabezeile einmal?

Oder sprichst Du von etwas anderem (was ich dann nicht verstanden habe)?

[mkinzler]

Ich Vermute Mal es wird versucht eine Rückgabe auszuwerten, welche wegen .ExecSQL ausbleibt und die Aktion deshalb wiederholt wird.

[himitsu]

Innerhalb von StoredProcs (Postgres) kann man

Delphi-Quellcode:

PERFORM FunktionDieEtwasMachtAberKeinResultHat();

machen,
aber in Query/Script-Kompnenten geht nur

Delphi-Quellcode:

SELECT FunktionDieEtwasMachtAberKeinResultHat();

und schon bringt der Code von Delphi.Narium leider nichts, bzw. funktioniert zur Hälfte nicht. :zwinker:

PS: Recursive SELECTS werden von dir auch nicht beachtet, also wenn das SELECT nicht direkt am Anfang steht,
oder noch ein Kommentar davor oder ....

Und nein, "Result mit 0 Rows" und "kein Result" sind nicht das Selbe. :angle:
Bei Ersterem gibt es X Fields/Columns und beim Anderen 0 Field-Infos.

[Delphi.Narium]

Heißt das, dass Du sowas nicht machen kannst?

Delphi-Quellcode:

qry.SQL.Text := 'drop table irgendeinetabelle';
qry.ExecSQL;

Was wird denn dann aus

Delphi-Quellcode:

qry.SQL.Text := 'delete from tabelle where id = 1';
qry.ExecSQL;

oder

Delphi-Quellcode:

qry.SQL.Text := 'update tabelle set wert = 1234 where id = 1';
qry.ExecSQL;

Bei Open frag' ich in der Regel per Rec(ord)Count ab, wieviele Ergebniszeilen es so gibt.

Bei ExecSQL bekommt man ggfls. über RowsAffected die Anzahl der geänderten / gelöschten / eingefügten Sätze mit.

Bei manchen Komponenten ist ExecSQL 'ne Funktion, die bei Erfolg true und bei Misserfolg false ist oder bei Misserfolg fliegt 'ne Ausnahme.

Allerdings: Einheitlich ist da nun wirklich nicht geregelt, was den Wechsel der Komponenten zuweilen schon recht aufwändig machen kann.
Und einheitliche Lösungsvorschläge fast unmöglich.

[jobo]

Zitat:

Zitat von himitsu (Beitrag 1394917)

Innerhalb von StoredProcs (Postgres) kann man

Delphi-Quellcode:

PERFORM FunktionDieEtwasMachtAberKeinResultHat();

machen,
aber in Query/Script-Kompnenten geht nur

Delphi-Quellcode:

SELECT FunktionDieEtwasMachtAberKeinResultHat();

und schon bringt der Code von Delphi.Narium leider nichts, bzw. funktioniert zur Hälfte nicht. :zwinker:

Ich verstehe nicht, wo du meinst, dass etwas doppelt/mehrfach ausgeführt wird.
Ist es so gemeint, wie mkinzler schrieb, also eine falsche Interpretation aus Delphi mit erneutem Ausführen? Oder anders?

[himitsu]

Wie gesagt, das bezieht sich jetzt auf Postgres mit PgDAC.
k.A. ob es solche Probleme auch bei anderen DBMS und Zugriffskomponenten gibt.#
War als Beispiel erwähnt, dass Fehlermeldungen nicht immer "ganz" richtig sein müssen.

Also, irgendwo inderhalb einiger Query-Komponenten (z.B. TPgQuery) wird scheinbar bei fehlendem Result die Abfrage nochmal ausgelöst, beim Open/OpenTable. (nicht beim Execute/ExecSQL)
Ganz tief in den Klassen.
Der PgSQLMonitor bekommt die wiederholte Anfrage nicht mit, drum hatte es auch etwas länger gedauert das Problem zu identifizieren, vorallem da es im Programm nicht immer knallt. (das untere Beispiel ist bei uns aber reproduzierbar)

Zum Test: Das Erstellungsscript und 3 Test-Scripte/Queries

SQL-Code:

CREATE OR REPLACE FUNCTION SetSetting(Name VARCHAR, Value INTEGER) RETURNS VOID AS $$
BEGIN
  -- hier INSERT or UPDATE
  RETURN;
END$$ LANGUAGE plpgsql;

SELECT SetSetting('Test', 0);  -- hier fällt es "nicht" auf, wenn es doppelt gesetzt wird

SELECT SetSetting('Test', GetSetting('Test') + 1);  -- hier dagegen ist es +2
--SELECT GetSetting('Test');  -- beide SQL gemeinsam ausgeführt zählen direkt in Zweierschritten hoch und zeigen es sofort an

SELECT GetSetting('Test');

Das tritt auch manchmal auf, wenn ein SELECT ein Result liefert, aber in einem der Felder der "Fehler" liegt.

SQL-Code:

SELECT 'abc', SetSetting('Test', +1);  -- machmal, aber nicht immer doppelt ... Muster noch nicht gefunden

[jobo]

Ok, ich arbeite nicht mit den Komponentenm, aber das ist ja etwas gruselig.
Ich gehe mal davon aus, dass Ihr einen zuverlässigen Workaround habt, sonst könnte man das Konstrukt ja nicht gebrauchen mit den Komponenten.

[himitsu]

Meistens fällt es nicht auf, bis auf paar "Sonderfälle".

SELECT wird doppelt ausgeführt, also braucht auch doppelt so lange, die beiden Abfragen ... wenn die Abfrage nun länger dauert, dann fällt das schon auf (oder man denkt erstmal das dauert wirklich so lange)

Oder wo eben mit Rückgaben gearbeitet wird, bzw. wo etwas erstellt/gelöscht wird.