Por selectividad debemos entender el conjunto de reglas que debemos definir para que los clientes (dispositivos) reciban una base de datos “personalizada”, NO una copia de lo que hay en el servidor.
En proyectos en los que la base de datos del servidor es grande, esto es incluso obligatorio, pues los dispositivos, evidentemente, no van a soportar un tamaño de base de datos tan grande.

A partir de que un proyecto se va a definir con selectividad, en la tabla donde tenemos todas las licencias de los dispositivos, MASTER_REPLICA_SLAVE, habría que poner como valor por defecto a 1 en el campo CONDITIONAL, para que cada vez que firmemos una licencia con el xonemanager, ésta ya sea selectiva por defecto.

Las tablas que intervienen en la selectividad son:

CAMPO DESCRIPCIÓN
ADM_SELECTED_TEMPLATE Tabla de plantilla con las reglas de selectividad.
ADM_DINAMYC_SELECTED Tabla que asocia un DISPOSITIVO con un USUARIO.
MASTER_REPLICA_SELECTED Tabla que realmente define las condiciones de selectividad y es la que mira el servidor de réplica. Habrá un registro por cada TABLA y cada MID (dispositivo) que vaya a entrar en selectividad.
MASTER_REPLICA_SQUEUE Tabla con las operaciones de la tabla MASTER_REPLICA_QUEUE (campo QID), que han cumplido las reglas de selectividad definidas en la tabla MASTER_REPLICA_SELECTED que tiene que descargarse cada MID (Dispositivo).

Esta tabla NO define la selectividad directamente, ES UNA PLANTILLA para poder rellenar posteriormente la tabla MASTER_REPLICA_SELECTED, que es realmente la tabla que define las reglas de selectividad.

CAMPO TIPO DESCRIPCIÓN
ID Autonumérico
TABLENAME Varchar(50) Nombre de la tabla
ALWAYS Numérico ALWAYS=1, se reciben todas las operaciones de la tabla especificada en TABLENAME y se ignora lo que haya definido en CRITERIA, ALWAYS=0, se evalúa la consulta que haya definida en el campo CRITERIA
CONDITIONAL Numérico Deprecated. Utilizado en el servidor de réplica anterior a .NET. Cuando ALWAYS=1, CONDITIONAL=0 y cuando ALWAYS=0, CONDITIONAL=1.
CRITERIA Varchar(4096) Si el criterio es simple se puede especificar simplemente la condición (P.Ej:IDEMPRESA=1) ó si la condición es compleja con varios joins simplemente tendremos que rescatar el campo ROWID de los valores que cumplen la condición.
CRITERIAPROVISIONNING (Con 2 N) Varchar(4096) Opcional. Puede ser utilizado para saltarnos la condición definida para la selectividad en el campo CRITERIA a la hora de provisionar una base de datos. Si este campo está vacío, se coge lo que haya en el campo CRITERIA. La SQL que se defina en este campo rescataría TODOS los datos de la tabla en cuestión y NO únicamente el ROWID. Para que este campo tenga efecto, en la configuración del servicio xoneprovisioning hemos de tener el parámetro Using-subqueries=true además de tener el campo ALWAYS=0.

Ejemplos de CRITERIA en TEMPLATE

/* Ejemplo de registro de plantilla para la tabla de clientes, a los clientes se le asocia un IDUSUARIO 
y al enlazar en ADM_DINAMYC_SELECTED el usuario con el dispositivo, si enlazamos con ésta tabla el dispositivo 
recibirá los registros que afecten a dicho cliente por estar asociado a ése usuario. 
La macro ##MID## la sustituiremos cuando vayamos a rellenar la tabla MASTER_REPLICA_SELECTED.  */
SELECT c.ROWID FROM gen_clientes c 
INNER JOIN adm_dinamyc_selected a ON c.IDUSUARIO=a.IDUSUARIO WHERE a.MID=##MID##
 
/* En este otro ejemplo, para la tabla de visitas, el dispositivo únicamente recibirá las operaciones de visitas 
de los clientes que tienen asociado su IDUSUARIO. */
SELECT D.ROWID FROM gen_visitas D 
LEFT OUTER JOIN gen_clientes C ON D.IDCLIENTE= C.ID 
INNER JOIN adm_dinamyc_selected S ON c.IDUSUARIO=S.IDUSUARIO WHERE S.MID=##MID##

El campo CRITERIA es para especificar la SQL con la condición a cumplir, se pone Varchar(4096) o más, evitar el uso de NTEXT o TEXT en el tipo de dato, pues posteriormente no funcionará la función replace si queremos ejecutar alguna consulta sobre esta tabla reemplazando los valores para insertarlos en la tabla MASTER_REPLICA_SELECTED.

Esta tabla contiene la relación entre un USUARIO y un MID (dispositivo). Esta relación se establece cuando se asocia Usuario-Dispositivo en el xonemanager.

1.- Datos en ADM_DINAMYC_SELECTED 2.- Asociación de USUARIO-DISPOSITIVO en xonemanager.

En esta tabla podemos poner otros campos que creamos necesarios para la selectividad de nuestro proyecto, de forma que podemos asociar un dispositivo con un IDZONA o un IDTIPO o con cualquier otra cosa que nos resulte necesaria.

Esta tabla es la que define realmente las condiciones de selectividad del proyecto. Si una operación de la tabla MASTER_REPLICA_QUEUE del servidor cumple las condiciones definidas en ésta tabla, dicha operación se inserta en la tabla MASTER_REPLICA_SQUEUE que es la tabla que se mira para saber las operaciones que tienen que descargarse los dispositivos que tienen definida selectividad.

