Insert/MS Access

[Anfänger2013]

Hallo Leute,
mitlerweile habe ich mein ganzes Programm fertig, aber wie solls auch sein ...es gibt immer etwas was schief läuft.

Delphi-Quellcode:

with ADOQuery_Buchen3 do
  begin
    SQL.Text:= ('INSERT INTO Buchung (Pass_Nr, Zimmer_Nr, Anreise, Abreise) Values ("bu_e_passnummer.Text", "strtoint(bu_e_zimmernummer.Text)", "anreise", "abreise");');
    ExecSQL;
    Active:= True;
  end;

oben könnt ihr mein Quelltext zum insertbefehl sehen. Laut meinem Wissen und Internet ist eig der Insertbefehl richtig. ich habe auf datum in der datenbank geachtet und auch mal in text umgewandelt und immer wieder bekomm ich eine fehlermeldung und ich weiß nicht was falsch ist. ich habe auch die fehlermeldung (Datentypen in Kriterienausdruck unvertraglich.) gegooglet und hat auch net wirklich weiter geholfen.
hatte auch mal wie mir mal geraten wurde mit parametern probiert, da kam aber auch i.eine fehlermeldung. ...entweder mach ich was falsch oder die datenbank ist faul :/

Habt ihr vlt ne idee woran es liegen könnte?

danke im voraus

[Bummi]

Wenn Deine Buchungstabelle nur aus Varchars bestehen würde hättest Du hinterher folgende Daten in der Datenbank:

Pass_Nr |Zimmer_Nr |Anreise|Abreise
__________________________________________________ ____________________
bu_e_passnummer.Text|strtoint(bu_e_zimmernummer.Te xt)|anreise|abreise

[sx2008]

Ich würde es mir nicht so schwer machen und lieber auf einige Millisekunden an Performance verzichten:

Delphi-Quellcode:

// die Bedingung WHERE 0=1 bewirkt, das keine unnötigen Daten abgerufen werden
ADOQuery_Buchen.SQL.Text := 'SELECT * FROM Buchung WHERE 0=1';
ADOQuery_Buchen.Open;
ADOQuery_Buchen.Append;  // Datensatz anhängen

// das direkte Befüllen der Felder macht die Sache sehr einfach
ADOQuery_Buchen['Pass_Nr']   := bu_e_passnummer.Text;
ADOQuery_Buchen['Zimmer_Nr'] := strtoint(bu_e_zimmernummer.Text);
ADOQuery_Buchen['Anreise']   := anreise;
ADOQuery_Buchen['Abreise']   := abreise;
// Datensatz speichern
// im Hintergrund erzeugt die VCL eine INSERT-Anweisung und schickt sie an die Datenbank
ADOQuery_Buchen.Post;

[Perlsau]

Zitat von Anfänger2013:

Datentypen in Kriterienausdruck unvertraglich

Also deutlicher kann eine Fehlermeldung wohl nicht mehr ausfallen. Du mußt jetzt einfach überprüfen, ob alle Daten, die du an Access schickst, den richtigen Datentypen entsprechen. Oder worauf sonst sollte diese Fehlermeldung wohl hinweisen? Zeig doch mal deine Tabellendefinition.

[Sir Rufo]

Du hast hier mehr als nur einen Fehler drin ...

Delphi-Quellcode:

with ADOQuery_Buchen3 do
  begin
    // Wenn ADOQuery_Buchen3 jetzt aber noch geöffnet ist ... ?
    SQL.Text:= 
      ( // Wozu die Klammer?  
        'INSERT INTO Buchung (Pass_Nr, Zimmer_Nr, Anreise, Abreise) ' +
        'Values (' +
        '"bu_e_passnummer.Text", ' +
        '"strtoint(bu_e_zimmernummer.Text)", ' +
        '"anreise", ' +
        '"abreise"' +
        ');' 
      );
    ExecSQL;
    Active:= True; // Wieso soll diese Abfrage (INSERT) wieder geöffnet werden?
  end;

1. Du weist der ADOQuery_Buchen3 einfach etwas zu, obwohl die geöffnet sein kann -> vorher schließen
2. Du schreibst direkt in das SQL-Skript (wird in der/durch die Database-Engine ausgeführt) Bezüge aus deinem Programm (bu_e_passnummer.Text , bu_e_zimmernummer.Text ) bzw. benutzt dort Delphi-Funktionen (strtoint ).
   Dies/e sind aber der Database-Engine (MS-Access) gänzlich unbekannt
