Bekomme kein INSERT mit FB und IBDAC hin!?!

[mkinzler]

Zitat:

Du solltest das Feld ID ganz weglassen und stattdessen das Feld DATUM zum Primärschlüssel machen.

Ist aber auch eine Frag der Philosopie, ob man "Nutzfelder" zum PK macht onder künstliche Schlüssel verwendet

[hoika]

Hallo,

zu deiner Ausgangsfrage, warum es nicht klappt.

Delphi-Quellcode:

  TMPSQL := TIBCSQL.Create(nil);

  for I := 1 to 31 do 
  begin
    TMPSQL.SQL.Add('INSERT INTO TBLCALENDAR(ISHOLIDAY,DATUM) VALUES(0,''13.07.2010'');');
  end;

31 mal wird insert into als Befehl eingetragen

Delphi-Quellcode:

  
  TMPSQL.AutoCommit := True;
  TMPSQL.Execute;

Jetzt wird der Code einmal zum Server geschickt.
Der sieht jetzt also folgendes

INSERT INTO TBLCALENDAR(ISHOLIDAY,DATUM) VALUES(0,''13.07.2010'');INSERT INTO TBLCALENDAR(ISHOLIDAY,DATUM) VALUES(0,''13.07.2010'');
INSERT INTO TBLCALENDAR(ISHOLIDAY,DATUM) VALUES(0,''13.07.2010'')

Und das waren nur 3 der 31.

Firebird kann im Untershcied zu MS-SQL immer nur einen Befehl ausführen
(es sei denn, man benutzt irgendeine Script-Komponente).

Durch das Umbauen auf die Parameter ist das TMPSQL.Execute;
mit in die For-Schleife gerutscht.
Somit wird der Befehl auch korrekt 31 mal ausgeführt.

Das war ja auch der ursprüngliche Plan ...


Zum Ändern der Tabellen-Struktur:
Warum soll das bei Firebird mehr Leistung bringen,
vom Trigger abgesehen ?
Index ist Index (bei Firebird zumindestens)

Ich würde das so lassen, falls später mal Replikation ein Thema ist,
ist der künstliche Schlüsel ID ideal.

Heiko

[RWarnecke]

Zitat von scrat1979:

Aber warum MUSS(?) man parametisierte Abfragen benutzen?

Bei der Parametisierung brauchst Du nicht auf die Formatierung in der SQL-Anweisung zu achten, ob Du jetzt zum Beispiel ein Hochkomma schreiben musst oder nicht.

Ein Beispiel :
Query.SQL.Add('INSERT INTO TBLCALENDAR(ISHOLIDAY, Reiseziel, Startflughafen) VALUES(0,''''Hawaii'''', ''''Frankfurt'''');'); Wenn Du jetzt noch mehrere solcher Felder hast, tust Du Dich schwer den kompletten SQL richtig vernüpftig zu lesen. Jetzt gibt es zwei Varianten, wie man das ganze etwas überischtlicher gestalten kann.

1. Möglichkeit:
Hier muss ich aber wieder auf die Formatierung in der SQL-Anweisung achten. Ich ersetze die vier Hochkommas durch QuotedStr. Das ganze sieht dann so aus :Query.SQL.Add('INSERT INTO TBLCALENDAR(ISHOLIDAY, Reiseziel, Startflughafen) VALUES(0,' + QuotedStr('Hawaii') + ', ' + QuotedStr('Frankfurt') + ');'); Das ganze ist zwar schon besser zu lesen und übersichtlicher, aber den kompletten Insert-Befehl kann ich nicht erkennen.

2. Möglichkeit:
Die Werte, die ich über Variablen oder Fest in den SQL-Befehl einfügen will, übergebe ich mit Parametern. Das ganze sieht dann so aus :

Delphi-Quellcode:

