¡Ah! Ok.

// Saludos

No, necesita que se le añada la tabla, el "from loquesea" y devuelve los registros que tenga la tabla o los que devuelva el filtro que le pongas, o sea, añade ese valor numérico como un campo más a todos los registros.

Asi es, pero la sentencia

Código SQL [-]
Select first 1 from tablaX

Entonces si sólo muestra 1 registro de la tablaX, lo cual me parece un tanto lógico, ¿ los otros motores que muestran roman ?, me parece interesante ver lo que produce la sentencia Select 1 digamos en MySQL

Saludos

Hola roman.

Así sin más, no.

Si se puede como en el código de la imágen de Casimiro (y supongo que en el de egostar) haciendo referencia a una tabla.

O para evitar referenciar una tabla se podría hacer algo como:

Código SQL [-]
SELECT FIRST 1 NULL FROM RDB$DATABASE

Pero una consulta que no devuelva ni siquiera una constante, nada de nada ... la verdad no lo se. :confused:

Saludos. :)

Pues eso, produce 1:

// Saludos

O más claro:

// Saludos

Esa consulta, o escrita de ese modo, no la soporta Firebird. Puede ser que exista otro modo de formularla pero no tengo conocimiento de ello.

Saludos. :)

Ah ok.

Y si la sentencia es Select 10 produce diez registros ¿?

Saludos

Bueno me auto respondo, debería de regresar un registro con el valor 10, mas bien la pregunta es, ¿ que utilidad se obtiene de una consulta así ?

Saludos

Exacto. Es bastante directo, tú le dices "selecciona 84" y él te regresa exactamente eso, 84 :D También puedes hacer

Código SQL [-]
select 'hola mundo'

o bien

Código SQL [-]
mysql> select concat('hoy es ', curdate());
+------------------------------+
| concat('hoy es ', curdate()) |
+------------------------------+
| hoy es 2012-08-13            |
+------------------------------+
1 row in set (0.01 sec)

// Saludos

Hola.

Me quedé pensando... aún si ejecutara:

Código SQL [-]
SELECT 1

En el DBgrid aparecería la selección ¿ o no ?

Sinceramente yo había entendido que quería eliminar los datos de la tabla (mensaje #3):
Saludos.

Regresando al tema en cuestión.

No será mejor que se use una tabla en memoria (CDS) y usarla para agregar los registros y "borrarla" cuando ya no se requiera ¿? eso nos permitiría usarla para cualquier tabla y cualquier base de datos, el problema es que hay mucho más trabajo en tiempo de ejecución, pero así se evitaría afectar físicamente los datos de las tablas utilizadas.

Saludos

Bueno, una base de datos tendra que estar conectada, pero no se necesita saber el nombre, cuando ya esta uno conectado.

Igualmente, SQL queries son independientes de estar atados a una tabla. La tabla se especifica en el SQL query. Mi aplicacion arranca sin nombre de base de datos, y sin tablas, y el usuario especifica ya al usarla.

El problema que me encontre es con SQLite3, al correr codigo que abre Blobs o Memos durante OnColEnter. Y es que para jalar los datos usa el nombre de la columna (manda un Query).

Eso trabaja bien, pero al mandar un query a OTRA tabla, se regresa un error diciendo que la columna "X" no existe. La columna X pertenece a la tabla anterior.

Monitoreo el SQL que manda la aplicacion, y NO TIENE NADA que ver con la columna X.

La verdad es que esto ya lo doy por "bug" (despues de muchismos analisis y pruebas) de DBGrid de Lazarus, pues la aplicacion trabaja perfectamente mientras no mande un query a otra tabla. Y por lo pronto no le veo el merito a discutir esto mas alla. Tal vez despues.

Gracias por el interes.

P.S., tambien, con el codigo identico, mientras no se accesen Blobs(imagenes) ni Memos (dentro de OnColEnter), SI SE PUEDE mandar queries a OTRA tabla, perfectamente.

A proposito, a mi esto, en Lazarus, usando SQLite3, vacia el grid:

select * from basurax31429cdr

Pero tal vez no en todos los motores sea asi.

Hombre, si vas a hacer un select de unos campos a una tabla y pretendes hacer el mismo select a otra tabla que tiene otros campos... pues es normal que diga que no exista algún campo si, efectivamente, no existe. Eso es lo lógico, no es ningún bug.

Ya explique que el query es correcto, y que funciona perfectamente en otra tabla, mientras no se accesen Blobs en OnColumEnter de la tabla anterior.

Y ESO si seria un bug. Lo que tu describes seria algo muy bobo de hacer, si asi fuese.

.....ademas, el Query ni siquiera menciona las columnas de la Tabla siguiente.

Pues.... me parece que en el evento OnColumnEnter, deberías trabajar un poco más para validar el tipo de campo, dependiendo del campo que actué en consecuencia, digo, es lo más lógico.

Saludos

Es buena observacion, mas eso ya esta validado, y como se ha dicho, el codigo trabaja y muestra imagenes, o Memos, perfectamente, MIENTRAS no se mande un query a otra tabla.

Creo yo que hay un escurrimiento de memoria, o le falta alguna validacion cuando en OnColEnter del DBGrid se accede a Imagenes o a Memos en la rutina de algun componente; creo you que en DBGrid de Lazarus.

Aparte, las tablas son de 3 o 4 tiras, y ninguna tiene campos vacios, y las imagenes son tipicas de camara de 3 megapix y los memos son un parrafo o dos tipicos de texto. Todo se muestra correcto. No hay basura en la data,ni nada asi.

En caso de encontrar algo mas tangible, con gusto se los reporto, aun si fuese defecto de mi desarrollo.

¿Y digo yo porqué en lugar de asumir ciertas cosas (como pensar que se trata de un bug) y ser demasiado esquivo al señalar puntualmente cuales son tus problemas, y ni que decir... que en ningún momento has mostrado siquiera como es que efectivamente estás desarrollando no te tomas en serio y contribuyes al explicarte? Porque muchas palabritas, pero con muy poco sentido, totalmente dispersas, muchas asunciones y de temas tan aislados que al final no se entiende a lo que va la cosa.

ElMug, si deseas recibir ayuda debes explicarte y ceder en brindar la información lo más ordenada y completa posible. Y sin ver al menos pedacito de tu código la tienes IMPOSIBLE.
¡Déjate ayudar! Porque así como lo pones... ¿que más quieres que hagamos? :o