Ver Mensaje Individual
  #17  
Antiguo 07-06-2008
Angel Fernández Angel Fernández is offline
Miembro
 
Registrado: may 2004
Ubicación: Valencia - España
Posts: 141
Reputación: 20
Angel Fernández Va por buen camino
Hola, de nuevo por aquí con algo más de información.
Cita:
Empezado por Al González Ver Mensaje
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.
Responder Con Cita