File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes JDBC and Relational Databases and the fly likes Byte order! Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Databases » JDBC and Relational Databases
Bookmark "Byte order!" Watch "Byte order!" New topic

Byte order!

Maulin Vasavada
Ranch Hand

Joined: Nov 04, 2001
Posts: 1873
i am using MS-SQL server and bita version of the JDBC driver for that. in my database table i have a field with type "uniqueidentifier" which is 16 byte number with "-" in between. its in format of,
4-2-2-2-6 bytes. (this field has been used to generate unique id for each record i have).
now here comes the problem. when i try to get that field using resultset.getString(1) i get the data correctly but in different byte order.
the interesting thing is the last 8 bytes are in correct order but first 8 are not in order. the byte order is changed for first 8 bytes. so first 4 bytes if i put in reverse order gives me the correct 4 bytes (that corresponds to the first 4 bytes of the database field entry). similar thing for next 2-2 bytes.
e.g. if first 8 bytes are,
A1B2C3D4-AEBC-DF2A in the database field entry then i would get,
D4C3B2A1-BCAE-2ADF when i try resultset.getString(1)...
the rest of the bytes are in correct order.
so last 8 bytes were,
then i get,
C582-E3FF4562A7DD as last 8 bytes (so they are in correct order)...
this problem i guess is due to the byte order problem (little endian/big endian). what i guess is, MS-SQL server stores the first 8 bytes in little endian and last 8 bytes in big endian format. so when my java program gets data by using getString() or getBytes() on resultset i get first 8 bytes in reverse order as i explained. this is due to the fact that java enterprets in big endian format!
well i can get around the problem just by adjusting the first 8 bytes but is my reasoning correct about the problem? and if there is another way out?
well i yet need to check the metadata col type for this field (i didnt get time and it occurred to my mind after i was out the office...)...
can anybody throw some light on this if you have encountered similar problem?
Adam Hardy
Ranch Hand

Joined: Oct 09, 2001
Posts: 567
I was playing around with bytes and string objects when I was writing code to save hashed passwords to a string field. I didn't have the same problem but I did have to play around alot converting bytes into strings etc.
Perhaps if you try retrieving the value as getBytes() or getBlob() or getBinaryStream() or something similar, and then make the string yourself from it?

I have seen things you people would not believe, attack ships on fire off the shoulder of Orion, c-beams sparkling in the dark near the Tennhauser Gate. All these moments will be lost in time, like tears in the rain.
Maulin Vasavada
Ranch Hand

Joined: Nov 04, 2001
Posts: 1873
hi adam,
thanks for response but the problem i have is the ordering of bytes. i tried getBytes() , getBinaryStream() also but the order of the bytes i recieve remains the same (this is bound to happen as i'm actually having data in little endian format and i am interpreting it in big endian format)....
getBlob() or any other getX() method doesnt work (except getString())....
my questions was "am i correct about my reasoning about the incorrect byte order or not?". i will surely solve the problem changing the byte order and converting back to string etc...but i want to know what i reason is right or i am missing something as i don't know much about MS-SQL storage stuff etc...
btw, i tried getColumnClassName() on result set metadata and the class type is byte[]!!!
any more lightening from MS-SQL Experts??(i am going to post this problem on MS-SQL news group and see if i can get to know the correct reason)...
Adam Hardy
Ranch Hand

Joined: Oct 09, 2001
Posts: 567
you've gone beyond my experience. Perhaps its an issue that the jdbc driver should deal with. I don't know quite what big-endian and little-endian imply. I thought Apple Macs were the only computers that had that problem!
I agree. Here's the link:
subject: Byte order!
It's not a secret anymore!