The error messages when Azure Table Storage data insert fails are far from being descriptive.
This is the complete list of supported datatypes (or Property Types as they call them):
- Binary: An array of bytes up to 64 KB in size.
- Bool: A Boolean value.
- DateTime: A 64-bit value expressed as UTC time. The supported range of values is 1/1/1601 to 12/31/9999.
- Double: A 64-bit floating point value.
- GUID: A 128-bit globally unique identifier.
- Int: A 32-bit integer.
- Int64: A 64-bit integer.
- String: A UTF-16-encoded value. String values can be up to 64 KB in size.
Really. Nothing more. You just have to get along with that one! 
The list is taken from Windows Azure Table Storage and Windows Azure SQL Database - Compared and Contrasted.
Things you fail to notice:
- .Net DateTime Structure as range of 00:00:00 (midnight), January 1, 0001 Anno Domini (Common Era) through 11:59:59 P.M., December 31, 9999 A.D. (C.E.) in the Gregorian calendar. Not from January 1, 1601 AD.
- That shouldn't be an issue. My app had problems and it had recorded dates into year 201. This was a really nice way of finding that out.

- In intergers, there are no unsigned versions.
- In decimal numbers, there is no decimal, a 128-bit floating point number. You have to settle with Double, a IEC 60559:1989 (IEEE 754) compliant version.
- There is no reasonable way of storing money-type data which needs an exact number, no floating point conversions.
- The string really is UTF-16, a two byte -version. It stores up to 32768 characters.
- Which is Not much when compared to TEXT or varchar(max) which range from 2 GiB to anything you have
Hopefully this list helps somebody. I spent a nice while finding all these out.