Al incluir un Uses ¿se carga todo a memoria?

[cestradar]

Eso es precisamente lo que no nos agrada, esta persona esta acostumbrada a trabajar así, con una unit a manera de repositorio de utilerias genéricas (una función que regrese un dataset de un Excel, una función que abra un data set, otra que ejecute un query, etc, etc) y no nos convence eso.

Voy a documentarme sobre las referencias específicas que mencionas para poder descartar un problema por ese lado, voy a tratar de convencer de que en lugar de tener esta unit con funciones de todo tipo, hacer varias conforme la esencia de cada una de ellas; aunque me sigue quedando la duda sobre la utilidad real de una unit de operaciones de bases de datos, y digo, un método para abrir un DataSet mandado de parámetro o ejecutar un query, buscar un registro, etc, no sé exactamente que ta bueno sea, ya que en cada método hay que crear el objeto DataSet, configurarlo, hacer lo que se tenga que hacer y regresar un valor que sea usado en un evento donde también se tuvo que crear una variable DataSet y todo eso.

No se por que no trabajar con componentes en un datamudule como lo hemos hecho tradicionalmente. A lo mejor yo soy el que no ve la "ventaja" que esto me puede ofrecer, por ello mismo me trato de informar

Gracias

[[Lepe]]

El tema de la unidad DateUtils es muy particular. Si te fijas, toda la unidad se basa en FormatDatetime, EncodeDateTime y DecodeDatetime, el resto.... y mira la cantidad de funciones que hay, se llaman entre sí y de forma escalonada.

Sólo quieres usar una función, pero si de forma escalonada se ejecutan 10 funciones, obviamente, las 10 funciones irá en el ejecutable final.

Sobre crear tus propias bibliotecas, bueno, es inevitable, pero más vale que sigas un esquema como la vcl, en mi caso:
lpDateUtils (LP = Lepes)
lpForms
lpClasses
lpconstantes (saltolinea, saltoCarro, etc)
lpTipos (excepciones personalizadas, etc).


Los casos que explicas no veo necesario crear unidades, pero, por ejemplo, todos tenemos una función llamada:

function Createqry(sql:string):TQuery

o ¿no?

Saludos

[roman]

[Paréntesis]
No lo puedo creer. Sé que nunca has mencionado tu nombre real en estos foros amigo Lepe, pero, no me vas a decir que incluso en el prefijo de tus funciones y librerías usas Lepe.
[/Paréntesis]

// Saludos

[Dedalo]

Si no me equivoco, el compilador de Delphi tiene una opcion en el proceso de compilacion de eliminacion de codigo muerto, es decir, que elimina todos los objetos y funciones no utilizados, asi se reduce el tamaño del ejecutable. Esa opcion en los compiladores de C de Borland esta OFF por defecto, mira si la encuentras en Delphi y como esta...

[[Lepe]]

Empezado por roman

Sé que nunca has mencionado tu nombre real en estos foros amigo Lepe,

No puedes afirmar eso, has estado ausente mucho tiempo

Empezado por roman

pero, no me vas a decir que incluso en el prefijo de tus funciones y librerías usas Lepe.
[/Paréntesis]

// Saludos

No uso prefijo en funciones. En el nombre de las unidades sí, para seguir los nombres de la VCL.


CreateQry la uso cuando necesito temporalmente ejecutar una sentencia SQL, pero no quiero tener un TQuery en el Datamodule o en el TForm sólo para una llamada, al final acaba estorbando más que ayudando, por eso uso la rutina que crea, configura la consulta y opcionalmente la ejecuta:

Código Delphi [-]
function Createqry(sql:string):TQuery;
begin
  Result := TQuery.Create(nil);
  Result.DatabaseName:=  el que sea
  Result.sql.text := sql;
end;

function ExecSql(sql:string):integer;
var q:TQuery;
begin
   q := Createqry(sql);
   q.ExecSql;
    Result := q.RowsAffected;
   q.Free;
end;

Muchas veces necesitas una consulta de forma puntual, sólo para actualizar un registro, etc. Tener que poner un TQuery en la ventana (o datamodule), configurarlo, ponerle nombre, y por último llamarlo desde código es "perder el tiempo", "ExecSql" son 7 letras más el SQL y listo .

Saludos

[roman]

Empezado por Lepe

No puedes afirmar eso, has estado ausente mucho tiempo

Las leyes de la lógica son inmutables. Además, tengo un código que examina las paginas de los foros y me avisaría en cuanto dieras tu nombre

Pero a ver, para que no se diga que nada más ando en este hilo fuera de tema les voy a dar mi opinión: no estoy de acuerdo.

El ejemplo de mayenes (quien me debe una cerveza desde hace tiempo) no me convence de la necesidad de CreateQuery. Esas dos Queries que construye, ¿por qué no están en un DataModule? Si estuvieran ahí en primera instancia, ahorraría todavía más código.

