40K crashing Long Integer data type

Libre

been around a little
Local time
Today, 14:09
Joined
May 3, 2007
Messages
683
It took hours for me to find it because it SHOULDN'T crash. One record had a value of 40,000 for a certain column. The data type is Long Integer in the table. I should have a range of -trillions to +trillions. I can't understand why 40K is crashing it. I'm running the 64 bit version of Access too. When I reduced the value to 20K it ran fine. But that 40K value would cause the error handler to catch a Stack Overflow when trying to open the record.
Any ideas why? 40K is not that a big number.
 
That value is not making it crash, but likely something related to it.
You speak about Stack Overflow. Is there VBA code involved here, presumably behind a form that is bound to this table?

As a test, comment out all VBA, and Repair and Compact the app. Still a crash?
If yes, what if you have the Form wizard create a form on this table. Still a crash?

One oher thought: change the value to 32767. No crash? Then change to 32768. Crash? If so, you are overflowing integer data type (max 2^15-1).
 
Last edited:
There's VBA code that uses this value in many places.
However it's only declared one time in a Module: Global giCI as Long
Which I changed from: Global giCI as Integer

I don't want to comment out ALL the VBA because as I said - it's used in many places.
There's more testing I'll need to do to nail it down any further.
It MIGHT be that declaration change.
 
you need to revise the code that causes the error, eg:

Dim Result As long

Result = Clng(giCl) * Clng(anyValue)
 
There's VBA code that uses this value in many places.
However it's only declared one time in a Module: Global giCI as Long
Which I changed from: Global giCI as Integer

I don't want to comment out ALL the VBA because as I said - it's used in many places.
There's more testing I'll need to do to nail it down any further.
It MIGHT be that declaration change.
Integer will crash it. That only goes up to 32k (2^15, maybe 2^15 - 1 to be precise), so 40k is too big. I rarely define any whole number as anything other than a LONG.
 
Hardware-wise, that 40K value will easily fit into a LONG, which gives you about a 2.147 billion limit as a signed long integer. If you have a "native" Access back-end file, or if the app is a single Access .MDB or .ACCDB stand-alone file, you cannot define an unsigned integer. (If the back end is an SQL Server or another active SQL engine, all bets are off.) However, at some point you appear to be running into a case where an "ordinary" (word) INTEGER is the recipient of a LONG value. As noted by others, you reach a hardware limit for INTEGER at 32767, the largest signed value a word integer can hold. Adding 1 to 32767 in an INTEGER flips the sign bit due to an overflow.

Inside any VBA expression there is an automatic feature (called LET coercion) that will adjust data sizes of the expression elements to match what is needed to keep the expression from blowing up on you. However, there are cases where this coercion effect doesn't apply. The three biggest cases are

(1) assigning the value of a LONG (or floating-point) expression to an INTEGER (i.e. INTEGER = LONG expression)
(2) Inside a subroutine, assigning a LONG return value to a subroutine parameter that was defined as an INTEGER BY REF
(3) Returning a LONG value for a function declared to return an INTEGER.

Catching a STACK OVERFLOW message adds a little spice to this recipe. You normally cannot directly reference the hardware Stack Pointer so this error has to be triggered by an indirect effect. Do you attempt anything recursive in your code that would be based on that variable that you said was getting 40K as its content?

What is MORE interesting is that storing a number >32767 in an INTEGER should have triggered run-time error 6, "Overflow" - which would have occurred BEFORE whatever triggered that "Stack Overflow" error you mentioned. I checked the VBA Language Reference (2014 version) and it does not say what value would be stored in that case (LONG trucated to INTEGER? set to 32767? set to 0? VBA Language Reference doesn't say). But you would get no value at all unless you had an ON ERROR RESUME NEXT in your code.
 
It took hours for me to find it because it SHOULDN'T crash. One record had a value of 40,000 for a certain column. The data type is Long Integer in the table. I should have a range of -trillions to +trillions. I can't understand why 40K is crashing it. I'm running the 64 bit version of Access too. When I reduced the value to 20K it ran fine. But that 40K value would cause the error handler to catch a Stack Overflow when trying to open the record.
Any ideas why? 40K is not that a big number.
Post your code.
 
There's VBA code that uses this value in many places.
However it's only declared one time in a Module: Global giCI as Long
Which I changed from: Global giCI as Integer

I don't want to comment out ALL the VBA because as I said - it's used in many places.
There's more testing I'll need to do to nail it down any further.
It MIGHT be that declaration change.

Sorry, I thought you were using an "integer" data type. I misread that you had changed it FROM integer.
I expect there must be somewhere you still have integer, rather than long. Can you identify the precise point that causes the crash?
 
Last edited:
Changing the declaration worked. I changed a bunch of "as Integer" to "as Long".
Thanks, group.
It now works without crashing.
 

Users who are viewing this thread

Back
Top Bottom