Datenerfassung mit Firebird Datenbank

[Jens Hartmann]

Um nochmal auf das Case Sensitiv zu kommen.

Wenn ich das jetzt richtig vertanden habe, brauchte ich die Anführungszeichen gar nicht, da ich in meiner Datenbank auch nicht mit Anführungszeichen gearbeitet habe, und somit meine Feldnamen nicht Case sensitiv sind

[DeddyH]

Richtig, bei den Feldnamen brauchst Du sie nicht, aber bei den Stringfeldern. Hier wäre es sowieso besser, mit SQL-Parametern zu arbeiten.

[mkinzler]

Es sihet aber so aus, als ob du das hättest. Zum Bsp. wenn du die entsprechende Option im IBExpert gesetzt hast

[Jens Hartmann]

In der Form.Create sage ich...

Delphi-Quellcode:

procedure TFUebung.FormCreate(Sender: TObject);
var
i : integer;
begin
  {Datenbankverbindung aufbauen über ZConnection (ZEOS)}
  ConSecurdat.Connect;

Dann öffne ich die Datenbank...

Delphi-Quellcode:

{Datenbank Öffnen}
procedure TFUebung.Button8Click(Sender: TObject);
begin
  QrySecurdat.Open;
end;

Und beim eintrage sage ich...

Delphi-Quellcode:

procedure TFUebung.Button9Click(Sender: TObject);
var
  i : integer;
begin
  QrySecurdat.Active := false;
  QrySecurdat.SQL := Memo1.Lines;
  QrySecurdat.Active := true;

Und dann habe ich noch AfterPost angelegt

Delphi-Quellcode:

{Refreshanweisung nach AfterPost}
procedure TFUebung.QrySecurdatAfterPost(DataSet: TDataSet);
begin
  QrySecurdat.Refresh;
end;

[mkinzler]

Delphi-Quellcode:

  QrySecurdat.Close;
  QrySecurdat.SQL := Memo1.Lines;
  QrySecurdat.ExecSQL;

.Open/.Active := True nur bei Selects. Bei DML-Statements immer .ExecSQL!

[Jens Hartmann]

Zitat:

Es sihet aber so aus, als ob du das hättest. Zum Bsp. wenn du die entsprechende Option im IBExpert gesetzt hast

Ich vermute du meinst den Haken "datenbankobjektnamen immer groß schreiben" in der Datenbank Registrierung.

Ist aber nicht so.

Zitat:

.Open/.Active := True nur bei Selects. Bei DML-Statements immer .ExecSQL!

Jetzt ist zwar der Fehler weg, aber bei der SQL-Abfrag mit SELECT, erscheinen keine Daten

Delphi-Quellcode:

{SQL-Abfrage starten}
procedure TFUebung.Button7Click(Sender: TObject);
begin
  QrySecurdat.Open;
  QrySecurdat.SQL := Memo2.Lines;
  QrySecurdat.Active := true;
end;

[EDIT]...

Zitat:

Finde es irgenwie beruhigend, das Du über die Steine stolperst, über die ich vor ein paar Tagen gestolpert bin (selber SQL Anfänger)

Hast du den einen Thread oder so, wo ich eine bißchen lesen könnte oder Info´s sammeln könnte die Dir weiter geholfen haben

[mkinzler]

Bei Abfragen, welche eine Datenmenge zurückgeben (Select):

Delphi-Quellcode:

  QrySecurdat.Close;
  QrySecurdat.SQL := Memo2.Lines;
  QrySecurdat.Open;

[Satty67]

Nein, aber ein gutes Buch und Zeit (lese hier jeden Thread, der auftaucht und Hilfreiche Informationen beinhalten könnte)... und natürlich auch ein Übungsprojekt.

Für die Abfrage mal

Delphi-Quellcode:

  Query.SQL.Text := 'SELECT...';
  Query.Open;

Zu dem Anführungszeichen Wirrwarr, also was mir geholfen hat war irgendwo die Information:

