Consulta muy sencilla, extrañamente lenta

[Angel Fernández]

He sustituido los componentes MDO por FIBPLUS y hasta ahora, las pruebas que he hecho han sido satisfactorias, es decir, el problema parece haberse arreglado.
Sin embargo y por intentar arrojar un poco de luz a este asunto y poder ayudar a alguien que le pase lo mismo, he hecho lo que me apunta Al y he intentado depurar el programa paso a paso con F7, incluso dentro de los distintos componentes. Lamento decir que no lo he conseguido porque me meto en un berenjenal que no parece tener fin: entro en forms, system, mdoquery y un larguísimo etcétera de unidades y procesos. Al cabo de 15 minutos de estar dándole a F7 me he mareado, he pulsado F9 y ¡aparece el parón pero no sé dónde!
Sin duda es mi culpa pues mis conocimientos son muy escasos y estoy dando los segundos pasos con firebird (no los primeros, pero casi).

Empezado por Casimiro Notevi

Y de paso puedes extraer un metadata de la base de datos y de los datos de esa tabla para que probemos con MDO también. Si puedes, claro.

Lo que son datos de la tabla de sensores y tipo de sensores creo que sí puedo darte (no puedo darte los datos que recogen los sensores pues esos pertenecen al cliente). Lo de metadata no sé muy bien qué es; con IBManager he hecho un export metadata de la tabla de sensores y me da algo así (perdón por el formateo de los datos):

RecId Field Name Description Field Type Domain Not Null Default Source Computed Source
1 IDSENSOR INTEGER RDB$64 True
2 IDPROYECTO INTEGER RDB$65 True
3 IDTIPOSENSOR INTEGER RDB$66 True
4 REF CHAR(6) RDB$67 True
5 UBICACION VARCHAR(150) RDB$68 False
6 NOMBRE VARCHAR(50) RDB$69 False
7 ACTIVO 0 Inactivo, 1 Activo SMALLINT RDB$70 True 1
8 BUENAFUNCION 0 No va bien. 1 va bien. SMALLINT RDB$13 True 1

Si lo que quieres es eso, puedo extraer esos datos de la tabla sensores, tipo de sensor y alguna otra a la que apunta sensores y enviártelos mejor formateados.

Gracias a todos por vuestra ayuda y un saludo.

[Angel Fernández]

Añadido:

He copiado los mdodataset que me dan el problema y los he copiado a otra aplicación nueva. Estoy intentado discernir si el problema ocurre sólo con mi aplicación o es de los mdo.
El caso es que lo he probado y funciona bien, pero claro, acababa de probarlo en mi aplicación con lo cual ya no es la primera vez que se ejecuta.
Estoy dando palos de ciego... a ver si entre todos hallamos una solución.

Gracias otra vez.

[[Al González]]

¡Hola!

Empezado por Angel Fernández

...por intentar arrojar un poco de luz a este asunto y poder ayudar a alguien que le pase lo mismo, he hecho lo que me apunta Al y he intentado depurar el programa paso a paso con F7, incluso dentro de los distintos componentes. Lamento decir que no lo he conseguido porque me meto en un berenjenal que no parece tener fin: entro en forms, system, mdoquery y un larguísimo etcétera de unidades y procesos. Al cabo de 15 minutos de estar dándole a F7 me he mareado...

No subestimes la complejidad de la VCL.

Hay que usar F8 también, con puro F7 demorarías varias semanas en encontrar el problema.

Creo que este otro mensaje puede orientarte al respecto:
http://www.clubdelphi.com/foros/show...22&postcount=4

Un saludo.

Al.

[Angel Fernández]

Hola a todos. Por aquí de nuevo, con algo de retraso pero es que voy muy liado últimamente.

Casi he conseguido localizar dónde se produce el parón. Con F8 como me indicaba Al va mucho mejor que F7 que era para salir loco .

Al grano: he dicho "casi" porque tengo el procedimiento donde se produce el parón, pero no la línea. El procedimiento es el siguiente:
TMDOSQL.Prepare

Ahora no puedo pasarle otra vez el F8 porque el problema, recordad, era sólo para la primera vez. (Manda huevos).

En fín, aquí sigo, investigando...

Un saludo.

[[Al González]]

Empezado por Angel Fernández

...tengo el procedimiento donde se produce el parón, pero no la línea. El procedimiento es el siguiente:
TMDOSQL.Prepare...

Coloca un punto de ruptura en el Begin de ese método. Ejecuta el programa de manera normal y cuando tu consulta se ejecute y se detenga en ese punto de ruptura, continúa de nuevo con F8/F7 dentro de las sentencias de esa rutina.

Ya acorralaste a la anomalía, casi la has cazado.

Seguimos leyéndote.

Al.

[Delfino]

Pero esta tardanza ocurre sólo la primera vez que se abre el MDODATASET

