Xailer & OZ Software

Hola,
Tengo la siguiente sentencia SQL:
SELECT E.*, D.PHONE_NO
FROM EMPLOYEE E, DEPARTMENT D
WHERE E.DEPT_NO = D.DEPT_NO
El programa me devuelve la consulta, pero el Phone_no de la segunda
tabla no aparece por ningún sitio.
He mirado la dbf temporal y tampoco está.
¿Se pueden hacer uniones de dos tablas?
Un saludico,
Fredy

Fredy,
Creo que el sistema que usa Xailer para los nombres de campo no admite
más de nueve caracteres. (10 que admiten las DBF menos 1 de control que
se usa internamente).
Ponle un alias a la columna y pureba a ver:
SELECT E.*, D.PHONE_NO AS PHONE
FROM EMPLOYEE E, DEPARTMENT D
WHERE E.DEPT_NO = D.DEPT_NO
Y si no es mucho pedir, usa INNER JOIN para estar un poco al dia del uso
del SQL y usa solo el WHERE para hacer filtros.
SELECT E.*, D.PHONE_NO AS PHONE
FROM EMPLOYEE E
INNER JOIN DEPARTMENT D ON E.DEPT_NO = D.DEPT_NO
Saludos,
Jose A. Suarez
Fredy escribió:
> Hola,
>
> Tengo la siguiente sentencia SQL:
>
> SELECT E.*, D.PHONE_NO
> FROM EMPLOYEE E, DEPARTMENT D
> WHERE E.DEPT_NO = D.DEPT_NO
>
> El programa me devuelve la consulta, pero el Phone_no de la segunda
> tabla no aparece por ningún sitio.
> He mirado la dbf temporal y tampoco está.
>
> ¿Se pueden hacer uniones de dos tablas?
>
> Un saludico,
> Fredy

Hola!
> Ponle un alias a la columna y pureba a ver:
No, ya lo he probado y no funciona.
>
> Y si no es mucho pedir, usa INNER JOIN para estar un poco al dia del uso
> del SQL y usa solo el WHERE para hacer filtros.
Sí­, pero ahora tengo un cacao entre uniones, equiuniones, consultar,
subconsulta, lógica de tres niveles, etc.. que más que unido estoy
totalmente enredado.
Cuando deslí­e la madeja, te prometo usarlas
Un saludico,
Fredy

Fredy,
Si que se pueden hacer uniones de dos tablas. Te recomiendo que primero
intentes hacer la consulta con cualquier asistente, y a continuación lo
pases a Xailer.
Un saludo,
"Fredy" <fredy@airtel.net> escribió en el mensaje
news:[email=MPG.1c969bfc7bd71a589896b7@news.ozs.com...]MPG.1c969bfc7bd71a589896b7@news.ozs.com...[/email]
Hola!
> Ponle un alias a la columna y pureba a ver:
No, ya lo he probado y no funciona.
>
> Y si no es mucho pedir, usa INNER JOIN para estar un poco al dia del uso
> del SQL y usa solo el WHERE para hacer filtros.
Sí, pero ahora tengo un cacao entre uniones, equiuniones, consultar,
subconsulta, lógica de tres niveles, etc.. que más que unido estoy
totalmente enredado.
Cuando deslíe la madeja, te prometo usarlas
Un saludico,
Fredy

Ignacio,
Ya he conseguido la union de tablas, lo que pasa es que lo hace de una
forma un tanto confusa. Hay algo que no estoy haciendo como se tiene que
hacer y es lo que da problemas. Me explico.
En la propiedad cSelect del Dataset tengo:
SELECT * FROM EMPLOYEE.
Por lo visto, esta es la sentencia que toma de base para crear la base
de datos temporal y si luego "reconstruyo" la sentencia en nuevos
campos, no los actualiza.
Fí­jate, por ejemplo en el cSelect del DataSet pongo:
SELECT FIRST_NAME, LAST_NAME, PHONE_NO FROM EMPLOYEE, DEPARTMENT
y luego a lo largo del programa le digo:
::oOdbcDataSet1:lOpen := .f.
::oOdbcDataset1:cSelect :=SELECT E.*, PHONE_NO FROM EMPLOYEE E,
DEPARTMENT D WHERE ..
::oOdbcDataset1:lOpen := .t.
La dbf temporal resultantee es la que adjunto al mensaje.
Xailer se ha puesto a meter los campos de la nueva consulta en la dbf
temporal ya creada en el orden en el que le vienen, y claro, no los pone
bien.
Del mismo modo, si tengo un select ya definido y le cambio las columnas
(por ejemplo: cambio el * por FIRST_NAME, LAST_NAME) me da un GPF.
Tengo que poner lOpen a .f., cerrar xailer, volver a entrar, cambiar el
select y poner lOpen a .t.
Algo parecido pasa con el browse. Cuando defines el cSelect en el
inspector de objetos, automáticamente crea las columnas del browse y si
luego cambiamos la condición del select se lí­a de nuevo.
Lo que no sé es cómo hacer para borrar la dbf temporal y forzar que se
cree de nuevo (está claro que el lOpen no lo hace).
¿Cómo tengo que hacer para que se elimine la dbf temporar y se cree de
nuevo?
Las columnas del browse lo veo más complejo y supongo que habrá que
definirlas de nuevo por programación.
Sí­, ya sé que es un poco raro eso de cambiar las columnas de selección
en tiempo de ejecución, pero es que de momento la anchura del cSelect en
el inspector de objetos no da para muchas alegrí­as.
Un saludico,
Fredy
--

