Overflow error

[funderburgh]

The version of Visual Basic in my Access 2007 is 6.5. I am adapting some code for smart card processing from Visual Basic 2008. I am getting an overflow error on Integer variables, here is an example:

PublicConst SCARD_PROTOCOL_RAW As Integer = &H10000

This works in the 2008 compile. If I change it to AS LONG, I do not get the error but the function using the argument returns an error.

I can't figure out how to upgrade VB, or if there is another aspect that I am missing on this.

Any help is most welcome.

 

[ajetrumpet]

it could be a problem like i was having earlier. your variable types have to be in sync with what you're putting in as arguments. for example, the input to your function must be LONG if the output of your function is LONG.

 

[boblarson]

for example, the input to your function must be LONG if the output of your function is LONG.

That doesn't make sense. The inputs do not have to be the same in a function to match the output.

I can have

Function Something(intSomething As Integer) As Long

and that is okay, or even


Function Something(intSomething As Long) As Integer

It all depends on the operations I'm doing to get it into that value.

So, the question in my mind here is - what is the value: &H10000

and what is it being used for in the function?

It seems that we have a combination of .NET programming and Access VBA going on here which needs to be accounted for.

 

[dfenton]

It would seem that VB.NET uses "integer" data type the same way SQL Server uses it, i.e., a SQL Server integer field is the same as a Jet/ACE Long Integer.

In this case, your constant is too large to be stored in a VBA Integer variable, which is limited to values from 32,768 to 32,767. The Hex number &H10000 is 65536 decimal, so you have to make the constant a Long.

 

[ChrisO]

I don’t know how big the function is but it might be reasonable to do a find Integer and replace it with Long throughout the entire function.

These days, with memory size and computer speed the way it is, integers may still have their place but I think it is hard to justify their use.

 

[ajetrumpet]

That doesn't make sense.

it is if it is explained correctly

 

[funderburgh]

Thanks for all of the input. I may have a solution but it takes me into an area I am unfamiliar with. The .Net application I am using came with an object library that I can reference in Access. I can select the object library in the object reference screen and see the objects and methods it contains. What I don't understand is how to use that in my code - I can see it in the reference screen, but so what? Any tips would be welcome.

 

[dfenton]

These days, with memory size and computer speed the way it is, integers may still have their place but I think it is hard to justify their use.

You use integer data type if your data is within the limits of the integer data type. It has nothing to do with storage efficiency -- it's entirely a matter of strongly typing your variables so that you can't store a nonsensical number in a variable.

 

[dfenton]

The solution has already been provided. Change this:

Public Const SCARD_PROTOCOL_RAW As Integer = &H10000

...to this:

Public Const SCARD_PROTOCOL_RAW As Long = &H10000

That will fix the problem. You don't need to worry about trying to reference a .NET library, because the variable declaration is in VBA, not .NET.

 

[ChrisO]

David.

I really don’t see the value of the point you are making. (Perhaps my fault.)

>>You use integer data type if your data is within the limits of the integer data type. It has nothing to do with storage efficiency -- it's entirely a matter of strongly typing your variables so that you can't store a nonsensical number in a variable.<<

So let's assume that a person wants to 'strongly type' a variable but in doing so it raises a runtime error, as it is in this case.
Was the 'strongly typed' variable strong enough to prevent the runtime error or was it there to simply satisfy some esoteric notion which caused the error in the first place?

The answer in this thread seems to imply raising the 'strongly typed' Integer to a less 'strongly typed' Long.
You said the same thing yourself with >> In this case, your constant is too large to be stored in a VBA Integer variable, which is limited to values from 32,768 to 32,767. The Hex number &H10000 is 65536 decimal, so you have to make the constant a Long.<<
(That quote is in itself wrong because it should have read from -32,768 to 32,767, {not 'strongly typed' at post time.})

By all means state your case, whatever it may be. But please do not try to overstate your case; it will make you a target as I think you already know.

I am prepared to argue the case for 'weak data types' but only if you are prepared to reply without overstating your case in some absolute manner.

Regards,
Chris.

 

[dfenton]

>>You use integer data type if your data is within the limits of the integer data type. It has nothing to do with storage efficiency -- it's entirely a matter of strongly typing your variables so that you can't store a nonsensical number in a variable.<<

