Long Number problem

[scoob8254]

hi

i have an issue with what i thought was a simple bit of maths, i hae a formula to convert one sort of id to another, but because the key involved is a very large number, access doesnt handle it like i expected it to.

is their a work around ? below is a quick example

(145774 * 2) + 76561197960265728 + 1

here is an example how i want access to handle it, the 76561197960265728 number is the key, but soon as i input the key into vba it gets converted to this
7.65611979602657E+16, the final result is also in this format as the result is also a very large number.

if i do the maths by hand with a calc everything is fine, basicaly just want access to do the maths i want it to and give me a straight answer

any help appreciated
scoobs

 

[Freshman]

Wow - that is quite a number you've got there.
Let me guess - are you using it to asign some sort of a unique key to be used at a licence number for your software? Or why does it have to be that big a number.

If so, all you need is a really long number (not big number) and there is an easier way to do that.

 

[JamesMcS]

That's a biggie! Does changing the field data types in the table do any good? I remember seeing this once before and for me it was just a case of widening the columns... but that would be too easy

 

[scoob8254]

its a unique id, unfortunatly i dont have control over how long the number is, and the long number thats causing the problem is static, no idea why they picked that number, but since they using that as a key for how they generate the unique ids i cant change it..

bit suprised the windows calc can handle a number of that length but vba cant

scoobs

 

[JamesMcS]

It might be something to do with data type, I know that each one has upper and lower bounds.... might be worth a look at but other than that I'm stumped - actually the only other thing I can think of is to store the result as text, I'm sure it can handle the calculation, using cstr(expression). It'll get rid of the E+... but it's a bit clunky

 

[scoob8254]

That's a biggie! Does changing the field data types in the table do any good? I remember seeing this once before and for me it was just a case of widening the columns... but that would be too easy

the number wont be saved in any tables, will just be displayed in a form thats it, basicaly its a number thats appened to the end of a url to display a persons personal page, that formula is a way of generating the id they use in the url from their authid

 

[JamesMcS]

Ah I see. So does CStr do any good?

 

[scoob8254]

Ah I see. So does CStr do any good?

ill try that, just got to nip out for an hour or two then will give it a try,

cheers
scoobs

 

[Freshman]

Gosh - I played around with (I think) all CStr and other Text format possibilities and got nowhere.

You said the ID is static. Do you mean they use it as a type of a algorithm refrence?
If so, is it possible to work with only a part of the ID and patch it together again afterwords? Something like this:

NewUID = Right(Me.UID, 10)
NewUID = (145774 * 2) + NewUID + 1
NewUID = Left(Me.UID, 7) & NewUID

With the above:
UID: 76561197960265728 result in
NewUID: 76561197960557277

Which is what Win Calc also gives me.

 

[scoob8254]

Gosh - I played around with (I think) all CStr and other Text format possibilities and got nowhere.

You said the ID is static. Do you mean they use it as a type of a algorithm refrence?
If so, is it possible to work with only a part of the ID and patch it together again afterwords? Something like this:

NewUID = Right(Me.UID, 10)
NewUID = (145774 * 2) + NewUID + 1
NewUID = Left(Me.UID, 7) & NewUID

With the above:
UID: 76561197960265728 result in
NewUID: 76561197960557277

Which is what Win Calc also gives me.

think your onto something, they key is so huge a number the digits on the left prob wont move at all,

ill try it but think it will work like you said

scoobs

 

[scoob8254]

works a treat, thanks every1