Drawing a enterprise geodatabase line with symbol from a related Enterprise geodatabase table not working.

[PaulHuffman]

I'm still trying to get used to Enterprise geodatabase 10.3.1 based on SQL 2012 R2.  Migrated all my data over from SDE 9.3.1.  Then I thought I'd move in some data from NHDPlus so I could offer my users a few layers of streams  with line widths symbolized by average annual flow  for different scales using a relate to the NHDPlus EROM_MA0001 table.  I moved a file geodatabase containing the stream lines and table with indexes on the join items in each table over to the new enterprise geodatabase server.  Imported the feature classes and table into an existing SDE geodatabase.  The indexes seemed to be preserved in the import.  But the strange thing is that when I set up the relate between the SDE line feature class and the SDE table, then try to symbolize the line width by flow from the related table, the feature class doesn't draw.  I get a warning that sampling has reached its limit when I set up the symbology,  but I continue to manually classify the symbol ranges to spread them from minimum to maximum flow.

I tried some other tables and combinations of relates.  It appears that if the feature class and the table are both in the enterprise geodatabase,  nothing draws.  If either or both the feature  class and the table are the file geodatabase,  it draws as expected with graduated symbols.  Tried a feature class that is a geographically selected subset of the whole line feature class but got the same disappointing results.

Is the enterprise geodatabase somehow getting tangled up when both the feature class and the table are in the same geodatabase?  I thought I would be improved draw performance with the enterprise geodatabase.

[PaulHuffman · Accepted solution]

It appears that there were two different problems.  With Ahmed from ESRI Customer Care,  I figured out that something was wrong with the first copy of the table. I made a new copy of the EROM table into SDE and that helped. Unknown what was wrong with that first copy.  But we also found out that when making the Join, I had to check the box to use the "Keep only matching records" option.  If either the feature class or the table was from the file geodatabase,  "Keep only matching records" was not necessary.

The NHDPlus Feature Class is a line feature class with 272340 records.  The joined table EROM has 238811 records.  But there are 39529 records in the Feature Class that have no match in the table. I didn't know there were that many mismatched records. I had to run the selection again to be sure.  These unmatched records with a null value in the graduated symbol item seemed to upset the drawing in the SDE feature class - SDE table drawing, but the other pairings were not as sensitive.

I did some further testing with the complicated  graduated symbology and differences in draw times with SDE and File Geodatabases.

SDE Feature Class - SDE table - Keep Only Matching records-        draw time 9.7 seconds

SDE Feature Class -  FGDB table - Keep All -                                                  58.0 seconds

SDE Feature Class -  FGDB table - Keep only -                                               51.7 seconds

FGDB Feature Class - FGDB table - Keep Only -                                             44.7 seconds

FGDB Feature Class - FGDB table - Keep all -                                                 48.3 seconds

These are the kind of performance gains I was hoping for with SDE!  I'm glad it works.