If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
uint32 in Access 2007
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 |
#2
|
|||
|
|||
uint32 in Access 2007
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.) Donar wrote: 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 |
#3
|
|||
|
|||
uint32 in Access 2007
On Tue, 6 Oct 2009 09:50:28 -0700 (PDT), Donar
wrote: 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? 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? Number... Integer for 16 bit, Number... Long Integer for 32. -- John W. Vinson [MVP] |
#4
|
|||
|
|||
uint32 in Access 2007
John W. Vinson wrote:
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. 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. |
#5
|
|||
|
|||
uint32 in Access 2007
John W. Vinson wrote:
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. 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. |
#6
|
|||
|
|||
uint32 in Access 2007
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. |
#7
|
|||
|
|||
uint32 in Access 2007
On Tue, 06 Oct 2009 12:06:05 -0700, Banana Banana@Republic wrote:
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. Thanks, Banana. I should have binged the term uint32! -- John W. Vinson [MVP] |
#8
|
|||
|
|||
uint32 in Access 2007
Banana Banana@Republic wrote:
Do you need to do calculation upon the number? 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 -- Tony Toews, Microsoft Access MVP Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ Granite Fleet Manager http://www.granitefleet.com/ |
#9
|
|||
|
|||
uint32 in Access 2007
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. @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). |
Thread Tools | |
Display Modes | |
|
|