Feldnamen anfangs immer in Anführungszeichen einschließen (dieser doppel Strich über der 2)
Datenwerte in Apostroph einschließen (die einzelnen Striche wie bei Delphi-Strings)

Ersteres wäre nur nötig bei CaseSensitiven Namen, aber schadet auch erstmal nicht. Man kommt mit reservierten Wörtern nicht in die Quere.

Query.FieldByName('Name').AsString ist besser, hat mich aber Anfangs sehr verwirrt, weil ich bei Mengen nicht wusste welcher Satz aktiv ist.

[Jens Hartmann]

Zitat:

Nein, aber ein gutes Buch und Zeit

Zeit ist immer so eine Sachen, momentan habe ich genug davon. Ein gutes Buch, was würdest Du empfehlen.

[Satty67]

Ich kenne nur zwei SQL Bücher, konnte ja nicht alles kaufen. Sehr gut finde ich von Markt&Technik "Jetzt lerne ich SQL". Das ist einfach und geht nicht zu sehr in die Tiefe (was am Anfang aber eher hilfreich ist).

Das zweite ist "SQL Gritty", was ich unübersichtlich finde. Aber das könnte besser sein, wenn ich mehr verstanden hab'.

Beide Bücher sind wohl schon etwas älter, aber mit SQL-92 / SQL-99 was ja ausreichend ist (Firebird oder Interbase Spezialitäten behandeln beide leider nicht)

[DeddyH]

Eine spezielle Empfehlung hab ich jetzt nicht, aber schau mal hier: http://www.terrashop.de/buecher/db/sql/. Da sollte für jeden Geschmack und Geldbeutel etwas dabei sein.

[Jens Hartmann]

Super, eindlich mal ein Erfolgserlebnis, aber natürlich wie immer mit einem Haken.

Es funktioniert, ich bekomme Verbindung zur Datenbank, kann eintragen und auch Abfragen. Aber,immer die Einträge nach dem Programmstart.

Starte ich das Programm neu, und mache als erstes die Abfrage, ist die Tabelle leer, Fügen ich dann aber Daten ein, kann ich diese Abfragen, und erkenne auch an hand der ID das mal andere Datensätze vorhanden waren.

[DeddyH]

Dann schließt Du Deine Transaktion anscheinend nicht mit Commit ab.

[Jens Hartmann]

Danke, Funtz.

Das war ne schwere geburt.

Das Commit, ist ja von Firebird. Das hatte ich schon wieder verdrängt..

Aber es stand ja so in der Beschreibung Commit zum Abschluß und Rollback für Zurück.

Danke, Danke.

Jetzt werde ich das ganze heute Abend mal noch ein bißchen testen und dann morgen mal in mein Projekt einarbeiten.

[DeddyH]

Zitat:

Zitat von Jens Hartmann

Danke, Funtz.

Öhmm... ich heiße Detlef :roll:

[mkinzler]

Funzt heisst funktioniert :zwinker:

[Jens Hartmann]

Hallo nochmal zusammen,

So das mit dem INSERT, UPDATE und so, funktioniert soweit ganz gut, ich habe die Datenbank jetzt an mein Programm angebunden und auch das funktioniert einwandfrei.


Jetzt mal ne Frage, ich habe hier im Forum und sonst schon gesucht, kann allerdings nichts finden.

Ich habe ja jetzt verschiedene String´s, die den verschiedenen Feldern der Tabelle zugeordnet werden sollen. Bis lang, habe ich mit folgendem INSERT- Befehl gearbeitet. Wie ersetze ich jetzt die festen Eingaben gegen Variablen.

Delphi-Quellcode:

{Neue Daten in Datenbank einfügen}
procedure TForm1.BTDatenbankClick(Sender: TObject);
begin
  QryMB256PLUS.Close;
  QryMB256PLUS.SQL := Memo2.Lines;   //Der Inhalt von Memo2 ist mein SQL String
  QryMB256PLUS.ExecSQL;
  ConMB256PLUS.Commit;
end;

SQL-Code:

