Beim erstellen einer Tabelle Datum schreiben
Hallo,
Ich hab da ein Problem und vielleicht kann mir da einer Helfen.
Ich erstelle mit einem PHP Formular in einer mssql DB eine Tabelle.
Und beim erstellen sollte gleich das Datum und Uhrzeit mit eingetragen werden.
Wie macht man das?
Die Tabelle erstelle ich so:
Die Spalte
sollte gleich das aktuelle Datum und Uhrzeit haben.
Danke.
Ich hab da ein Problem und vielleicht kann mir da einer Helfen.
Ich erstelle mit einem PHP Formular in einer mssql DB eine Tabelle.
Und beim erstellen sollte gleich das Datum und Uhrzeit mit eingetragen werden.
Wie macht man das?
Die Tabelle erstelle ich so:
$sql="CREATE TABLE Ergebnisse
(Schluessel INTEGER IDENTITY (1,1) NOT NULL,
aktion nvarchar(255) NULL,
timestamp timestamp NULL,
PRIMARY KEY (Schluessel)
)";
mssql_query($sql);
timestamp timestamp NULL,
sollte gleich das aktuelle Datum und Uhrzeit haben.
Danke.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 175285
Url: https://administrator.de/forum/beim-erstellen-einer-tabelle-datum-schreiben-175285.html
Ausgedruckt am: 07.04.2025 um 20:04 Uhr
12 Kommentare
Neuester Kommentar
Ich verstehe deine Frage nicht ganz:
Du stellst eine Tabell mit folgendem Aufbau her: Schluessel | aktion | timestamp
Wo willst du da das aktuelle Datum haben? Du hast ja noch keinen Datensatz drin. Falls du einen Defaultwert setzen möchtest, dann häng an die timestamp Zeile einfach DEFAULT CURRENT_TIMESTAMP oder DEFAULT NOW() dran. Welches von beiden weiß ich grad aus dem Kopf nicht und meine Testumgebung ist im Büro.
LG.
Du stellst eine Tabell mit folgendem Aufbau her: Schluessel | aktion | timestamp
Wo willst du da das aktuelle Datum haben? Du hast ja noch keinen Datensatz drin. Falls du einen Defaultwert setzen möchtest, dann häng an die timestamp Zeile einfach DEFAULT CURRENT_TIMESTAMP oder DEFAULT NOW() dran. Welches von beiden weiß ich grad aus dem Kopf nicht und meine Testumgebung ist im Büro.
LG.
`timestamp` TIMESTAMP DEFAULT CURRENT_TIMESTAMP /* ggf noch: ON UPDATE CURRENT_TIMESTAMP */
Moin helmuthelmut2000,
ergänzend zu den Vorkommentaren, insbesondere zu nxclass', noch die Anmerkung:
Grüße
Biber
ergänzend zu den Vorkommentaren, insbesondere zu nxclass', noch die Anmerkung:
- ein timestamp-Feld in einer Tabelle timestamp zu nennen -> in mehrfacher Hinsicht suboptimal
- nenn es "AngelegtAm", wenn du den Anlage-Timestamp mitschleppen willst
- nenn es "AktualisiertAm", wenn du den Zuletzt-Geändert-Timestamp mitschleppen willst (und dann inkl. der ON UPDATE-Clause oben)
- lege zwei Felder an, wenn du "AngelegtAm" und "AktualisiertAm"-Timestamps mitschleppen willst
Grüße
Biber
Hm...
Ich hatte heute morgen schon etwas dazu gesucht, es dann aber doch noch nicht Posten wollen (05:35Uhr und vom Handy aus).
Es geht hier doch um MSSQL und nicht um MySQL, sollte das nicht ein Unterschied sein ?
Zum Problem steht im MSDN:
RTFM
Da sollte man halt zuerst nachschauen
~Arano
Ich hatte heute morgen schon etwas dazu gesucht, es dann aber doch noch nicht Posten wollen (05:35Uhr und vom Handy aus).
Es geht hier doch um MSSQL und nicht um MySQL, sollte das nicht ein Unterschied sein ?
Zum Problem steht im MSDN:
Quelle: MSDN - CREATE TABLE (Transact-SQL)
DEFAULT
Gibt den Wert an, der für die Spalte bereitgestellt wird, wenn kein Wert explizit angegeben wurde. DEFAULT-Definitionen können auf alle Spalten angewendet werden, mit Ausnahme der als timestamp definierten Spalten sowie von Spalten mit der IDENTITY-Eigenschaft.
[...]
DEFAULT
Gibt den Wert an, der für die Spalte bereitgestellt wird, wenn kein Wert explizit angegeben wurde. DEFAULT-Definitionen können auf alle Spalten angewendet werden, mit Ausnahme der als timestamp definierten Spalten sowie von Spalten mit der IDENTITY-Eigenschaft.
[...]
RTFM
Da sollte man halt zuerst nachschauen
~Arano
Moin Helmuthelmut,
ergänzend zu Arano:
ich hatte auch überlesen, das jemand dir eine MSSQL-Datenbank angedreht hat.
Die Redmonder haben in der Tat einen Datentyp "timestamp" angelegt, um DAUs wie uns zu leimen.
Dieser Typ "timestamp" ist nur ein Synonym für den Binär-Typ "RowVersion", hatten wir neulich schon mal hier.
--> Also defintiv: nimm Typ "datetime" für deine Zwecke.
Und nein, es wird definitiv nicht NULL sein, wenn Datensätze eingefügt werden.
Grüße
Biber
ergänzend zu Arano:
ich hatte auch überlesen, das jemand dir eine MSSQL-Datenbank angedreht hat.
Die Redmonder haben in der Tat einen Datentyp "timestamp" angelegt, um DAUs wie uns zu leimen.
Dieser Typ "timestamp" ist nur ein Synonym für den Binär-Typ "RowVersion", hatten wir neulich schon mal hier.
--> Also defintiv: nimm Typ "datetime" für deine Zwecke.
Und nein, es wird definitiv nicht NULL sein, wenn Datensätze eingefügt werden.
Grüße
Biber
Moin helmuthelmut2000,
Ja nee...is' klar.
Da geb ich dir recht - wenn es SO ausufert, dann ist es offensichtlich nicht der richtige Weg.
Ich kenn mich ja auch mit Datenbankkrams nicht so aus, aber mit laienhaftem Halbwissen würde ich behaupten
Ist aber -wiederum in dieser Galaxie - alles schon mehrfach erfunden worden, möchte ich daher ungern nochmal ganz neu erfinden,
Aber eine Suche nach "Trigger on update examples" sollte schon Treffer liefern.
Ich arbeite gern und viel mit Oracle und DB2-Datenbankblechen, gelegentlich auch mit mySQL - bei allen drei System kann ich nachvollziehen, was wohl so die treibenden Gedanken bei der Entwicklung der jeweiligen Architektur, des Designs, der Implementierung gewesen sein könnten.
Ich verstehe (oder glaube zu verstehen), was die Intention, die Philosophie, der Charme der jeweiligen Variante ist.
Und ich kann stellenweise den Spass der Coder bei der einen oder anderen Sonderlocke nachvollziehen - speziell dem ständigen Wettlauf um innovative Features und güldene Knöpfchen zwischen IBMs DB2 und Oracle könnte ich noch weitere Jahrzehnte lang amüsiert und interessiert zusehen.
MSSQL dagegen ist zwar benutzbar, bedienbar und durchaus robust.
Aber hat den Charme eines VW Polo oder eines Opel Kadett Baujahr 1986 in der Ausführungsvariante ohne Radio, ohne Uhr im Armaturenbrett und Seitenspiegel nur gegen Aufpreis.
Nichts für Vergnügungstouren - aber wenn du damit nur täglich zur Arbeit fahren musst und wieder zurück - dafür mag es reichen.
Hoffe, das Beispiel war verständlich.
Grüße zurück
Biber
Zitat von @helmuthelmut2000:
Mal noch ne Frage.
Ich mach das so um einen Verlauf von einer anderen Tabelle zum Darstellen.
Das heist.
Ich habe eine Tabelle und da sind Einträge, und zu jedem Eintrag mach ich jetzt noch eine Tabelle und dort
schreibe ich dann rein was sich wann verändert hat. Das gibt dann aber sehr viele Tabellen.
Gibt es da eine andere Möglichkeit?
Mal noch ne Frage.
Ich mach das so um einen Verlauf von einer anderen Tabelle zum Darstellen.
Das heist.
Ich habe eine Tabelle und da sind Einträge, und zu jedem Eintrag mach ich jetzt noch eine Tabelle und dort
schreibe ich dann rein was sich wann verändert hat. Das gibt dann aber sehr viele Tabellen.
Gibt es da eine andere Möglichkeit?
Ja nee...is' klar.
Da geb ich dir recht - wenn es SO ausufert, dann ist es offensichtlich nicht der richtige Weg.
Ich kenn mich ja auch mit Datenbankkrams nicht so aus, aber mit laienhaftem Halbwissen würde ich behaupten
- definitiv sind keine "ErstelltAm"/"GeändertAm"-Felder in ZUSÄTZLICHEN Tabellen nötig.
- ein "ErstelltAm"-Feld in einer Tabelle kannst du in jeder ver###ten Datenbank dieser Galaxie über einen Defaultwert setzen - auch in MSSQL
- ein "GeändertAm"-Feld in einer Tabelle kannst du fast in jeder Datenbank dieser Galaxie nur via eigene Programmlogik neu setzen oder aber über einen Trigger.
Ist aber -wiederum in dieser Galaxie - alles schon mehrfach erfunden worden, möchte ich daher ungern nochmal ganz neu erfinden,
Aber eine Suche nach "Trigger on update examples" sollte schon Treffer liefern.
Noch was.
Warum schreibst Du man hat mir eine MSSQL-Datenbank angedreht.
Ist die nicht gut?
Na ja... sagen wir so: etwas bieder kommt die schon daher.Warum schreibst Du man hat mir eine MSSQL-Datenbank angedreht.
Ist die nicht gut?
Ich arbeite gern und viel mit Oracle und DB2-Datenbankblechen, gelegentlich auch mit mySQL - bei allen drei System kann ich nachvollziehen, was wohl so die treibenden Gedanken bei der Entwicklung der jeweiligen Architektur, des Designs, der Implementierung gewesen sein könnten.
Ich verstehe (oder glaube zu verstehen), was die Intention, die Philosophie, der Charme der jeweiligen Variante ist.
Und ich kann stellenweise den Spass der Coder bei der einen oder anderen Sonderlocke nachvollziehen - speziell dem ständigen Wettlauf um innovative Features und güldene Knöpfchen zwischen IBMs DB2 und Oracle könnte ich noch weitere Jahrzehnte lang amüsiert und interessiert zusehen.
MSSQL dagegen ist zwar benutzbar, bedienbar und durchaus robust.
Aber hat den Charme eines VW Polo oder eines Opel Kadett Baujahr 1986 in der Ausführungsvariante ohne Radio, ohne Uhr im Armaturenbrett und Seitenspiegel nur gegen Aufpreis.
Nichts für Vergnügungstouren - aber wenn du damit nur täglich zur Arbeit fahren musst und wieder zurück - dafür mag es reichen.
Hoffe, das Beispiel war verständlich.
Gruß
Helmut
Helmut
Grüße zurück
Biber