LINQ queries improvement - repetition of query
The first thing (and this is very minor) is that the expression a == true and simply a are identical. Thus you don't need all those == true's. 

The simplest, most obvious way is to simply extract a private method for your filter:

private boolean isActive(AnswerSelectLabel answer)
{
  return answer.Active
      &amp;&amp; answer.Variable.Active 
      &amp;&amp; answer.Variable.Question.Active
}

public IEnumerable&lt;AnswerSelectLabel&gt; GetAll()
{
  return db.AnswerSelectLabel
      .Where(isActive) //you'll pardon me if this is syntax error, I've been in java land too long now, where this would be this::isActive
      .OrderBy(x =&gt; x.DisplayOrder)
      .ThenBy(x =&gt; x.Value);
}

public IEnumerable&lt;AnswerSelectLabel&gt; GetByVariable(IEnumerable&lt;Respondent&gt; respondents, string idVariable)
{
  return respondents.SelectMany(x =&gt; x.AnswerSelect)
      .Select(x =&gt; x.AnswerSelectLabel)
      .Where(isActive)
      .Where(x =&gt; x.idVariable == idVariable);
}


and so on.

Slightly more sophisticated (and almost certainly overkill), is to extract some kind of interface on your answer, variable, and Question, classes. Something like 

interface IActivatable
{
  public Active { get; }
}


If you make this change, you can start to play games with exactly what you're asking to be active:

public IEnumerable&lt;AnswerSelectLabel&gt; GetByVariable(IEnumerable&lt;Respondent&gt; respondents, string idVariable)
{
  return respondents.SelectMany(x =&gt; x.AnswerSelect)
    .Select(x =&gt; x.AnswerSelectLabel)
    .Where(x =&gt; new IActivatable[]{x, x.Answer, x.Answer.Question}.all(x =&gt; x.Active))
    .Where(x =&gt; x.idVariable == idVariable);
}


which, again, we can extract a method for. But this time we're parameterized on the actual things we want to check, which is nice because it means we can pick-and-choose what we want to be active. In your case it looks like this is always answer, question, and variable, but if that's not the case this is likely helpful:

public IEnumerable&lt;AnswerSelectLabel&gt; GetByVariable(IEnumerable&lt;Respondent&gt; respondents, string idVariable)
{
  return respondents.SelectMany(x =&gt; x.AnswerSelect)
    .Select(x =&gt; x.AnswerSelectLabel)
    .Where(x =&gt; isActive(x, x.Answer, x.Answer.Question))
    .Where(x =&gt; x.idVariable == idVariable);
}

private boolean isActive(params IActivateable activatables){
  return activatables.all(x =&gt; x.Active);
}


Of course, if this isn't the case, this is just useless speculative code, so don't do it.



If I could make a couple more notes:


using strings as a catch-all for ID's has gotten me in trouble, so now I push to create specialized ID classes (where a simple GUID wont do). Don't let this burn you too!
GetByQuestion(IEnumerable&lt;Respondent&gt; respondents, string idQuestion) and GetByVariable(IEnumerable&lt;Respondent&gt; respondents, string idVariable) are suffering from a sort of linq-feature-envy. They don't use your db field at all, so why are they on this class? Do these methods exist so that I can do something like this:

var respondents = dal.GetAllRespondents();
respondents = respondents.Where(callerSpecificFilter);
var asnwers = GetByVariable(respondents, "1234");


If this is the case, and you can afford the potential performance hit, you can remove the respondents parameter and take a Func&lt;Respondent, Boolean&gt; filter instead. Then simply apply the filter yourself.