Open en MDOQuery

[mlara]

Hola nuevamente... tengo este caso con un MDOQuery. Alguien sabrá de esto?

Uso: Delphi 7, FireBird 2, y MDOLibRC2.

Tengo un MDOQuery con una consulta muy simple:


select * from "Users"


Cuando ejecuto el método Open, me da este error: "Range check error". Si ejecuto desde Delphi, se abre el archivo MDOCustomDataSet.pas y el cursor se localiza en la línea 1625.

Es como si fuese necesario agregar campos al MDOQuery usando el editor. Pero no necesito hacer esto, ya que con el mismo componente ejecuto mil consultas en toda mi aplicación.

Gracias...

[vtdeleon]

Saludos

Chequea este hilo

[mlara]

Nada vtdeleon. Deshabilité la opción Range Checking en las opciones de proyecto, y no soluciona nada. También recompilé sin la opción 'Range Checking' e instalé nuevamente los componentes. Incluso tuve que recompilar otros (los Hash que uso para validar contraseñas). Ensayé también poniendo los *.pas en carpetas \pas, y bueno, de repente ya no me da el mismo error. El error que sale es otro (Dynamic SQL Error) relacionado con el archivo MDO.pas. Pero si vuelvo a poner los *.pas en el directorio original (runtime), vuelve a salir el error inicial. No importa si compilo con la opción 'Range Checking' o sin ella.

No sé si otra persona tenga idea de lo que pasa. Mientras sigo haciendo pruebas...

[vtdeleon]

Mi experiencia con esos componentes en estos momento es casi nula, pero llegaremos al paso al asunto;). El error que sale es otro (Dynamic SQL Error)[...]Probaste quitando las comillas a la table?
Si agregas los campos usando el editor, funciona?
Invoca solo un campo a ver...

[mlara]

Ok,... ahora el error es otro (en mi código), así que el asunto inicial ya está solucionado.

Conclusión: Si alguien tiene el mismo problema puede probar esto:

1. Recomiple sin la opción 'Range checking' y reinstale los componentes MDOLib.
2. Como Delphi seguirá mostrando el mismo mensaje, mueva los *.pas que se encuentran en la carpeta runtime a otra carpeta (se puede llamar \pas), y listo.

vtdeleon, muchas gracias. Voy a solucionar mi nuevo inconveniente, y espero no frenarme mucho.

[Delfino]

tengo este caso con un MDOQuery.

Usa en su lugar el MDODataset q es igual q un query pero puede hacerse Live si es necesario..

[Lepe]

LLevo usando los MDO algunos meses, MDODataset, MDOQuery, MDOSql y el monitor de sql, no he visto jamás ese fallo que comentas.

El problema con las comillas dobles no debe dar problemas, ya que el MDOCustomDataset tiene una propiedad de "doublequote identifiers", lo he probado y funciona a las mil maravillas.

El problema más bien lo veo de SQL, puede que una udf, palabra reservada de SQL, etc se llame igual que tu tabla Users, y por ahí empiezan los problemas. No sabe identificar si es una tabla o una función.

Yo le cambiaría el nombre a la tabla si estuviese a tiempo.

Tampoco lo cambiaría por un TMDODataset, ya que este último está pensado para actualizar, y no tiene sentido si solo vas a consultar. Incluso si no necesitas moverte por los registros hacia atrás, puedes usar un TMDOSql, el cual es un componente más liviano todavía que el MDOQUERY.

Saludos

[Delfino]

Tampoco lo cambiaría por un TMDODataset
El MDOQuery es solo para compatibilidad con el componente TQuery del BDE, el MDODataset sirve para actualizar solo si le asigna SQL a sus InsertSQL, DeleteSQL etc. En caso contrario es igual q un MDOQuery.

La preferencia del MDODataset es cuando no se sabe si la query va ser actualizable o no, se pone al principio solo con el SelectSQL y cuando se quiere hacerla modificable se configuran las otras, ademas uno puede borrar la unidad MDOQuery de la uses y ahorrar unos bits :p

[Lepe]

Realmente no lo había mirado, pero ahora sip:

En total son unas 40 lineas de código para:

constructor TMDOCustomDataSet.Create(AOwner: TComponent);
...
FQDelete := TMDOSQL.Create(Self);
FQDelete.OnSQLChanging := SQLChanging;
FQDelete.GoToFirstRecordOnExecute := False;
FQInsert := TMDOSQL.Create(Self);
FQInsert.OnSQLChanging := SQLChanging;
FQInsert.GoToFirstRecordOnExecute := False;
FQRefresh := TMDOSQL.Create(Self);
FQRefresh.OnSQLChanging := SQLChanging;
FQRefresh.GoToFirstRecordOnExecute := False;
FQSelect := TMDOSQL.Create(Self);
FQSelect.OnSQLChanging := SQLChanging;
FQSelect.GoToFirstRecordOnExecute := False;
FQModify := TMDOSQL.Create(Self);
FQModify.OnSQLChanging := SQLChanging;
FQModify.GoToFirstRecordOnExecute := False;
...



Sobre el Tquery, muestro el constructor completo:

constructor TMDOQuery.Create(AOwner: TComponent);
begin
inherited Create(AOwner);
FSQL := TStringList.Create;
TStringList(SQL).OnChange := QueryChanged;
FParams := TParams.Create(Self);
ParamCheck := True;
FGenerateParamNames := False;
FRowsAffected := -1;
end;


Aunque TMDOQuery deriva de TMDOCustomDataset, hace un override del constructor.

Por cierto, gracias por hacerme mirar el código, seguiré usando TQuerys cuando solo vaya a consultar datos :p

Saludos

[mlara]

Muy interesantes sus apreciaciones. Por lo que a mí respecta, pues usaré el MDOQuery, ya que trabajo en la migración de un sistema, y necesito trabajar con componentes compatibles a los usados anteriormente.

Con respecto a lo del mensaje 'Range check error', he seguido haciendo pruebas y al parecer lo que tengo es un conflicto con componentes Hash, que uso para cifrar las contraseñas y compararlas. Pero por fortuna, he logrado hacer correr mi aplicación. Ya voy más adelante.