So let's assume that a person wants to 'strongly type' a variable but in doing so it raises a runtime error, as it is in this case.

Well, if you need to store a value that exceeds the capabilities of a certain data type, you have to choose another data type. You wouldn't choose currency or double to store whole-number values, not just because they take up more space, but because they could allow non-whole numbers.

It's a matter of choosing the most appropriate data type not the most limiting one. You choose the most limiting one that fits the data you're producing.

I learned this lesson a few years ago when I made an incorrect choice, mismatching my VBA variable with the data type for the filed in the table. I was using a standard Autonumber for PK (which is a long), but it was a small table that I knew would never exceed the range of the integer variable. (can you see t coming?) Well, that worked fine until the data file got replicated, which randomizes the Autonumber. It was a rather static table, and hardly ever had records added, so it was literally *years* after the back end was replicated before it threw the error. The error was that the PK of a new record in that table was a very large absolute value, larger than could be stored in an integer variable.

If I'd matched the variable type in VBA to the data type in the underlying table, the error never would have occurred.

Was the 'strongly typed' variable strong enough to prevent the runtime error or was it there to simply satisfy some esoteric notion which caused the error in the first place?

"Strongly typed" doesn't mean "narrowest data type" -- it only means "narrowest APPROPRIATE data type" for the range of values in question.

The answer in this thread seems to imply raising the 'strongly typed' Integer to a less 'strongly typed' Long.

Integer is inappropriate, so could not be strongly typed -- it can't even hold all the values needed. The strongest data type is Long Integer. Weaker data types would be currency, single, double or variant. The latter will restrict nothing at all, as it will accept any value, Null or string or numeric or date or whatever. Currency, single and double are inappropriate if you're storing only whole-number values. Thus, for the value of the constant in your example, long integer is the most strongly typed data type.

You said the same thing yourself with >> In this case, your constant is too large to be stored in a VBA Integer variable, which is limited to values from 32,768 to 32,767. The Hex number &H10000 is 65536 decimal, so you have to make the constant a Long.<<
(That quote is in itself wrong because it should have read from -32,768 to 32,767, {not 'strongly typed' at post time.})

Heh! Yes, I guess I missed catching the negative sign when I copied it from the help file.

By all means state your case, whatever it may be. But please do not try to overstate your case; it will make you a target as I think you already know.

I am prepared to argue the case for 'weak data types' but only if you are prepared to reply without overstating your case in some absolute manner.

You seem to have read a post that I didn't write.

Really, the question of strong data typing is orthogonal to the question of converting the VB.NET variable type to the correct VBA data type. It's not even a question of choosing a different data type -- VBA's long integer *is* the same as VB.NET's integer (if I'm not mistaken) -- it's only the name that is different (confusingly so, yes).

If offered the observation on strong data typing more or less as an aside, not as an explanation of why your code needed to be corrected. For any realm where the values are known to be limited to the range of the VBA integer type, then integer is the correct type (unless something more restrictive is better, e.g., Boolean if the values are purely True/False). This is *not* because of a quest for storage efficiency, but entirely to make sure that your code will puke if you try to feed it data that is outside the range of the appropriate values.

 

[ChrisO]

Thank you for your reply David.

My first comment is to cleanup a statement I made. (Sorry to quote myself.)
>>But please do not try to overstate your case; it will make you a target as I think you already know.<<
That was in reference to your title, which you and I currently share, on another site and perhaps share it for the same reason.

And so on to the subject of ‘strongly typing variables’.

It will be my intension to raise a question, in the minds of readers, as to when ‘strongly typing’ comes into play.

My first point would be to agree with you if the person is a reasonably good programmer.

My second point would be to disagree with you because most people who use VBA aren’t programmers at all but are in fact just people wanting to get the job done.

Please let me try to explain…

VBA is a programming language targeted at applications. Access, Word, Excel, Power Point, Outlook, AutoCAD, RSView, Citect…fill in the one’s I’ve missed.
As such, it is also targeted at the people who use those applications and they may not be programmers.

The aim of VBA should therefore be to get the job done.
To satisfy that aim VBA should be ‘syntax tolerant’.
By placing restrictions on data types it decreases ‘syntax tolerance’.
The best variable type for ‘syntax tolerance’ is the Variant.
Conversely, the worst variable type for ‘strongly typed variables’ is the Variant.

