überfordert ~.~

[nahpets]

Hallo,

habe gerade mal ein bisserl nix zu tuen, deshalb schau ich kurz in den Quelltext

warum

Delphi-Quellcode:

anreise:=(DatetoStr(bu_anreise.Date));
abreise:=(DatetoStr(bu_abreise.Date));

if (anreise >= abreise) then 
  begin
    Showmessage('Buchung nich möglich. Bitte überprüfen Sie das Datum.');
  end
else
  begin

Datumswerte kann man miteinander vergleichen (auch unter Delphi 6)
if (bu_anreise.Date >= bu_abreise.Date) then dürfte die gleiche Wirkung haben, wobei ein Vergleich von z. B. 25.05.2013 mit 01.08.2013 als Datumswerte durchaus zu einem "besseren" Ergebnis führen kann als als Zeichenfolge. Als Zeichenfolge ist 01.08.2013 kleiner als 25.05.2013, bei einem Datumsvergleich nicht.

Bitte mal in der Hilfe die Beschreibungen zu den Datumsfunktionen der Unit DateUtils anschauen. Dort sollte es sowas wie DayOf, MonthOf, YearOf geben, die Funktionen benötigen alle als Eingabeparameter einen TDateTime, der mit bu_anreise.Date... ja vorhanden ist. Dadurch läßt sich die gesamte Zeichenfolgenverarbeitung vermeiden und die Ergebnisse werden sicherlich einfacher und korrekt ermittelt.

Die gesamte Datumsumformatierungsorgie mit DD, MM und JJ wird dadurch hinfällig.

Da es sich bei den Buchungsdaten für Anreise und Abreise um Datumswerte handelt, sollten hier in der Datenbank auch Datumswerte gespeichert werden und keine Timestamps. Der Datentyp Date ist der genutzten Datenbank bekannt.

Die Datenbankabfragen sollten parametrisiert werden, damit das Zusammenbauen der SQL-Statements vereinfacht wird.
Das könnte dann z. B. so oder so ähnlich aussehen:

Delphi-Quellcode:

ADOQuery_Buchen2.sql.text:=('SELECT Buchung.Zimmer_Nr FROM Buchung WHERE Buchung.Anreise >= :anreise AND Buchung.Abreise <= :abreise ');
ADOQuery_Buchen2.Parameters.ParamByName('anreise').Value := bu_anreise.Date;
ADOQuery_Buchen2.Parameters.ParamByName('abreise').Value := bu_abreise.Date;
ADOQuery_Buchen2.Active:=true;

Dashier erschließt sich mir überhaupt nicht:

Delphi-Quellcode:

    For zeile := 1 to 20 DO                      //Zeilen im DBGrid hochzaehlen
      begin
       with DBGrid1.DataSource.DataSet do
         begin
          RecNo := Zeile;
          s:= Fields[spalte-1].AsString;
         end;
         b:=strtoint(s);
      end;

DBGrid1 ist mit ADOQuery_Buchen2 verbunden, es dürfte also auch mit

Delphi-Quellcode:

    For zeile := 1 to 20 DO                      //Zeilen im DBGrid hochzaehlen
      begin
       with ADOQuery_Buchen2 do
         begin
          RecNo := Zeile;
          s:= Fields[spalte-1].AsString;
         end;
         b:=strtoint(s);
      end;

gehen. Spalte wird am Anfang auf 1 gesetzt und dann immer mit Spalte-1 genutzt, warum? Spalte könnte dann auch direkt 0 sein oder direkt Fields[0].AsString. Da das Feld Zimmer_Nr gelesen wird, wäre FieldByName('Zimmer_Nr').AsString aber eleganter.
Aber sinnvoll ist das Ganze nicht, was ist, wenn die Abfrage weniger als 20 Zeilen hat?
Die Logik geht hier davon aus, dass die Ergebnismenge immer über 20 Zeilen verfügt, das dürfte eher unwahrscheinlich sein. Zimmer_Nr ist in der Datenbank numerisch, warum dann ein derartiges Konstrukt?