Query.SQL.Add('INSERT INTO TBLCALENDAR(IsHoliday, Reiseziel, Startflughafen) VALUES (:IsHoliday, :Reiseziel, :StartFlughafen);');
Query.SQL.ParamByName('IsHoliday').AsInteger := 0;
Query.SQL.ParamByName('Reiseziel').AsString := 'Hawaii';
Query.SQL.ParamByName('StartFlughafen').AsString := 'Frankfurt';

Hier sehe ich einwandfrei den SQL-Befehl und weiss was er macht. In den Zeilen darunter sehe ich dann die übergebenen Parameter. Was auch der Übersichtlichkeit dient. Ein weiterer Vorteil ist, dass ich jetzt die Query nehmen kann und hier immer nur noch die Parameter übergebe und dann den SQL-Befehl ausführen kann ohne jedes mal überlegen zu müssen, was muss ich wohin schreiben.

[Bernhard Geyer]

Zitat von scrat1979:

Aber warum MUSS(?) man parametisierte Abfragen benutzen? WARUM funktioniert mein 1. Vorschlag nicht, rein formal ist er doch ok, oder?

Datumsangaben sind im SQL-String immer problematisch, da je nach Server(konfiguration) das ISO/Deutsche/US/EN oder was weiß ich Format erwartet wird. Bei MS Access wird teilweise je nach Zugriffsweg auch ein # am Anfang und Ende der Datumsangabe benötigt. Bei parametrisierten Abfragen treten diese Probleme nicht auf da hier auf jedenfall das richtige Format bei verwendung von "AsDatetime" ankommt.

Und Probleme mit SQL-Injection bekommst du auch keine.

[sx2008]

Zitat von hoika:

Zum Ändern der Tabellen-Struktur:
Warum soll das bei Firebird mehr Leistung bringen,
vom Trigger abgesehen ?
Index ist Index (bei Firebird zumindestens)

Das Feld DATUM braucht einen Unique Index, denn es muss verhindert werden, dass man mehrfach das gleiche Datum eintragen kann.
Ohne das Feld ID spart man sich einen weiteren Index (und den Trigger).
Die Tabelle ist kleiner und benötigt so weniger Resourcen.
Wie mkinzler gesagt hat ist das natürlich auch eine Frage der Philosopie.
Wenn man aber einen eindeutigen natürlichen Primärschlüsselkandidaten findet (hier das DATUM), dann sollte man ihn auch benützen.

Also mein Verständnis von Primärschlüsseln ist so:
Gibt es einen natürlichen Primärschlüsselkandidaten bestehend aus nur einem Feld?
Falls ja dann benützen.
Wenn zwei oder mehr Felder benötigt werden um einen Primärschlüssel zu bilden, dann sollte man einen künstlichen Schlüssel einführen.
Das gilt auch, wenn das potentielle Primärschlüsselfeld sehr lang ist.
Wenn die Möglichkeit besteht, dass der Inhalt des Primärschlüsselfelds später geändert wird, dann sollte man auch einen künstlichen Schlüssel bevorzugen. (Beispiel)

[hoika]

Hallo,

Zitat:

Wenn die Möglichkeit besteht, dass der Inhalt des Primärschlüsselfelds später geändert wird, dann sollte man auch einen künstlichen Schlüssel bevorzugen.

Korrekt.

Bsp. Kundennummer

Kunde sagte, die sind immer eindeutig -> Prim Key

2 Jahre später will er, dass das erweitert wirrd
um ein neues 2. Feld (z.B. Kunden-Nr. / Niederlassung).

Man kann so viel vordenken, wie mn will,
es kommt immer anders

Ausserdem werden Prim.-Keys oft auch als ForeignKeys verwendet,
im Fall des Kunden müßte man jetzt an der ganzen DB rumschrauben.


Sch... of die paar Bytes des Integer


Heiko

[scrat1979]

Ich danke Euch für Eure ausführlichen Erläuterungen!! Vorerst bleibe ich mal bei meinem "künstlichen" Schlüssel. Ein neuer Plan (=Aufrufen des Triggers) wird nur 1x im Monat erstellt, ich denke, damit kann man gut leben

SCRAT