2

EDIT: Let me turn this into a straight SQL question...

I have a varbinary(max) column containing a byte array that represents Microsoft Ink data. Ink data is comprised of Strokes and the Strokes appear to be delimited by 0x00. For example

0x0090011D04A4048C040304481045141914320800C03402E9A46242330800E01202D0BA014211ABAAD3411E060484E24F6C400A0701096B800A4AC00A060108690943800A2B3C82FCD9F9B56001165CB61440059412CA8B2882FC61F8C66692772AC4D92A2C22E5CD2CAB08DCBB1365940A212182FE043BF810FCCCD6B360AB9A2A451482FC6DF8D664AB337C55DCA9B2D5B650...

Stroke 1 is 0090011D04A4048C0403044810451419143208

Stroke 2 is 00C03402E9A462423308 (I think the 0x08 at the end of both is a coincidence)

etc.

The last Stroke is corrupt because the data was truncated on insert. How do I remove only the last Stroke from the data? I want to do this in a SQL update if possible.

Due to a Fluent NHibernate mapping SNAFU, we have some Microsoft Ink data that was truncated at 8000 bytes and stored in a SQL Server database varbinary(max) column. Attempting to load this data into a new Ink object throws the exception "Catastrophic failure (Exception from HRESULT: 0x8000FFFF (E_UNEXPECTED)".

Is it possible to recover any of the Ink data? I know it is stored as strokes, so if there is a delimiter to identify individual strokes then I could just remove the trailing bad data.

Community
  • 1
  • 1
Jamie Ide
  • 48,427
  • 16
  • 81
  • 117

1 Answers1

1

I'm not familiar with Ink data but would it be possible to read it as a byte array and try and convert it to ink data starting from the end of the array working sequentially backward in the byte array until the creation of the ink data doesn't throw an exception. You would then store this resulting object in the database.

This seems like it could take a long time if your result set is large but it seems like it could work.

Cole W
  • 15,123
  • 6
  • 51
  • 85
  • I tried something similar -- if the Ink failed to load I located the last delimiter and truncated it. Unfortunately Ink Serialized Format (http://en.wikipedia.org/wiki/Ink_Serialized_Format) is more complicated than that. – Jamie Ide Nov 03 '11 at 12:12
  • Well it looks like from the format it is like you said much more complicated than that. It appears that to do this you would have to basically truncate off the end of the data until you ran into your last ending `TAG_STROKE`. You would then also have to modify the size of all your `TAG_STROKE` blocks and set that value in the proper place at the beginning of the Ink Object. You would also have to modify the `GUID` table at the beginning of the Ink object such that all the missing `TAG_STROKE` sections would be removed from this lookup table. – Cole W Nov 03 '11 at 13:48