Office: (Office 2016) Uhzreit in Zahl umwandeln

Hi,
finde irgendwie nichts im Netz.

Ich will eine eindeutige ID Nummer erstellen aus dem heutigen Datum und der aktuellen Uhrzeit (am liebsten wär mir wenn das heutige Datum z.B. der 01.01.2018 und die Uhrzeit 14:00:00 Uhr ist folgende Zahl: 01012018140000).
Geht das irgendwie?
(Es muss eine Zahl sein kein Datumsformat)

:)

 

Zahlen haben keine führenden Nullen. Von der Länge Deiner Ziffernfolge her bekommst Du das auch nicht in Long unter, das hat einen Wertebereich bis etwa 2,14 Mrd., das sind angekratzte 10 Stellen statt der gewünschten 14.

Abbilden könnte man das als Text:
Code:

Wenn man auf eine ID-Funktionalität abzielt: Ein DateTime-Wert ist intern eine Zahl (Double) und benötigt weniger Byte zur Darstellung als Text, was dann nicht so unegal ist bei folgenden ID-Verwendungen.
Zahlenfähigkeit:
Code:

 

Hi,

wenn ichs dann so mache:
Code:

kommt Syntaxfehler

(Feld Zeit_Vergabe_Zahl = Double)

 

hat sich erledigt

Habe es so gelöst:
Code:

 

Hallo,
i ist ersatzlos überflüssig ?
Code:

 

Hallo
hast Du es schon mit
CDbl versucht ?
nur mit Zeit habe ich es noch nicht versucht aber mit einem Datum/Zeit:

