I have a potential need to use integer numbers up to 17 digits long.
Access03 that I currently use can go up to 10 digits (32 bit
restriction). I am wondering whether Access10 (64bit) woould solve the
problem. I understand that it has three new keywords (2 data types and
1 modifier): LongPtr, LongLong and PtrSafe, a new function: CLngLng()
and new compilation constants: VBA7 and Win64.

What is the biggest integer value that Access10 (64bit) can support?

Also what is the maximum physical table size that Access10 (64bit) can
support?

Any caveats on using Access 10 Vs Access 03 would be appreciated.

John

?"JohnP"  wrote in message=20
news:88442832-bf14-43b0-bb36-4b805a2c7020@o4g2000yqd.googlegroups.com...

>I have a potential need to use integer numbers up to 17 digits long.
>Access03 that I currently use can go up to 10 digits (32 bit
>restriction). I am wondering whether Access10 (64bit) woould solve the
>problem. I understand that it has three new keywords (2 data types and
>1 modifier): LongPtr, LongLong and PtrSafe, a new function: CLngLng()
>and new compilation constants: VBA7 and Win64.

There also a function called CLngPtr to convert expressions to a long=20
pointer data type.

As a minor note, the numbering system in versions of access is:

access 97            access 7
access 2000        access 8
access 2002        access 10   (this version was also called XP in some=20
cases)
access 2003        access 11
access 2007        access 12
access 2010        access 14

Note that 13 was skipped.

So, when you say access 10, it generally accepted to mean access 2002 =
not=20
2010.

So, it is best say access 2010, or access 14, but not access 10 when you =

mean to say 2010.
(as this as noted this is minor here, but wrongly using the version =
number=20
could become confusing in the future for you).

ok, lets tackle some questions:

>What is the biggest integer value that Access10 (64bit) can support?

It a real 64 bit sighed big honking integer. It is 8 bytes in size. The=20
range is:

-9,223,372,036,854,775,808 to 9,223,372,036,854,775,807

So, it can handle up to 19 digits as per above.

However, this will NOT help you, since in a table, the long data type =
HAS=20
NOT changed, and remains a 32 bit long.

What I would suggest in this case is to simply use a decimal column. =
There=20
are some noteworthy problems, but those columns can easily handle 17 =
digits.=20
in fact, the default is 18 digits without a decimal place. And the real =
nice=20
feature about decimal collums is they don't need the 64 bit version of=20
access. In fact, I think they go all the way back to access 2002, or =
even=20
2000.

So, in table design mode, choose number type, and then in the drop down, =
you=20
will see the decimal type as a choice. When you choose it, you see a =
option=20
for digits (it defaults to 18, and for scale, you see 0).  I would use =
the=20
default of 18 and 0 for decimal places.

Note that if you need to use this number in any VBA code, you have to =
use a=20
type variant.

You are thus best to use the above data type, and it will work in pre =
2010=20
versions (you do not need 64 bit edition to use this feature).

>Also what is the maximum physical table size that Access10 (64bit) can
support?

The allowed size of 2 gig has not been changed.  So a typical mailing=20
address is about 120 bytes (characters) in size

2 gig =3D  2,147,483,648 Bytes
1 Character =3D 1 Byte
120 Characters =3D 120 Bytes

2 gig / 120 =3D 32 million records

So, the limit is NOT the number of records..but "how many" records you =
can
fit into 2 gig.

Of course, if each customer name only takes up 60 characters...then you =
can
store 64 million records in the file.

So keep in mind that data types and size for tables are
not changed, even when running in 64 bit version of Access 2010.

I think a decimal type column should work for your needs.

--=20
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
Pleasenospam_kallal@msn.com=20

