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
news:88442832-bf14-43b0-bb36-4b805a2c7020 (AT) o4g2000yqd (DOT) googlegroups.com...

There also a function called CLngPtr to convert expressions to a long
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
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
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
could become confusing in the future for you).

ok, lets tackle some questions:

It a real 64 bit sighed big honking integer. It is 8 bytes in size. The
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
NOT changed, and remains a 32 bit long.

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.

So, in table design mode, choose number type, and then in the drop down, you
will see the decimal type as a choice. When you choose it, you see a option
for digits (it defaults to 18, and for scale, you see 0). I would use the
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
type variant.

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


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

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

2 gig / 120 = 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.

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
Pleasenospam_kallal (AT) msn (DOT) com

On Dec 19, 4:43*pm, JohnP <j... (AT) kosmosbusiness (DOT) com> wrote:
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 (AT) msn (DOT) com> wrote in
news:9OJPo.60836$wf4.36610 (AT) newsfe05 (DOT) iad:

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
news:Xns9E54D25BFD927f99a49ed1d0c49c5bbb2 (AT) 74 (DOT) 209.136.95...

The problem here is the OP needs 17 digits. A double will not get you that
many digits.
(And, since that is floating point then it subject to rounding and you
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).

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
MORE trouble then it gets you into.

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

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

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

However, for numbers beyond double (about 14 or 15 digits), and beyond that
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
use large scale (pun intended!) integers, then the packed decimal is a great
choice IMHO.

--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
Pleasenospam_kallal (AT) msn (DOT) com

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

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.