I am trying to do a Mod 11 check on a 16 digit number to validate credit/debit cards but I get an overflow error. I guess this is because the number is too big. How can I get round this problem?
Ths is code I use to validate credit cards and may help you:
Function CheckCreditCard(CCNum As String, CCType As String) As Boolean
Dim ValidCC As Boolean
Dim CCNumLen As Integer
Dim CheckDigit As Integer
Dim Pos As Integer
Dim Digit As Integer
Dim CCSum As Integer
ValidCC = False
CCNumLen = Len(CCNum)
Select Case CCType
Case "American Express"
ValidCC = (CCNum Like "37*" Or CCNum Like "34*") And CCNumLen = 15
Case "CarteBlanche"
ValidCC = (CCNum Like "94*" Or CCNum Like "95*" Or CCNum Like "389") And CCNumLen = 14
Case "CarteBlanche International"
ValidCC = (CCNum Like "9*") And CCNumLen = 10
Case "Diners Club"
ValidCC = (CCNum Like "30*" Or CCNum Like "36*" Or CCNum Like "38[1-8]*") And CCNumLen = 14
Case "Discover (Novus)"
ValidCC = (CCNum Like "60110*" Or CCNum Like "6011[2-4]*" Or CCNum Like "60119*") And CCNumLen = 16
Case "Encryption"
ValidCC = (CCNumLen >= 16 And CCNumLen <= 19)
Case "JCB"
ValidCC = (Left$(CCNum, 4) >= "3528" And Left$(CCNum, 4) <= "3589") And CCNumLen = 16
Case "MasterCard"
ValidCC = (CCNum Like "5[1-5]*") And CCNumLen = 16
Case "Optima"
ValidCC = (CCNum Like "37?7*") And CCNumLen = 15
Case "Switch"
ValidCC = (CCNum Like "49*" Or CCNum Like "56*" Or CCNum Like "6*") And (CCNumLen = 16 Or CCNumLen = 18 Or CCNumLen = 19)
Case "Visa"
ValidCC = (CCNum Like "4*") And (CCNumLen = 13 Or CCNumLen = 16)
Case Else
ValidCC = False
End Select
If ValidCC Then
For Pos = 1 To CCNumLen - 1
Digit = CInt(Mid$(CCNum, CCNumLen - Pos, 1)) * 2 ^ (Pos Mod 2)
CCSum = CCSum + Digit \ 10 + Digit Mod 10
Next
ValidCC = (10 - (CCSum Mod 10)) = CInt(Right$(CCNum, 1))
End If
CheckCreditCard = ValidCC
End Function
0
With monday.com’s project management tool, you can see what everyone on your team is working in a single glance. Its intuitive dashboards are customizable, so you can create systems that work for you.
This happens when the expressions used with the MOD operator are assumed to be a certain numeric type, but the results are of a different numeric type which induces an overflow error.
For example, if the expressions used are Integers (implied or explicit), but the result is of type Long, this can generate an Overflow Error.
Try the following in the Debug Window:
Print 32767 * 2
You get an Overflow Error because both numbers are Integers, but the result is Long. But, if you do the following:
Print CLng(32767) * 2
You do not get an error since one of the terms is a Long, therefore the result is assumed to be a Long.
The same thing can occur with the MOD operator. You may need to convert one or more terms of your expression into a Long Integer.
Barring that, perhaps you could give us an example which causes this overflow error, and the current values and data type of each of the involved variables.
Actually in this case and as ryancys previously pointed out MOD simply does not handle any numeric expression larger than 2,147,483,647.
In any case if all that is required is a check on the credit card digits than there is no need to do a MOD on the whole number. The algorithm (I believe it is called the Luhn algorithm) that I posted is quite simple.
But your point is well made and I know what you are referring to; we have had this issue since the days MS Basic.
>Actually in this case and as ryancys previously pointed
>out MOD simply does not handle any numeric expression
>larger than 2,147,483,647.
Somehow I had missed ryancys' comments; I *knew* there was something else, for there was another post sometime back which had asked this same question, and I could not quite recall exactly what the problem was. But it's all coming back to me now.
The manual method of arriving with the MOD (such as rspahitz suggested) was the solution to that problem.
Yes. There are known limitations of each of the mathematical functions used in VB. It used to be that things like Sine, Cosine, etc. only offered single precision (or maybe that was the pre-VB days of QuickBASIC). Eventually they were upgraded since the processors actually encouraged such improvements.
With the advent of .net, and it's 64-bit processing, there's a good chance that the mod function will support the larger numbers that you are requesting...but I suppose you don't want to wait around for that.
One solution is to create an "anticipatory" function so you can more easily upgrade in the future. To do this, instead of using mod, use a user-defined function such as this:
...
Private Function MyOwnModulus(BaseNumber as double, Modulus as integer) as long
MyOwnModulus = BaseNumber - int(BaseNumber / Modulus) * Modulus)
' 'The following is for future use when the 'mod' function supports larger numbers
' MyOwnModulus = BaseNumber mod Modulus
end Function
In the future, when implementing .net, change this routine to:
Private Function MyOwnModulus(BaseNumber as double, Modulus as integer) as long
MyOwnModulus = BaseNumber mod Modulus
end Function
--
If you find a lot of these "workarounds" you may want to drop them into a separate module or even your own class module.
Thanks for all your input guys. All very useful but Tim's was the first that I used which solved my problem.
Thanks again
Dave
0
Featured Post
With monday.com’s project management tool, you can see what everyone on your team is working in a single glance. Its intuitive dashboards are customizable, so you can create systems that work for you.
Gives an example of how to validate a credit card. This may be useful to you.