Dwain, that first code worked perfect, the second one only has D/N/P/Y appearing for district 000, which may or may not work live. Since the first one does work the way that I need, that's the one that I'll use. I'd never used that format of a Select, most of my time has previously been spent in a DBA role. This greatly improves the fairly ugly code that I was dealing with. Much thanks!

Joe, the reason for a filtered view on the Students table is that I'm implementing row-level security. People assigned to one district are not normally allowed to view student data details of kids in another district: FERPA privacy regulations, not unlike HIPAA. The view provides that isolation quite nicely, I'd welcome a good suggestion for other ways to do it. Even though I'd rather not have views calling views, I prefer to have the security established in one view that works well than risk copying the code every time that students are referenced and potentially omitting or breaking it.

A join only between Districts and Students would not satisfy my need because not all APHCodes would be represented all of the time which would break the downstream report. Putting in a zero value record is for the downstream report to get consistent columns since it's doing a crosstab, I wanted all values represented. It has nothing to do with moving values.

As far as field names are concerned, they are based on the state-level data model which I'm following to maximize familiarity for the users using my app with other apps that I have no control over. If you have a link to an ISO guide to data element naming conventions for the education industry, I'd love to see it.