uint32 in Access 2007

  • Thread starter Thread starter Donar
  • Start date Start date
D

Donar

Good evening, Ladies and Gents,

I need to store an uint32 in an Access 2007 column (range 0 to
4Gig-1). It appears, that A2007 does not provide uint 32 bit, nor int
64 bit. But maybe I am wrong and can't see it?

I hesitate to use floating point values, due to the time needed for
conversions between IEEE and ints, and frankly I am also fearing
possible rounding issues (the div 0 bug is still remembered).

Decimals seem to have their issues as well. At least when googling, I
find a lot of them.

So, what do you recommend instead? FieldHi for the MSB 16 bit and
FieldLo for the 16 LSB? Something else?

Thanks for your input.

Best regards,
//Donar
 
There's a critical piece of information we need to know...

Do you need to do calculation upon the number?

If you don't have to, then you can get away with storing it as Text or
two long integer (both have their tradeoffs; text is more expensive to
store, but requires no concatenating everytime we read it whereas two
long integers is easier on space but we have to consistently
reconstitute the parts.)
 
Good evening, Ladies and Gents,

I need to store an uint32 in an Access 2007 column (range 0 to
4Gig-1). It appears, that A2007 does not provide uint 32 bit, nor int
64 bit. But maybe I am wrong and can't see it?
Click to expand...

Clashing jargon. A Number... Long Integer is a 32 bit whole number, equivalent
to uint32. 64 bit integers aren't directly supported but Decimals do work and
could be used if you need more precision.
I hesitate to use floating point values, due to the time needed for
conversions between IEEE and ints, and frankly I am also fearing
possible rounding issues (the div 0 bug is still remembered).

Decimals seem to have their issues as well. At least when googling, I
find a lot of them.

So, what do you recommend instead? FieldHi for the MSB 16 bit and
FieldLo for the 16 LSB? Something else?
Click to expand...

Number... Integer for 16 bit, Number... Long Integer for 32.
 
John said:
Clashing jargon. A Number... Long Integer is a 32 bit whole number, equivalent
to uint32. 64 bit integers aren't directly supported but Decimals do work and
could be used if you need more precision.
Click to expand...

Actually, not quite. Both long integer (also known as int32) and uint32
are indeed 32 bit but they represent different ranges owning to the one
bit being treated as signed for int32 and just one more place value in
unsigned.

If we placed a int32 containing a value of -1 in a unint32 bitwise, we
would get 4,294,967,295 in return.

If the OP needed numbers bigger than 2,147,483,647, the maximum number
in a int32/long integer then there may be an issue.


But I had a thought. One feasibly could get away with using int32 to
represent uint32 values if one took steps to convert the value
correctly. Would the coding/setup be simpler than the alternative I've
posted? I'm not sure.

In one application I needed 128-bit number for cryptography and of
course Access couldn't handle this, so I chose to use Text and reference
a .NET library capable of performing arbitrary precision calculation.
 
John said:
Clashing jargon. A Number... Long Integer is a 32 bit whole number, equivalent
to uint32. 64 bit integers aren't directly supported but Decimals do work and
could be used if you need more precision.
Click to expand...

Actually, not quite. Both long integer (also known as int32) and uint32
are indeed 32 bit but they represent different ranges owning to the one
bit being treated as signed for int32 and just one more place value in
unsigned.

If we placed a int32 containing a value of -1 in a unint32 bitwise, we
would get 4,294,967,295 in return.

If the OP needed numbers bigger than 2,147,483,647, the maximum number
in a int32/long integer then there may be an issue.


But I had a thought. One feasibly could get away with using int32 to
represent uint32 values if one took steps to convert the value
correctly. Would the coding/setup be simpler than the alternative I've
posted? I'm not sure.

In one application I needed 128-bit number for cryptography and of
course Access couldn't handle this, so I chose to use Text and reference
a .NET library capable of performing arbitrary precision calculation.
 
So sorry about double-posting.

I wished I thought of it before but there is a better alternative: Currency.

Currency is essentially decimal capable of 15 digits to left, 4 to
right, which is just big enough for uint32 and then a bit more and has
none of the problem Decimal suffers from.

Much easier than mucking with the other solutions I mentioned before.
 
So sorry about double-posting.

I wished I thought of it before but there is a better alternative: Currency.

Currency is essentially decimal capable of 15 digits to left, 4 to
right, which is just big enough for uint32 and then a bit more and has
none of the problem Decimal suffers from.

Much easier than mucking with the other solutions I mentioned before.
Click to expand...

Thanks, Banana. I should have binged the term uint32!
 
Banana said:
Do you need to do calculation upon the number?
Click to expand...

Trouble is Access wouldn't be able to do any calculations with the
numbers anyhow. Or maybe with an exceedingly large amount of jiggery
pokery such as creating mathematic libraries in VBA.

Thus I'd suggest a text field or use a product that supports uin64
such as, presumably, C# or VB.Net.

Tony
 
Thanks all for your participation and your the contributions!

I made up my mind and decided to go for two words storing the 16 most
and 16 least significant bits each, resp., i.e. two de-facto uint16's
stored in two int32's.

This makes it easy to convert forth and back with a simple shift and a
boolean operation, while avoiding all the issues with the fancy data
types. Of course, a SELECT's WHERE clause is a bit longer.

Thanks again.

Best regards,
//Donar


On Oct 7, 4:50 am, "Tony Toews [MVP]"
Thus I'd suggest a text field or use a product that supports
uin64 such as, presumably, C# or VB.Net.
Click to expand...

@Tony: I think you do misunderstand the problem. I do use C# (in
ASP.NET 3.5 with IIS 7). C# does understand uint32 perfectly well.

However, the project dictates that an Access 2007 32-bit database is
being used, and it is this Access that won't support uint32 nor int64
(just int32 or int16).
 
Back
Top