No creo q la causa sean los MDO, a mi me paso una vez y la causa era el campo lookup, mas concretamente abrir la tabla lookup en un momento inadecuado..

[Angel Fernández]

Hola, de nuevo por aquí con algo más de información.

Empezado por Al González

Ya acorralaste a la anomalía, casi la has cazado.
Al.

Gracias Al por tu apoyo pero me temo que voy a defraudarte. He encontrado la línea de código que ocasiona el parón.
Concretamente es la unit MDOSQL.PAS procedure TMDOSQL.PREPARE (copio y pego directamente del editor para tratar de ubicar un poco mejor el problema):

Código Delphi [-]procedure TMDOSQL.Prepare;
var stmt_len: Integer; res_buffer: array[0..7] of Char;
type_item: Char;
begin if FCursor = '' then FCursor := Name + RandomString(8); CheckClosed; FBase.CheckDatabase; FBase.CheckTransaction; if FPrepared then exit; if (FSQL.Text = '') then MDOError(mdoeEmptyQuery, [nil]);
if not ParamCheck then FProcessedSQL.Text := FSQL.Text else PreprocessSQL; if (FProcessedSQL.Text = '') then MDOError(mdoeEmptyQuery, [nil]);
try Call(isc_dsql_alloc_statement2(StatusVector, DBHandle, @FHandle), True); {PROBLEMA --> } Call(isc_dsql_prepare(StatusVector, TRHandle, @FHandle, 0, PChar(FProcessedSQL.Text), Database.SQLDialect, nil), True);
{ After preparing the statement, query the stmt type and possibly
create a FSQLRecord "holder" } { Get the type of the statement } type_item := Char(isc_info_sql_stmt_type); Call(isc_dsql_sql_info(StatusVector, @FHandle, 1, @type_item, SizeOf(res_buffer), res_buffer), True); if (res_buffer[0] <> Char(isc_info_sql_stmt_type)) then MDOError(mdoeUnknownError, [nil]);
stmt_len := isc_vax_integer(@res_buffer[1], 2);
FSQLType := TMDOSQLTypes(isc_vax_integer(@res_buffer[3], stmt_len));
{ Done getting the type } case FSQLType of SQLGetSegment, SQLPutSegment, SQLStartTransaction: begin FreeHandle; MDOError(mdoeNotPermitted, [nil]);
end;
SQLCommit,
SQLRollback,
SQLDDL, SQLSetGenerator,
SQLInsert, SQLUpdate, SQLDelete, SQLSelect, SQLSelectForUpdate,
SQLExecProcedure: begin { We already know how many inputs there are, so... } if (FSQLParams.FXSQLDA <> nil) and (Call(isc_dsql_describe_bind(StatusVector, @FHandle, Database.SQLDialect, FSQLParams.FXSQLDA), False) > 0) then MDODatabaseError; FSQLParams.Initialize; if FSQLType in [SQLSelect, SQLSelectForUpdate,
SQLExecProcedure] then begin { Allocate an initial output descriptor (with one column) } FSQLRecord.Count := 1; { Using isc_dsql_describe, get the right size for the columns... } Call(isc_dsql_describe(StatusVector, @FHandle, Database.SQLDialect, FSQLRecord.FXSQLDA), True); if FSQLRecord.FXSQLDA^.sqld > FSQLRecord.FXSQLDA^.sqln then begin FSQLRecord.Count := FSQLRecord.FXSQLDA^.sqld; Call(isc_dsql_describe(StatusVector, @FHandle, Database.SQLDialect, FSQLRecord.FXSQLDA), True); end else if FSQLRecord.FXSQLDA^.sqld = 0 then FSQLRecord.Count := 0; FSQLRecord.Initialize; end;
end;
end;
FPrepared := True;
if not (csDesigning in ComponentState) then MonitorHook.SQLPrepare(Self); except on E: Exception do begin if (FHandle <> nil) then FreeHandle; raise;
end;
end;
end;


Y ya no sé qué mas hacer. Yo no soy capaz de resolver el problema ni aún sabiendo que está en esa línea.

Lo que dije en un post anterior que con FIBPLUS se solucionaba, no es del todo cierto. Se soluciona al acceder a la tabla sensores en un primer momento, pero extrañamente, aparece el parón con retardo.

Entiendo que debe ser algo relacionado con los registros que dependen de la tabla sensores. Hay que recordar que de esta tabla dependen dos tablas más que son las que almacenan los datos, y ahora mismo tienen más de 6 millones de datos entre las dos. Esto lo he deducido de una de mis múltiples pruebas a ciegas: he quitado los datos de las tablas de datos y el parón en la tabla de sensores desaparece (al menos así parece). ¿Es posible que un número muy grandes de datos de una tabla dependiente ocasione retardo en la tabla madre? Todo esto me da un dolor de cabeza tremendo y me temo que lo voy a dejar así.

