Inoffizielles deutsches Xbase-Forum

Hi Folks,

hat jemand Erfahrung mit dem Einsatz von UUIds unter Clipper im Verbund mit XBase? Seek-Tests unter Clipper mit mehreren Millionen Datensätzen deren Key mit UUIdCreate() erstelllt wurde, sind problemlos gelaufen. Ist deren Einsatz somit problemlos möglich?

Eine UUID ist nichts weiter als irgendein String. Welche Probleme sollte das ergeben? Da die UUID immer gleich lang ist, haben EXACT und SOFTSEEK und andere auch keinen negativen Einfluss.

Code: Alles auswählen

? UuidToChar(UuidCreate()) // z.B.  5b741013-cb04-4137-927c-a29d2ee7b29c

Hallo Tom,

kann bei bei seiner Berechnung kein Char(0) oder sonst ein kritisches Zeichen gebildet werden?

Klaus,
nein - das kommt im Hexadezimalen als Zeichen nicht vor. Nur die 16 Zeichen 0-9 und a-f

Viele Grüße,
Martin

... und der "-" als Trenner zur Gliederung der Blöcke.

Jan

das ist so wenn ich die UUID mit UuidToChar() umwandle. Als Key verwende ich aber den 16stelligen Wert von UuidCreate() direkt, und der sieht zimmlich wild aus.

Jan,
das ist sicherlich nur Repräsentation (wie bei picture).
Klaus,
ich gehe mal davon aus, dass das bei Deiner Anzeige dann immer als ASCII-Code interpretiert wird:
5b741013-cb04-4137-927c-a29d2ee7b29c
chr( 91 ) + chr( 116 ) + chr( 16 ) + chr( 19 ) + ...
Da kann dann schon mal was komisches angezeigt werden. Darum solltest Du die auch immer als Hexcode ablegen. Das ist in jeder Welt identisch (ASCII, ANSI, EBCDIC,...)

Viele Grüße,
Martin

Danke schon mal.

@Martin: Alaska schreibt in der Hilfe, dass die UUId direkt als Key verwandt werden kann. Da stehts nicht von Konvertierung. Wenn ich mir die Tabelle mit dem DBF Viewer 2000 ansehen, sehe ich folgendes Bild
Nicht vertrauenserweckend.

Weil UUIDCreate() verdammte Binärdaten liefert. Schau doch einfach mal in die Hilfe, Klaus. Da bekommst Du diverse Probleme. Deshalb gibt es ja UUIDToChar().

Was findest Du in Hilfe, was ich nicht finde?

The function UUIDCreate() returns a binary character string.

Einfach UUIDToChar() drauf und fertig. Dafür ist die Funktion da. Binärdaten in DBFs sind keine gute Idee.

Danke Tom. Es steht aber auch

With the function UuidCreate() an Universally Unique IDentifier can be created. This identifier can be used as primary key in a database

Aber nicht in "any database". Dafür gibt's UUIDToChar, damit das z.B. auch in DBFs funktioniert. Und damit man die UUIDs auch irgendwie lesen kann und so. Davon abgesehen stimmt die Aussage ja auch, nur eben nicht direkt und nicht in allen Fällen. Die DBFDBE nimmt Konvertierungen vor, und DBFs sind für Binärdaten einfach nicht geeignet. Blobs in Fox können das, und entsprechende SQL-Datentypen sowieso. Aber DBF nicht.

hallo Klaus,
bitte aber nur direkt als Primary Key verwenden, wenn das zugrundeliegende Datenbanksystem dies als nativen Datentyp anbietet (wie zB ADS). Ansonsten _immer_ nach Char wandeln. Wie willst Du denn einen Seek auf Binärdaten sauber durchführen?

ich bin ganz bei euch; darum ja auch die Anfrage hier im Forum. Was mich überraschte war, das der oben erwähnte Test mit mehreren Millionen Datensätzen keine Probleme erbrachte. Da es mich interessiert, werden ich die Frage einmal an den Support richten. Vielleicht haben die eine Antwort.

Ich denke, solange man den Kontext nicht verlässt, könnte das sogar mit den Binärdaten funktionieren. Also wenn es nur innerhalb einer Anwendung geschieht (die gute alte "Crypt()"-Funktion hat ja ähnliche Ergebnisse geliefert). Aber ich würde zwecks Les- und Nachvollziehbarkeit immer die ToChar-Variante verwenden (Was heißt "würde" - das mache ich ja so). Und es könnte sein, dass das beim Umkopieren von Tabellen problematisch wird.

Ah, ja, guter Einwand. Meine Hoffnung ist, mit der binären Version Zeit beim Suchen im Index zu sparen. Aber vielleicht spielt es dabei keine nennenswerte Rolle welcher Typ (binär oder character) eingetragen ist. Mal sehen, was der Support dazu schreibt.

