>>Regarding Mike Gagnon's suggestion, remember that you have already a series of integer values, not of 32-bit integers, but of 8-bit integers. That's what a string is. To hold 250 different logical values, CEILING(250 / 8) = 32 characters would be enough, and a string like yours "YYYNYYNN" could be represented as a single CHR(236).
>
>And four such characters are represented in memory just the same as one 32 bit integer :).
>
>I was thinking of a different solution - to chop the 250 into 50 5-bit groups, and set the lower five bits of a character as described before. The upper bits would be zero except for the 5th. IOW we'd have 50 of chr(64+lnBits) lined up in a c(50) field, scrambled with a seed taken from PK.
>
>I've already used a scheme like that, for different purposes (a space(250) with zero bit set for locked, one bit for changed - and what was locked or changed was one of other 249 fields in the current record.
>So if field 49 was changed but not locked, the substr(LockChangeField, 49,1) would be chr(32+2+0), i.e. a quote. Had a couple of methods which would retrieve a field's number from its name (from an aFields() array), then get or set a bit in the LCField. Still works, after ten years or so.

When faced with a similar setup and uneven distribution of values (for instance first tupel often all positive, last 2 tuples often all negative) I created separate "build" step randomized across records, ordering the tuples for the records in different manner described in a special order field (but named somewhat different). Helps if you are not certain that the encryption function is good enough to thwart statistical analysis by throwing another destructuring into the patterns