How can we help you today?
Value was either too large or too small for an Int32.
Looking at your PROCEDURE declaration at the top, you have it both using @id as BigInt OUT and returning @id. Stored Procedures do have a return value (rarely used, I think), but I believe it can only be an Int32 (SQL Int), so returning the declared BigInt parameter may be what is blowing up. That seems consistent with the exception message, although not necessarily the specific Stack Trace.
It's also possible that Scope_Identity() itself is blowing up expecting only an Int identity. We'll have to check that code.
Is your identity column declared as BigInt, and is it actually getting to values that exceed the limits of an Int?
-Rob
We were able to reproduce the error with a unit test extrapolated from this example. The problem (which also fails with @@IDENTITY) is that the data type of the SCOPE_IDENTITY() function is set in the Prepare() phase, before the row has been inserted, and it is defaulting to Int rather than BigInt when there hasn't been an insertion since the connection was opened. It then blows up in the Execute() phase when the actual identity value can't convert to an Int.
We'll see about fixing this by changing these to always use BigInt internally, but we'll have to make sure the change doesn't break the more common case of an Int column without anyone needing to change their code.
In the meantime, you can fix your PROCEDURE by using LASTIDENTITY(Id, Intervals)--assuming the column is named Id--instead of SCOPE_IDENTITY(). By specifying the explicit column and table it is able to correctly determine the data type in the Prepare() phase and avoid the internal mismatch.
Ben Gehring
I have a .NET Core 3.1 app. Using the latest release of VistaDB. I'm getting an error and can't figure out what I'm doing wrong. I'm inserting a string into the database via a stored procedure.
The table structure is ID bigint and Name Varchar(100).