Timestamp vs GetTime

Alles rund um die Sprache ABAP®: Funktionsbausteine, Listen, ALV
9 Beiträge • Seite 1 von 1
9 Beiträge Seite 1 von 1

Timestamp vs GetTime

Beitrag von cut1 (Specialist / 121 / 0 / 0 ) »
Hallo,

bin gerade dabei eine transp. Tabelle anzulegen in der ein Key der Tabelle das Systemdatum+SystemUhrzeit sein soll.
(Tabelle dient zum abspeichern von Meldungen)

nun stellt sich für mich die Frage ob ich

a) timestamp
oder
b) get time field f

benuzten soll.


bei get time field f wird die Uhrzeit mit dem Datenbankserver noch synchronisiert, alles schön und gut aber was bringt mir das ? bzw welche "Falle" tut sich den da auf ???

danke im vorraus

gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


Beitrag von ewx (Top Expert / 4844 / 311 / 640 ) »
Mit dem Zeitstempel bist du deutlich genauer.
Wenn du nur die Uhrzeit benötigst, um zu wissen, wann ein Datensatz hinzugefügt wurde, dann ist GET TIME besser, da du ein lesbares Format zurückbekommst.
Der Timestamp muss meines Wissens immer umgewandelt werden.

Gruß,
Enno.

Beitrag von JDO ( / / 0 / 3 ) »
Hallo Cut1,

Datum/Uhrzeit bzw. Timestamp als Tabellenkey ist meiner Meinung nach keine gute Idee, da nicht sichergestellt ist, daß bei mehrfachen, nahezu gleichzeitigen Updates wirklich unterschiedliche Keys erzeugt werden, ganz zu schweigen von unterschiedlichen Zeitzonen (-> set locale) und Zeitdifferenzen zwischen verschiedenen Servern.

MfG Juergen

Beitrag von ewx (Top Expert / 4844 / 311 / 640 ) »
JDO hat geschrieben:Datum/Uhrzeit bzw. Timestamp als Tabellenkey ist meiner Meinung nach keine gute Idee, da nicht sichergestellt ist, daß bei mehrfachen, nahezu gleichzeitigen Updates wirklich unterschiedliche Keys erzeugt werden, ganz zu schweigen von unterschiedlichen Zeitzonen (-> set locale) und Zeitdifferenzen zwischen verschiedenen Servern.
Guter Einwand!
Ausserdem gibt es zum Speichern von Meldungen gute Standardbausteine (Siehe Programme SBAL_DEMO*).
Falls das doch zu aufwändig ist, bietet sich als Schlüssel eher ein eigener Nummernkreis an (TA SNRO, Fuba NUMBER_GET_NEXT).

Gruß,
Enno.

Beitrag von cut1 (Specialist / 121 / 0 / 0 ) »
@JDO:

Zeitzonen+differnz:
da kann ich mir leider grad gar nix drunter vorstellen, welches Problemm das für den Eintrag in die Tabelle bedeuten würde. Kannst du mir das bitte vielleicht etwas verdeutlichen ?

ich denke die Programm laufen ja immer auf dem gleichen Server, da muss ich mal bei der Technik bei uns nachharken.


Updates:
du meinst bei nahezu gleichzeitigen updates auf die Tabelle könnte ich Information bzw die Meldung verlieren. hmmm der Schlüssel besteht noch aus anderen Komponenten (Meldungsnr.. rechnungsnr), aber theoretisch ist wohl dieser "Falle" denkbar.
z.b bei parallel verarbeitung wenn halt der identische Fehler zur gleichen Zeit auftritt. dann würde ja wohl nur die Meldung einmal auf die Datenbank geschrieben, obwohl sie 2-x mal auftratt. hmm.

@ewx

Nummernkreis:
benötige jedoch eine Zeitkomponente-> um feststellen zu können ob die Meldung veraltet ist ...

synchronisierung Datenbankserver
tja welcher Server gibt den da den Ton an ??
der DB-Server oder der Applications-Server


grüsse
cut1[/u]

Beitrag von ewx (Top Expert / 4844 / 311 / 640 ) »
cut1 hat geschrieben:Nummernkreis:
benötige jedoch eine Zeitkomponente-> um feststellen zu können ob die Meldung veraltet ist ...
Hi cut,

du kannst das Zeitfeld ja trotzdem aufnehmen. Nur nicht als Schlüsselfeld!

Gruß,
Enno.

Beitrag von babap (Expert / 681 / 1 / 1 ) »
Hallo,

kurz zu den beiden angesprochenen Themen:

TIMESTAMPS:
Zum auseinanderhalten von Ereignissen und deren Zeitpunkten sind TIMESTAMPS schon geeignet. Als alleiniger Key reichen sie allerdings nicht aus (Gleichzeitigkeit!!)

Das Problem der Zeitzonen bekommt man durch die Normierung auf UTC in den Griff.

MELDUNGEN:
Das Sammeln und abspeichern von Meldungen sollten man nicht mit eigenen Tabellen machen, dafür gibt es SAP-Konstrukte, die das bereitstellen (s.o.)

Gruß
babap

Beitrag von cut1 (Specialist / 121 / 0 / 0 ) »
Meldungen:

damit ist wohl die Sachen mit den Nachrichtenklassen gemeint ?.

Ich möchte für "Batch-Programme" die Ihre Meldungen auf eine Liste schreiben, einen Meldungstext mit mehr als 4 Parameter benutzen. Außerdem sind die Meldungen noch untergliedert in Zuständigkeit für Meldung/pro Meldung, deswegen die Sache mit den Meldungen in eine eigene Tabelle.

Bei Dialogprogramme hab ich dann natürlich das Problemm bei verwendung des Message Befehls das ich nur 4 Parameter von bis max 8 verwenden kann. Da muss ich mir dann noch was überlegen


grüsse

Beitrag von Haubi (Expert / 625 / 20 / 30 ) »
Moinsen.

@Meldungen:
Versuche lieber, Dich auf die vorhandenen 4 Parameter zu beschränken. Einerseits musst Du dann nicht zwei verschiedene Message-Handlings schreiben und andererseits kannst Du das Applikationslog nutzen (Tx SLG0, SLG1 und FuBa BAL*).

Gruss,
Haubi
Das ABAP Kochbuch ab sofort bei Amazon...

I'd rather write code that writes code than write code...

Seite 1 von 1

Vergleichbare Themen

2
Antw.
3501
Views
Timestamp
von errorist » 09.07.2008 13:36 • Verfasst in ABAP® für Anfänger
5
Antw.
20198
Views
Konvertierung Timestamp
von jeyloeso » 24.10.2012 08:40 • Verfasst in ABAP® für Anfänger
5
Antw.
2191
Views
Timestamp Kalkulation
von Lbyte » 27.11.2017 15:43 • Verfasst in ABAP® für Anfänger
2
Antw.
552
Views
TIMESTAMP 15 vs. 14 Zeichen
von sapdepp » 04.11.2022 08:49 • Verfasst in ABAP® Core
1
Antw.
4477
Views
Zeitstempel TIMESTAMP und TIMESTAMPL
von KleinerEisbaer » 15.09.2008 12:53 • Verfasst in ABAP® für Anfänger

Über diesen Beitrag


Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.

Unbeantwortete Forenbeiträge

Daten an Tabelle binden
vor 20 Stunden von Bright4.5 1 / 459
aRFC im OO-Kontext
vor 4 Wochen von ralf.wenzel 1 / 2107
Hilfe bei SWEC/SWE2
letzen Monat von retsch 1 / 8701