Zeiteintrag als UTC aus Spalte1 nach Spalte2 schreiben?

Ginga

Neuer Benutzer
Beiträge
4
Hallo Zusammen,

Betrifft MS SQL Server 2014 oder 2019

Ich müsste einen Zeiteintrag (DateTime) aus einer Spalte in einer weiteren Spalte als UTC Zeit eintragen.
Das ganze habe ich schon als Trigger automatisiert (bei Update der Spalte), ABER ich muss den exakten Zeiteintrag nehmen. Dieser entspricht nicht der Systemzeit. Das wäre ja mit GetUTCDate() möglich...

Also z.B.

Spalte1: 2021-03-24 16:00:00

müsste UTC

Spalte2: 2021-03-24 15:00:00

lauten

Wie bekomme ich das per z.B. Trigger (Update) hin, dass beim aktualisieren der Spalt1 auch die Spalte 2 den richtigen UTC Stempel bekommt?!

Ist das verständlich erklärt??

Viele Dank an ALLE schon einmal

Viele Grüße
 
Werbung:
Warum, das ist doch redundant. Die Zeit kannst Du bei der Abfrage auch als extra Splate in UTC ausgeben, wenn nötig, aber mit 2 Spalten ist es redundant.
 
Danke für die Antowort.
Nein, der Eintrag muss in der Tabelle stehen. Dort sind mehrere Zeiten erfasst. Und eine Spalte muss halt extra als UTC Datumsformat formatiert sein!

Die Zeiten werden "Willkürlich" erfasst und sind keine aktuellen Systemzeiten! Sonst könnte ich das mit der Funktion GetUTCDate() lösen

Also wenn ich jetzt sage, "14:00" eintragen (Meldungsende), muss als meldungsendeUTC "13:00" automatisch eingetragen werden.
Das muss dann per Trigger im SQL Server erledigt werden, da die Zeiteinträge per UPDATE in die Tabelle realisert werden

Screenshot: (OK, ist per ACCESS Datenbank erstellt worden :) )


upload_2021-3-24_16-30-31.png
 
Code:
edb=> create table ginga(meldung timestamptz);
CREATE TABLE
edb=*> insert into ginga values (now());
INSERT 0 1
edb=*> select meldung, meldung at time zone 'utc' from ginga ;
             meldung              |         timezone         
----------------------------------+---------------------------
 24-MAR-21 17:46:46.881806 +01:00 | 24-MAR-21 16:46:46.881806
(1 row)
edb=*> select meldung, meldung::timestamp at time zone 'utc', to_char(meldung, 'dd.mm.yyyy HH24:mm:ss') as zeit, to_char(meldung::timestamp at time zone 'utc','dd.mm.yyyy HH24:mm:ss') as zeit_utc from ginga ;
             meldung              |             timezone             |        zeit         |      zeit_utc       
----------------------------------+----------------------------------+---------------------+---------------------
 24-MAR-21 17:46:46.881806 +01:00 | 24-MAR-21 18:46:46.881806 +01:00 | 24.03.2021 17:03:46 | 24.03.2021 18:03:46
(1 row)

edb=*>

Du denkst jetzt noch mal drüber nach, ob Du Daten wirklich redundant speichern willst.
 
Danke für Deine Mühe!

Aber ich will ja da gar nichts selber per SELECT oder sonstiges machen. Das soll der SQL Server per TRIGGER selber erledigen.

Ablauf:
=====

Es erfolgt eine Aktualisierung per UPDATE Befehl in die Tabelle "tblMeldungen" in die Spalte "Meldungende" von eine SPS . Die Steuerung schreibt da irgendeine Uhrzeite (DateTime Format) rein.
nachdem die Spalte beschrieben wurde, soll der Trigger auslösen und die Spalte MeldungendeUTC den eben geschriebenen Wert nach UTC schreiben.

Da gibt es kein Select from... oder sonstiges....
Ich habe die Lösung schon per Systemzeit realisiert. Aber ich habe in der Spalte Meldungende eben NICHT immer die Systemzeit stehen, von daher muss das irgendwie anders laufen ?!
Standardmäßig als Feldwert habe ich =GetUTCDate() eingetragen. Dann macht er bei einem Update des Datensatzes das auch... Aber, wie gesagt, ich habe nicht immer die Systemzeit,
deshalb benötige ich da eine Funktion oder so etwas. Am besten würde sein GetUTCDate (tblMeldungen.Meldungende), dass geht natürlich nicht. Wäre auch zu einfach :-(
 
weil Du es bist ... :

Code:
edb=> create table ginga_trigger(meldung timestamptz, chst timestamptz, gmt timestamptz, kst timestamptz);
CREATE TABLE
edb=*> create or replace function trg_tz() returns trigger as $$begin new.chst = new.meldung at time zone 'Pacific/Guam'; new.gmt = new.meldung at time zone 'gmt'; new.kst = new.meldung at time zone 'kst'; return new; end; $$ language plpgsql;
CREATE FUNCTION
edb=*> create trigger trg1 before insert on ginga_trigger for each row execute procedure trg_tz();
CREATE TRIGGER
edb=*> insert into  ginga_trigger (meldung) values (now());
INSERT 0 1
edb=*> select * from ginga_trigger ;
             meldung              |               chst               |               gmt                |               kst               
----------------------------------+----------------------------------+----------------------------------+----------------------------------
 24-MAR-21 18:39:59.882106 +01:00 | 25-MAR-21 03:39:59.882106 +01:00 | 24-MAR-21 17:39:59.882106 +01:00 | 25-MAR-21 02:39:59.882106 +01:00
(1 row)

Es gibt übrigens 1216 verschiedene Zeitzonen-Namen ;-)
 
Ich unterstütze da die Ansagen von akretschmer. Redundanz ist das Stichwort, die gleiche Information an anderer Stelle. Das ist eine ziemlicg üble Fehlerquelle. Nicht in dem Moment, wo man sie erstellt, aber danach geht's los.
Nun vermute ich aufgrund Deiner Angaben, dass es sich um einen Einsatz im Produktionsumfeld handelt. Die Daten werden nicht von "tausend Seiten" abgefragt. "Kein Select" halte ich allerdings auch für eine Untertreibung. Irgendwer wird das abfragen.
Stichwort hier wäre "Interface" oder "View", als Vehicle zum Interface. Daten clean speichern und dann je nach Bedarf aufbereitet und sauber per View anbieten. Spart Platz und Ärger.
Ob das in Deinem Fall umsetzbar ist, kann ich von hier aus nicht beurteilen.

Und für Deinen Trigger oder was auch immer Du nehmen willst zur Transformation der Originaldaten noch ein Statement:
Code:
SELECT current_timestamp as Originalwert, current_timestamp AT TIME ZONE 'Central European Standard Time'  AT TIME ZONE 'UTC' as originalAsCESTtoUTC;
Das ist ein Beispiel. Welche Timezone bei Dir vorliegt (auf dem jeweiligen Server) musst Du herausfinden, notfalls dynamisch, falls es verschiedene Installationen betrifft. Ob Dein MS SQL Server das in der installierten Version versteht, musst Du auch herausfinden.
 
Werbung:
Hallo Zusammen,

Danke für Eure Tipps!!
Wir haben nun eine Lösung. Wir machen das in der Tat nun über eine VIEW im SQL Server. Die SPS führt diese aus und holt sich das Ergebniss, welches benötigt wird.
Dann wird die richtige Zeit eingetragen.

Und, über Sinn und Unsinn, darf man manchmal nicht nachdenken :) Aber ich weiß was ihr meint
 
Zurück
Oben