De lo que apunta Delfino de un campo lookup abierto en un momento inadecuado, no creo que sea eso porque ya desactivé el campo lookup y el problema persistía.

Gracias a todos por vuestras aportaciones y en especial a Al que me ha animado a "cazar" la anomalía (aunque el cazador en este caso es un novato con un rifle de perdigones que no mataría ni un pollito). Si se te ocurre alguna otra prueba, Al, dímela y encantado la hago.

Un saludo.

[Angel Fernández]

Perdón, al hacer vista previa de mensaje, el código delphi se veía bien, pero al enviar la respuesta definitiva me lo formatea mal.

Vuelvo a enviar el código delphi formateado:

Código Delphi [-]
procedure TMDOSQL.Prepare;
var
  stmt_len: Integer;
  res_buffer: array[0..7] of Char;
  type_item: Char;
begin
  if FCursor = '' then
    FCursor := Name + RandomString(8);
  CheckClosed;
  FBase.CheckDatabase;
  FBase.CheckTransaction;
  if FPrepared then
    exit;
  if (FSQL.Text = '') then
    MDOError(mdoeEmptyQuery, [nil]);
  if not ParamCheck then
    FProcessedSQL.Text := FSQL.Text
  else
    PreprocessSQL;
  if (FProcessedSQL.Text = '') then
    MDOError(mdoeEmptyQuery, [nil]);
  try
    Call(isc_dsql_alloc_statement2(StatusVector, DBHandle,
                                    @FHandle), True);
    Call(isc_dsql_prepare(StatusVector, TRHandle, @FHandle, 0,
               PChar(FProcessedSQL.Text), Database.SQLDialect, nil), True);
    { After preparing the statement, query the stmt type and possibly
      create a FSQLRecord "holder" }
    { Get the type of the statement }
    type_item := Char(isc_info_sql_stmt_type);
    Call(isc_dsql_sql_info(StatusVector, @FHandle, 1, @type_item,
                         SizeOf(res_buffer), res_buffer), True);
    if (res_buffer[0] <> Char(isc_info_sql_stmt_type)) then
      MDOError(mdoeUnknownError, [nil]);
    stmt_len := isc_vax_integer(@res_buffer[1], 2);
    FSQLType := TMDOSQLTypes(isc_vax_integer(@res_buffer[3], stmt_len));
    { Done getting the type }
    case FSQLType of
      SQLGetSegment,
      SQLPutSegment,
      SQLStartTransaction: begin
        FreeHandle;
        MDOError(mdoeNotPermitted, [nil]);
      end;
      SQLCommit,
      SQLRollback,
      SQLDDL, SQLSetGenerator,
      SQLInsert, SQLUpdate, SQLDelete, SQLSelect, SQLSelectForUpdate,
      SQLExecProcedure: begin
        { We already know how many inputs there are, so... }
        if (FSQLParams.FXSQLDA <> nil) and
           (Call(isc_dsql_describe_bind(StatusVector, @FHandle, Database.SQLDialect,
                                        FSQLParams.FXSQLDA), False) > 0) then
          MDODatabaseError;
        FSQLParams.Initialize;
        if FSQLType in [SQLSelect, SQLSelectForUpdate,
                        SQLExecProcedure] then
        begin
          { Allocate an initial output descriptor (with one column) }
          FSQLRecord.Count := 1;
          { Using isc_dsql_describe, get the right size for the columns... }
          Call(isc_dsql_describe(StatusVector, @FHandle, Database.SQLDialect, FSQLRecord.FXSQLDA), True);
          if FSQLRecord.FXSQLDA^.sqld > FSQLRecord.FXSQLDA^.sqln then
          begin
            FSQLRecord.Count := FSQLRecord.FXSQLDA^.sqld;
            Call(isc_dsql_describe(StatusVector, @FHandle, Database.SQLDialect, FSQLRecord.FXSQLDA), True);
          end else if FSQLRecord.FXSQLDA^.sqld = 0 then
            FSQLRecord.Count := 0;
          FSQLRecord.Initialize;
        end;
      end;
    end;
    FPrepared := True;
    if not (csDesigning in ComponentState) then
      MonitorHook.SQLPrepare(Self);
  except
    on E: Exception do
    begin
      if (FHandle <> nil) then
        FreeHandle;
      raise;
    end;
  end;
end;

Disculpad.

[Angel Fernández]

Y ahora me olvido indicar la línea con el problema.
Es ésta:

Call(isc_dsql_prepare(StatusVector, TRHandle, @FHandle, 0,
PChar(FProcessedSQL.Text), Database.SQLDialect, nil), True);

Ruego a los moderadores perdonen mi torpeza (aunque en mi descargo diré que es un problema del botón "Vista Previa de Mensaje")