Frustrated....dec 2 hex (1 Viewer)

I can't for the life of my figure out how to set a field to convert the previous fields decimal input to hexadecimal automatically when moved to next field. Any advice?

ex: Field A = Dec, Field B = Hex

Field A Field B

210013 3345D


How do I get Field B to populate automatically with the hexadecimal of Field A???:banghead:

Use the HEX() function perhaps?

I did give that a go but it requires a number. I attempted the Hex$ as well with the field I am trying to convert and it also errors stating the field is not a field lol

Wyo said:

I can't for the life of my figure out how to set a field to convert the previous fields decimal input to hexadecimal automatically when moved to next field. Any advice?

ex: Field A = Dec, Field B = Hex

Field A Field B

210013 3345D


How do I get Field B to populate automatically with the hexadecimal of Field A???:banghead:

Click to expand...

Hi, not sure what you want to do with this. In database design, it makes no sense to store the same number in two fields which only differ in numerical notation. The way to do it is to store the number as decimal and use the hex notation as you need, as a function in a query.

Best,
Jiri

I know:-( Boss man wants them both in the database.......

Best I can think of then is run a query to update B from A when required.?
If in a form, then it is not a problem.?

Requires code (macro or VBA) to save calculated data or run an UPDATE action. I agree, makes no sense. Also, risk of data getting 'out-of-sync'. Dynamically calculate when needed.

Is the boss savvy enough to catch that the decimal is stored but the hex only exists in a query? You can (truthfully) tell the boss that Access works better when things are driven off of a query. People shouldn't be futzing around directly in tables anyway. AND the hex value IS stored in the database anyway. A LONG is internally stored as a binary number, and Hex is merely a regrouping of binary in chunks of 4 bits at a time. To be honest, the only reason you see a decimal number is because the field type has a default of base 10.

The data is actually stored as a 4 byte word.

Each byte contains 8 bits. Each half byte contains 4 bits. So 4 bits can contain 16 combinations, representing numbers from 0 thru 15. In Hex, 10-15 are replaced by letters A to F so you get 0-9,A-F - hence Hexadecimal, meaning 16.

So your 4-byte word represents 8 hex characters. 3345D will actually be stored in the word as

0003345D, ( it might actually be in a different order, but that doesn't matter really)

Now whether you choose to view this as one of the following.

0000 0000 0000 0011 0011 0100 0101 1101 (which is how it is stored based on your Hex number - I have just added the gaps to make it easier to see )

or 4 single bytes 0 3 52 93
or 4 signed single bytes, which might be different again
or the 4 ascii characters represented by the above byte values, some of which are non-printing in this example.
or 0003554D (8 half bytes)
or 210013 (base 10)
or even used directly as the binary, giving you 32 single bit on/off flags

The largest number you can get in a single byte is 255 (2^8 -1), which in Hex corresponds nicely to FF. Hence colour code 0 (for black is Hex 00 00 00 00) and colour code whatever it is in decimal (for white) is Hex 00 FF FF FF.

The Hex colour code also corresponds nicely to it's RGB constituents. Each of the 3 FF s corresponds to the proportion of RGB in the mix. (In some systems the colours are stored as BGR, rather RGB).

so you get pure red by 00 FF 00 00
so you get pure green by 00 00 FF 00
so you get pure blue by 00 00 00 FF

red plus green = yellow,
so yellow is 00 FF FF 00
etc

this is also why we get 24bit colours - 3 8 bit combinations of RGB.

normally we would use the ascii text characters, the base 10 num, or the Hex (base 16) number whichever is appropriate.

So your boss asctually wants you to store the same thing twice! You don't want to do this. You can show it on a form or on a query in both ways. That's different. We probably do that occasionally, especially when we are talking about colours. When you use a Hex editor it will generally show you both the Hex pair and the decimal equivalent - so a space character is chr(32) (3 tens plus 2 units) or chr(20) in Hex (2 16s and 0 units)

so the reason you can't think how to do it, is because it's exactly the same. You could give the second field the field type of TEXT, and store it as a 4-byte string, (cstr(Decimal value)) but the character codes may give you problems as you have control characters in there - tabs, carriage returns and the like - but TEXT isn't going to be the same as the represention of the Hex number. It will just look like gibberish. (and it's STILL the same binary)


[just edited - I had the wrong Hex for D]