4cd814cfb6845b4dfa8a7a24c49c5b5a87ebdebc
galt
  Tue Feb 23 13:19:56 2016 -0800
refs #16860. Fixes bug in index order. I thought that knownGene might be immune to the need for sorting, but that was wrong after we switched to handling as single chromosomes, which adds a where chrom= clause which triggers mysql to use  some other index which disturbs the order of rows returned.

diff --git src/hg/hgTracks/hgTracks.c src/hg/hgTracks/hgTracks.c
index 0a91460..743d1c0 100644
--- src/hg/hgTracks/hgTracks.c
+++ src/hg/hgTracks/hgTracks.c
@@ -3599,31 +3599,31 @@
 	{
 	hashAdd(ktHash, row[0], NULL);
 	}
     sqlFreeResult(&sr);
     }
 setEMGeneTrack();
 if (!emGeneTable)
     errAbort("Unexpected error, emGeneTable=NULL in initVirtRegionsFromEMGeneTableExons");
 if (hIsBinned(database, emGeneTable)) // skip first bin column if any
     ++rowOffset;
 sqlSafef(query, sizeof(query), "select * from %s", emGeneTable);
 if (virtualSingleChrom())
     sqlSafefAppend(query, sizeof(query), " where chrom='%s'", chromName);
 // TODO GALT may have to change this to in-memory sorting?
 // refGene is out of order because of genbank continuous loading
-if (!sameString(emGeneTable,"knownGene"))
+// also, using where chrom= causes it to use indexes which disturb order returned.
 sqlSafefAppend(query, sizeof(query), " order by chrom, txStart");  
 //warn("query = [%s]", query); // DEBUG REMOVE
 sr = sqlGetResult(conn, query);
 
 char chrom[256] = "";
 int start = -1;
 int end = -1;
 char lastChrom[256] = "";
 int lastStart = -1;
 int lastEnd = -1;
 int chromSize = -1;
 char lastChromSizeChrom[256] = "";
 boolean firstTime = TRUE;
 boolean isEOF = FALSE;
 struct kce *kceList = NULL, *bestKce, *prevKce;