Hi Jim,

It's always good to see Bioconductor documentation but I fail to see the relevance in this case. For one thing, there was no criticism of the select function in my post. For another, the problems reported by OP could not have arisen by any of the issues that you mention. In particular, it is impossible to disassociate chromosome from symbol for any gene by using select with two columns, so OP's main problem, which is getting gene symbols without a chromosome, could not possibly has arisen that way. The advice in the help page you quote, to run select multiple times, would simply complicate OP's workflow for no purpose.

The problem is rather with the content of the Mus.musculus package itself.

I use Entrez Gene Ids in most of my workflows and I like to use the canonical gene-level annotation provided by the NCBI through its Entrez Gene website or its gene_info files. Every Entrez Id has a gene symbol and a chromosome. There is a 1-1 correspondence between Entrez Ids and symbols. For mouse, every gene is found on exactly one chromosome except for seven genes that are on both the X and Y chromosomes. Exactly the same mouse gene information as provided by NCBI can be found on the MGI website.

The NCBI/MGI mouse gene information is faithfully provided by the Bioconductor organism package org.Mm.eg.db. For example, for the genes shown by the OP we get:

> EntrezId
[1] "100043915" "668039"    "102639653" "665211"    "329575"   
[6] "100043387" "70673"     "100043764" "100043381"
> select(org.Mm.eg.db,keys=EntrezId,columns=c("SYMBOL","CHR"),keytype="ENTREZID")
'select()' returned 1:1 mapping between keys and columns
   ENTREZID  SYMBOL CHR
1 100043915  Gm4724   2
2    668039 Gm14434   2
3 102639653  Gm2007   2
4    665211 Gm14326   2
5    329575 Gm14325   2
6 100043387 Gm14305   2
7     70673  Prdm16   4
8 100043764  Gm4631   2
9 100043381 Gm14308   2

and all Entrez Ids have both symbols and chromosomes. It is easy to verify that all the SYMBOL and CHR values returned do indeed correspond to current NCBI/MGI annotation.

On the other hand, using the Mus.musculus package for the same genes gives:

> select(Mus.musculus,keys=EntrezId,columns=c("SYMBOL","TXCHROM"),keytype="ENTREZID")
'select()' returned 1:1 mapping between keys and columns
   ENTREZID  SYMBOL TXCHROM
1 100043915  Gm4724    <NA>
2    668039 Gm14434    chr2
3 102639653  Gm2007    <NA>
4    665211 Gm14326    chr2
5    329575 Gm14325    chr2
6 100043387 Gm14305    chr2
7     70673  Prdm16    chr4
8 100043764  Gm4631    <NA>
9 100043381 Gm14308    chr2

and now we have NA values as shown by the OP.

I see no logical explanation for why a geneid should ever have a valid symbol but not a chromosome. Any gene model, even a predicted gene, must be associated with a chromosome. If the Mus.musculus package didn't find any information for a particular Entrez Id, then I might put the problem down to differences in annotation databases. On the other hand, finding a symbol for a gene but not a chromosome seems to be a clear mistake. You don't like the word "buggy" (and fair enough, I have edited my post to remove the word), but this behaviour really does seem to me to be wrong.

As a developer, I find this issue very frustrating. For many years, I have been singing the praises of the org.Mm.eg.db and org.Hs.eg.db packages. But for the past few years they have issued a deprecation warning:

Warning message:
In .deprecatedColsMessage() : Accessing gene location information via
  'CHR','CHRLOC','CHRLOCEND' is deprecated. Please use a range
  based accessor like genes(), or select() with columns values
  like TXCHROM and TXSTART on a TxDb or OrganismDb object
  instead.

pushing users to packages like Mus.musculus instead. And then I have to spend my time explaining to users why they have NA chromosomes. I think it is unfortunate that users doing a gene-level analysis are being dissuaded from using the well-recognized and well understood NCBI/MGI gene-level annotation that is contained in org.Mm.eg.db.

Best wishes
Gordon