Si una tabla NO tiene ningún registro definido en la tabla MASTER_REPLICA_SELECTED para un determinado MID (dispositivo), dicho dispositivo NO recibirá operaciones por réplica que afecten a dicha tabla, ni tampoco se recibirá ningún registro en dicha tabla cuando se provisione una base de datos para ese dispositivo.

CAMPO TIPO DESCRIPCION
ID Autonumérico
MID Numérico Identificador del dispositivo (MASTER_REPLICA_SLAVE)
TBL Varchar(50) Nombre de la tabla
OPER Numérico Deprecated. Anterior al servidor .NET. Campo de sistema para compatibilidad con versiones antiguas del replicador.
CONDITIONAL Numérico Deprecated. Utilizado en el servidor de réplica anterior a .NET. Cuando ALWAYS=1, CONDITIONAL=0 y cuando ALWAYS=0, CONDITIONAL=1.
ALWAYS Numérico ALWAYS=1, se reciben todas las operaciones de la tabla especificada en TABLENAME y se ignora lo que haya definido en CRITERIA, con ALWAYS=0 se evalúa la consulta que haya definida en el campo CRITERIA
CONSOLIDATE Numérico Deprecated. Anterior al servidor .NET. Campo de sistema para compatibilidad con versiones antiguas del replicador.
CRITERIA Varchar(4096) Si el criterio es simple se puede especificar simplemente la condición (P.Ej:IDEMPRESA=1) o si la condición es compleja con varios joins simplemente tendremos que rescatar el campo ROWID de los valores que cumplen la condición.
CRITERIAPROVISIONNING (Con 2 N) Varchar(4096) Opcional. Puede ser utilizado para saltarnos la condición definida para la selectividad en el campo CRITERIA a la hora de provisionar una base de datos. Si este campo está vacío, se coge lo que haya en el campo CRITERIA. La SQL que se defina en este campo rescataría TODOS los datos de la tabla en cuestión y NO únicamente el ROWID. Para que este campo tenga efecto, en la configuración del servicio xoneprovisioning hemos de tener el parámetro Using-subqueries=true además de tener el campo ALWAYS=0.

Rellenar la Selectividad

Consulta para generar de nuevo la selectividad (MASTER_REPLICA_SELECTED) a partir de la plantilla definida en ADM_SELECTED_TEMPLATE sustituyendo la cadena ##MID## por el MID correspondiente de la tabla MASTER_REPLICA_SLAVE.

TRUNCATE TABLE master_replica_selected;
 
INSERT INTO master_replica_selected (MID,TBL,ALWAYS,CRITERIA)
	SELECT S.MID, T.TABLENAME, T.ALWAYS, REPLACE(T.CRITERIA,'##MID##',S.MID)
	FROM master_replica_slave S, adm_selected_template T
	WHERE MID>1 ORDER BY MID
 
/* En caso de que también tengamos CRITERIAPROVISIONNING... */
INSERT INTO master_replica_selected (MID,TBL,ALWAYS,CRITERIA,CRITERIAPROVISIONNING)
	SELECT S.MID, T.TABLENAME, T.ALWAYS, REPLACE(T.CRITERIA,'##MID##',S.MID), REPLACE(T.CRITERIAPROVISIONNING,'##MID##',S.MID)
	FROM master_replica_slave S, adm_selected_template T
	WHERE MID>1 ORDER BY MID
 
/* REINICIAR EL SERVICIO DE REPLICA */

La consulta anterior vuelve a generar los registros en la tabla MASTER_REPLICA_SELECTED para todos los MID a partir del 1, si previamente había registros en ésta tabla, habría que borrarlos. Tras rellenar de nuevo la tabla de la selectividad, habría que reiniciar el servidor de réplica para que tome los nuevos valores.

Ver registros por recibir

Consulta para conocer las operaciones que tiene pendientes de descarga por réplica un MID(Dispositivo). Estas operaciones son las que hayan cumplido los criterios de selectividad descritos en la tabla MASTER_REPLICA_SELECTED, que han sido puestos en cola en la tabla MASTER_REPLICA_SQUEUE.

SELECT * 
    FROM master_replica_queue 
    	WHERE (ID IN (SELECT qid FROM master_replica_squeue WHERE MID=432) 
    	AND 1=(SELECT CONDITIONAL FROM master_replica_slave WHERE MID=432))
    OR (
    	(ID>(SELECT LASTID FROM master_replica_slave WHERE MID=432) AND MID<>0 AND MID<>432)
    	AND (0=(SELECT CONDITIONAL FROM master_replica_slave WHERE MID=432)
    		OR (SELECT CONDITIONAL FROM master_replica_slave WHERE MID=432) IS NULL) 
    	)     
    OR (ID>(SELECT LASTDMID FROM master_replica_slave WHERE MID=432) AND DMID=432)
ORDER BY DMID DESC, ID ASC;

La consulta anterior saca un listado con las siguientes operaciones que tiene pendientes de descargarse un dispositivo, por orden de descarga. Esta consulta sirve tanto para los dispositivos “selectivos” (primera parte del WHERE) como para los “no selectivos” (segunda parte del WHERE, el primer OR). Debemos saber que si hay algún DMID(Operación generada por el servidor a petición de un dispositivo)(segundo OR en la consulta) pendiente de descarga, éste tiene absoluta prioridad para descargarse, por eso ordenamos primero por DMID desc y después por ID asc.

Para saber los DMID que tiene un dispositivo por descargarse:

SELECT * FROM master_replica_queue WHERE ID>(select LASTDMID from master_replica_slave where MID=432) AND DMID=432 ORDER BY ID ASC;