unsigned integer in MS Access

[Chris Mills]

Thing i would like to do is let access accept unisgned integers, but i don't
know

how. Is it even possible?

You can invent anything you like, but in outside objective reality you can see
the Access data types just as well as anyone. Allen said as much. ;-)

When Allen or Brendan or Albert becomes the writer of MS-Access, I'm sure they
won't mind changing it for you. )

Putting byte values in an integer data field, or single values in double

field I don't really feel comfortable with.

Why? they're the same just larger. An integer is an integer just the max value
varies (in this case, is larger). I put binary data in a text field which
Access handles magnificently (for PrtDevMode) because you can actually extract
the 8-bit bytes.

You said it shouldn't have been a big problem. Indeed it is not, IMHO. You
always have the choice of a "better" platform.

I already said i will not reply to this thread,

Oh.

 

[Albert D.Kallal]

Btw, i don't have currencies in access, only doubles, decimals and singes

as
an option to Longintegers...

Why don't you have a currency in access? It is a defined, and supported data
type in both VB(A), and also in JET tables.

It is a 8 byte singed integer, and should provide ample room for summing.
(support for the packed decimal type is poor at best in ms-access).

If i seem a bit sarcastic, i will explain it in an other post, above.

No, it has not been explained to me. I have no idea "why" you don't have
currencies in access? I absolute nothing wrong with using a currency data
type here. That currency data type is a scaled integer of 8 bytes long, and
should suffice for your needs...

A currency data type has a max value of

+/- 922337203685477

(the above ignores that we actually have 4 decimal al places to the
right..but it is actually a scaled integer)

The max value of a 32 integer

4294967294

So, we get:

? 922337203685477 / 4294967294
214748.3649

Hence, as long as your file is less then 214 thousand records, then the
currently data type (in both JET, and VBA) should suffice for your needs.
Further, that 214,000 reocrds would assume a MAX 32 bit value, and that
would likey be a bad assumption on my part. So, it would seem you got lots
of head room here with a currecy data type.

The fact that it is called a "currency" type is not a issue, but it is a
HANDY 8 byte signed integer data type that is scaled to 4 decimal places.

I don't think you need the decimal places, but so what. Once again, the
currency datatype does seem to be your solution here, and I still not seeing
why it is not your first choice.

The suggestions here to use a long is NOT a good idea, as they can EASILY
experience a overflow with your type of data (however, currency can handle
this data with ease).

So, once again, the only reasonable choice here is to use currency type.
(unless there is more information given that would eliminate currency as a
choice here)

 

[Brendan Reynolds]

Perhaps he's looking at 'Field Size' in table design view, instead of 'Data
Type'. It would be an understandable enough error in someone not familiar
with Access. I've never understood myself why 'Decimal' is a 'Field Size'
while 'Currency' is a 'Data Type'.

 

[Guest]

The answer is already given by Allen: It's impossible. He seemed to

You are oversimplifying

You can store an 32 bit unsigned value in an Access/Jet/VBA "long",
if you want to.

Converting uInt to signed is not realy an option as I have to sum all
the imported data regulary.

So? They still sum correctly. Certainly this is the easiest
way if your sums will fit into 32 bits.

However, if your imported numbers are so large that you
had to USE the extra bit in the unsigned 32 bit representation --
then you are going to have overflow problems when you
sum them.

The sign bit is the "most significant bit" in the binary representation.
Anything which uses this bit for magnitude representation can't be
summed without overflow problems.

So you will have to use a larger data type to do the summation.

By the way, 32 bit integers can also be stored without error in
doubles: doubles can store 52 bit integers.

(david)

 

[Albert D.Kallal]

Perhaps he's looking at 'Field Size' in table design view, instead of
'Data Type'. It would be an understandable enough error in someone not
familiar with Access. I've never understood myself why 'Decimal' is a
'Field Size' while 'Currency' is a 'Data Type'.

Yes, the above makes sense. The problem here is that you can't have a
un-signed 32 bit integer, and Allen is correct. However, while you can't
have a 32 bit unsigned integer, there are other data types in ms-access that
will easily handle the un-signed values anyway. This is really just a case
of
a persons mind closing up, and looking at things through a straw.

The OP is viewing this problem as a open and shut case, since we can't have
a
32bit un-singed integer.

Perhaps what is not realized is that the regular access commands (and sql)
such as "sum" will operate with the currency data type, and will NOT
overflow for the 32 bit integer use the OP requites. Point in fact that
currency data types are a 64 bit signed integers.

These values should both import, export, and work well in any kind of
calculations and code that the original poster needs.

Oh well, try as we may, it seems this approach escapes the original
author....

 

[Chris Mills]

If he's worried about summing, and worried about 32bit signed which is half
the size of 32-bit unsigned, then something's wrong - he's going to get into
overflow anyway - IF he NEEDS unsigned for base storage then he's in the
"upper half" and the first sum might well overflow. Theory - not Statement


Anyone getting anywhere near the capacity of a field is heading for overflow
trouble sooner or later. Unsigned vs Signed is only 2:1 capacity vs (say)
Currency. Statement - not Theory )

In any case the Responders have given many Options...and it seems to me Access
has just about as many number options (even if different) as almost anything
else. "Enough" for the "average" user anyway ))

I've always been amazed how you can use text fields for full binary, byte,
nibble manipulation of basic storage such as Operating System structures...I
would have expected Access to have at least SOME limitations )))

I personally have appreciated all the technical replies given here,
Chris