Delphi-Quellcode:

s:= Fields[spalte-1].AsString;
b:=strtoint(s);

Wir lesen also einen Integerwert der Datenbank als String, um diesen dann in einen Integer zu verwandeln?b := FieldByName('Zimmer_Nr').AsInteger liefert das gleiche Ergebnis. Interessant ist, dass bei dieser Logik am Ende b immer den Wert der 20. Zimmmer_Nr aus der Ergebnismenge hat. Man könnte dann auch sowas programmieren:

Delphi-Quellcode:

ADOQuery_Buchen2.Active:=true;  
ADOQuery_Buchen2.MoveBy(20);
b := FieldByName('Zimmer_Nr').AsInteger;

Hier gibt es, wie mir scheint, mehrere Probleme: Einige, für die Aufgabenstellung erforderliche, Grundlagen sind nicht (hinreichend?) bekannt. Die Aufgabenstellung ist nicht bekannt oder verstanden worden bzw. die Aufgabe wurde nicht in hinreichend kleine Teilstücke zerlegt, um diese dann sinnvoll in Quelltext umsetzen zu können.

[SubData]

@Perlsau, @Delphi-Laie

Sorry für das OT, aber ich möchte euch beide mal daran erinnern, dass auch ihr mal Anfänger wart und viele Dinge,
die für uns "alte Hasen" absolut selbstverständlich sind, für Neulinge eben nicht so selbstverständlich rüber kommen.
Ihr habt beide manchmal eine sehr harsche und direkte Schreibweise, die viele mit Sicherheit auch abschrecken wird.
Ob gerechtfertigt oder nicht, lass ich einfach mal im Raum stehen.

Ich möchte einfach kurz daran appelieren, dass ihr vielleicht ein wenig vorsichtiger und verständnisvoller an neue
Poster herangeht und nicht gleich das schlechteste annehmt bzw. ein wenig sanfter mit euren Formulierungen umgeht.

Sorry, wollte ich einfach mal los werden.


Kleiner Nachtrag: Ja, ich hätte das auch per PN machen können, da mir in einzelnen Fällen auch schon andere aufgefallen
sind, auf die das ebenso zutrifft, ist das eher ein Hinweis an die Allgemeinheit. Nicht nur auf die beiden persönlich
bezogen. Ausserdem soll das kein Angriff, sondern ein gut gemeinter Rat sein

[Delphi-Laie]

Zitat von SubData:

@Perlsau, @Delphi-Laie

Sorry für das OT, aber ich möchte euch beide mal daran erinnern, dass auch ihr mal Anfänger wart und viele Dinge,
die für uns "alte Hasen" absolut selbstverständlich sind, für Neulinge eben nicht so selbstverständlich rüber kommen.
Ihr habt beide manchmal eine sehr harsche und direkte Schreibweise, die viele mit Sicherheit auch abschrecken wird.
Ob gerechtfertigt oder nicht, lass ich einfach mal im Raum stehen.

Ich motze aber niemanden voll (was allerdings nicht implizit bedeutet, daß ich es Perlsau in dieser Diskussion unterstelle). Ich weiß, daß aller Anfang schwer ist und bin immer noch nur mittelleicht fortgeschrittener.

Und eines wirst Du bei mir nirgendwo finden: Daß ich mein Selbstwertgefühl daran aufpoliere, daß ich vermeintliche oder tatsächliche (in jedem Falle aber unbewiesene) "Crossposter" jage und erlege.

An Sergejs Reaktion ist ja wohl abzulesen, daß ich mich eher gemäßigt ausdrückte (und es zudem auch so meinte)

[p80286]

Manno Mann,
Jetzt ist aber langsam gut!
Ein bischen krabitzig ist ja gut aber so helfen wir sergej nicht unbedingt weiter.