‘Out of the box’, what do we get with VBA?
We get Option Explicit turned off. (Yes there is a certain cringe factor with that situation.)
But what that leads too, by default, is non-declared Variants.
So, by default, VBA becomes more ‘syntax tolerant’ and less ‘strongly typed’.

I don’t think that is a mistake by Microsoft, they have been asked many times to turn it on but have not done so.
I think it is an attempt to make the product (VBA) usable by people, not just programmers.
All in all, I think Microsoft have done a pretty good job with that flag.

Overall, I think VBA is somewhat different from other programming languages in that it is designed to be ‘syntax tolerant’ so that it may be used by people, not just programmers.

You and I, as programmers, may not like that situation (I know I don’t) but it must make very good commercial sense, to Microsoft, to have such a program available for the applications and the people who use them.

PS.
Be carful how you use Booleans, they can bite in the strangest way.

PPS.
To anyone else reading this, if you haven’t already done so…turn on Option Explicit.

Regards,
Chris.

 

[dfenton]

My first comment is to cleanup a statement I made. (Sorry to quote myself.)
>>But please do not try to overstate your case; it will make you a target as I think you already know.<<

That was in reference to your title, which you and I currently share, on another site and perhaps share it for the same reason.

I'm sorry, but this is pure gibberish to me. I haven't a clue what you're talking about.

most people who use VBA aren’t programmers at all but are in fact just people wanting to get the job done.

This is an Access forum, so the context is not one that applies to anyone but Access programmers (or users of Access who create code with the wizards and so forth). Since Access is a database application, strongly-type variables and data types in fields are a necessity for maintaining data reliability and integrity.

The requirements of database applications are different from other types of apps, and thus, the use of variables should be different.

‘Out of the box’, what do we get with VBA?
We get Option Explicit turned off. (Yes there is a certain cringe factor with that situation.)

This is UNTRUE for any version of Access except 2000. The justification for having modules created by default without OPTION EXPLICIT in A2000 was for consistency with all the other VBA apps (it was part of the introduction of the VBE, which previous to 2000, Access did not use). Microsoft recognized that this default was a MISTAKE and changed it back in the next version of Access.

Thus, Access is NOT consistent with the other Office apps, and the reason is because Access is a different kind of app, where strongly-typed data is more important, because the code is interacting with a database, where data types are strongly enforced.

I don’t think that is a mistake by Microsoft, they have been asked many times to turn it on but have not done so.

Eh? What are you talking about? OPTION EXPLICIT is the default for new modules in all versions of Access *except* 2000. I don't know, nor do I care, whether MS has refused to default to OPTION EXPLICIT in the other Office apps, as I don't program in those apps.

And those other apps are not directly relevant to discusions on this site, because this is an Access site.

 

[ChrisO]

David.

>>I'm sorry, but this is pure gibberish to me. I haven't a clue what you're talking about.<<

Your title on UA is ‘Utterly Banned’ and we currently share that title.
It doesn’t concern me all that much but you may be interested to know that this link was got directly from Google. There was no need to go to UA and log in, so your customers may see it and I can’t think it doing you or your company any good. Also, you may want to consider that this post might also end up on Google and that is the reason for me not stating it clearly in the first place.

So ‘gibberish’ has its place but, of course, that is entirely up to you to call it what you will.


And so, back to business…

------------------------------

Luke Chung
President of FMS, Inc.

No date available.

>>By default, Access/Office ships with this option turned off, so be sure to turn it on.<<
http://www.fmsinc.com/freE/NewTips/VBA/Option/index.html

That was still his opinion a few weeks ago at Dev Con in Brisbane.
His argument was that it is done to reduce calls to Microsoft.
My argument was that it is done to help make it work in VBA.
On considering both arguments carefully I should have said it would amount to the same thing.
(Luke’s was an aim, mine was a method.)

------------------------------

Kathleen McGrath
Microsoft Corporation
June 2003
>>Declaring Variables. In VBA, you can use the Option Explicit statement to enforce explicit variable declaration. You can also set this automatically by selecting the Require Variable Declaration check box in the VBA IDE options, which by default is not selected. All implicitly declared variables are of Variant type.<<
http://msdn.microsoft.com/en-us/library/aa192490(office.11).aspx

------------------------------

