Ejemplo de llamada a la función

Código Delphi [-]
ghCopyDataSetProps (SQLDSClienteDesde, SQLDSClienteHasta,'Name',True,'');

Definición de la función - Sacada de GHFreebrary de Al González

Código Delphi [-]
  { Copy Data Set Props }
  Procedure ghCopyDataSetProps (
    Const Source, Dest :TDataSet; -- datasource origen, datasource Destino
    Const Excludeds :String = ''; -- aqui ponemos las propiedad que queremos excluir , en el ejemplo el nombre
  Const IncludeFields :Boolean = True; -- aqui indicamos si incluimos los campos o no en la copia
    Const ExcludedFieldProps :String = '' -- aqui indicamos la propiedad de los campos que queremos excluir
  );

Saludos
PD: Con el permiso del maestro. Un abrazo FREE

Muchas gracias Javier. :)

Bueno, primeramente decir que GH Freebrary viene dentro del paquete MagiaData7.zip que subí, y es que las clases TMagiaXXX llaman a algunas funciones "sueltas" de GH Freebrary. Por ejemplo, la propiedad DataSetCloned de TMagiaDataSource causa que internamente se llame a la función ghCloneDataSet de la unidad GHFData, misma unidad donde se encuentra también la función que amablemente ilustró fjcg02.

Neeruu, yo uso todo el tiempo la anterior característica. Es decir, coloco en uno o varios módulos de datos los data sets, pero pongo los data sources (TMagiaDataSource) en los formularios, activándoles a estos la propiedad DataSetCloned para que el formulario trabaje con una copia propia y local del conjunto de datos (un "clon"), y así darle mayor autonomía y evitar conflictos con otros formularios que también necesiten trabajar con el mismo conjunto de datos (ya sea simultáneamente o después en la misma sesión).

Así no tengo necesidad de crear varias instancias de un mismo módulo de datos y tampoco me preocupo de las propiedades que le establezco en tiempo de ejecución al conjunto de datos, porque es un clon que sólo afecta al ámbito del formulario y será destruido cuando el formulario se destruya también.

No obstante, comentas que sin usar nada de esto tienes demoras en las conexiones o aperturas de los conjuntos de datos. Entonces quizá convenga que primero revises por qué se tarda al abrir. Tal vez me equivoque, pero puede que estés trayendo muchos registros al activar alguna tabla o consulta. Creo que sería oportuno atacar primero ese problema. :)

Mencionas también que leíste ya algo sobre Magia Data. Probablemente se trata de este material. De cualquier manera lo enlazo para ayudar a explicar de forma más clara por qué había necesidad de algo así y las ventajas que se obtienen con el componente.

Qué mejor que el padre de la criatura dando las explicaciones oportunas y precisas.

Al, ya que te has lanzado, ahora sería estupendo que nos ilustraras con algún ejemplo práctico de cómo usas todas esas piezas del puzzle que has confeccionado a lo largo del tiempo !!

Ya sabes que me gusta lo bueno, aunque desgraciadamente no tenga dinero para pagarlo. A veces sólo la esencia es suficiente ... y con gusto la disfruto !! ;)

Un abrazo

Hola Javier, disculpa la demora de seis meses. :p

De momento esto puede servir: http://www.clubdelphi.com/foros/show...d=1#post431019

Ojalá hubiera un alma en este mundo que se animara (pero en serio) a echarme una mano con la biblioteca. :(

Saludos.

Al.

Nunca es tarde si la "picha" es buena !!!

jajajajajaj

Una solución simple; almacena en la BBDD las SQL que necesites en tu aplicación. En una segunda tabla almacenas (Formulario, campo y idSQL).
En tu aplicación en el evento "oncreate" del formulario creas en tiempo de ejecución los objetos de datos y los "datasource" correspondientes y lo conectas al campo correspondiente de tu formulario. No necesitas clonar nada y simplificas. La próxima vez que necesites una SQL en otro formulario, ya lo tienes y solo tienes que incluir los datos en la tabla (formulario, campo, idsql):D