Gruß
K-H

[Aviator]

Hallo Sergej,
bin auch gerade mal über dein Programm drübergeflogen. Mir sind einige Dinge aufgefallen, die auch die Stabilität des Programms in Frage stellen könnten. Du benutzt z.B. als Name deines TPageControl das Wort "register". Register ist allerdings in Delphi ein reservierter Begriff und im falschen Kontext durchaus auch falsch zu verstehen.
Des Weiteren schließe ich, bevor ich einer Query einen neuen SQL.Text zuweise, immer zuerst die Query, weiße dann den String zu und öffne sie dann erst wieder.

Das hier:

Delphi-Quellcode:

For zeile := 1 to 20 DO                      //Zeilen im DBGrid hochzaehlen
      begin
       with DBGrid1.DataSource.DataSet do
         begin
          RecNo := Zeile;
          s:= Fields[spalte-1].AsString;
         end;
         b:=strtoint(s);
      end;

solltest du vielleicht in eine

Delphi-Quellcode:

while NOT ADOQuery_Buchen2.EOF do begin
...
  ADOQuery_Buchen2.Next;
end;

Schleife verpacken. Somit kannst du sicher sein, dass immer alle Datensätze ausgelesen werden. Sollten mal weniger DS in der DB vorhanden sein, wird dir dein Programm einen Fehler melden. Sind mehr drin, werden diese nicht ausgelesen.

Die Daten solltest du wie auch schon von "nahpets" beschrieben, direkt vergleichen und nicht erst in einen String umwandeln. Des Weiteren übergibst du bei deinem SQL-Statement die Daten in Form eines Strings. In der DB ist das Feld aber als DateTime Feld angelegt. Warum sind die "#"-Zeichen vor und hinter dem jeweiligen Datum angebracht? Sollten das Hochkommata " ' " sein? Wenn ja, schau dir bitte mal die Funktion QuotedStr() an. Die erledigt genau das. Wobei das in diesem Fall nicht benutzt werden soll. DateTime Werte können direkt an eine DB per SQL-Statement übergeben werden.

Zu deinem Problem mit dem Einfügen in die Datenbank beim Klick auf "Buchen".
Ein Hinweis noch wenn ihr mir den erlauben darf. Lagere doch Speicherprozeduren aus und durchlaufe nicht alles im OnButtonClick Event. Das kann dir auch beim Finden deiner Fehler helfen.

Das Hinzufügen der Werte in die DB musst zu nicht zwingend über das "INSERT INTO" Statement machen. Du kannst über deine ADOQuery_Buchen auch in etwa so etwas machen:

Delphi-Quellcode:

with ADOQuery_Buchen do begin
  Append;
  FieldByName('Pass_Nr').AsInteger := NaechtePassNr;
  FieldByName('Zimmer_Nr').AsInteger := ZimmerNr;
  ...
  Post;
end;

Alternativ zu FieldByName() kannst du auch Fields[I] benutzen. Bei C ist Fields[I] zumindest als schneller angegeben. Wie es bei Delphi aussieht weiß ich nicht genau.
Wenn du das Eintragen in die DB per "INSERT INTO" machen willst, dann sag nochmal bescheid. Dann müssen wir uns dein SQL-Statement mal genauer ansehen.

[kwhk]

Zitat:

anreise:=(DatetoStr(bu_anreise.Date));
abreise:=(DatetoStr(bu_abreise.Date));

if (anreise >= abreise) then

Hierbei werden die Datum-Angaben jeweils in Strings des Formates TT/MM/JJJJ gewandelt und so verglichen.
Datum-String-Vergleiche sollte man aber immer im Format JJJJ/MM/TT durchführen, andernfalls ist der 02/04/2013 kleiner als der 31/03/2013.

[DeddyH]

Wieso eigentlich Datumswerte als String vergleichen statt gleich als TDate(Time)?