Attached files DATABASE.dbf (517 B)Â

Fredy,
>>::oOdbcDataset1:cSelect :=SELECT E.*, PHONE_NO FROM EMPLOYEE E,
Esto construye un dataset COMPLETAMENTE NUEVO. No tiene nada que ver con lo
que pudiera haber antes. De hecho NO TIENE NINGUN SENTIDO hacerlo, es
preferible que utilices un nuevo DataSet y destruyas el que tienes
Olvidate de la Dbf temporal no has de tocarla nunca, imaginate que no
existe, de verdad. Se borrar sola.
De la unión de tablas se encarga el motor SQL Xailer no hace absolutamente
nada más que consultar al motor el cual da una relación de filas ordenada en
base tu sentencia SELECT. Creo que te estas liando sin motivo.
No entiendo cuando dices que cambias las columnas, es imposible cambiarlas,
como las cambias?
Un saludo,
"Fredy" <fredy@airtel.net> escribió en el mensaje
news:[email=MPG.1c96ca76cbc5ad149896b9@news.ozs.com...]MPG.1c96ca76cbc5ad149896b9@news.ozs.com...[/email]
Ignacio,
Ya he conseguido la union de tablas, lo que pasa es que lo hace de una
forma un tanto confusa. Hay algo que no estoy haciendo como se tiene que
hacer y es lo que da problemas. Me explico.
En la propiedad cSelect del Dataset tengo:
SELECT * FROM EMPLOYEE.
Por lo visto, esta es la sentencia que toma de base para crear la base
de datos temporal y si luego "reconstruyo" la sentencia en nuevos
campos, no los actualiza.
Fíjate, por ejemplo en el cSelect del DataSet pongo:
SELECT FIRST_NAME, LAST_NAME, PHONE_NO FROM EMPLOYEE, DEPARTMENT
y luego a lo largo del programa le digo:
::oOdbcDataSet1:lOpen := .f.
::oOdbcDataset1:cSelect :=SELECT E.*, PHONE_NO FROM EMPLOYEE E,
DEPARTMENT D WHERE ..
::oOdbcDataset1:lOpen := .t.
La dbf temporal resultantee s la que adjunto al mensaje.
Xailer se ha puesto a meter los campos de la nueva consulta en la dbf
temporal ya creada en el orden en el que le vienen, y claro, no los pone
bien.
Del mismo modo, si tengo un select ya definido y le cambio las columnas
(por ejemplo: cambio el * por FIRST_NAME, LAST_NAME) me da un GPF.
Tengo que poner lOpen a .f., cerrar xailer, volver a entrar, cambiar el
select y poner lOpen a .t.
Algo parecido pasa con el browse. Cuando defines el cSelect en el
inspector de objetos, automáticamente crea las columnas del browse y si
luego cambiamos la condición del select se lía de nuevo.
Lo que no sé es cómo hacer para borrar la dbf temporal y forzar que se
cree de nuevo (está claro que el lOpen no lo hace).
¿Cómo tengo que hacer para que se elimine la dbf temporar y se cree de
nuevo?
Las columnas del browse lo veo más complejo y supongo que habrá que
definirlas de nuevo por programación.
Sí, ya sé que es un poco raro eso de cambiar las columnas de selección
en tiempo de ejecución, pero es que de momento la anchura del cSelect en
el inspector de objetos no da para muchas alegrías.
Un saludico,
Fredy

In article <422d6a4d$1@ozsrv2.ozlan.local>, InvalidAccount@ozs.com
says...
> Fredy,
>
> >>::oOdbcDataset1:cSelect :=SELECT E.*, PHONE_NO FROM EMPLOYEE E,
>
> Esto construye un dataset COMPLETAMENTE NUEVO. No tiene nada que ver con lo
> que pudiera haber antes. De hecho NO TIENE NINGUN SENTIDO hacerlo, es
> preferible que utilices un nuevo DataSet y destruyas el que tienes
Pues no lo hace bien. O por lo menos a mí­ no me lo hace así­.
Correcto en que crea una consulta nueva con nuevos datos, pero sobre la
definición de columnas (select) que tení­a antes, no sobre la nueva. Solo
cambia los datos, no la estructura

