Mensaje de error extraño

[[coso]]

// Removed the code FCursor set name from the TMDOSQL.Create.
  // This is needed because if you create the MDOSQL dynamically, the name is
  // not assigned in the create and the cursor is only based on a 'random'
  // number. And, in some special situation, duplicate cursornames will appear
  //FCursor := Name + RandomString(8);

que cosa mas cutre...y lo peor de todo, lo dejan a sabiendas...
yo de ti no perderia mas el tiempo con estos componentes. Ahora bien, si aun los quieres usar, puedes probar de, en el create del componente, asignar el nombre del cursor de una manera que a ti te convenga :ej, numero de componentes MDOSQL en la aplicacion o con el GetNamePath, asignando el nombre a cada MDOSQL que crees dinamicamente, o bien haciendo overload del create con un parametro de cursor.

[Sick boy]

Efectivamente, es una chapuza, si al menos hubieran dicho cuales son las condiciones especiales se podria tratar de evitarlas.

Parece que tendre que cambiar de componentes, pero mientras tanto, quisiera resolver esto y ganar un poco de tiempo.

Afortunadamente, solo un cliente tiene esas condiciones especiales.

No me atrevo a meterle mano al codigo de MDO, pero esta claro que de alguna manera debo modificar el nombre del cursor para hacerlo unico, pero no se como hacerlo.

ej, numero de componentes MDOSQL en la aplicacion o con el GetNamePath, asignando el nombre a cada MDOSQL que crees dinamicamente, o bien haciendo overload del create con un parametro de cursor.

Entiendo lo que me dices, el numero de componentes creados dinamicamente es muy variable, no se si sera buena idea.
GetNamePath parece mejor opcion.

Esto funcionaria??:
FCursor := self.getnamepath + RandomString(8);

No es que no quiera probarlo yo mismo, es que me es muy dificil reproducir el error, en mis equipos no pasa.

El overload, pues no tengo ni idea de como quedaria, en este punto necesitaria un ejemplo.

[[Lepe]]

Yo me reservo el derecho de criticar.

Para mí, una gente que trata directamente con la API de un SGBBDD y que dan al programador una interfaz al estilo de Interbase, ya se merecen mi respeto, si además lo hacen Open Source, un aplauso para ellos. Y ya ni hablar del elegante diseño de clases, jerarquías, calidad del código, etc.

Existen componentes de pago (nada baratos) que sólo ver el código fuente se les debería caer la cara de vergüenza, al menos ese fallo, conceptualmente, no tiene mucha importancia (para Sick boy si lo tendrá porque le está amargando la existencia ).

La generación de números aleatorios siempre han tenido ese fallo, pueden repetirse en "determinadas circunstancias". Dicho sea de paso, si la función random hiciera su trabajo bien, los MDO no fallarían .

Saludos

[[coso]]

Esto funcionaria??:
FCursor := self.getnamepath + RandomString(8);

si esta creado dinamicamente y no has asignado un nombre anteriormente, no, pues es mas o menos lo que ya estaban haciendo ellos. Yo haria algo asi: pasar FCursor a protected o a public o bien crear una propiedad con el numero de cursor que es, y hacer algo asi:

Código Delphi [-]
NCursor := 0;
for i := Application (o parent o owner).ComponentCount - 1 do
if (Application.Components[i] is TMDOQuery) 
then NCursor := Max((Application.Components[i] as TMDOQuery).NCursor + 1,NCursor);

FCursor := inttostr(NCursor);

tambien, ahora que lo pienso, puedes capturar la excepción alla mismo:

Código Delphi [-]

Libre := false;
while not Libre then 
try
FCursor := Name + RandomString(8);
Call(isc_dsql_set_cursor_name(StatusVector, @FHandle, PChar(FCursor), 0), True)
...
Libre := true;
except
end;

Lo que me sigue intrigando personalmente es que tansolo te pase en una unica tabla. Quiza deberias mirar mas profundamente las diferencias entre el diseño de la tabla que da error y el resto. Saludos.

[[coso]]

El overload seria algo asi:

