When the identity is a BIGINT

[dyanarose]

Hi,

Looking at these two lines, it looks like the code assumes identities will be Int32s. So this would fail if instead, it's an Int64 for example.

https://github.com/FransBouma/Massive/blob/v2.0/src/Massive.Shared.cs#L1053 https://github.com/FransBouma/Massive/blob/v2.0/src/Massive.Shared.cs#L1066

[FransBouma]

You're right!

Problem is though: there's no info to determine what the type should be, everything is dynamic... so I picked 'int' as in general that's a safe bet in this case... Any suggestions?

[Siliconrob]

For the case of MS SQL I know you can ignore the overflow values by using

SET ARITHABORT OFF; - MSDN SET ARITHIGNORE ON; - MSDN

In that case at least you can use Int64 and the downcast to Int32 identities should work. Helpful?

[FransBouma]

Hmm. It smells like on error resume next however ;) Perhaps some other route to specify the type might be better... But haven't given it much thought

[mikebeaton]

Looking at the code at that date #L1053 #L1066 those two lines will not fail if the PK is a long which can fit into an int, only if the value is a long which can't fit.

Massive probably/possibly can't do better than this, as a cross-DB wrapper where most supported DBs work with ints.

But actually there was a line in that file #L785 which used an (int) cast instead of Convert.ToInt32(), to handle the result of COUNT, and that line failed with an exception (even for values which should fit into int) when ported to a DB which sent back a long count.

This is now fixed, or at least now follows the reasonable(?) pattern of the other two lines, as of https://github.com/FransBouma/Massive/commit/57073a937915f69ae060cc3e928ed097bfb100a8 for MySQL support. It will basically work for most users, if you really need long for PKs and COUNT values in your DB, you'd have to go in and edit these three lines.