In a bitfield, the Masks are as follows:<br>
Lets say it's an Integer, 2 bytes. Starting from rightmost bit 0:<br>
Bit0=1,Bit1=2,Bit2=4,Bit3=8,Bit4=16, etc---> Bit 14=16384. (remember it a Signed integer, so if you define it as an integer field, you can't use bit 15, the sign bit, you'll get an overflow--it's best to use one long int bitfield per 31 datafields)<br>
<br>
Use an OR mask to set the bit, an AND mask to read it:<br>
<br>
You have 8 fields (simplified)<br>
Field# 2 (zero based) was changed.<br>
In AfterUpdate of the Field, do me!bitfield = Me!bitfield OR 4<br>
the bitfield now looks like:<br>
00000100<br>
It has a value of 4.<br>
Now, field 7 changes. In After Update of the *Field*:<br>
me!bitfield = Me!bitfield OR 128<br>
Now, the bit field is:<br>
10000100, having a value of 129. <br>
To read, lets say you're checking field 7, say, in either Before or After Update of the *Form*<br>
If me(7) AND 128 then 'will return Mask's value (128) if bit set<br>
'then it's bit is set, do whatever<br>
endif<br>
Now, you need to decide when to clear the bitfield, ie, when is the 'new' data condsidered 'old data', which must then be flagged when it is then changed again--per session, per day, per user, etc--user 1 changes record, user 2 changes it back. Lots of stuff to think about.<br>
<br>
If this seems tedious, it is somewhat, but it's a tradeoff--the alternative of a separate 'changed' flag field, though, may seem easier to code, it adds so much to the weight of the table, and if it's on a network, Access would need to gather, ie, 31 separate fields to read or set these values, when a Long Integer would do the same in 4 bytes. Multiply that by a table of, say, 500,000 records, and the tradeoff decision is easier.<br>
<br>
Having said all that, remeber you have the Form.Dirty, the Form!Control.Oldvalue properties you can use as well, but only at runtime when the form is open--what the bitfield does is store the 'flags' after the form is closed.<br>
--Jim