Código Delphi [-]
protected
constructor Create(AOwner : TComponent); overload;
constructor Create(AOwner : TComponent; ncursor : string); overload;
...

etc...
Tambien puedes darle un nombre por defecto al componente cuando se crea aunque seria un poco estirar el problema

Código Delphi [-]
...
if FName = '' then 
Name := 'MDOQuery_' + FormatFloat('00000000',random(99999999));

[Sick boy]

Empezado por Lepe

Yo me reservo el derecho de criticar.

Para mí, una gente que trata directamente con la API de un SGBBDD y que dan al programador una interfaz al estilo de Interbase, ya se merecen mi respeto, si además lo hacen Open Source, un aplauso para ellos. Y ya ni hablar del elegante diseño de clases, jerarquías, calidad del código, etc.
Saludos

Bueno, lo de chapuza lo decia por el problemon que estoy teniendo, los componentes me han funcionado muy bien hasta ahora.
Un poco chapuza dejar el codigo editado y sin corregir, al menos sabian que podia haber un problema.

He revisado el codigo de los IBX y tienen el mismo codigo, esta vez sin editar, y no veo que tengan otro mecanismo para solucionarlo.

Sobre los numeros aleatorios, ¿Cuales seran las "determinadas circunstancias"?
No es que pase solo con una base de datos, es que pasa solo en un PC, yo sigo sin poder reproducir el error en mis ordenadores.

Voy a probar una modificacion en la creacion de los numeros aleatorios, y quizas tratar de capturar la excepcion como sugiere coso.

El lunes podre probarlo en el cliente y os comento si funciona.

Por cierto, las tablas son iguales, no hay ninguna diferencia. Incluso rellene una base de datos nueva y vacia con los datos de la que daba problemas, y sigue igual.

[[coso]]

...todo un misterio...¿no tendra algo que ver el nombre de la tabla?...bueno, ya nos diras. Saludos y suerte.

[[Al González]]

¡Hola a todos!

Descargué la biblioteca de componentes Mercury Database Objects —MDO— (la misma versión que está usando Sick Boy, según me comentó), para echar un vistazo con mayor cercanía, específicamente sobre lo que se ha comentado de las unidades MDOSQL.pas y MDOUtils.pas (lo del nombre de cursor aleatorio, vaya), comparando diferencias con las unidades equivalentes nativas IBSQL.pas y IBUtils.pas de los IBX.

Empezado por Sick boy

...intenta establecer el nombre del cursor con una llamada call

Código Delphi [-]
// En MDOSQL.pas

procedure TMDOSQL.ExecQuery;
var
  fetch_res: ISC_STATUS;
begin
  ...
        Call(
          isc_dsql_set_cursor_name(StatusVector, @FHandle, PChar(FCursor), 0),
          True);

FCursor debe tener la informacion que buscamos, asi que hago una busqueda en el codigo y encuentro esto en el CONSTRUCTOR de TMDOSQL:

Código Delphi [-]
// En MDOSQL.pas

constructor TMDOSQL.Create(AOwner: TComponent);
begin
  inherited Create(AOwner);
  ...
  // Removed the code FCursor set name from the TMDOSQL.Create.
  // This is needed because if you create the MDOSQL dynamically, the name is
  // not assigned in the create and the cursor is only based on a 'random'
  // number. And, in some special situation, duplicate cursornames will appear
  //FCursor := Name + RandomString(8);

buffff, atentos a esto: "And, in some special situation, duplicate cursornames will appear" !!!!!

Justo lo que me sucede ahora, ya que muchas querys las creo dinamicamente...

Es curioso esto que encontraste, por varias razones:

1. El nombre de un componente (propiedad Name) es una cadena vacía durante su construcción. A menos que el constructor realice, directa o indirectamente, una asignación de valor a la propiedad Name, no tiene sentido usarla como parte de una expresión dentro del constructor.

2. Los creadores de MDO movieron esa sentencia al método Prepare, como bien lo señalaste, pero en los IBX sí está habilitada en el constructor de TIBSQL, por lo que, en ese caso, el nombre del cursor siempre será solamente lo que devuelva la función RandomString (un número aleatorio de 8 dígitos). Un dato importante para los usuarios de IBX.

3. Esto me hace pensar, y trato de recordar si lo que voy a mencionar es cierto, que en versiones más antiguas de Delphi, al agregar un componente a un formulario o módulo de datos en tiempo de diseño, dicho componente obtenía su nombre predeterminado ("Label1", "IBSQL1") por medio del constructor Create de TComponent. Si alguien tiene Delphi 5 o anterior y algo de tiempo para comprobar ésto definiendo e instalando una clase de componente de prueba que muestre su nombre como última sentencia del constructor, se lo agradecería.

4. Los creadores de MDO movieron la sentencia al método Prepare, con el argumento de "if you create the MDOSQL dynamically, the name is not assigned in the create and the cursor is only based on a 'random' number". Es claro que se dieron cuenta de lo mismo que comenté anteriormente (desde X versión de Delphi, o quizá desde siempre, la propiedad Name no tiene valor durante la ejecución del constructor). Pero asumen, o dan por recomendado, que debe asignarse un valor a la propiedad Name del objeto antes de ejecutar la consulta para que el nombre del cursor quede más rico y sea menos probable que se repita, lo cual es sencillo si el componente es agregado en tiempo de diseño o lo instanciamos nosotros mismos y enseguida le damos valor a Name. Sin embargo, la clase común TMDOCustomDataSet, al igual que sucede en los IBX, crea varias instancias internas de estos objetos SQL sin darles valor a su propiedad Name (a no ser que lo haga en algún punto del código que no logro ver). Así pues, con el nombre del cursor (FCursor) generado en el constructor Create o en el método Prepare, éste siempre será un número de 8 dígitos, a menos que se trate de un componente TMDOSQL que nosotros mismos hayamos preparado.

Empezado por Sick boy

...
Vale, ya tenemos localizado el problema, los creadores de MDO ya lo sabian, veamos como lo resolvieron....

Código Delphi [-]
// En MDOSQL.pas

procedure TMDOSQL.Prepare;
var
  stmt_len: Integer;
  res_buffer: array[0..7] of Char;
  type_item: Char;
begin
  if FCursor = '' then      // !! Parece que NO LO RESOLVIERON !!!
    FCursor := Name + RandomString(8);  // !! Utilizan el randomstring(8) igual que...

En mi caso, los cursores que dan errores solo lo forman 8 numeros, el "Name" parece no contener ningun valor.

Esto va acorde con lo que comenté en el punto #4, pero no demerita el cambio que hicieron. Cuando agregues tú mismo un componente TMDOSQL a un módulo de datos, a éste le servirá realmente ese cambio. Entiendo que en la práctica esto parece poco útil, porque principalmente se usan derivados de TMDOCustomDataSet que crean instancias internas y sin nombre de objetos TMDOSQL, pero acabo de encontrar algo al respecto que te agradará (lo menciono más abajo ).

Empezado por Sick boy

...Estas son las funciones que generan el nombre (numero) del cursor:

Código Delphi [-]
// En MDOUtils.pas

function RandomString(iLength: Integer): String;
begin
  result := '';
  while Length(result) < iLength do
    result := result + IntToStr(RandomInteger(0, High(Integer)));
  if Length(result) > iLength then
    result := Copy(result, 1, iLength);
end;

function RandomInteger(iLow, iHigh: Integer): Integer;
begin
  result := Trunc(Random(iHigh - iLow)) + iLow;
end;

Ahora mi duda es la siguiente, ¿Garantizan estas funciones numeros aleatorios para los cursores??

Si no son seguras, se pueden mejorar???...

Son las mismas funciones en IBX. Sí garantizan números aleatorios, pero no únicos. Las probabilidades parecen ser bajas (1 en decenas de millones), pero, ahora que existen los GUIDs, podría ser preferible usar las funciones CreateGUID y GUIDToString de la unidad SysUtils.

Empezado por Sick boy

...Por otro lado, si el problema no es por la generacion del numero de cursor, entonces es que un cursor se queda "pillado", pero no se como puede ser posible...

Eso necesitaría de otra línea de investigación. Pero dinos una cosa: en las máquinas donde falla, ¿cuántas veces por día u hora tu programa realiza una consulta Select sobre la base de datos? Una cifra estimada.

Empezado por coso

  // Removed the code FCursor set name from the TMDOSQL.Create.
  // This is needed because if you create the MDOSQL dynamically, the name is
  // not assigned in the create and the cursor is only based on a 'random'
  // number. And, in some special situation, duplicate cursornames will appear
  //FCursor := Name + RandomString(8);

que cosa mas cutre...y lo peor de todo, lo dejan a sabiendas...
yo de ti no perderia mas el tiempo con estos componentes...

Con todo respeto, creo que fue algo precipitado ese comentario amigo Coso. Por lo que expliqué antes, me parece que fue un acierto del autor mover esa parte del código al método Prepare, que si bien no es una solución brillante, al menos hará más seguro al componente cuando lleve un nombre. El texto no parece tener una buena redacción, pero lo entiendo como "movimos esto a otro lugar, porque en este punto el componente no tiene nombre y por tanto el nombre del cursor sería solamente un número aleatorio que podría llegar a repetirse".

Empezado por Sick boy

...Ya me gustaria saber cual es la "special situation" a la que se refieren...si al menos hubieran dicho cuales son las condiciones especiales se podria tratar de evitarlas...

Creo que te sales un poco de órbita. Sólo está diciendo que por ser un simple número aleatorio (sin el nombre del objeto como prefijo) es mucho más probable que coincida con el nombre de otro cursor abierto. Entiendo lo de "special situation" como "en algunas pero muy poco frecuentes ocasiones", y reitero que no fue nada malo ese cambio en el código.

Empezado por Sick boy

...Parece que tendre que cambiar de componentes...

Aun cuando ya no suelo usar este tipo de componentes especializados en un motor (tarde o temprano te enamoras de dbExpress con TClientDataSet ), creo que cambiar de componentes sería algo aventurado en este momento.

Empezado por Sick boy

...Afortunadamente, solo un cliente tiene esas condiciones especiales...

¿Será que él es el único que hace un uso extensivo de la aplicación? Vuelvo a mi pregunta de más arriba: ¿cuántas consultas realiza el programa en una sola sesión de ese cliente? Y, por casualidad, ¿no estará alguna parte del programa jugando con la variable RandSeed?

Empezado por Sick boy

...No me atrevo a meterle mano al codigo de MDO, pero esta claro que de alguna manera debo modificar el nombre del cursor para hacerlo unico, pero no se como hacerlo...

Podrías modificar el código fuente de MDO, pero, para evitar conflictos de versiones cuando compartas o actualices tu código, sería más sencillo asignarle un valor a la propiedad QSelect.Name de tus componentes de consulta antes de que sea llamado el método Prepare, buscando, desde luego, que sean nombres únicos los que establezcas. Esto puedes hacerlo en el evento OnCreate del módulo de datos, o justo después de crearlos en tiempo de ejecución. Sólo toma en cuenta que la propiedad QSelect (que es el objeto TMDOSQL de la discordia), está protegida en algunas clases como TMDOQuery (al parecer no en TMDODataSet). Pero puedes usar el típico truco de molde de tipo para acceder a esa propiedad en caso de ser necesario.

Empezado por Sick boy

...me es muy dificil reproducir el error, en mis equipos no pasa...

Te sugiero emplear la misma función, RandomString, pero con un valor de 1 en lugar de 8, para intentar reproducir las condiciones que generan la excepción.

Empezado por Lepe

...La generación de números aleatorios siempre han tenido ese fallo, pueden repetirse en "determinadas circunstancias"...

Totalmente de acuerdo. Aunque el fallo es querer usar números aleatorios cuando lo que realmente se busca obtener son números únicos. Por ello mi sugerencia de usar GUIDs.

Empezado por Lepe

...Dicho sea de paso, si la función random hiciera su trabajo bien, los MDO no fallarían ...

Esto me llamó mucho la atención, Lepe. ¿Cómo debería hacer su trabajo la función Random?


Como punto y aparte, y a pesar del análisis anterior, yo no descarto que la causa del problema pueda ser otra cosa. Esperemos a ver qué nos trae Sick Boy...

