If I understand correctly the struct and the fact that its SqlServer on Intel P4 means I'm seeing little endian first in the DWORD and WORD fields? That makes the pattern intelligible: Type Field HexOctet DWORD Data1 - [lsb0][lsb1][msb0][msb1] WORD Data2 - [lsb][msb] WORD Data3 - [lsb][msb] BYTE Data4[8] - just bytes
I'm not sure what this should mean to o.a.c.id.uuid.UUID...since the UUID implementation I've worked out uses BigInteger to store the 128-bits, and I also allow a constructor from a BigInteger. I felt systems that wish to store the byte value and not the char value could benefit. (For example, to store in db2 I would use a the 16 byte value not the 36 byte string representation.) The IETF Draft spec says the 128 bit object should be composed of the various fields in network byte order, so it seems the numeric value returned from ms-sql is system specific? and the a.o.c.id.uuid implementation is ok by the spec? I'm going off of: http://www.ietf.org/internet-drafts/draft-mealling-uuid-urn-01.txt (Section: 4.1.2 Layout and byte order) I'm wondering if someone might try to construct an o.a.c.id.UUID from the hexidecimal value they pulled from MS-SQL? It may be a long shot, but perhaps a note in the documentation is needed? e.g. String fromMSSQL = "0904F0B4F8CE2248802CDEB20704C365"; BigInteger bInt = new BigInteger(fromMSSQL, 16); UUID myUUID = new UUID(bInt); System.out.println(myUUID.toString()); Outputs: 0904f0b4-f8ce-2248-802c-deb20704c365 and Not B4F00409-CEF8-4822-802C-DEB20704C365 and would not produce the same GUID from ms-sql to o.a.c.id.uuid.UUID because the hexidecimal representation from ms-sql is this way. Another option might be a new method parseMSSQLHexidecimal(String)? Any thoughts? PS> Thanks Martin... I would not have figured out that out. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
