![]() See much like a past post I had missed something pretty crucial on the MSDN page – HASHBYTES has an 8000 character limit!Īt least this time the implications were glaringly obvious, and I had noone else to blame but myself. It turned out that this was because I was passing my cast value straight to HASHBYTES which was in turn throwing an error. Unfortunately, while this is a decent enough function for hashing, it led me on a bit of a wild goose chase as I tried to work out why I couldn’t seem to cast my XML field to varchar without getting an error. Returns the MD2, MD4, MD5, SHA, SHA1, or SHA2 hash of its input. However, given the hashing direction the HASHBYTES function seemed a good start. Indeed it’s the improved solution I list below. Upon reflection however I don’t see a real reason (beyond perhaps performance) I couldn’t have followed Matt Woodward’s method and performed a simple string conversion and comparison (well a comparison of substrings given the requirement to ignore the header). Now in the heat of the moment I went with a hashed solution as StackOverflow proposed. ![]() Develop this solution ASAP (this was needed in a critical support situation)Ī single application had populated the table, so fortunately I could assume all XML was equally processed.Keep the first row of a set of duplicates.Only apply the duplicate checking to some of the rows.Only compare a subset of the XML value (a timestamp header would still differ on XML values we considered duplicates).However, my “requirements” as they were differed a little from the existing solutions: There’s a StackOverflow question covering it.Matt Woodward has covered the simplest case of duplicate checks.Had the interesting problem today of trying to detect duplicate XML values in a SQL Server table (stored in a column of field type XML).
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |