Uno de nuestros procedimientos permite a los usuarios insertar registros relacionados de forma masiva seleccionando una vista y luego presionando un botón de cinta. Se guarda el formulario, se establece una bandera y un complemento hace su trabajo.

Estamos utilizando un subgrid con un selector de vista para permitir a los usuarios elegir o crear sus propias vistas sobre la marcha. Una vez que se selecciona una vista, se muestra el número de resultados (siempre que sea lte 5k).

Cuando un complemento ejecuta el mismo lado del servidor fetchxml (Recuperar de consulta de usuario o guardado, luego Recuperar + Extracción), los resultados cambian. No solo obtenemos un número diferente de registros sino que también algunos registros son diferentes.

Llegamos a la conclusión de que el tema tiene que ver con las zonas horarias. Algunos filtros incluyen operadores "en o después" junto con valores de fecha. Ejemplo:

<filter type="and">
  <condition attribute="modifiedon" operator="on-or-after" value="2011-01-01" />
  <condition attribute="modifiedon" operator="on-or-before" value="2011-12-31" />
</filter>

El plugin corrió como administrador. Cambiar el usuario del complemento no tiene ningún efecto, como si la zona horaria del usuario actual no se tuviera en cuenta al extraer registros del CRM utilizando una FetchExpression.

¿Cómo puedo asegurarme de que una expresión fetchxml devuelva los mismos resultados del lado del cliente y del servidor?

Probablemente relacionado:Hilo de MSDN.

Gracias por tu tiempo.

Edición: siguiendo la sugerencia de Daryl, ejecuté un seguimiento de SQL. Los resultados son desconcertantes. Las fechas se compensan correctamente para las consultas del lado del cliente (ejecutadas desde CRM, es decir, Búsqueda avanzada); esto significa que el fetchxml se traduce correctamente usando la configuración de zona horaria del usuario. Esto no sucede para la misma consulta, del lado del servidor; el SQL de salida contiene los filtros de fecha "tal cual", sin desplazamiento de zona horaria. Asumí que la misma traducción ocurrió sin importar el origen del contexto de ejecución de la consulta.

Edición 2: una marca en una región oculta del código (mi último recurso de depuración) impedía que el complemento creara una instancia del servicio en el contexto del usuario en ejecución. Todo funciona bien ahora. Gracias a todos por su tiempo y su ayuda, es muy apreciado.