Primary Key ANALYSE

[robroy85]

Hallo Community!

Ich habe eine Warenwirtschaft auf MS SQL 7.0 Basis
Ich möchte gerne wissen wie der Primary Key von der Warenwirtschaft erstellt wird!?!?
Dazu habe ich einfach mal ein paar Kundeneinträge hintereinander geschrieben und siehe da:
1. Die IDs sind fortlaufend (wer hätte es gedacht) :-D
2. wenn man die 10stellige ID als Hexadezimalzahl sieht und umwandelt kommt nur Müll heraus(Sonderzeichen)
3. Es scheint mir als wärs eine zeitlich abhängige Funktion, denn wenn ich mir zwischen zwei Kundeneinträgen Zeit gelassen hab, so ist auch die Differenz ziwschen den jeweiligen IDs größer! :gruebel:

Kann mir jemand helfen, den Aufbau bzw die "Herstellung" weiter zu analysieren?
Im SQL Server Enterprise Manager steht folgendes zur ID:
Name: Kundenid, Typ: varchar, Größe 10 und natürlich NULL nicht erlaubt!

schönen gruß, robert

Hier die Beispielliste von Einträgen
kundenid Kundennumm
---------- --------------------
434f7a9209 010001
434f7a97de 010002
434f7aa14b 010003
434f7aa542 010004
434f7aa76b 010005
434f7aaad4 010006
434f7aacaf 010007
434f7aae22 010008
434f7ab40f 010009
434f7b0f86 010010
434f7b1113 010011
434f7b1348 010012
434f7b14a9 010013
434f7b15a9 010014
434f7b165b 010015
434f7b175b 010016
434f7b180d 010017
434f7b19ee 010018
434f7b1b71 010019
434f7b1c42 010020
434f7b41a5 010021
434f80a238 010022
434f80d213 010023

[robroy85]

Ich hab mal einige Einträge von Hexadezimal in Dezimal gewandelt.

So wird aus: 43 4f 6e dd d4 => 67 79 110 221 212
und aus: 43 4f 7a ac af => 67 79 122 172 175

Könnte das auf einem Timestamp basieren?

ich habe mal scherzeshalber meine Systemzeit auf den 14.10.1985 gestellt und siehe da der Eintrag hat folgende ID bekommen:

1d b0 fd 3d 71 also dezimal: 29 176 253 61 113

:gruebel: :gruebel: :gruebel:
HAt jemand einen Ansatz/ eine weitere Idee für mich?

[marabu]

Die ersten 4 Byte erhältst du so:

Delphi-Quellcode:

uses
  DateUtils;
begin
  ShowMessage(IntToHex(DateTimeToUnix(Now), 8);
end;

Die letzten beiden Bytes werden Bruchteile von Sekunden sein.

Grüße vom marabu

[Flocke]

Wenn du das letzte Byte weglässt, dann könnte es von der Differenz her ein Unix-Timestamp sein (also Sekunden seit 1.1.1970 GMT).

($434f6eddd4 - $1db0fd3d71) / (20 * 365,2425 * 86400) ~= 256
(Differenz durch Anzahl Sekunden in 20 Jahren)

Vielleicht ist das letzte Byte 1/256 Sekunden zusätzlich?

//EDIT: Mist, zu spät...

[robroy85]

OK, mittlerweile habe ich dann auch herausgefunden, dass man Hexadezimalzahlen nicht Byte für Byte einzeln umrechnen kann :lol: :lol:

ALso ich habe gleichzeitig einen neuen Eintrag über die Warenwirtschaft gestartet und einen Mausklick später die von marabu angegebene Funktion IntToHex(DateTimeToUnix(Now), 8) aufgerufen und siehe da: DIFFERENZEN :-D

Im Dezimalsystem gerechnet, haben sie eine Differenz von exakt 7200 Sekunden, also 2 Stunden. :wiejetzt:
Die Programmierer werden sich schon was dabei gedacht haben :wall:

Naja, ich bedanke mich für die Hilfe!
Meine Fragen diesbezüglich wären dann erstmal geklärt!


____________________________________
PS: Toll diese Smileys

[marabu]

Eine Stunde wegen dalight savings time und eine wegen Greenwich...

marabu

[robroy85]

Dann hab ich doch nochmal ne Frage:
Rechnet mein PC mit der Greenwich-Zeit und zeigt mir dann nur das +01:00 im Winter (und das +02:00 im Sommer) in der Uhrzeit an?

[marabu]

Im PSDK steht zum Thema Windows System Information / System Time folgendes:

The system bases system time on coordinated universal time (UTC). UTC-based time is loosely defined as the current date and time of day in Greenwich, England.

Das sollte alle Klarheiten beseitigen...

marabu