DISP_E_OVERFLOW (0X8002000A) - Out of present range

Quick Answer

Convert the offending value to a String or Variant of type VT_BSTR before passing it to the COM method. If you’re stuck with a large integer (e.g., >2^31-1), use CStr() in VBA, .ToString() in C#, or [string] cast in PowerShell.

Context & Why It Happens

I’ve seen this one in the wild more times than I can count — usually in Excel automation, ADODB recordset updates, or old VB6 components where a value crosses the 32-bit integer boundary. The culprit here is almost always a number that fits in a 64-bit integer (like file sizes, timestamps, or row counts) but gets jammed into a VARIANT that defaults to VT_I4 (32-bit signed integer). The COM layer throws DISP_E_OVERFLOW because, well, it can’t stuff a 64-bit value into a 32-bit slot.

Real-world trigger: You’re looping through a CSV with 3 million rows, writing to a COM object, and hit this on row 2,147,483,648. Or you’re automating Excel from PowerShell and pass a 2,000,000,000 row count. The fix doesn’t change the data — just how you pass it.

Fix Steps

Try these in order. Step 1 works 80% of the time.

1. Cast the value to a String before the COM call
   If you’re using VBA:

   Dim bigNumber As LongLong
   bigNumber = 3000000000
   someCOMObject.SomeMethod CStr(bigNumber)

   In C#:

   object comObj = new SomeCOMClass();
   comObj.SomeMethod(bigNumber.ToString());

   In PowerShell:

   $comObject.SomeMethod([string]$bigNumber)

2. Use VariantChangeType explicitly (C++/ATL)
   If you’re writing native code, don’t rely on automatic coercion. Call VariantChangeType with VT_BSTR before passing the variant.
3. Switch to a 64-bit compatible COM interface
   Some older COM components (like ADODB 2.x) only support 32-bit integers. Find a newer version or wrapper that accepts VT_I8. Check the component’s type library for long long or Int64 parameters.
4. If the value is a date/time or timestamp
   Convert it to a Date (VT_DATE) first — don’t pass raw ticks or Unix timestamps as integers. Example in VBA:

   someCOMObject.SomeMethod CDate(SomeTimestamp)

Alternative Fixes (When Main One Fails)

If casting to string breaks the method (some COM methods reject strings for numeric params), try these workarounds:

• Split the value into two parts — pass the high and low 32-bit words separately if the COM interface allows it. Rare but exists in some math libraries.
• Use a 64-bit type library — regenerate or re-register the COM component with a 64-bit proxy/stub. Run regsvr32 /64 yourdll.dll on 64-bit Windows and make sure the calling code targets x64.
• Wrap the COM call in a try-catch and retry with a smaller value — sloppy but works if the overflow is intermittent. Not recommended for production.
• Upgrade to .NET interop instead of raw COM — .NET handles 64-bit integers natively. Rewrite the caller in C# with System.Runtime.InteropServices and bypass the variant marshaling.

Prevention Tips

You won’t hit this again if you follow three rules:

• Always pass large numbers as strings or doubles to COM methods unless you’re 100% sure the interface expects a 64-bit integer.
• Check the type library with OLE View (oleview.exe) before writing the automation code. Look for long vs long long in the method signatures.
• Use a wrapper function that explicitly tests the value against 2^31-1 and casts to string if it exceeds the limit. Keep it in a shared module — saves debugging time later.