Un abrazo sin nombre.

Al González.

P.D. Algo más: ¿alguien conoce el ámbito que tienen los nombres de cursores? ¿Es por conexión (programa), por máquina cliente, globales para todos los clientes...? Pienso que deberían ser por conexión/transacción, pero quisiera confirmarlo.

[[Lepe]]

Empezado por Al González

El texto no parece tener una buena redacción,

Ya sé que no es excusa, pero los creadores de MDO son portugueses, al menos el creador original.

Empezado por Al González

Esto me llamó mucho la atención, Lepe. ¿Cómo debería hacer su trabajo la función Random?

Ya me metió en el fregao.... ... o mejor dicho, me lo busqué yo solito .
Si los de borland no lo han solucionado... no voy a ser yo quien lo haga .

No he tenido tiempo de mirar el código, amén de que no uso MDO ahora mismo. Por otra parte lo de GUID fue lo primero que pensé, pero dado que no sabía que tal rebuscado era el código (si estaba dentro de threads, secciones críticas o "cosas más raras aún") preferí ser cáuto y no decir nada. También es posible que los MDO se usarán, como bien dices, en versiones más antiguas de delphi donde no estuviese disponible el GUID.

Empezado por Sick boy

Un poco chapuza dejar el codigo editado y sin corregir, al menos sabian que podia haber un problema.

Te pido disculpas anticipadas y espero no te lo tomes a mal Sick boy, pero echa una visual por ejemplo al código fuente de la JVCL y lo verás lleno de "todo's", preguntas del estilo "¿esto dará fallo?" y lo más gracioso:"not implemented yet" en propiedades que tienes en el inspector de objetos y frases aún peores. Lo que quiero que comprendas es que un componente estable no significa "finalizado", e incluso uno "finalizado" no quiere decir que funcionará por tiempo ilimitado, tarde o temprano saldrá una actualización de tal o cual .dll o incluso de hardware que echará por tierra el buen funcionamiento de todo componente.

Y las disculpas anticipadas, era por este comentario:
"Entonces, no usarás la JVCL ¿verdad? siguiendo tu línea ¡¡es descabellado usar la JVCL!! ¡¡ está plagado de todo's y not implemented yet!!".

En fin, no puedo aportar nada de valor al hilo y no quiero desvirtuar más de lo necesario, así que con el permiso de venia, me retiro.

... bueno... quizás sí... Sick Boy, si quieres un TMDOAutoDataset, es decir, un componente que se crea en ejecución y que dando la sql de selección genera automáticamente las demás sqls de inserción, borrado y actualización, dilo y subo el archivo.

Saludos

[Sick boy]

Ole, no se por donde empezar.

1. El nombre de un componente (propiedad Name) es una cadena vacía durante su construcción. A menos que el constructor realice, directa o indirectamente, una asignación de valor a la propiedad Name, no tiene sentido usarla como parte de una expresión dentro del constructor.

Ayer ya me di cuenta (le puse un showmessage al crear el cursor) de que la propiedad Fname no tiene ningun valor. Salvo que haya otro punto donde se creen los cursores, Fname es vacio tanto si creas el objeto en diseño o en ejecucion. Por lo tanto, todos los cursores son numeros de 8 digitos.

Efectivamente, el prefijo Fname ayudaria mucho a crear cursores unicos.

Los creadores de MDO movieron la sentencia al método Prepare, con el argumento de "if you create the MDOSQL dynamically, the name is not assigned in the create and the cursor is only based on a 'random' number". Es claro que se dieron cuenta de lo mismo que comenté anteriormente (desde X versión de Delphi, o quizá desde siempre, la propiedad Name no tiene valor durante la ejecución del constructor). Pero asumen, o dan por recomendado, que debe asignarse un valor a la propiedad Name del objeto antes de ejecutar la consulta para que el nombre del cursor quede más rico y sea menos probable que se repita, lo cual es sencillo si el componente es agregado en tiempo de diseño o lo instanciamos nosotros mismos y enseguida le damos valor a Name. Sin embargo, la clase común TMDOCustomDataSet, al igual que sucede en los IBX, crea varias instancias internas de estos objetos SQL sin darles valor a su propiedad Name (a no ser que lo haga en algún punto del código que no logro ver). Así pues, con el nombre del cursor (FCursor) generado en el constructor Create o en el método Prepare, éste siempre será un número de 8 dígitos, a menos que se trate de un componente TMDOSQL que nosotros mismos hayamos preparado.

