Insertar registros en TClientDataSet para no actualizarlos

[delphijm]

Hola a todos,

Expongo lo que quiero hacer y mi problema en el punto final:

- Tengo un TClientDataSet cargado con una serie de registros procedentes
de la tabla A.
- Durante el transcurso de la aplicacion, en un momento dado, me interesa
leer otra serie de registros de la misma tabla A, pero usando un
TClientDataSet diferente al primero.
- Con los dos TClientDataSets disponibles, me interesaria copiar los
registros del segundo TClientDataSet en el primero.
- Asi, en el primer TClientDataSet, tendria todos los registros...
- El segundo TClientDataSet lo cerraria para no usarlo mas...
- Lo que no quiero es que los registros que he insertado en el primer
TClientDataSet se actualicen en la Base de datos al hacer el
ApplyUpdates porque ya estan en ella...

Como puedo indicarle a un TClientDataSet que algunos de los registros que contiene no deben ser actualizados al hacer el ApplyUpdates???

Gracias a todos y sobretodo a quin pueda ayudarme...

Un Saludo

[Neftali [Germán.Estévez]]

Empezado por delphijm

- Con los dos TClientDataSets disponibles, me interesaria copiar los
registros del segundo TClientDataSet en el primero.

- Lo que no quiero es que los registros que he insertado en el primer
TClientDataSet se actualicen en la Base de datos al hacer el
ApplyUpdates porque ya estan en ella...

Como puedo indicarle a un TClientDataSet que algunos de los registros que contiene no deben ser actualizados al hacer el ApplyUpdates???

Cuando dices "copiar registros" a qué te refieres?
¿Los has insertado? ¿Los has actualizado?

No acabo de entender cómo puedes diferenciar (y cómo lo va a hacer el ApplyUpdates) los unos y los otros.

Tal vez la lógica del proceso no sea la correcta, porque no acabo de entender el porqué de esos pasos. ¿Puedes explicar qué necesitas hacer (además del cómo que ya has explicado) para ver si hay otra forma de enfocarlo?

[[fjcg02]]

Si aplicas applyupdates a nivel de registro ( evento afterpost del dataset), podías añadir un campo que indique el origen del registro.

En este caso, en el evento que te he indicado, podrías hacer lo siguiente:

( es pseudo código ...)
if dataset.fieldbyname('origen').AsString ='A' then
dataset.AppplyUpdates(0);


siendo origen el campo calculado que contendrá A en los registros cuyo origen sea la tabla a modificar y otro valor en el caso de que sean los registros insertados la otra tabla.

Incluso se podría controlar que en base a ese valor, unos registros sean editables y otros no.

Si no se indica la primera premisa, lo veo bastante más difícil.


Espero haberte ayudado en algo.

Saludos

[delphijm]

Hola,

La idea del campo que actua como flag para conocer el origen del registro me parece muy buena... La aplicare... Muchas gracias a tod spor la ayuda...

[[Al González]]

Sin menospreciar la aportación de Javier, me uno a las preguntas de Neftalí.

delphijm: ¿podrías dedicarnos un par de minutos para explicar con mayor detalle y contexto tu caso?

Fue un poco desconsiderado de tu parte que volvieras a escribir sin responder a las preguntas que él te hizo con el fin de ayudarte. Lo cortés no quita lo valiente, compadre.

En lo personal, conozco algunos de los mecanismos internos de TClientDataSet. Si aclaras el tema, quizá pueda proponerte alguna buena alternativa.

Un abrazo por el arco del triunfo.

Al González.

[delphijm]

Hola a todos,

Antes de nada, Al, tienes razon en lo de que fui desconsiderado al no responder a las preguntas de Neftali y Javier cuando me ofrecieron su ayuda... Perdon a todos y a ti tambien...

A continuacion os expongo lo que quiero hacer... El como, como dices ya lo dije pero quizas no sea la forma correcta...

El caso es que estoy desarrollando una aplicacion de gestion de planing de carga de vehiculos en diferentes centros de expedicion...

Existen varios centros de expedicion y tambien varios vehiculos...
Cada centro de expedicion tiene asignados unos vehiculos concretos...

Por ejemplo:
--> Centros de expedicion --> 1=Centro 1, 2=Centro 2
--> Vehiculos --> VEH01, VEH02, VEH03

El mecanismos del planing es que, en un centro de expedicion se visualizan los vehiculos que estan asignados al centro...

Por ejemplo:
--> En el centro de expedicion 1 --> Vehiculos asignados VEH01, VEH02
--> En el centro de expedicion 2 --> Vehiculos asignados VEH03

Cuando se gestiona el planing del centro de expedicion 1, se crean tantas expediciones a uno de los vehiculos como pueda realizar en el dia.

El tema esta en que puede ser que el vehiculo VEH03 que corresponde al centro 2 tambien puede añadirse, eventualmente, en el centro 1 para realizar alguna expedicion...

Asi, puede darse el caso que un vehiculo, por ejemplo VEH03 el mismo dia tenga una expedicion en el centro 1 i otra en el centro 2...

Ahora viene el problema:

Cuando se empieza a gestionar el planing, se pide al usuario que centro de expedicion quiere gestionar...

Cuando escoje, por ejemplo, el centro 1, yo recupero de la BBDD todas las expediciones asignadas al centro 1..

Centrandonos en el vehiculo VEH03, en el ClientDataSet de expediciones tendre la/las expediciones del vehiculo del centro 1, pero no tengo la expedicion que pudiera tener en el centro 2 (ya que estoy gestionando el centro 1)...

Me interesa que esa expedicion tambien aparezca para que el usuario sepa de la existencia de esa otra expedicion...

Lo que queria hacer, es, recuperar en otro dataset todas las expediciones del vehiculo VEH03, independientemente del centro.

Como me interesaria trabajar con unico dataset porque lo tengo enlazado con un control de agenda (al que claro, solo puedo enlazar un ClientDataSet), mi idea era añadir los registros del segundo al primero (y "general")... Una especie de "merge"...

Pero claro, para añadir los registros al primer dataset tendre que hacer append's y el ClientDataSet va a "pensar" que son nuevos registros (de hecho para el si, pero no para la BBDD), con lo que cuando haga el applyupdates intentara insertar y provocara un error de clave duplicada...

JAVIER --> Si, hago el applyupdates a nivel de registro en el afterpost... Por eso me parecia que tu idea podia ser factible...

NEFTALI --> Quizas lo que expongo aclare las dudas que veias y, si quizas no es la mejor forma de hacerlo...

AL --> Te agradecere cualquier alternativa mejor que puedas proponerme... Ademas me alegro que tengas experiencia en el trabajo con el TClientDataSet, yo los uso y los tendre que usar con cierta intensidad, en general todo el mecanismo de acceso a Datos de DbExpress... Soy relativamente nuevo en el desarrollo en Delphi y en ocasiones me trabo en los lugares mas insospechados!!!

Gracias a todos y un saludo

Josep Mª

[[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 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ª

[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