Insertar registros en TClientDataSet para no actualizarlos

[[Al González]]

Hola Josep.

Fue un total desafío leer tu último mensaje carente de acentos, pero lo comprendí a grandes rasgos. Nada más por eso me debes una cerveza León.

Sin proponer una alternativa a la estructura de la información, existen dos sencillas formas de solucionar el problema a nivel del conjunto de datos cliente:

1.

Mi recomendación es que no agregues esos registros al conjunto de datos 1 mediante los métodos Insert, Append, InsertRecord o AppendRecord. Todos ellos emplean mecanismos que están pensados para "nuevas capturas", es decir, registros que al ser agregados al conjunto de datos cliente se anotan en la lista de cambios (change log) de éste. Y como has de saber ya, al llamar a ApplyUpdates esa lista de cambios es enviada al servidor.

Mejor utiliza el método AppendData así:

Código Delphi [-]
CDS1.AppendData (CDS2.Data, True);

Eso hará que todos los registros contenidos en el conjunto de datos 2 (CDS2) se copien a la lista de registros del conjunto de datos 1 (CDS1), pero sin que se marquen como "nuevos", es decir, sin aparecer en la lista de cambios. Tales registros se mezclarán con los ya existentes sin distinción especial alguna por parte de CDS1.

2.

Si te vieras forzado a utilizar los tradicionales métodos Append, Insert, etc., aún podrías evitar que los registros agregados se anotaran en la lista de cambios. Para ello se requiere desactivar la propiedad LogChanges temporalmente:

Código Delphi [-]
CDS1.LogChanges := False;

Try
  { Añadimos registros a CDS1 con Append...Post, pero no se enlistarán en 
     el "change log" }
Finally
  CDS1.LogChanges := True;
End;

Como podrás ver, resulta más fácil usar AppendData que poner temporalmente en False la propiedad LogChanges, pero hay algo que debes saber sobre el provechoso método AppendData:

Si CDS1 tiene campos de tipo InternalCalc, tales campos no se copiaran aunque estén presentes también en CDS2. La razón de ello no la tengo muy clara, pero se encuentra en las entrañas de MIDAS, cuyos fuentes en C++ (hechos públicos a partir de Delphi 2010) he tenido la fortuna de poder revisar, aunque sin mucha profundidad aún. En ellos he encontrado extractos como:

         // This test must come after
         if (iFieldID > pDs->iFieldsDataPacket)
         {
            // Calculated fields ? Do not read from pickle
            continue;
         }

      if (bAppend)
      { // Updates calculated fields, indexes, aggregates, iRecNoNext etc.
         // NOTE: currently does not update calculated fields
         rslt = pDs->InsertRecord(NULL, NULL);
         if (rslt)
            break;
      }

      for (i = 0; i < pDs->iFields; i++)
      { // Disregard blob/calculated fields
         BOOL bBlank = FALSE;

         pDs->GetField(pRecUpd, i+1, NULL, &bBlank);

Quien vea las rutinas completas notará que esos fuentes poseen un marcado estilo presuroso, propio de un programador C duro de la vieja guardia; contrastan con la elegancia de código que podemos ver en muchos archivos .pas de la VCL. Sospecho que Borland le encargó la elaboración de la biblioteca MIDAS.dll a un programador externo a su plantilla, quizá famoso por escribir algoritmos de rápida ejecución (eso se reconoce), pero tal vez él ya se retiró o vaya usted a saber, porque, según he podido colegir, esos fuentes siguen siendo prácticamente los mismos desde versiones como la 7.

Es como si el fabricante de Delphi tuviera miedo de tocarlos, acaso por no tener idea clara de cómo trabajan. Y entonces uno se explica por qué el componente TClientDataSet, lleno de tantas cualidades (se reconoce también), presenta, bajo circunstancias muy precisas, algunos "extraños" en su funcionamiento (como éste).

Cierro el paréntesis psicológico para volver al punto: El problema de AppendData es que por no incluirse los campos InternalCalc en la copia, ocurre cierto defecto (bug) con una bandera interna de dichos campos (el byte blank flag). Si CDS1 tiene campos InternalCalc y le haces múltiples llamadas a su método AppendData, los primeros registros aparecerán con esos campos en blanco (algo que puede no representar ningún problema), pero eventualmente, en registros agregados con posteriores llamadas a AppendData, tales campos vendrán con su bandera "blank" en 0 en lugar de 1, lo que se traduce en que serán tomados como campos que sí tienen valor, pero cuyo contenido será incierto. De hecho este defecto es causa de la excepción "'0.0' is not a valid timestamp", cuando se tiene un campo InternalCalc de tipo fecha en el conjunto de datos y se hacen múltiples llamadas a AppendData.

He realizado algunas pruebas, y al parecer eso puede ser corregido mediante el uso del método DSBase.PutBlank. Pero no nos adelantemos, Josep; quizá no tienes campos InternalCalc en CDS1, o quizá no realizas tantas llamadas sucesivas a su método AppendData como para producir el efecto mencionado. Así que ese método puede resultarte efectivo.

Coméntanos al respecto.

Un abrazo en C++ ({).

Al González.

[[AzidRain]]

Yo creo que puedes usar un simple select con sus correspondientes join para mostrar todos los datos del vehiculo independientemente de su centro de expedición y utilizar un dataset solo para mostralos. Para añadir los registros utiliza otro dataset que será el que controle las inserciones. Me parece que es la forma más sencilla y que te puede dar mejor resultado. Obviamente despues de la inserción hay que actualizar la consulta anterior para que muestre los datos ya capturados.

Haciendo un poco de resumen:
1.- Obtener todos las expediciones que correspondan a vehículos asignados al centro elegido SIN IMPORTAR en donde lo expidieron. (Veo mis vehiculos y tambien veo si algun otro centro les asignó algo). Este seria nuestra consulta principal.
2.-Gestiono altas, bajas o modificaciones de expediciones al vehículo que deseo. Esto lo hacemos con otra consulta independiente.
3.- Actualizo la consulta generada en el paso 1 siempre que haga algo con la del paso 2.

Creo que el problema es como estás modelando la consulta pues tu mismo mencionas que obtienes "todo lo asignado al centro 1", y debe ser "todo lo asignado a vehículos del centro 1", con ese pequeño cambio obtienes lo que necesitas.

[delphijm]

Empezado por AzidRain

Yo creo que puedes usar un simple select con sus correspondientes join para mostrar todos los datos del vehiculo independientemente de su centro de expedición y utilizar un dataset solo para mostralos. Para añadir los registros utiliza otro dataset que será el que controle las inserciones. Me parece que es la forma más sencilla y que te puede dar mejor resultado. Obviamente despues de la inserción hay que actualizar la consulta anterior para que muestre los datos ya capturados.

Haciendo un poco de resumen:
1.- Obtener todos las expediciones que correspondan a vehículos asignados al centro elegido SIN IMPORTAR en donde lo expidieron. (Veo mis vehiculos y tambien veo si algun otro centro les asignó algo). Este seria nuestra consulta principal.
2.-Gestiono altas, bajas o modificaciones de expediciones al vehículo que deseo. Esto lo hacemos con otra consulta independiente.
3.- Actualizo la consulta generada en el paso 1 siempre que haga algo con la del paso 2.

Creo que el problema es como estás modelando la consulta pues tu mismo mencionas que obtienes "todo lo asignado al centro 1", y debe ser "todo lo asignado a vehículos del centro 1", con ese pequeño cambio obtienes lo que necesitas.

Hola Azidrain,

Tienes razon en tu planteamiento, pero tal como tengo estructurada la tabla de expediciones me es muy facil obtener todas las expediciones que parten del centro de expedicion 1... En esta consulta me apareceran expediciones tanto de vehiculos normalmente asignados al centro 1 MAS alguna expedicion de vehiculos que no son normalmente del centro 1... Y aqui esta el caso, que a la vista de los datos es cuando conozco los vehiculos implicados en el centro 1 no antes...

En ese momento necesito hacerme un "resumen" de los vehiculos implicados, y buscar las expediciones por vehiculo...
Para cada vehiculo guardare en ese segundo dataset las expediciones que no son del centro 1 (porque ya las tengo de antes) sino de otros centros, para mostrarlos añadiendolos al primer dataset...

Esa es mi idea inicial, que con la solucion de Al puede funcionarme...

Tambien es cierto que otra solucion y quizas mejor, como dices, es replantearme la forma de obtener la informacion de la base de datos, obteniendo un primer dataset con los vehiculos implicados en el centro 1 con el select adecuado y a partir de este consultar, vehiculo a vehiculo sus expediciones, pero tambien necesitare aplicar aqui la tecnica de ir añadiendo a un dataset "unico" con "appenddata"...

En definitiva... asi es la informatica, datos arriba, datos abajo...

Ya os dire como acaba todo esto...

Gracias

[delphijm]

Empezado por Al González

Hola Josep.

Fue un total desafío leer tu último mensaje carente de acentos, pero lo comprendí a grandes rasgos. Nada más por eso me debes una cerveza León.

Sin proponer una alternativa a la estructura de la información, existen dos sencillas formas de solucionar el problema a nivel del conjunto de datos cliente:

1.

Mi recomendación es que no agregues esos registros al conjunto de datos 1 mediante los métodos Insert, Append, InsertRecord o AppendRecord. Todos ellos emplean mecanismos que están pensados para "nuevas capturas", es decir, registros que al ser agregados al conjunto de datos cliente se anotan en la lista de cambios (change log) de éste. Y como has de saber ya, al llamar a ApplyUpdates esa lista de cambios es enviada al servidor.

Mejor utiliza el método AppendData así:

Código Delphi [-]CDS1.AppendData (CDS2.Data, True);


Eso hará que todos los registros contenidos en el conjunto de datos 2 (CDS2) se copien a la lista de registros del conjunto de datos 1 (CDS1), pero sin que se marquen como "nuevos", es decir, sin aparecer en la lista de cambios. Tales registros se mezclarán con los ya existentes sin distinción especial alguna por parte de CDS1.

2.

Si te vieras forzado a utilizar los tradicionales métodos Append, Insert, etc., aún podrías evitar que los registros agregados se anotaran en la lista de cambios. Para ello se requiere desactivar la propiedad LogChanges temporalmente:

Código Delphi [-]CDS1.LogChanges := False; Try { Añadimos registros a CDS1 con Append...Post, pero no se enlistarán en el "change log" } Finally CDS1.LogChanges := True; End;


Como podrás ver, resulta más fácil usar AppendData que poner temporalmente en False la propiedad LogChanges, pero hay algo que debes saber sobre el provechoso método AppendData:

Si CDS1 tiene campos de tipo InternalCalc, tales campos no se copiaran aunque estén presentes también en CDS2. La razón de ello no la tengo muy clara, pero se encuentra en las entrañas de MIDAS, cuyos fuentes en C++ (hechos públicos a partir de Delphi 2010) he tenido la fortuna de poder revisar, aunque sin mucha profundidad aún. En ellos he encontrado extractos como:

         // This test must come after
         if (iFieldID > pDs->iFieldsDataPacket)
         {
            // Calculated fields ? Do not read from pickle
            continue;
         }

      if (bAppend)
      { // Updates calculated fields, indexes, aggregates, iRecNoNext etc.
         // NOTE: currently does not update calculated fields
         rslt = pDs->InsertRecord(NULL, NULL);
         if (rslt)
            break;
      }

      for (i = 0; i < pDs->iFields; i++)
      { // Disregard blob/calculated fields
         BOOL bBlank = FALSE;

         pDs->GetField(pRecUpd, i+1, NULL, &bBlank);

Quien vea las rutinas completas notará que esos fuentes poseen un marcado estilo presuroso, propio de un programador C duro de la vieja guardia; contrastan con la elegancia de código que podemos ver en muchos archivos .pas de la VCL. Sospecho que Borland le encargó la elaboración de la biblioteca MIDAS.dll a un programador externo a su plantilla, quizá famoso por escribir algoritmos de rápida ejecución (eso se reconoce), pero tal vez él ya se retiró o vaya usted a saber, porque, según he podido colegir, esos fuentes siguen siendo prácticamente los mismos desde versiones como la 7.

Es como si el fabricante de Delphi tuviera miedo de tocarlos, acaso por no tener idea clara de cómo trabajan. Y entonces uno se explica por qué el componente TClientDataSet, lleno de tantas cualidades (se reconoce también), presenta, bajo circunstancias muy precisas, algunos "extraños" en su funcionamiento (como éste).

Cierro el paréntesis psicológico para volver al punto: El problema de AppendData es que por no incluirse los campos InternalCalc en la copia, ocurre cierto defecto (bug) con una bandera interna de dichos campos (el byte blank flag). Si CDS1 tiene campos InternalCalc y le haces múltiples llamadas a su método AppendData, los primeros registros aparecerán con esos campos en blanco (algo que puede no representar ningún problema), pero eventualmente, en registros agregados con posteriores llamadas a AppendData, tales campos vendrán con su bandera "blank" en 0 en lugar de 1, lo que se traduce en que serán tomados como campos que sí tienen valor, pero cuyo contenido será incierto. De hecho este defecto es causa de la excepción "'0.0' is not a valid timestamp", cuando se tiene un campo InternalCalc de tipo fecha en el conjunto de datos y se hacen múltiples llamadas a AppendData.

He realizado algunas pruebas, y al parecer eso puede ser corregido mediante el uso del método DSBase.PutBlank. Pero no nos adelantemos, Josep; quizá no tienes campos InternalCalc en CDS1, o quizá no realizas tantas llamadas sucesivas a su método AppendData como para producir el efecto mencionado. Así que ese método puede resultarte efectivo.

Coméntanos al respecto.

Un abrazo en C++ ({).

Al González.

Hola Al,

Perdona por el desafio al que te someti... Lo de la cerveza dalo por hecho cuando se de la ocasion....

En cambio para mi es un placer leer tu respuesta llena de sabiduria y experiencia en los TClientDataset, intuyo en ella bastantes noches en blanco como las que empiezo a pasar yo hasta que los domine a mi antojo!!!

Asimilare lo que me cuentas y lo probare... A priori me parece la solucion perfecta... Ya te contare el resultado...

Muchas gracias de nuevo

Josep Mª