MS SQL-Abfrage mit Zeitstempel-/Datumszeit-/DatumsdatenHallo zusammen,
Wir möchten eine Datentabelle in einer Datenbank speichern und später die Datenbank abfragen (mit MS SQL), um die Tabelle abzurufen. Da es bei der Übertragung des Zeitstempels in die Datenbank zu Problemen kam, haben wir einen Workaround eingerichtet. Erstens verfügt die Tabelle in JMP über eine „Datums“-Spalte mit dem Namen „SecondsSince1904“, in der die Datums- und Uhrzeitangabe als verstrichene Sekunden seit der Epoche 1904 (01.01.1904 00:00:00) gespeichert wird. Diese Spalte ist als „Fixed Dec (30,0)“ formatiert. Um die Datentabelle in die Datenbank zu übertragen, verwenden wir das folgende Skript:
Names Default To Here(1);
dt = Current Data Table();
// This will delete the table "yourTable" in the database. BE CAREFUL!!!
Open Database(
"yourDSNconnectionString",
"DROP TABLE dbo.yourTable"
);
// This will upload the table "dt = Current Data Table" to the database, where it will be saved as "yourTable".
dt << Save Database("yourDSNconnectionString",
"dbo.yourTable"
);
// After saving the table to the database, we find the column "SecondsSince1904" formatted as FLOAT.
// Now we want to manipulate the table "yourTable" and add a computed column named "timestamp", where we will display the correct timestamp,
// i. e. something like "2015-09-26 00:00:02.000".
// We do this by calculating the correct timestamp from the column "SecondsSince1904". We also add an additional column named "SecondsAfterMidnight" just for fun.
dbc = Create Database Connection(
"yourDSNconnectionString"
);
Execute SQL(dbc,
"
ALTER TABLE dbo.yourTable ADD timestamp AS
DATEADD(ss, (CAST(yourTable.SecondsSince1904 AS BIGINT)%86400),
DATEADD(dd, (CAST(yourTable.SecondsSince1904 AS BIGINT)/86400), '1904-01-01' ) );
ALTER TABLE dbo.yourTable ADD SecondsAfterMidnight AS
(CAST(yourTable.SecondsSince1904 AS BIGINT)%86400)
"
);
Close Database Connection(dbc);
So weit, ist es gut. Bis hierhin kein Problem. Die „SecondsAfter1904“ werden korrekt in die Datenbank übertragen und auch der Zeitstempel wird korrekt berechnet. Schauen Sie in der Datenbank nach:

Jetzt fragen wir die Datenbank ab und rufen die Tabelle zurück in JMP ab, indem wir zu Datei > Datenbank > Tabelle öffnen gehen. Und das ist der Punkt, an dem die Dinge durcheinander geraten. Schauen Sie in JMP nach:

