Datum in DB setzen

[barnti]

Hallo,

ich habe ein kleines Problem mit der Verwendung des Datentyps 'TDateTime'.

Delphi-Quellcode:

procedure ExecInvalidate(Datasource: TDatasource; Field, Value: String; InvalidationTime: String);
var Query: TmySQLQuery;
begin
  Query:= CreateQuery;

  Query.Close;
  Query.SQL.Clear;
  Query.SQL.Add('UPDATE '+DataSource.Name);

  // Hier versuche ich den String 'invalidationTime' in die DB zu schreiben
  // Erzeugt wird dieser beim Aufruf von ExecInvalidate(Datasource,Field,Value,DateTimeToStr(now))

  Query.SQL.Add('SET valid= '+QuotedStr(invalidationTime));
  Query.SQL.Add('WHERE '+Field+'='+QuotedStr(Value));
  showmessage(Query.SQL.Text);
  Query.ExecSQL;
  Query.free;
end;

Leider kommt in der DB immer nur '0000-00-00 00:00:00' an. Muss ich den String anders formatieren? Ich krieg das nicht auf die Reihe...

Danke.

[Cuchulainn]

Welchen Datentyp hast du in diesem Feld denn in der Tabelle?

[barnti]

Hi,
'hups'...vergessen zu erwähnen: 'Datetime'.

[Robert_G]

Warum zum Geier ist invalidationTime ein String und was soll das bringen?

Wenn du den Datensatz auf invalid incl. Zeitpunkt setzen willst, geht doch ganz easy so:

Delphi-Quellcode:

  With Query Do
  Begin
    SQL.Text :=
      'UPDATE ' + Owner + '.' + Table_Name + #10 +
      'SET    Valid = SysDate' + #10 +
      'WHERE  ' + Field + ' = :i_FieldName';
    Prepared := True;
    Parameters.ParamByName('i_FieldName').Value := Value;
    ExecSQL;
  End;

Vorausgesetzt du verwendest immer noch Oracle, ansonsten musst du nach der Bezeichnung des aktuellen Zeitpunktes in deiner DB suchen.

OffTopic:
Wobei mir die Tabelle so nicht gefällt.
Sinnvoll wären die Felder:

SQL-Code:

OWNER        Varchar2(30)
TABLE_NAME   Varchar2(30)
isVALID      Integer
ModDate      Date
ModUser      Varchar2(30)

... plus einem Audit log, in dem alle vergangenen Änderungen gelistet werden.

[barnti]

Tja,

ich arbeite immer noch mit mysql

Ich muss das Datum durch ein Menge von rekursiven Aufrufen durchschleifen, daher kann ich nicht die Funktion 'now'
direkt benutzen. Das heißt, ich muss bei ersten Aufruf der Prozedur zum Invalidieren ein Datum festlegen und als Parameter übergeben. Ob String oder TDateTime erscheint mir gleich. Beim Zusammensetzen meines SQL-Strings brauche ich sowieso einen String => also ist der Parameter auch ein String, den ich mit

Query.SQL.Add('SET valid= '+QuotedStr(invalidationTime)); in das SQL-Satement schreibe. Dabei mache ich wohl einen Denkfehler, der mit der Behandlung von TDatetime/ DB/DateTime zu tun hat...?

Hast Du noch etwas zum topic?

Danke.

[Hansa]

MySql? Dann o.G. 8) aber warum wandelst Du nicht das TDateTime einfach um ? Ohne die QuotedStr ?
z.B. so:
FieldByName ('KUNDESEIT').value := date;

[barnti]

Hallo Hansa,

ich arbeite mit einem Query.ExecSQL. Da gibt es keine Felder, auf die ich zugreifen kann.

Deshalb muss ich die Zeit direkt in mein Statement schreiben und dann absenden.

Noch weitere Ideen?

[Hansa]

Benutze ein DataSet.

[kiar]

hallo,

was steht denn in now drin?

musste gestern auchMyDate.= SysUtils.now; machen

raik

[Robert_G]

Das Datum des Clients zu verwenden, halte ich für komplett ungeeignet. Du kannst nie wissen ob die Systemzeit richtig gestellt ist. Außerdem könnte man damit absichtlich die History verfälschen, indem man mehrere Änderungen bei veränderter Systemzeit auf dem Client vornimmt

Die Variable als String finde ich auch sinnlos. mySQL wird wohl auch DateTime unterstützen

Zitat:

...Ich muss das Datum durch ein Menge von rekursiven Aufrufen durchschleifen, daher kann ich nicht die Funktion 'now' direkt benutzen. ...

Tja...
Da hast du 2 Möglichkeiten:

• Du suchst dir eine DB in der man "programmieren" kann (es muss ja nicht gleich PL/SQL sein ).
  zu erwähnen wäre da als kostenose Alternative zu Oracle vielleicht PostGreSQL.
• Du musst dich für einen Zeitpunkt, beim Setzen des (in-)valid-Flags festlegen. An dem Schritt nimmst du das Systemdatum der DB und sagst "jetzt ist der Record invalid oder valid".

Alles andere würde niemals eine Software validierung überstehen, da es an allen Ecken und Kanten Lücken zur Manipulation oder Benutzerfehlern lassen würde.
Stichworte: ISO 9001 und DIN 46001