Es como si en lugar de borrar la dbf temporal, le hiciera solo un zap
> Olvidate de la Dbf temporal no has de tocarla nunca, imaginate que no
> existe, de verdad. Se borrar sola.
Vale... lo intentaré...
A partir de ahora será el "buffer temporal"
> De la unión de tablas se encarga el motor SQL Xailer no hace absolutamente
> nada más que consultar al motor el cual da una relación de filas ordenada en
> base tu sentencia SELECT. Creo que te estas liando sin motivo.
>
> No entiendo cuando dices que cambias las columnas, es imposible cambiarlas,
> como las cambias?
No!, es justo al revés, no las cambia.
No sé como está por dentro xailer, pero me imagino que hará algo así­
cuando hacemos una consulta.
- obtener el nombre de los campos
- crear el "buffer temporal" de acuerdo con esos datos
- Cargar el buffer
si modifico el cselect, xailer me vuelve a cargar el buffer, pero existe
la posibilidad de que los nombres de los campos pueden haber cambiado.
Eso es lo que no tiene en cuenta. Recupera los datos bien, pero no los
guarda dónde debe.
No sé si me estoy explicando bien.
Un saludico,
Fredy

Fredy,
>>Pues no lo hace bien. O por lo menos a mí no me lo hace así.
>>Correcto en que crea una consulta nueva con nuevos datos, pero sobre la
>>definición de columnas (select) que tenía antes, no sobre la nueva. Solo
>>cambia los datos, no la estructura
Efectivamente ahora mismo esta fallando, ya que no borra la tabla temporal y
debería hacerlo por seguridad. Pero es que a decir verdad no esta pensado
para usarse de esa forma, no tiene ningún sentido hacer un Select de nuevo,
no obstante se corregirá.
>>si modifico el cselect ...
Porque te empeñas en modificar cSelect? Es como si abrieses una tabla de
clientes y luego quisisess que sobre ese mismo área abrieses otra de
artículos, no tiene sentido. En la próxima version cada vez que se haga un
Select sobre un DataSet que ya esté abierto se destruirá absolutamente
cualquier buffer o DBF temporal que hubiese. De momento te recomiendo que
simplemente crees un nuevo DataSet y destruyas el anterior.
Un saludo,
"Fredy" <fredy@airtel.net> escribió en el mensaje
news:[email=MPG.1c9791e46fdfa7919896be@news.ozs.com...]MPG.1c9791e46fdfa7919896be@news.ozs.com...[/email]
In article <422d6a4d$1@ozsrv2.ozlan.local>, InvalidAccount@ozs.com
says...
> Fredy,
>
> >>::oOdbcDataset1:cSelect :=SELECT E.*, PHONE_NO FROM EMPLOYEE E,
>
> Esto construye un dataset COMPLETAMENTE NUEVO. No tiene nada que ver con
> lo
> que pudiera haber antes. De hecho NO TIENE NINGUN SENTIDO hacerlo, es
> preferible que utilices un nuevo DataSet y destruyas el que tienes
Pues no lo hace bien. O por lo menos a mí no me lo hace así.
Correcto en que crea una consulta nueva con nuevos datos, pero sobre la
definición de columnas (select) que tenía antes, no sobre la nueva. Solo
cambia los datos, no la estructura
Es como si en lugar de borrar la dbf temporal, le hiciera solo un zap
> Olvidate de la Dbf temporal no has de tocarla nunca, imaginate que no
> existe, de verdad. Se borrar sola.
Vale... lo intentaré...
A partir de ahora será el "buffer temporal"
> De la unión de tablas se encarga el motor SQL Xailer no hace absolutamente
> nada más que consultar al motor el cual da una relación de filas ordenada
> en
> base tu sentencia SELECT. Creo que te estas liando sin motivo.
>
> No entiendo cuando dices que cambias las columnas, es imposible
> cambiarlas,
> como las cambias?
No!, es justo al revés, no las cambia.
No sé como está por dentro xailer, pero me imagino que hará algo así
cuando hacemos una consulta.
- obtener el nombre de los campos
- crear el "buffer temporal" de acuerdo con esos datos
- Cargar el buffer
si modifico el cselect, xailer me vuelve a cargar el buffer, pero existe
la posibilidad de que los nombres de los campos pueden haber cambiado.
Eso es lo que no tiene en cuenta. Recupera los datos bien, pero no los
guarda dónde debe.
No sé si me estoy explicando bien.
Un saludico,
Fredy