okbangas (6/26/2012)
T-SQL type Int is storage-equivalent to VarBinary(4).
T-SQL type BigInt is storage-equivalent to VarBinary(8).
This is definitely not so, as varbinary require a VLB (Variable Length Block), whereas int and bigint does not. If they are storage-equivalent to something, that would be binary(4) and binary(8) respectively.
Furthermore, I do not appreciate casts to variable length data without specifying the max length, even though it in your cases implicitly means varchar(30).
Casting to varbinary does not convert it to hex, hex is a representation which may be used for displaying the data to the client.
Thank you okbangas for so ardently pointing out these minor details...
You are correct, I should have used Binary(4) and Binary(8) in my examples or have used the phrase "length-equivalent" instead of "storage-equivalent" in my final notes, however, the end results are the same.
Casting either Int or BigInt to VarChar will always work without truncation as the default VarChar length is 30 characters and neither Int nor BigInt could contain that many digits when represented as a VarChar data type.
Any time data is displayed to a user it is a representation of the internal storage type, i.e. binary. Casting simply changes the representation to that of the Cast's target type. Guess you missed my use of the term "representation" just before the Final Notes. Also, as one poster pointed out VarBinary seems misleading; maybe they should have called it VarHex 😉
I hope that okbangas's well-meaning academic adherence to principle didn't detract from the point of this article; simple ways to avoid byte-at-a-time conversions to hexadecimal representation.
Rate this anyway you please. I don't post for accolades, I post to help folks solve real-world problems using a woefully inadequate programming language (T-SQL).