FiveTech Support Forums

Amigos:

Tengo una tabla, llamada HDRVDM (Es el detalle) la cuan relaciono con su tabla PROVEEDORES de la siguiente forma

   oRsHdr := FW_OpenRecordSet(oApp:oCon,"SELECT " +;
                                          "*," +;
                                          "PRO_RAZ " +;
                                       "FROM " +;
                                          "HdrVdm " +;
                                       "LEFT JOIN " +;
                                          "Proveedores " +;
                                       "ON " +;
                                          "HDR_PRV = PRO_NUM " +;
                                       "WHERE " +;
                                          "YEAR(HDR_FDM) = '" + STR(nAmo,4,0) + "' " +;
                                       "ORDER BY " +;
                                          "HDR_FOL",adLockOptimistic,adOpenDynamic,0)

Cuando el primer registro en la tabla HDRVDM, el campo HDR_PRV esta en cero (Es correcto, no todos los registros deben tener valor), al abrir la tabla me tira el error siguiente

El identificador de fila se refirió a una fila eliminada o a una fila marcada para eliminar. (0x80040E23): Microsoft Cursor Engine

Sin embargo, si el primer registro en la tabla HDRVDM el campo HDR_PRV tiene valor > 0 no hay error !

Espero haberme explicado

Alguna sugerencia?, muchas gracias

Estimado Armando:

El cero no debería obligarte a eliminar esos registros. Si no existe un proveedor con PRO_NUM = 0, el LEFT JOIN conserva la fila de HdrVdm y devuelve NULL en los campos de Proveedores. Cambiarlo por INNER JOIN o filtrar HDR_PRV > 0 ocultaría precisamente los registros que necesitas conservar.

Por el mensaje de Microsoft Cursor Engine y porque lo abres con adLockOptimistic, una hipótesis a comprobar es la identificación de las filas del resultado combinado para su actualización. No tengo reproducido tu caso y el mensaje por sí solo no confirma esa causa.

He revisado FW_OpenRecordSet(): el tercer argumento es el bloqueo, el cuarto es el tipo de cursor y la función establece adUseClient. Con cursor cliente, ADO admite adOpenStatic; pedir adOpenDynamic no garantiza que el cursor obtenido sea dinámico.

Para separar la consulta SQL de la posibilidad de actualizarla, haría estas comprobaciones en una prueba aparte:

1. Abrir la misma consulta en modo adLockReadOnly y con adOpenStatic, solo para leer y recorrer los registros. Si así funciona y con adLockOptimistic falla, tendremos una pista sobre la actualización/identificación del JOIN, no una solución definitiva.

2. Revisar la lista de campos: SELECT *, PRO_RAZ incluye los campos de ambas tablas y vuelve a seleccionar PRO_RAZ. Conviene seleccionar los campos de HdrVdm y PRO_RAZ una sola vez, con nombres sin ambigüedad. Comprobar también que HdrVdm tiene una clave primaria y que PRO_NUM identifica un único proveedor; si hay varios proveedores con el mismo número, el JOIN multiplica filas.

3. Comprobar si falla dentro de FW_OpenRecordSet() o en el primer acceso posterior a un campo, MoveFirst() o al browse. Esa diferencia nos ayuda a localizarlo.

¿Qué motor de base de datos y proveedor/controlador ADO utilizas? ¿El resultado del JOIN es solo para mostrarlo o también editas HdrVdm a través de él? Con esos datos y el resultado de la prueba de solo lectura podremos concretar el siguiente paso sin perder los registros sin proveedor.

Referencia de Microsoft sobre los cursores cliente:
https://learn.microsoft.com/en-us/office/client-developer/access/desktop-database-reference/cursortype-property-ado

Un saludo,
FiveTech AI

Estimado Antonio:

En resumen:

Con INNER JOIN no funciona, sigue el mismo error Con adLockReadOnly y adOpenStatic, Funciona de 100, no hay error Con adLockReadOnly y con adOpenDynamic, tambien funciona de 100, no hay error

Parece que el problema se da con adLockOptimistic, lo necesito Read & Write

Muchas gracias por tu apoyo

Saludos

Estimado Armando:

Gracias por hacer las pruebas. Que la misma consulta funcione en solo lectura y falle al solicitar adLockOptimistic acota el problema hacia la apertura del resultado como actualizable, aunque todavía no identifica la causa exacta. ReadOnly era una prueba de diagnóstico, no una solución para tu necesidad de lectura y escritura.

Que también funcione al pedir adOpenDynamic con ReadOnly no contradice lo anterior: FW_OpenRecordSet usa cursor cliente y ADO puede sustituir el tipo solicitado por el que admite. Por eso cambiar solo ese argumento no demuestra que hayas obtenido un cursor dinámico.

El siguiente paso sería separar la tabla que quieres editar del JOIN: en una copia de prueba, abrir únicamente HdrVdm, con el mismo filtro y orden, adLockOptimistic y adOpenStatic, sin Proveedores. Primero comprobar si abre y recorre los registros; cualquier prueba de escritura, solo sobre datos de prueba.

• Si también falla sin el JOIN, habría que revisar la clave primaria de HdrVdm y cómo el proveedor ADO identifica sus registros.
• Si funciona sin el JOIN, volvería al LEFT JOIN seleccionando los campos de HdrVdm y PRO_RAZ una sola vez, incluyendo explícitamente la clave primaria de HdrVdm y comprobando que PRO_NUM sea único. Así aislamos si el problema depende del resultado combinado.

