Thank you guys for your thoughtful response!

I really like the idea of just using 7 bits and keeping the 8th a '1', thus ruling out the possibility of ever having a #0. It is an easy conversion in my routine and storage.

As far as I know NONE or OCTET is the closest thing to rawbyte, but as I mentioned (and another responded) the string is being truncated at the first #0. His comment is probably true: somewhere in IBO this is happening. Waiting on the IBO forum to respond.

Adding another table with a couple of columns seems like too much, too. I was thinking of abandoning my attachment to the BIN to Char conversion, which ultimately is arbitrary. A simple encryption of the BIN string would probably work well, too, albeit longer, but really, even if 8x as much storage we are not talking about much.

BLOBs just seem like over kill for storing a max of 64 chars!

Not sure I follow how to OR, AND the bytes.  What does x80 and x7F do?

Thank you, both!

Chuck

Hi Chuck

I am a Firebird newbie so don't know if Fbd will let you do what you want. Perhaps there is a fixed length raw byte field you could use, or perhaps a blob?

If it does not, then a more efficient work around than the one yours would be to store only seven bits to a byte, forcing the top bit to 1.

This is an inefficiency in terms of storage space but the complexity on retrieval would be simplified greatly, as would the home grown code to repack the data. And you save the storage overhead of the subrecord sequence numbers.

The packing routine would move 7 bytes of data into each 64bit word, and vice versa on retrieval.

An even cruder hack to save packing and repacking the data is to process it in 7bit form throughout. Before storing you would OR each byte with x80 and on retrieval AND it with x7F. That would mean having a dummy group every eighth group that nobody ever belongs to, which moves the complication elsewhere in your code.

Either of these workarounds would be more efficient for data access, more efficient in running your custom code  and easier to write that code too.

Could that be worth an extra 1/7 cost in storage space?

Regards

River~~

On Sat, 4 Aug 2018, 01:30 Chuck Belanger phytotech@... [firebird-support], <firebird-support@yahoogroups.com> wrote:

 

Hello:

I have been using a string of '0000's and '11111's to indicate access to
the underlying position in a database. I have been storing this string
of '000111' combinations by converting to a set of characters
representing each 8 "bits" of the actual 0s and 1s.

The problem I am facing is how to store those occasional strings that
look like this:

'ü@'#0'0'#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0#0

It is not so much all the null characters after the '0', but that null
character between the '@' and the '0'. The above string is created and
stored in a string just as you see it, but how do I store it in Firebird
, preferably as-is in a table field?

I have tried rawbytestring but that truncates the string at the first #0
character, thus losing the information in the '0' (or some other
character) that follows.

I have not run across this issue before, but as my list of possible user
access groups grows, it is apparent that some users have 8 positions
without having access to any of the related groups, thus the #0 in the
string. And that would be OK, except that they do have access to some
group or groups after those 8 positions. Right now, the access code
truncates that part of the access code information because of the #0.

My only solution right now is to create a new table in a one:many
relation, such that I can have more than one record per Access code.
Each record would hold the characters up to the first #0 character
behind the character set. I would then store the number of #0 characters
that follow the string. That way I can iterate through the records and
reconstruct the original '0000's and '11111's string.

Any thoughts?

Thank you,

Chuck

I did post this on IBObject forum, too. I do use IBO for my database
access. I use Firebird 3.0 on WIndows, mainly desktop. I use NONE as my
default Character Set.

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Virus-free. www.avast.com