Primero, this isn't officially supported.
La respuesta a la que se vincula para LINQ to SQL es simplemente usar la capacidad del servidor de bases de datos para realizar consultas heterogéneas. No veo por qué eso no funcionaría para Entity Framework, también, ya que es una función de servidor de base de datos, no una característica de ninguno de los marcos. En otras palabras, LINQ to SQL todavía está tratando con la conexión como si solo estuviera involucrado un servidor de base de datos. Tenga en cuenta, sin embargo, que no todos los servidores de bases de datos pueden hacer esto.
En cuanto a qué cambiar en el EDMX, busque el atributo Esquema del nodo EntitySet en la sección "Contenido SSDL".
Una advertencia sobre esta técnica es que cuando actualiza su modelo desde la base de datos, el modelo de almacenamiento se borra y se reemplaza desde cero. Entonces, necesitaría volver a aplicar estos cambios. Esto no es un problema en LINQ to SQL, porque LINQ to SQL no admite actualizaciones automáticas de la base de datos.
Una mejor alternativa sería crear una VISTA en la base de datos que hiciera referencia a la otra base de datos y mapear esa vista en lugar de asignar la tabla y la otra base de datos directamente.
La vista Sólo funciona bien si cada db está en el mismo servidor de base de datos, de lo contrario, se va a cruzar db. En sql 2005+, creo que un sinónimo también puede funcionar, pero no soy 100%. En cuanto a los cambios que se pierden, si deja de usar el diseño y tiene los cuatro archivos editados manualmente, deja de ser un problema. – NikolaiDante
Traté de cambiar el atributo de esquema de dbo a, por ejemplo, OtherDatabase.dbo, en vano. Después de estos cambios, las consultas lanzan una excepción 'nombre de objeto no válido OtherDatabase.dbo.MyTable'. – Sam
Nath, necesitaría usar un servidor vinculado (con EF o LINQ-to-SQL) si está en un servidor diferente. Sam, pruebe el enfoque VIEW, entonces. –