>George,
>
>I use them to concatenate interger values.

Jim,

Yeah, I thought of that possibility with 64 bit integers (LCIDs).

After doing some, admittedly half-baked, tests. I found little difference between using BINTOC() keys as opposed to integers, except in the area of indexing, where the integer keys were about 5% faster. Optimized and un-optimized LOCATEs were about the same.

Then I did something that will probably get my hacker's license revoked < s >, I read the docs. What I'm about to state is conjecture. I haven't done any testing yet, so readers of this post should take it with a sizable grain of salt. However, the conclusions, in my mind are logical.

If you have a situation where the recordsets are small (and I have a number of these), using BINTOC() can help reduce the table and index size. It also should (this is where the salt part comes in), result in improved performance. Assuming a maximum record count of 32,767, the integer keys could be stored in a two byte as opposed to a four byte field, with BINTOC(lnKey, 2). This, naturally, leads smaller table and index sizes, and should, because of fewer comparisons, improve performance.

I didn't mean to answer my own question. Still, I'm going to go back and find Mac's article and re-read it.

Thanks for the feedback,