Ahora, para una consulta puntual, también se puede tener una Query genérica para eso. Porque, si sólo se tiene una consulta puntual en todo el código, haber definido una función es más trabajo del necesario, así que asumo que se trata de varias consultas puntuales, pero, como digo, para ello se puede usar un query genérico.

Al final de cuentas, creo, el punto está en, ¿por qué queremos construir componentes Query por código?



pd: lo digo un poco por molestar, pero es que no me han convencido.

// Saludos

[MAXIUM]

Creo que se han desviado del tema central.

[[maeyanes]]

Empezado por MAXIUM

Creo que se han desviado del tema central.

Algo raro en estos foros...


Saludos

[[maeyanes]]

Empezado por roman

Pero a ver, para que no se diga que nada más ando en este hilo fuera de tema les voy a dar mi opinión: no estoy de acuerdo.

El ejemplo de maEyAnes () (quien me debe una cerveza desde hace tiempo) no me convence de la necesidad de CreateQuery. Esas dos Queries que construye, ¿por qué no están en un DataModule? Si estuvieran ahí en primera instancia, ahorraría todavía más código.

Al final de cuentas, creo, el punto está en, ¿por qué queremos construir componentes Query por código?



pd: lo digo un poco por molestar, pero es que no me han convencido.

// Saludos

Anda ya... te debo una cerveza? xDDD

No me acordaba

Y sobre mi ejemplo, en realidad fue algo que escribí así de bote pronto... y bueno... para mi si es práctico, por que solo creas el objeto al momento de usarlo, ejecutas el query, obtienes el resultado y lo liberas de la memoria...

Ahora, yo mayormente uso Interbase/Firebird y los componentes IBX, y estoy tienen un componente llamado TIBSQL el cual es más ligero en memoria, y para queries donde solo necesito obtener un valor rapidamente son mejores.

Empezado por Delphi Help

TIBSQL

Use an TIBSQL component for data operations that need to be fast and lightweight. Operations such as data definition and pumping data from one database to another are suitable for IBSQL components.

Saludos...

[cestradar]

Empezado por Lepe

...

Los casos que explicas no veo necesario crear unidades, pero, por ejemplo, todos tenemos una función llamada:

function Createqry(sql:string):TQuery

o ¿no?

mmmmmmmmmmmmmmm, no, no todos

¿Qué ventaja me da tener esa función en una librería a tener un componente TQuery? , digo, igual voy a configurarlos, ya sea con parámetros o desde código.
¿ahorro de código?, igual voy a definir variables tipo TQuery o TDataSet para recibir esa función, no le veo la utilidad real

[[maeyanes]]

Hola...

Empezado por cestradar

mmmmmmmmmmmmmmm, no, no todos

¿Qué ventaja me da tener esa función en una librería a tener un componente TQuery? , digo, igual voy a configurarlos, ya sea con parámetros o desde código.
¿ahorro de código?, igual voy a definir variables tipo TQuery o TDataSet para recibir esa función, no le veo la utilidad real

Pues como bien comentas, ahorro de código...

No es lo mismo hacer:

Código Delphi [-]
var
  AQuery1: TQuery;
  AQuery2: TQuery;

begin
  AQuery1 := TQuery.Create(nil);
  with AQuery1 do
    try
      SQL.Text := 'select * from tabla1';
      Prepare;
      Open;
      // Código X aquí
    finally
      Free
    end;
  AQuery2 := TQuery.Create(nil);
  with AQuery2 do
    try
      SQL.Text := 'select * from tabla2 where campo1 = 5';
      Prepare;
      Open;
      // Código X aquí
    finally
      Free
    end;
  AQuery1 := TQuery.Create(nil);
  with AQuery1 do
    try
      SQL.Text := 'select * from tabla3 where campo1 = 7 and campo2 = ''Hola''';
      Prepare;
      Open;
      // Código X aquí
    finally
      Free
    end;
end;

A tener algo como:

Código Delphi [-]
unit MyFunctions;

interface

uses
  Classes, DB;

function CreateQuery(SQLStr: string): TQuery;

implementation;

function CreateQuery(SQLStr: string): TQuery;
begin
  Result := TQuery.Create(nil);
  with Result do
  begin
    SQL.Text := SQLStr;
    Prepare
  end
end;

end.


unit Form1;

interface

// ...

implementation

uses MyFunctions;

procedure TForm1.Button1Click(Sender: TObject);
begin
  with CreateQuery('select * from tabla1') do
    try
      Open;
      // Código X
    finally
      Free
    end;
  with CreateQuery('select * from tabla2 where campo1 = 5') do
    try
      Open;
      // Código X
    finally
      Free
    end
end;

end.

Ves la diferencia?

Me ahorré declarar 2 variables y re-escribir bastante código...


Saludos...