Bueno, me dices que name deberia tener un valor en componentes creados en tiempo de diseño, pero estoy casi seguro de que no es asi, los cursores siempre son 8 digitos. Voy a ver si consigo darle valor a Name, creo que seria una buena solucion.

He seguido investigando en el codigo MDO, y veo que TMDOSQL no tienen por ninguna parte la propiedad Fname, mientras que la clase TMDOXSQLVar si que la tiene. Por lo que veo es la unica clase con esa propiedad.

Por ahora, no veo la forma de darle valor a Name, creo que esto mejoraria la situacion.

Acabo de pasar el randomString(1), es decir, los cursores son un numero de un digito, name sigue siendo nulo. Como era de esperar la aplicacion arranca con problemas, pero ya puedo reproducir el error facilmente.

Cita:
Empezado por Sick boy Ver Mensaje
...Por otro lado, si el problema no es por la generacion del numero de cursor, entonces es que un cursor se queda "pillado", pero no se como puede ser posible...
Eso necesitaría de otra línea de investigación. Pero dinos una cosa: en las máquinas donde falla, ¿cuántas veces por día u hora tu programa realiza una consulta Select sobre la base de datos? Una cifra estimada.

La pregunta es ¿cuantas veces abre el mismo Select? o ¿cuantos select/insert/... se realizan??
En este caso, el cliente realiza un uso bajo de la aplicacion, hay clientes que le superan por mucho.
Aproximado, no se, quizas 500 sentencias por hora. Algunas de las operaciones habituales requieren unos 6 cursores.

P.D. Algo más: ¿alguien conoce el ámbito que tienen los nombres de cursores? ¿Es por conexión (programa), por máquina cliente, globales para todos los clientes...? Pienso que deberían ser por conexión/transacción, pero quisiera confirmarlo.

No estoy seguro, pero ahora que tengo cursores de un digito, te puedo indicar que el cursor 1 puede habrirse 3 veces seguidas sin problemas, y quizas la cuarta de el error, asi que debe ser a nivel de transaccion, o me daria el error al salir la segunda vez.

Acabo de descubrir algo interesante.
Le he puesto transaction.name y sql.text al showmessage que me indicaba cuando un cursor nuevo es creado. Tambien he puesto un showmessage para ver los cursores que no son nuevos. Los cursores son de 1 digito.
Los cursores reutilizados funcionan bien.
Los cursores nuevos, nunca tienen nombre, y parece que el ambito es la transaccion, ya que si haces un comit, la proxima vez que se abre el cursor aparece como NUEVO y le asigna un nuevo numero sin problemas. Diferentes transacciones y mismos numeros hasta ahora todo bien.

La sorpresa es que los select internos tipo "Select F.RDB$COMPUTED_BLR, F.RDB$DEFAULT_VALUE ....." no llevan asignado un nombre de transaccion.
Cuando comienzan a abrirse estos cursores, en pocas sentencias se produce el error, por ejemplo, detecta que el cursor 1 ya esta declarado y salta la excepcion. Cada vez que vuelva a aparecer ese cursor 1 en la transaccion "sin nombre" saltará el error.
He puesto un timer que repite una sentencia SQL simple, el select mio se ejecuta bien en la transaccion que tiene asignada. Al ejecutar la sentencia interna que te devuelve los valores por defecto, campos calculados, .... el cursor asignado en los 10 ultimos select ha sido el 1 (poco aleatorio, pero bueno) y cada vez que sale el 1 da error en ese select, no en el mio.
Si aleatoriamente sale un numero distinto del 1 la sentencia funciona correctamente.

Si cierras la aplicacion y la vuelves a abrir comienza todo, por lo que creo que el ambito del cursor es a nivel de transaccion/conexion.