So what I would prefer is not some typed statement of fact but a link to one or many sites that state the Option Explicit default in VBA. (Please note VBA not VB)



As to your statement: -
>>And those other apps are not directly relevant to discusions on this site, because this is an Access site.<<
This site may be predominately an Access site but it is not restricted to Access.

It is still my contention that VBA is different from other languages.
It is different in that it is required to work in many different applications.
It is different in that it is required to work for people, not just programmers.
It is different in that it is required to be ‘syntax tolerant’.
It is different in that it is required to work…most of the time.

Regards,
Chris.

 

[funderburgh]

I appreciate all of the discussion on this problem, but I am still having an error. I have two projects for this smart card application outside of Access. VB.NET version works and VB.6 does not (outside of Access).

When I crib code from the VB6 app into access I get the same result, it does not work. When I crib from VB.Net I get the overflow message.

As I examine the two projects, they are identical, except for the data declarations i.e.:

VB.6:
Public Const OKERR_SCARD__E_CANCELLED As Long = &H80100002 '@cnst The action was cancelled by an SCardCancel request

VB.NET:
Public Const OKERR_SCARD__E_CANCELLED As Integer = &H80100002 '@cnst The action was cancelled by an SCardCancel request

If I simply change everything to Integer, I am essentially changing to the application that does not work.

I am grateful for any ideas.

 

[ChrisO]

Funderburgh.

>>If I simply change everything to Integer, I am essentially changing to the application that does not work.<<

I don’t know who suggested changing everything to Integer but in Post #5 I did suggest changing all Integers to Long.

Make several backups.
Do a find and replace. (Integer to Long)
Turn off any error handling that might be in place.
Compile and fix any errors.
Run it.
Report back any errors including the line(s) on which the error(s) occur.

Please remember, we can not see the code so you will have to post as much code as possible.

 

[dfenton]

Option Explicit is on by default in Access *after* A2000. All other Office programs default to having it off and always have.

I don't have a pristine Access installation to check this on, nor do I have the time or interest in re-installing Access to check.

The articles you cite are simply out of date.

I think we're done here.

 

[ChrisO]

I would be glad to be proved wrong, David, so can you please supply the proof and not just statements which you believe to be the fact.

 

[funderburgh]

I appreciate the interest. Here is an example of the VB.6 code that does not work, this is the function to find the smart card reader:

Public Declare Function SCardListReaders Lib "WINSCARD" Alias "SCardListReadersA" _
(ByVal hContext As Long, _
ByVal mszGroups As Byte, _
ByRef mszReaders As Byte, _
ByRef pcchReaders As Long) As Long

The VB.Net code is identical except hContext,pccReaders and the final designation are set to Integer.

The VB.Net project works. I don't have explicit error checking in my trial app in Access. I am basically just trying out a function, like the one above and checking the error code.

The VB.6 fountions returns "reader not found", the VB.Net returns an overflow.

Thanks for the help

 

[ChrisO]

Option Compare Database
Option Explicit

[color=green]' API call from inside ACCESS.[/color]
Public Declare Function SCardListReaders Lib "WINSCARD" _
                 Alias "SCardListReadersA" _
                           (ByVal hContext As Long, _
                            ByVal mszGroups As Byte, _
                            ByRef mszReaders As Byte, _
                            ByRef pcchReaders As Long) As Long
                 

Sub TestSyntax()
    Dim hContext       As Long
    Dim mszGroups      As Byte
    Dim mszReaders     As Byte
    Dim pcchReaders    As Long
    Dim lngReturnValue As Long
    
    [color=green]' A list of unknown arguments passed to the API function.[/color]
    hContext = 123456       [color=green]' value range -2,147,483,648 to 2,147,483,647[/color]
    mszGroups = 64          [color=green]' value range 0 to 255[/color]
    mszReaders = 128        [color=green]' value range 0 to 255[/color]
    pcchReaders = 654321    [color=green]' value range -2,147,483,648 to 2,147,483,647[/color]
    
    lngReturnValue = SCardListReaders(hContext, mszGroups, mszReaders, pcchReaders)
    
    MsgBox lngReturnValue   [color=green]' Returned 6 on my machine.[/color]

End Sub

The above runs on my machine with no references set so it would seem it is already used by Windows.

I have no idea of what the passed arguments mean but you should be able to find those on the net.

Hope that helps.

Regards,
Chris.