INSERT INTO MB256PLUS ("LfdNr", "Datum", "Uhrzeit", "Ereignis", "Teilnehmer", "Bereich")
VALUES('1234','12.12.2009','12:13:43','Extern Scharf','Schalteinrichtung','Verwaltung');

:gruebel:

[Satty67]

Man möge micht korrigieren, wenn es falsch ist ;)

Delphi-Quellcode:

// Entweder den String mit Variablen aufbauen
// QuotedStr halt die entsprechende Variable übergeben
Memo1.Text := 'INSERT INTO MB256PLUS ("LfdNr", "Datum", "Uhrzeit", "Ereignis", "Teilnehmer", "Bereich")
              VALUES('+
              QuotedStr('1234')+','+
              QuotedStr('12.12.2009')+','+
              QuotedStr('12:13:43')+','+
              QuotedStr('Extern Scharf')+','+
              QuotedStr('Schalteinrichtung')+','+
              QuotedStr('Verwaltung')+
              ')';

// oder gleich SQL.Text zuweisen.
// ExecSQL hinterher nicht vergessen 

// oder Field Eigenschaften von Query verwenden
Query.Insert;
Query.FieldByName('LfdNr').AsString := '1234';
Query.FieldByName('Datum').AsDate := StrToDate('12.12.2009');
[...]
Query.Post;

[mkinzler]

Mit (SQL-)Parametern

SQL-Code:

INSERT INTO MB256PLUS ("LfdNr", "Datum", "Uhrzeit", "Ereignis", "Teilnehmer", "Bereich")
VALUES(:lfdnr,:datum,:zeit,:ereignis,:teilnehmer,Bereich);

Die Abfrage setzt du einmalig und brauchst später nur noch die Werte setzen:

Delphi-Quellcode:

QryMB256PLUS.ParamByName('lfdnr').Value := ...
...
QryMB256PLUS.ExecSQL;

[DeddyH]

Nimm am besten SQL-Parameter.

Delphi-Quellcode:

Query.SQL := 'INSERT INTO Tabelle(Wert1,Wert2) VALUES(:wert1,:wert2)';
Query.ParamByName('wert1').AsInteger := 123;
Query.ParamByName('wert2').AsString := 'Wuppdi';
Query.ExecSQL;

[Satty67]

Wobei ich jetzt schon ein Problem der reinen SQL-Bücher sehe. So eine elegante Variante wie sie gerade mkinzler beschrieben hat, lernt man da nicht. (Oder hab' es gewissenhaft überlesen)

€: Nach ExecSQL fülle ich nur ParamByName neu auf und wieder ExecSQL (ohne SQL-Text zu verändern)?

[Jens Hartmann]

Danke erstmal wieder für die schnelle antwort,

Also, wenn ich das verstanden habe, kann ich schon in meiner Query Komponente die Parameters und auch den SQL String setzen.

Jetzt muss ich im eigentlichen Programm nur noch die Werte setzten

[mkinzler]

Zitat:

Wobei ich jetzt schon ein Problem der reinen SQL-Bücher sehe. So eine elegante Variante wie sie gerade mkinzler beschrieben hat, lernt man da nicht. (Oder hab' es gewissenhaft überlesen)

Dann ist es ein schlechtes Buch, wenn es keine parametrisierte Abfragen behandelt.

Zitat:

€: Nach ExecSQL fülle ich nur ParamByName neu auf und wieder ExecSQL (ohne SQL-Text zu verändern)?

Vor jedem Aufruf von .ExecSQL()( auch dem ersten)

[DeddyH]

Richtig, Du musst nur die Parameter neu befüllen, bevor Du ExecSQL erneut ausführst, das eigentliche SQL bleibt davon unberührt.

[Satty67]

Zitat:

Zitat von mkinzler

Dann ist es ein schlechtes Buch, wenn es keine parametrisierte Abfragen behandelt.

Hab es dann wohl überlesen, wenn das so elementar ist.

Sehe schon, hab' bisher doch ziemlich umständlich gearbeitet. (Funktioniert hat es aber ;) )

[Jens Hartmann]

So habe das jetzt mal so gemacht, er trägt auch Daten ein, bring mir nur wieder die Fehlermeldeung

Cannot retrieve Resultset Data

Ich habe das jetzt so integriiert..

Delphi-Quellcode:

{Neue Daten in Datenbank einfügen}
procedure TForm1.BTDatenbankClick(Sender: TObject);
begin
  QryMB256PLUS.Close;
  QryMB256PLUS.SQL.Text := 'INSERT INTO MB256PLUS ("LfdNr", "Datum", "Uhrzeit",'+
      '"Ereignis", "Teilnehmer", "Bereich")'+
      'VALUES(:LfdNr,:Datum,:Uhrzeit,:Ereignis,:Teilnehmer,:Bereich)';

  QryMB256PLUS.ParamByName('LfdNr').AsInteger := 1231;
  QryMB256PLUS.ParamByName('Datum').AsString := '12.12.2009';
  QryMB256PLUS.ParamByName('Uhrzeit').AsString := '12:12:43';
  QryMB256PLUS.ParamByName('Ereignis').AsString := 'Extern Unscharf';
  QryMB256PLUS.ParamByName('Teilnehmer').AsString := 'Schalteinrichtung';
  QryMB256PLUS.ParamByName('Bereich').AsString := 'Verwaltung';
  QryMB256PLUS.ExecSQL;
  ConMB256PLUS.Commit;
  QryMB256PLUS.Open;
end;

[mkinzler]

Wie schon öfters erwähnt kein .Open bei DML-Statements ( Insert, Update, Delete)
Du brauchst die Abfrage auch nur einmal zu setzen und nicht für jeden Datensatz

[Jens Hartmann]

Das mit der Abfrage ist klar, die kann ich doch auch in der Query direkt eintragen, weil das habe ich so gemacht.

Ich habe das lediglich gerade zum test gemacht.

Das mit dem open war mir schon wieder entgangen.

Funktioniert jetzt...... :wall:

[Jens Hartmann]

Ich muss nochmal nerven,

Ich habe das ganze jetzt mit dem Open und den ExecSQL mal so überlegt, um es zu verstehen, ich habe jetzt eine Unstimmigkeit in meinem Verständnis.

Beim Starten von meinem Programm, möchte ich ja das meine Daten von meiner Datenbank angzeigt werden. Also habe ich in die OnCreate von meinem Hauptformular folgende Anweisung geschrieben...

Delphi-Quellcode:

  {Datenbankverbindung aufbauen über ZConnection (ZEOS)}
  ConMB256PLUS.Connect;
  QryMB256PLUS.Open;

Da ich aber ja in meiner Query Komponente den SQL String festgelegt habe...

SQL-Code:

INSERT INTO MB256PLUS'("LfdNr", "Datum", "Uhrzeit", "Ereignis", "Teilnehmer", "Bereich")
     VALUES(:LfdNr,:Datum,:Uhrzeit,:Ereignis,:Teilnehmer,:Bereich)';

kommt es ja logischer Weise zu meinem bekannten Fehler.

Daraus folgere ich, das ich entweder die Datenansicht anders realisieren muss oder der Open Befehl anders eingesetzt werden muss.

[DeddyH]

Wenn Du den SQL-String unbedingt zur Designtime festlegen willst, dann verwende doch einfach mehrere Queries. Ansonsten nur eine und SQL zur Laufzeit befüllen.

[mkinzler]

Man unterscheidet Abfragen welche eine Ergebnismenge zurückliefern ( Select) und welche nicht (DML).
Für die erstere verwendet man ein .Open

[Jens Hartmann]

Das hatte ich auch schon mal überlegt.

Aber...

1. Wann weiße ich denn dann zur Laufzeit meinen SQL Befehl zu.

2. Wenn der Befehl zugewiesen ist, und ich Daten eingefügt habe, bleibt mein Grid leer.

Ich habe es jetzt so gelößt, funktioniert auch, aber ich weiß ja eigendlich das es falsch ist...

Delphi-Quellcode:

{Neue Daten in Datenbank einfügen}
procedure TForm1.BTDatenbankClick(Sender: TObject);
begin
  QryMB256PLUS.Close;
  QryMB256PLUS.SQL.Text := 'INSERT INTO MB256PLUS'+
      '("LfdNr", "Datum", "Uhrzeit", "Ereignis", "Teilnehmer", "Bereich")'+
      'VALUES(:LfdNr,:Datum,:Uhrzeit,:Ereignis,:Teilnehmer,:Bereich)';

  QryMB256PLUS.ParamByName('LfdNr').AsInteger := 1231;
  QryMB256PLUS.ParamByName('Datum').AsString := '12.12.2009';
  QryMB256PLUS.ParamByName('Uhrzeit').AsString := '12:12:43';
  QryMB256PLUS.ParamByName('Ereignis').AsString := 'Extern Unscharf';
  QryMB256PLUS.ParamByName('Teilnehmer').AsString := 'Schalteinrichtung';
  QryMB256PLUS.ParamByName('Bereich').AsString := 'Verwaltung';
  QryMB256PLUS.ExecSQL;
  ConMB256PLUS.Commit;

  QryMB256PLUS.Close;
  QryMB256PLUS.SQL.Text := 'SELECT * FROM MB256PLUS';
  QryMB256PLUS.Open;

end;

[DeddyH]

Wieso soll das falsch sein?

[mkinzler]

Warum nimmst du nicht einfach 2 Queries?

[Jens Hartmann]

Also ich fasse mal zusammen.

Meine Lösung ist nicht verkehrt, und funktioniert. (Sorry zum größten Teil Eurer Lösung)

Aber es wäre Besser mit 2 Query´s zu areiten.

Das heißt, ich nehme die eine für meine Anzeige, die ich aber wahrscheinlich nach jedem neuen eintragen mit einem Refresh füllen muss.

Die zweite Query nur für´s eintragen in die Datenbank, in der ich dann meinen SQL Befehl z.B. im OnCreate von Form1 zuweisen lassen kann.

Somit habe ich die Möglichkeit meine SQL Anweiseung später anzupassen und sie ist vorallem beim Programmstart leer.

[mkinzler]

Zitat:

Das heißt, ich nehme die eine für meine Anzeige, die ich aber wahrscheinlich nach jedem neuen eintragen mit einem Refresh füllen muss.

Ein enfaches

Delphi-Quellcode:

Query.Refresh;

sollte reichen

[Jens Hartmann]

Das habe ich jetzt auch so gemacht und alles Funktioniert.

Leider muss ich feststellen, das ich auch hier das selbe Problem habe, wie ich es in einem anderen Beitrag geschrieben habe.

Anderer Thread

Ich werde, diesen Beitrag jetzt nochmal anstoßen, vieleicht hat da noch jemand eine Idee

[Satty67]

Sorry, das ich mich hier immer reindrängel, aber der Thread passt halt prima auf meine eigene Situation/Fragestellungen

Ich hab' jetzt mal INSERT via FieldByParam in meinem Übungsprojekt umgesetzt:

Delphi-Quellcode:

zQueryArtikel.SQL.Text = 'INSERT INTO '+sql_tbl_ArticleIO+' ('+
                         sql_fn_Location+','+
                         sql_fn_ArticleNo+','+
                         sql_fn_ArticleDesc+','+
                         sql_fn_PackCount+','+
                         sql_fn_Packing+','+
                         sql_fn_Quantity+','+
                         sql_fn_QuantityUnity+','+
                         //...da kommt noch einiges...
                         sql_fn_Remarks+
                         ') VALUES ('+
                         ':'+CutQuotes(sql_fn_Location)+','+
                         ':'+CutQuotes(sql_fn_ArticleNo)+','+
                         ':'+CutQuotes(sql_fn_ArticleDesc)+','+
                         ':'+CutQuotes(sql_fn_PackCount)+','+
                         ':'+CutQuotes(sql_fn_Packing)+','+
                         ':'+CutQuotes(sql_fn_Quantity)+','+
                         ':'+CutQuotes(sql_fn_QuantityUnity)+','+
                         //...da kommt genausoviel
                         ':'+CutQuotes(sql_fn_Remarks)+
                         ');

Bei mir sind alle Feldnamen als Konstante gespeichert (incl. "..."). Damit ich nicht doppelte Konstanten hab', muss ich jetzt für Parameter-Namen die Quotes wieder entfernen.

Insert via ParamByName:

Delphi-Quellcode:

with zQueryArtikel do begin
  ParamByName(CutQuotes(sql_fn_Location)).AsString := EditLocation.Text;
  ParamByName(CutQuotes(sql_fn_ArticleNo)).AsString := EditArticleNo.Text;
  ParamByName(CutQuotes(sql_fn_ArticleDesc)).AsString := EditArticleDesc.Text;
  ParamByName(CutQuotes(sql_fn_PackCount)).AsString := EditPackCount.Text;
  ParamByName(CutQuotes(sql_fn_Packing)).AsString := EditPacking.Text;
  ParamByName(CutQuotes(sql_fn_Quantity)).AsString := EditQuantity.Text;
  ParamByName(CutQuotes(sql_fn_QuantityUnity)).AsString := EditQuantityUnity.Text;
  // usw...
  ExecSQL;
end;

INSERT wie ich es vorher hatte, als Funktionsaufruf:

Delphi-Quellcode:

function InsertArtikel(Location, ArticleNo, ArticleDesc [...] String):Integer;
// In der Funktion wird Insert generiert und abgesetzt
// als Feldwerte die Parameter der Funktion übernommen
  [...]VALUES ('+
       QuotedStr(Location)+','+
       QuotedStr(ArticleNo)+','+
       QuotedStr(ArticleDesc)+','+

Eventuelle Tipp-Fehler mal ignorieren, Copy+Paste ist gerade nicht verfügbar (deshalb auch stark gekürzt)... :cry:

Das sind ja (in meinem Fall) gut 15 weitere Methodenaufrufe pro Datenfeld. CutQuotes() gleicht sich mit QuotedStr() aus. Wirklich übersichtlicher ist es für mich auch nicht.

Mir stellt sich jetzt die Frage, wo die Vorteile von FieldByParam sind?

PS: Mein SQL-Buch behandelt Parameter nicht wirklich, wie sie in TQuery's verwendet werden. Zugriff via Delphi, C/C++ etc. ist da überhaupt kein Thema.

[mkinzler]

Parameter haben den Vorteil
-kein Quoten nötig
-weitgehenst automatiche Typkonvertierung
-das DBMS braucht die Abfrage nur einmal zu parsen und zu kompilieren, bei erneutem Aufrufen müssen nur die geänderten Paramter gesendet werden -> Geschwindigkeitsvorteil

[Satty67]

Ok, das mit dem Quoten ist bei meiner Vorgehensweise so eine Sache. Entweder ich lasse bei den Konstanten Spaltennamen die Quotes weg und muss die dann bei den Spaltennamen im INSERT-String wieder einfügen. Sobald ich Konstanten verwende, komme ich um einmal wegschneiden oder zufüge nicht drum rum.

Automatische Typkonvertierung ist ein großer Vorteil. Da ich bisher immer mit Record's gearbeitet hatte, hab' ich mich da selber drum gekümmert. Gestolpert bin ich aber da auch schon beim Automatismus: TypUmwandlung AsFloat. Hab' da meine liebe Mühe mit dem DezimalSeperator als Komma. Behelfe mir mit der verwendung von AsCurrency, dort wird die Einstellung verwertet.

Geschwindigkeit ist natürlich später auch ein großes Argument. Da merke ich im Moment beim Übungsprojekt noch nichts. Muss mir mal eine Zufallsdatenbank mit großer Datenmenge generieren, damit ich da besser testen kann.