Create a view - Service Requests and Incidents

Question

Hi all,
I have a Service Manager 2012 environment that has gone through an in-place upgrade from SCSM 2010.
In the SCSM 2010 environment, Service Requests were implemented by extending the Incident class with an attribute that would denote whether the work item was an Incident or a Service Request.
In SCSM 2012 I would like to create a view that would combine the SCSM 2010 "Service Requests" with SCSM 2012 Service Requests.
Is it possible to create a Type Projection that performs the job of an SQL UNION statement?  If I was doing this in SQL, I'd be writing a query similar to the following:
Select *
From ServiceRequestDim
Union Select *
From IncidentDim
Where ServiceRequestType = 'Service Request'
(Obviously, some mapping of attributes between the two class types would be needed...and perhaps that's the reason why a type projection of this sort would not be possible...)
An alternate approach - attack this from the Work Item class.  It's trivial to create a view that contains Service Requests and Incidents - just set your criteria to be: ID begins with 'SR' or ID begins with 'IR'.  Unfortunately, that criteria
returns all Incidents, and I only want the Incidents that have the attribute ServiceRequestType = 'Service Request'.  Is it possible to create a Type Projection starting with the Work Item type that employs criteria from child classes?

Answer 1

Work Item is an abstract class, and can't be extended for implementation reasons. 
i think Anders has understated the difficulty of combining these views: this is a bit like saying "show me all the orange things, given this bucket of cats and this bucket of fruit" yes, they are both "orange", but fur is not the same
as fruit rind; they're not the same "orange".
the 2010 Service Request implementation was never intended to be a serious use case (i assume you're talking about the SCSM Service Request demo implementation on codeplex), it was intended
to be a demo of what you could do with the form and object interfaces. 
The solution here should be simple, convince your client that their solution has been replaced by a newer, better version, Resolve Close and then deprecate these requests, and start reporting only the new type requests. these are history, and dirty data,
and should be ignored.