Necesitar editar HdrVdm no obliga a editar directamente el resultado de dos tablas. Otra opción de diseño es utilizar el JOIN para mostrar los datos y realizar las altas/cambios sobre un recordset de HdrVdm identificado por su clave, refrescando después la vista. Eso permite conservar los registros sin proveedor, sin convertir el JOIN en INNER JOIN.

ADO también dispone de la propiedad dinámica "Unique Table" para indicar la tabla actualizable de un JOIN, pero requiere que el recordset ya haya abierto correctamente y tenga los metadatos necesarios. No la presentaría como arreglo para una apertura que ya falla.

Con el resultado de la prueba de HdrVdm sola, el motor/proveedor que utilizas y el nombre de su clave primaria podremos elegir el camino adecuado. No tengo reproducido tu entorno y aún no daría el problema por resuelto.

Referencia de Microsoft sobre actualización de JOINs:
https://learn.microsoft.com/en-us/sql/ado/guide/data/updating-joined-results-unique-table?view=sql-server-2017

Un saludo,
FiveTech AI

cSql := "SELECT HdrVdm.*, Proveedores.PRO_RAZ " + ;
        "FROM HdrVdm " + ;
        "LEFT JOIN Proveedores ON HdrVdm.HDR_PRV = Proveedores.PRO_NUM " + ;
        "WHERE YEAR(HdrVdm.HDR_FDM) = ? " + ;
        "ORDER BY HdrVdm.HDR_FOL"

TRY
    oRsHdr := FW_OpenRecordSet(oApp:oCon, cSql, adLockOptimistic, adOpenDynamic, 0, nAmo)
CATCH oErr
    MsgAlert("Erro ao carregar registros: " + oErr:description, "Erro")
    oRsHdr := NIL
END

cSql := "SELECT HdrVdm.*, Proveedores.PRO_RAZ " + ;
        "FROM HdrVdm " + ;
        "LEFT JOIN Proveedores ON HdrVdm.HDR_PRV = Proveedores.PRO_NUM " + ;
        "WHERE HdrVdm.HDR_FDM >= ? " + ;
        "AND HdrVdm.HDR_FDM < ? " + ;
        "ORDER BY HdrVdm.HDR_FOL"

oRsHdr := FW_OpenRecordSet(oApp:oCon, cSql, ;
                           adLockReadOnly, ;
                           adOpenForwardOnly, ;
                           0, ;
                           StoD(Str(nAmo, 4, 0) + "0101"), ;
                           StoD(Str(nAmo + 1, 4, 0) + "0101"))

Avaliar índices:

CREATE INDEX IDX_HDRVDM_FDM
ON HdrVdm (HDR_FDM);

CREATE INDEX IDX_HDRVDM_FOL
ON HdrVdm (HDR_FOL);

CREATE INDEX IDX_HDRVDM_PRV
ON HdrVdm (HDR_PRV);

CREATE INDEX IDX_PROVEEDORES_NUM
ON Proveedores (PRO_NUM);

   LOCAL cYearIni := STRZERO( nAmo, 4 ) + "-01-01"
   LOCAL cYearFin := STRZERO( nAmo + 1, 4 ) + "-01-01"  // Usar < año siguiente cubre DATE y DATETIME sin perder milisegundos

   oRsHdr := FW_OpenRecordSet( oApp:oCon, ;
      "SELECT " + ;
         "H.*, " + ;
         "P.PRO_RAZ " + ;
      "FROM " + ;
         "HdrVdm H " + ;
      "LEFT JOIN " + ;
         "Proveedores P " + ;
      "ON " + ;
         "H.HDR_PRV = P.PRO_NUM " + ;
      "WHERE " + ;
         "H.HDR_FDM >= '" + cYearIni + "' AND H.HDR_FDM < '" + cYearFin + "' " + ;
      "ORDER BY " + ;
         "H.HDR_FOL", ;
      adLockOptimistic, adOpenDynamic, 0 )

Regards, saludos.

Estimado João:

Gracias por aportar alternativas. Hay un detalle importante en las dos primeras llamadas: he comprobado la implementación actual de FW_OpenRecordSet y su sexto argumento es nOpt, las opciones que se pasan a Recordset:Open(); no es un valor para sustituir los signos de interrogación de la consulta.

Por tanto, pasar nAmo o las fechas como sexto y séptimo argumentos no enlaza esos parámetros. Para usar marcadores ? habría que preparar un ADODB.Command con sus Parameters según el proveedor, y después abrir el recordset con ese comando. No conviene probar esas dos llamadas suponiendo que ya están parametrizadas.

La tercera propuesta sí evita ese problema de argumentos y selecciona PRO_RAZ una sola vez, pero el cambio del filtro de fechas no demuestra por sí mismo que quede resuelto el error de actualización. Además, Armando ya ha confirmado que necesita lectura y escritura: ReadOnly nos sirve para diagnosticar, no como solución final.

Mantendría el siguiente diagnóstico centrado en abrir HdrVdm sola como actualizable, sobre datos de prueba, para compararlo con el JOIN. Así podremos distinguir el problema de actualización de cualquier mejora independiente del filtro o de los índices.

Un saludo,

FiveTech AI