Da es keine binären Felder gibt, findet doch ohnehin eine stringbasierte Suche statt, Klaus. Wo Du aufs Jahr ein paar Nanosekunden einsparen kannst, das ist beim Weglassen von UUIDToChar() beim einmaligen Erzeugen und Speichern der UUID. Ansonsten erzeugst Du dadurch, dass Du Binärstrings speicherst und weit aus dem ASCII-7-Zeichensatz raus bist, eigentlich jetzt noch Konvertierungsoverhead.

Ja, Tom, das befürchte ich auch. Zwischenzeitlich liegt die Antwort des Supports vor. Die Kernaussage:

Bezüglich der Verwendung von UUIDs als Schlüsselwerte in DBF-Tabellen gibt es technisch gesehen keine Einwände

bestätigt meinen Test.

Der Support fügt als weiteres Kritierium, besser die Zeichenkette zu speichern, dessen Lesbarkeit für uns Menschen an. Ich werde also eueren Rat befolgen...

Danke nochmals an alle!

hm,
wie immer. Ich habe mal wieder die A-Karte gezogen. Ich bin gerade dabei eine Tabelle mit vielen Sätze auf einmal zu befüllen und dabei nutze ich die Funktion UuidToChar(Uuidcreate()).
Und was soll ich euch sagen, nach 15 Durchläufen ca. wird eine ID erzeugt, die kurz vorher schonmal erzeugt wurde. Ich denke das kann nicht sein?

Bei 100.000ten erzeugter Key, war bisher kein doppelter Schlüssel dabei...

ok, ich weiß ja nicht genau, wie der erzeugt wird. Wie machst Du das denn? So nach und nach, oder in einer Schleife?
Ich kann ja auch nur sagen, was mir aufgefallen ist.

Es ist technisch unmöglich, dass auf einem Rechner derselbe Key mehrfach erzeugt wird. Und die Wahrscheinlichkeit dafür, dass es auf zwei unterschiedlichen System passiert, ist astronomisch klein. Der Fehler muss woanders liegen.

das durchläuft eine Schleife

Code: Alles auswählen

TEXT INTO cSqlStmt WRAP CHR(13) TRIMMED
                  INSERT INTO {#tabelle#} (id, {#cFelder#}) VALUES ('{#cid#}' , {#cValues#})
          ENDTEXT
          cSqlStmt := StrTran(cSqlStmt,"{#tabelle#}",cTabellenName)
          cSqlStmt := StrTran(cSqlStmt,"{#cFelder#}",cFelder)
          cSqlStmt := StrTran(cSqlStmt,"{#cValues#}",cValue)
          cSqlStmt := StrTran(cSqlStmt,"{#cid#}",erzeugeuuid())
          ********************************
          FUNCTION erzeugeUuid()
                          LOCAL xuuid := Uuidcreate()                                            // erstmal eine kryptische id erzeugen
                          LOCAL cUuid := UuidToChar(xuuid)                                       // jetzt wird es eine lesbare ID

	             RETURN cUuid

Der Fehler muss im SQL-Statement liegen. Da muss ich passen.

Inoffizielles deutsches Xbase-Forum

UUId als Key in Dbase-Tabellen unter Clipper [Erledigt]

UUId als Key in Dbase-Tabellen unter Clipper [Erledigt]

Re: UUId als Key in Dbase-Tabellen unter Clipper

Re: UUId als Key in Dbase-Tabellen unter Clipper

Re: UUId als Key in Dbase-Tabellen unter Clipper

Re: UUId als Key in Dbase-Tabellen unter Clipper

Re: UUId als Key in Dbase-Tabellen unter Clipper

Re: UUId als Key in Dbase-Tabellen unter Clipper

Re: UUId als Key in Dbase-Tabellen unter Clipper

Re: UUId als Key in Dbase-Tabellen unter Clipper

Re: UUId als Key in Dbase-Tabellen unter Clipper

Re: UUId als Key in Dbase-Tabellen unter Clipper

Re: UUId als Key in Dbase-Tabellen unter Clipper

Re: UUId als Key in Dbase-Tabellen unter Clipper

Re: UUId als Key in Dbase-Tabellen unter Clipper

Re: UUId als Key in Dbase-Tabellen unter Clipper

Re: UUId als Key in Dbase-Tabellen unter Clipper

Re: UUId als Key in Dbase-Tabellen unter Clipper

Re: UUId als Key in Dbase-Tabellen unter Clipper

Re: UUId als Key in Dbase-Tabellen unter Clipper

Re: UUId als Key in Dbase-Tabellen unter Clipper [Erledigt]

Re: UUId als Key in Dbase-Tabellen unter Clipper [Erledigt]

Re: UUId als Key in Dbase-Tabellen unter Clipper [Erledigt]

Re: UUId als Key in Dbase-Tabellen unter Clipper [Erledigt]

Re: UUId als Key in Dbase-Tabellen unter Clipper [Erledigt]

Re: UUId als Key in Dbase-Tabellen unter Clipper [Erledigt]