Der Zeitstempel ist beschädigt. Es ist ein Fehler aufgetreten. Vielleicht ein Bitshift oder so etwas. Um Schlussfolgerungen zu ziehen, habe ich SecondsSince1904 „bitweise“ erhöht.
Weiß jemand, was hier passiert ist? Ist das ein Fehler? Jede Hilfe wird geschätzt.
Prost,
Sieger
Betreff: MS SQL-Abfrage mit Zeitstempel-/Datumszeit-/Datumsdaten<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />Vielen Dank, msharp. Ich werde Ihren Vorschlag mit dem Befehl TRUNCATE und INSERT INTO in eine vorhandene Tabelle ausprobieren. Allerdings weiß ich derzeit nicht, wie ich richtig angeben kann, aus welcher Datentabelle in JMP die Daten entnommen werden sollen. Vielleicht Ihr hilfreicher Beitrag in dieser Thread wird mich zu einer Lösung führen ...
Allerdings konnte ich das ursprüngliche Problem lösen, indem ich datetime2(0) in der Datenbank verwendete, wie ich unten beschrieben habe.
Betreff: MS SQL-Abfrage mit Zeitstempel-/Datumszeit-/DatumsdatenLetztendlich stellte sich heraus, dass beim Starten einer Abfrage ein Konvertierungsproblem in der Datenbank vorliegen musste. Ich versuche das zu erklären:
Nehmen wir an, dass einige Zeitstempel im Format „datetime“ in einer Datenbank gespeichert sind. Wenn ich dann eine Abfrage durchführe, werden die Zeitstempel bei der Übertragung fehlerhaft, wie im Beispiel oben. Das Gleiche passiert, wenn die Zeitstempel im Format „datetime2“ gespeichert werden, das standardmäßig „datetime2(7)“ ist.
Wenn ich jedoch eine Spalte in der Datenbank von, sagen wir, „datetime2(7)“ in „smalldatetime“ umwandele, Ich bekomme den gleichen Fehler. Daher vermute ich, dass das Problem nicht in JMP, sondern in der Datenbank liegt. Ich denke, dass JMP vor dem Herunterladen einen CAST- oder CONVERT-Befehl an die Spalte mit den Zeitstempeln sendet. Und ich vermute, dass dies der Moment ist, in dem das Problem auftritt.
Um dieses Problem zu lösen, ist es möglich, die Spalte mit den Zeitstempeln in „ datetime2(0) " Format. Dies ist das Format, das JMP richtig liest.
Hier ist der vollständige Code:
Names Default To Here(1);
dt = Current Data Table();
dt << Save Database("yourDSNconnectionString",
"dbo.yourTable"
);
dbc = Create Database Connection(
"yourDSNconnectionString"
);
Execute SQL(dbc, // Here we calculate the correct timestamp/date from the Macintosh or JMP epoche (01.01.1904 00:00:00)
"
ALTER TABLE dbo.yourTable ADD timestamp AS
DATEADD(ss, (CAST(yourTable.SecondsSince1904 AS BIGINT)%86400),
DATEADD(dd, (CAST(yourTable.SecondsSince1904 AS BIGINT)/86400), '1904-01-01 00:00:00' ) );
"
);
Execute SQL(dbc,
"
ALTER TABLE dbo.yourTable ADD Date datetime2(0);
"
);
Execute SQL(dbc,
"
UPDATE dbo.yourTable
SET Date = CONVERT(datetime2(0), timestamp);
"
);
Execute SQL(dbc,
"
ALTER TABLE dbo.yourTable DROP COLUMN timestamp, SecondsSince1904
"
);
Close Database Connection(dbc);
Vielleicht ist das für jemanden hilfreich
Betreff: MS SQL-Abfrage mit Zeitstempel-/Datumszeit-/DatumsdatenDu verstehst es nicht.Speichern Sie das Datum in der Datenbank als DateTime-Format.PMroz schlägt vor, alles in Datumszeichenfolgen zu konvertieren, bevor es an eine andere Plattform gesendet wird.Dies ist ein praktischer Tipp, wenn Sie sich mit verschiedenen Epochen befassen.
Sie haben Probleme beim Übergang von JMP zu SQL Server, weil Sie die Datentabelle löschen.Sie sollten es einfach mit „TRUNCATE TABLE Tabellenname“ löschen.In JMP gibt es keine Datums-/Uhrzeitspalte, es handelt sich lediglich um numerische Spalten, die als Datum/Uhrzeit formatiert sind.Wenn Sie also << Datenbank speichern verwenden, erstellt JMP einfach eine numerische Spalte, da es die Zeit nicht berücksichtigt.Wenn Sie jedoch bereits über eine SQL-Tabelle mit einer als Datum/Uhrzeit formatierten Spalte verfügen und diese einfügen, sollte alles in Ordnung sein.
Betreff: MS SQL-Abfrage mit Zeitstempel-/Datumszeit-/DatumsdatenObwohl es sich um eine Vermutung handelt, denke ich, dass Sie Recht haben. Es kommt mir wirklich so vor, als ob jede Sekunde 1000 Sekunden hinzufügt. Außerdem erfolgt das Zurücksetzen irgendwo zwischen 23 und 123 Sekunden. Ich könnte mir vorstellen, dass das Problem darin besteht, dass das Datum/Uhrzeit-Format in SQL Milli-, Mikro- und Nanosekunden enthält (TT.MM.JJJJ hh:mm:ss.mmmmmmn). Um die Spekulation fortzusetzen, könnte es sein, dass JMP beim Import aus der Datenbank in JMP davon ausgeht, dass 1000 Millisekunden 1000 Sekunden statt 1 Sekunde sind.
Ich habe mit ein paar Formaten und Stilen experimentiert, konnte JMP aber nicht beibringen, wie man die Tabelle korrekt aus der Datenbank importiert. Hier ist mein neuester Code, der sicherstellt, dass das Zeitstempelformat in der Datenbank mit dem in JMP übereinstimmt. Das Format heißt „smalldatetime“ und sieht aus wie „dd.mm.yyyy hh:mm:ss“.
...
SQL ausführen(dbc,
"
ALTER TABLE dbo.berstTry01 Zeitstempel hinzufügen AS
DATEADD(ss, (CAST(berstTry01.SecondsSince1904 AS BIGINT)%86400), CAST(
DATEADD(dd, (CAST(berstTry01.SecondsSince1904 AS BIGINT)/86400), '1904-01-01 00:00:00' ) AS smalldatetime) );
ALTER TABLE dbo.berstTry01 ADD SecondsAfterMidnight AS
(CAST(berstTry01.SecondsSince1904 AS BIGINT)%86400);
"
);
...
Leider hat auch das nicht funktioniert. Und im Moment habe ich keine Ahnung mehr, was ich tun soll, damit es funktioniert
Die in der Datenbank angewendete Formel interagiert tatsächlich überhaupt nicht mit JMP. Und die Rechnung stimmt offensichtlich, wie man dem ersten Bild entnehmen kann. Was passiert, ist, dass ein INTEGER in die Datenbank übertragen wird und die Werte des INTEGER zufällig die seit der „JMP-Epoche“ verstrichenen Sekunden sind (Sekunden seit 1904).
Wenn ich Ihr Beispiel ausführe, erhalte ich das richtige Datum, aber eine falsche Uhrzeit (18:07:17 statt 14:14:14) ...
Je mehr ich dieses Problem untersuche, desto mehr habe ich das Gefühl, dass es sich tatsächlich um einen Fehler handelt. Ich verwende JMP 12.2.0.
Betreff: MS SQL-Abfrage mit Zeitstempel-/Datumszeit-/DatumsdatenNun, es war eine der Optionen, die ich in Betracht gezogen habe, es so zu machen, wie Sie es vorgeschlagen haben (die Daten in der Datenbank als Zeichenfolge zu speichern). Aber ich dachte, es wäre praktisch, die Daten in der Datenbank im Datum-Uhrzeit-Format zu speichern. Wenn ich jedoch die JMP-Tabelle in der Datenbank speichere, werden die Daten als Zeichenfolge im Zeichenformat gespeichert. Ich muss also nicht von datetime in char konvertieren und weiß nicht, warum die Daten nicht standardmäßig im datetime-Format in der Datenbank gespeichert werden. Deshalb habe ich das obige Skript geschrieben ...
Ich schätze, dass ich am Ende auch bei Ihrer Lösung landen werde, nämlich die Daten in der Datenbank als in char formatierte Zeichenfolgen zu haben. Aber das ist für mich ein wenig enttäuschend.
Betreff: MS SQL-Abfrage mit Zeitstempel-/Datumszeit-/DatumsdatenDas ist eine Vermutung, aber es sieht so aus, als ob jede Sekunde 1000 Sekunden hinzufügt.Nach 86,4 Sekunden wird es dann auf 0 zurückgesetzt.Es scheint ein Problem mit der Art und Weise zu geben, wie die Formel beim Ziehen mit JMP interagiert.
Verwenden Sie die JMP-Epoche, wenn Sie in SQL einfügen?SQL ist 1-1-1900. Dies könnte der Grund dafür sein, dass Sie beim korrekten Einfügen in SQL Probleme haben.
diff = Num ( „1.1.1904“ ) - Num ( „1.1.1900“ );
Zeit = ( Num ( „14.07.1914 14:14:14“ ) + diff)/ 86400 ;
//In SQL
db = Datenbankverbindung erstellen ( „DRIVER=SQL SERVER;SERVER=BLAH\SQLEXPRESS;Database=Test_DB“ );
SQL ausführen (db,
„SELECT CAST(“ || verkohlen (Zeit)|| „AS DATETIME) AS ‚Zeitstempel‘“
);
Datenbankverbindung schließen (db);
Das gibt für mich den richtigen Wert zurück.
Betreff: MS SQL-Abfrage mit Zeitstempel-/Datumszeit-/DatumsdatenIch gehe beim Lesen aus einer Datenbank etwas anders mit Datumsangaben/Datumszeiten um.Ich konvertiere sie in eine Zeichenfolge und konvertiere sie dann, sobald ich in JMP bin, zurück in Datum oder Datum/Uhrzeit.So weiß ich, dass es richtig sein wird.Ich benutze to_char in Oracle.Ich sehe, dass SQL Server verwendet KONVERTIEREN oder GIESSEN etwas Ähnliches tun.Ich habe Funktionen in JMP, die meine String-Datumsangaben in JMP-Datumsangaben umwandeln.
In die andere Richtung (JMP zu SQL Server) Ich bin mir nicht sicher, warum Sie dieses Problem haben.Ist das Standarddatumsformat in SQL Server eine Untersuchung wert?