On Dec 19, 4:43=A0pm, JohnP <j...@kosmosbusiness.com> wrote:
> I have a potential need to use integer numbers up to 17 digits long.
> Access03 that I currently use can go up to 10 digits (32 bit
> restriction). I am wondering whether Access10 (64bit) woould solve the
> problem. I understand that it has three new keywords (2 data types and
> 1 modifier): LongPtr, LongLong and PtrSafe, a new function: CLngLng()
> and new compilation constants: VBA7 and Win64.
>
> What is the biggest integer value that Access10 (64bit) can support?
>
> Also what is the maximum physical table size that Access10 (64bit) can
> support?
>
> Any caveats on using Access 10 Vs Access 03 would be appreciated.
>
> John

Hi John,

I do no know what kind of calculus you want to do. But as you are
talking about very long integer numbers, you could also consider
string calculations.
In that case you can store the number up to 255 characters in a text
field, and even further if you use a memo field.

Imb

"Albert D. Kallal" <PleaseNOOOsPAMmkallal@msn.com> wrote in
news:9OJPo.60836$wf4.36610@newsfe05.iad: 

> What I would suggest in this case is to simply use a decimal
> column. There are some noteworthy problems, but those columns can
> easily handle 17 digits. in fact, the default is 18 digits without
> a decimal place. And the real nice feature about decimal collums
> is they don't need the 64 bit version of access. In fact, I think
> they go all the way back to access 2002, or even 2000.

Why not just use doubles, which have been available in all versions
of Access I've ever used, starting with Access 2? There are still
problems with the decimal data type within Access -- its
implemenantion was a sad victim of the "ADO wars" within Microsoft.
It got properly implemented in Jet 4, and in ADO, but never really
in Access at all, and perhaps not at all in DAO (not sure on that
latter). 

http://allenbrowne.com/bug-08.html

-- 
David W. Fenton                  http://www.dfenton.com/ 
contact via website only     http://www.dfenton.com/DFA/

?"David-W-Fenton"  wrote in message=20
news:Xns9E54D25BFD927f99a49ed1d0c49c5bbb2@74.209.136.95...

>Why not just use doubles, which have been available in all versions
>of Access I've ever used, starting with Access 2?

The problem here is the OP needs 17 digits. A double will not get you =
that=20
many digits.
(And, since that is floating point then it subject to rounding and you=20
really do not want that)

A  currency data type comes close to the OP requirement and has up to 15 =

digits, and another 4 to the right (so a scaled currency value might =
work).

>There are still
>problems with the decimal data type within Access -- its
>implemenantion was a sad victim of the "ADO wars" within Microsoft.

>http://allenbrowne.com/bug-08.html

The issues tend to be rather minor in most cases.

The packed decimal is REALLY NICE feature to have and gets one out of =
FAR=20
MORE trouble then it gets you into.

I find packed decimals work well if you know what to avoid. As noted, =
from=20
2003 onwards they work better, and even 2007 shows improvements in =
removing=20
minor nags.

Having written several payroll systems (one even in Pascal from =
scratch), I=20
can assure you that packed decimal support on those systems was a gift=20
horse.

The same goes for WHEN you need them in access. The ease at which this=20
poster can start using 17 digit numbers is at one fingertips with the =
mere=20
creating
of the required column in the table. For most financial work, currency =
in=20
access is the real ticket.

However, for numbers beyond double (about 14 or 15 digits), and beyond =
that=20
of currency, then decimal is a viable and reasonable choice.

As noted, there is some minor issues, but for the most part when you =
need to=20
use large scale (pun intended!) integers, then the packed decimal is a =
great=20
choice IMHO.

--=20
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
Pleasenospam_kallal@msn.com=20

"Albert D. Kallal" <PleaseNOOOsPAMmkallal@msn.com> wrote in
news:vcWPo.7694$111.6165@newsfe12.iad: 

> As noted, there is some minor issues, but for the most part when
> you need to use large scale (pun intended!) integers, then the
> packed decimal is a great choice IMHO.

Or, you need a different database engine.

-- 
David W. Fenton                  http://www.dfenton.com/ 
contact via website only     http://www.dfenton.com/DFA/

Access Data Projects can use 64 bit Integers without any trouble whatsoever.

Jet just sucks.. it doesn't support basic datatypes like BIGINT.