3. Nach dem Ausführen des SQl-Skripts (INSERT -> verändert Daten aber liefert keine Daten zurück) setzt du das auf aktiv, aber was soll das bezwecken? Da kann nichts zurückkommen, ausser dass der INSERT hier nochmals ausgeführt wird

Jetzt mal ein Schuss ins Blaue:

Ich vermute, dass in ADOQuery_Buchen3 eine Abfrage enthalten ist, die du (evtl. in einem Grid) anzeigst. Aus unerfindlichen Spargründen versuchst du Komponenten einzusparen und für unterschiedliche Zwecke zu gebrauchen.

Jetzt ein Lösungsvorschlag:

Erstelle dir für jede dieser Datenveränderungs-Aufgaben eine Methode (in einem TDataModule)/eine Prozedur und rufe dann diese Methode/Prozedur auf. Für das oben genannte Beispiel würde dass dann wie folgt aussehen:

Delphi-Quellcode:

procedure AddBuchung( AConnection : TADOConnection; const Pass_Nr : string; Zimmer_Nr : Integer; Anreise, Abreise : TDateTime );
var
  LQry : TADOQuery;
begin
  LQry := TADOQuery.Create( nil );
  try
    LQry.Connection := AConnection;

    LQry.SQL.Add( 'INSERT INTO Buchung (Pass_Nr, Zimmer_Nr, Anreise, Abreise)' );
    LQry.SQL.Add( 'VALUES ( :Pass_Nr, :Zimmer_Nr, :Anreise, :Abreise )' );

    LQry.ParamByName( 'Pass_Nr' ).Value := Pass_Nr; 
    LQry.ParamByName( 'Zimmer_Nr' ).Value := Zimmer_Nr; 
    LQry.ParamByName( 'Anreise' ).Value := Anreise; 
    LQry.ParamByName( 'Abreise' ).Value := Abreise; 

    LQry.ExecSQL;
  finally
    LQry.Free;
  end;
end;

Aufrufen kannst du das nun mit

Delphi-Quellcode:

AddBuchung( ADOConnection1, bu_e_passnummer.Text, StrToInt( bu_e_zimmernummer.Text ), Anreise, Abreise );
// Jetzt noch den Refresh/Requery auf das DataSet, womit die Buchungsdaten angezeigt werden

[Perlsau]

Und zur Not läßt man sich den SQL-Text einfach mal anzeigen – entweder mit einem ShowMessage oder einem SaveToFile für weitere Verwendung. Meist sieht man spätestens dann, was man mal wieder für einen Murks zusammengepfuscht hat

[Sir Rufo]

Zitat von Perlsau:

Und zur Not läßt man sich den SQL-Text einfach mal anzeigen – entweder mit einem ShowMessage oder einem SaveToFile für weitere Verwendung. Meist sieht man spätestens dann, was man mal wieder für einen Murks zusammengepfuscht hat

... und wenn man es nicht sieht, dann führt man den einfach mal direkt im Datenbank-System aus und lässt sich dort die Fehler um die Ohren hauen ... um zu merken, dass ist kein Delphi-Fehler, sondern mein Murks

[Perlsau]

Ist aber in diesem speziellen Fall nicht wirklich möglich, da der TE mit Delphi-Variablen arbeitet bzw. zu arbeiten versucht – und die kann Access beim besten Willen nicht kennen ...

[Sir Rufo]

Zitat von Perlsau:

Ist aber in diesem speziellen Fall nicht wirklich möglich, da der TE mit Delphi-Variablen arbeitet bzw. zu arbeiten versucht – und die kann Access beim besten Willen nicht kennen ...

Aber wenn man das nicht erkennt

[Perlsau]

... dann sollte man sich erst einmal mit SQL und Datenbank-Grundlagen befassen. Irgendwie find ich's immer etwas peinlich, wenn einfachste Fehlermeldungen nicht verstanden werden. Da frag ich mich dann manchmal, ob derjenige sich nicht besser ein anderes Hobby zulegen sollte als ausgerechnet Software-Entwicklung ... Oft wird ja nicht mal die Fehlermeldung genannt, sondern einfach nur "hilfe ich hab eine Fehlermeldung, was soll ich machen!" geschrien