1 Sekunde Unterschied zwischen DB DateTime Feld und Anwendung beim Speichern

[Furtbichler]

Zitat von Piro:

Für mich ist die Sekunde wichtig, da ich das lastupdate aus der Anwendung in einer weiteren Abfrage verwende

Das ist der eigentliche Fehler. Es entspricht nicht dem Wesen eines Datums/Uhrzeitwertes, als Identifikator für einen Datensatz herzuhalten. Du kannst Klimmzüge unternehmen (runden z.B.), aber das ist imho einfach nicht richtig. Was ist, wenn plötzlich zwei Anwendungen gleichzeitig Daten generieren. Oder eine Anwendung innerhalb einer Sekunde mehrere Datensätze?

Du möchtest doch einen eindeutigen Identifikator, um deine Daten wiederzufinden, oder? Dann verwende einen.

Um einen Datensatz zu markieren, verwende wahlweise einen Zähler (identity), eine GUID (uniqueIdentifier) oder einen Timestamp.
Du kannst das clientseitig generieren, hast aber dann i.A. das Problem, das bei Mehrfachzugriff auf die Schreibfunktionen diese Identifikatoren u.U. nicht eindeutig ist (Ausnahme: GUID).

Mein Tipp: Verwende eine IDENTITY-Spalte. Genausogut geht aber eine GUID oder TimeStamp-Spalte. ADO liefert dir den neu erzeugten Wert, wenn Du die Feldinformation dieser Spalte richtig initialisierst (Eigenschaften 'AutoGenerateValue'). Auch wenn es immer wieder diesbezüglich Fragen gibt.

Eine Alternative wäre das Absetzen des Befehls 'INSERT' mit der 'OUTPUT'-Klausel, was ich wiederum sehr charmant finde:

SQL-Code:

insert  
  YourTable 
  (Fields) 
output 
  inserted.PKColumn 
values 
  (<YourValueList>)

also z.B.:

SQL-Code:

--Create Table MyTable (ID int IDENTITY (1,1), Name VarChar(50))
insert MyTable (Name) output inserted.ID values ('Furtbichler')

Diesen Befehl kannst Du in einer TADOQuery ausführen. Natürlich mit parametrierten Werten

[jobo]

Fraglich ist außerdem, einen clientbasierten Zeitstempel einzutragen. Wie willst Du kontrollieren, wie die Clients ihre Uhrzeit eingestellt haben? Ich meine, da gehört ein Serverdatum hin. Das wiederum am besten per Trigger.
Und auch wenn Du dann an der Stelle sauber bist, solche Datumsabfragen gehören normal nicht in die Verarbeitung- wie bereits angeführt wurde, wenn dann ins Reporting.

[sx2008]

Bist du nicht der, der mit den Datentypen SmallDateTime und Date rumeexperimentiert?
Also ich habe mit SmallDateTime schon schlechte Erfahrungen gemacht, weil die Genauigkeit und der Bereich einfach zu klein ist.