In my application I have stored the timestamp as an integer on each entity I save. When I then later query the database by comparing timestamps I get an error such as the following:
Error: One of the request inputs is not valid. RequestId:3b61f705-ca01-4742-981b-6e2332029874 Time:2013-12-06T16:49:42.0282802Z
After a lot of debugging I finally found out what was going on. In my code I have the following query
var query = azure.TableQuery .select() .from(self.tableName) .where('added gt ?', timestamp);
If I set timestamp to be Math.pow(2,30), everything seems fine, but increasing it to Math.pow(2,31) will give me the error. I found this behaviour somewhat strange since among the Azure Table Storage types is the Int64 type. This is essentially making use of that, and the values I have stored are certainly much bigger than an Int32.
I ended up working around this by converting the values to DateTime by throwing new Date(timestamp) everywhere, but that should have been unnecessary. Anyone come across this, and managed to save integers as integers?
The Azure Table Storage API Int64 literal must use the L suffix.
var query = new azure.TableQuery() .where('loginTimeMS lt ?', 1406828512316); query._where+="L";
Effectively putting the following string into the table query...
"loginTimeMS lt 1406828512316L"
Note the L at the end. This query will find entities where the property loginTimeMS is less than 1406828512316 which is an Int64.
It feels like a work around - be interested to hear if anybody has found a more elegant solution.
This recipe can be found in it's original form on Stack Over Flow.