CDbl(#12/1/2001#)  Ergiebt eine Zahl(Double)aus einem Datum --> 37226

umgekehrt: cdt(cdate(37226)) gibt --> 01.12.2001

CDbl(#31/12/9999 23:59:59#) ' Doublewert  2958465.99998843 grösster Wert für ein Datum
CDbl(#01/01/0100 0:0:0#) ' Doublewert  -657434 kleinster Wert für ein Datum


noch ein Muster:
Code:

?xxd(#31/12/9999 23:59:59#)
Daum--> 31.12.9999 23:59:59
2958465.99998843

 

\@firela112,
fragt sich wofür du das überhaupt brauchst.
Als Zahl macht nur Sinn: yyyymmddhhnnss.
Das geht relative einfach, aber wozu, wenn du mit der einfach Zahl zurecht kommst?

Ich wundere mich ja immer dass bei Access nicht ein zusätzliches sinnvolles Datumskonzept nachgereicht wird.
Aber bei den gewaltigen Entwicklungsschritten die bei Access in einem Jahrzehnt üblich sind, dauert das .....

 

Wie sollte dieses "sinnvolle Datumskonzept" denn deiner Meinung nach aussehen? Oder, anders gefragt, welche konkreten Probleme hast du mit der gegenwärtigen Implementierung von Datum/Uhrzeit in Access, die durch dein "sinnvolles Datumskonzept" behoben werden würden?

 

\@sonic,
Der Gleitkommatyp als Basis verschwendet den Speicherplatz ist konzeptbedingt langsamer und die berechneten Ergebnisse haben Rundungs-Ungenauigkeiten.

Ich wünsche mir zusätzlich eine UInt8 Variable als Basis.
Konzept wie datetime2 des SQL Server wie auch in .net.

 

Diese Schwächen der gegenwärtigen Implementierung sind meiner Meinung nach von ihren Auswirkungen her eher von untergeordneter Bedeutung. Nur um diese, eher trivialen, Probleme zu beheben, die Datum/Uhrzeit-Implementierung in Access zu ändern, wäre aus meiner Sicht kompletter Wahnsinn.

UInt8 meint üblicherweise einen Unsigned 8-Bit Integer, also ein Byte in VBA. Wie dieser als sinnvolle Basis für eine Date/Time-Implementierung dienen soll, ist mir im Moment unklar.

datetime2 ist mit meistens 6 Byte etwas platzsparender als die 8 Byte des Access/VBA-Date/Time-Typs und leidet (vermutlich!) nicht unter den Rundungsungenauigkeiten. Dies allein rechtfertigt nicht den Aufwand einer Ergänzung (oder gar Umstellung) der Date/Time-Implementierung in Access.

Die Date/Time-Implementierung in .Net ist aufgrund ihres großen Funktionsumfanges natürlich super cool. - Dieser Vorteil verschwindet aber in dem Moment, in dem du die Daten zwecks Speicherung serialisieren musst. In VBA ließe sich etwas vergleichbares sicherlich implementieren und wäre durchaus sinnvoll, nicht aber bei der Integration in Access/Jet-Abfragen. Es würden also dadurch also zwei verschiedene Herangehensweise für den Umgang mit Date/Time erforderlich. - Sehr schlechte Idee.

Fazit: Ich bin von deinem Alternativ-Konzept nicht überzeugt.

 

\@Sonc,
ich hab von eine Ergänzung gesprochen.
Ich meinte natürlich einen 8Byte Integer.
Der dann auch in 100 Nanosekunden Steps speichert.

Hier geht es ja nicht um ein durchdachtes Konzept.
Es macht auch keinen Sinn, sich da Gedanken zu machen.
Wenn man was besseres will, gibts ja eh jedem Menge Möglichkeiten.

Wie viel Aufwand das bedeutet interessiert mich nicht.
Sonst programmieren die ja auch jeden Menge Unsinn um nach kurzer Zeit ganze Konzepte wieder in den Müll zu kippen. Was soll das für ein Argument sein wenn es um eine ergänzende Klasse geht?

Ich weiß nur das Berechnungen Rundungsfehler haben und der Double Wert aus Basis ein ungünstiges Konzept darstellt.

Da frage ich mich natürlich, welche Entwicklungsumgebung/Datenbank noch ausschließlich mit einem Gleitkommawert als Bais für DateTime arbeitet.

LG M

 

\@Markus,

mir sind bei der normalen Verwendung von Date-Variablen noch keine dargestellten Ungenauigkeiten aufgefallen. Selbst die IAU verwendet in ihrer Sofa-Library Double-Variablen (nur halt mit anderer Epoche), um Tagesanteile zu erfassen. Und auch FreePascal sowie Delphi setzen Double-Variablen mit der gleichen Epoche wie der COM-Standard ein, um selbst noch tausendstel Sekunden exakt auszugeben.

Was die Entwicklungsgeschwindigkeit der Database-Engine angeht, bin ich der gleichen Meinung wie Du. Man wird uns noch 10x in den nächsten 20-25 Jahren diesen alten Hut fast unverändert verkaufen; dafür sind dann die Bedienoberflächen jedoch unterschiedlich (bunt) gestaltet - Hauptsache, immer schön modern bleiben! *Smilie

 

Wenn es dir nicht um Luftschlösser, sondern um konkrete Verbesserungsvorschläge geht, ist der Aufwand ein elementarer Faktor.

Wir als Access Community haben heute über Access UserVoice mehr Einflussmöglichkeit auf die Weiterentwicklung von Access als jemals zuvor. Und dies nicht per se weil es diese Plattform gibt, sondern weil das Access-Team dort tatsächlich mitliest und dortige Vorschläge ernsthaft in Erwägung zieht.

Das Access-Team ist der Access-Community gegenüber wesentlich aufgeschlossener als je zuvor. Es ist aber zur Zeit auch ein sehr kleines Team und größere Projekte, wie z.B. das Access-Web-App-Debakel, stehen komplett außer Frage. Kleinere Weiterentwicklungen, die für eine signifikante Anzahl von Usern hilfreich sind, sind aber durchaus im Bereich des Möglichen.

 

Hallo zusammen!

Kann ich bestätigen. Hab mal sehr viel mit Kalenderdaten und Uhrzeiten experimentiert
und selbst bei den eingebauten Funktionen wie DateAdd Ungereimtheiten festgestellt.
Leider finde ich die DB auf die Schnelle nicht, doch ein kleines Beispiel ist schnell gestrickt:
Code:

Fazit: Vor allem bei Vergleichen mit berechneten Datumswerten ist Vorsicht geboten.

 

\@Marsu,

Zeitangaben sollte man für den exakten Vergleich normalisieren oder ein Epsilon verwenden. Code: