Vistas locales "Re escribibles"

15/11/2004 - 19:45 por Leopoldo Sánchez | Informe spam
Buenos días, alguien podría ayudarme con un detalle, genero vistas locales
al inicio de mi aplicación por código, pero cuando corro la aplicación desde
el exe, me pregunta si quiero re escribir las vistas, como puedo quitar esa
pregunta, se puede usar el readwrite como con los cursores?

Este es parte del código que uso:

*************************************************
* CREA LA VISTA LOCAL DE SOCIOS *
**********************************************************************************
WAIT WINDOW "Identificando Socios Activos" TIMEOUT 1.5
CREATE SQL VIEW vsocios_activos AS ;
SELECT * ;
FROM ;
DBC!socios ;
WHERE cstatus == 'ACTIVO';
ORDER BY nid_socios

ÛSETPROP("vsocios_activos","VIEW","TABLES","DBC!socios")
ÛSETPROP("vsocios_activos.nid_socios","Field","KeyField",.T.)
ÛSetProp("vsocios_activos","View","UpdateType",1)
ÛSETPROP("vsocios_activos.nid_socios","Field","UpdateName","socios.nid_socios")
ÛSETPROP("vsocios_activos.nid_socios","Field","Updatable",.F.)
ÛSETPROP("vsocios_activos.ctitulo","Field","UpdateName","socios.ctitulo")
ÛSETPROP("vsocios_activos.ctitulo","Field","Updatable",.T.)

Leopoldo Sánchez
Monterrey, México

Preguntas similare

Leer las respuestas

#6 Esparta Palma
16/11/2004 - 17:51 | Informe spam
Las vistas son consultas SQL con propiedades que hacen actualizables,
éstas se envian a través de sentencias SQL.
Quizas no se me ocurre que las BDs debieran estar afectadas por el
lenguaje en que son presentadas las aplicaciones, ya que son y/o deberían
ser independiente, pero si tus necesidades especifican esto, pues adelante.

Siempre he promovido el que las vistas remotas deberían ser estáticas, o
por lo menos poco dinámicas, ya que si necesitas cambiarlas frecuentemente
entonces podrías utilizar otros métodos como son las sentencias SQL, y de
ser posible hacer dichas cursores resultantes en actualizables (cosa que
no es posible si no fueren los producidos por SPT).

Por qué no recomiendo hacer "dinámicas" las vistas? , debido a que se cae
en algo llamado DBC Bloat, es decir, empiezas a llenar y borrar las BDs al
mismo ritmo (o quizás menor) que una tablaX, esto lleva consigo el que
pudieras terminar con DBCs enormes y lentos como un elefante, esto,
obviamente después de un tiempo, por lo que ahora tambien necesitas
rutinas de mantenimiento tambien de DBCs.

En resumen, a cada quien le toca vivir su propio calvario, esas son mis
recomendaciones, obviamente no estoy en contra de la dinamicidad, como
dirían por ahí: "Nada con exceso, todo con medida".



Hola Esparta, discrepo contigo respecto al uso que deberían tener las
vistas. Si bien es cierto que las vistas se crean para que funcionen en
determinadas situaciones(llámense X o Y), no es menos cierto que una vista
no es más que una consulta SQL. Mis mejores razones para seguir usando VFP
son la potencia de su lenguaje para implementar vistas y manejar su base de
datos. El uso de vistas "dinámicas" en una aplicación resulta enormemente
ventajoso. Un caso de ejemplo: se tiene una aplicación que es capaz de leer
la información en varios idiomas, hay una tabla para cada idioma con la
misma estructura en todas ellas, sin embargo, en el código de las formas,
reportes etc. hago referencia a una vista llamada miVista, esta vista es
creada dinámicamente en función del idioma elegido, algo que se puede hacer
durante la ejecución del programa sin necesidad de cerrar la aplicación y
volver ejecutar. Creo que así simplifico mucho el código necesario. ¿Qué te
parece este comentario?.

Saludos.

Víctor Brasó
Desarrollador independiente



"Esparta Palma" escribió en el
mensaje news:%
Veamos, creo que o no entendí bien o algo no está claro.

>Las vistas las creo para no trabajar directamente con las tablas,

Perfecto, esa si es parte de la idea.

>y las creo al inicio de la aplicación, creo que lo que me falta incluir


un
proceso para
>checar si existen las vistas y crearlas si no.

Eso está bien, a medias, si sería bueno tener una rutina para revisar que
estuvieren, pero de ninguna manera es bueno crearlas cáda que inicias la
aplicación, se supone que las vistas las has diseñado para que sean útiles
en X o Y situación, utilizarlas en Formularios, Reportes o Procesos
específicos. Y no necesitará cambiarse dentro del ciclo de vida de la
aplicación, sino hasta que se presente alguna modificación, es más, las
BDs (.DBC y archivos asociados) podrían marcarse como sólo lectura, ya
que una vez diseñada, no necesitará cambios, a menos de que se
especifiquen.

Así pues, está bien revisars, pero, por qué razón no estaría dicha
vista(s)? Si nadie las borra.


>Leopoldo Sánchez
>Monterrey, México



"Esparta Palma" escribió en el
mensaje news:
| Estás creando las vistas cada que se ejecuta algo??
| No es una de las prácticas más recomendadas, de hecho *no* se debería
| hacer, las vistas están pensadas para crearse una vez y usarse el tiempo
y
| lugares que sea necesario. El que se tenga un comando para crearlas por
| código es para que se pueda recrear cuando no se tenga.
| Ahora bien, mejor explícanos por o para que las estás creando, es decir,
| cual es el objetivo de esto?
|
|
|
| >Buenos días, alguien podría ayudarme con un detalle, genero vistas
locales
| >al inicio de mi aplicación por código, pero cuando corro la aplicación
desde
| >el exe, me pregunta si quiero re escribir las vistas, como puedo quitar
esa
| >pregunta, se puede usar el readwrite como con los cursores?
|
| >Este es parte del código que uso:
|
| >*************************************************
| >* CREA LA VISTA LOCAL DE SOCIOS *
|

***************************************************************************


*******
| >WAIT WINDOW "Identificando Socios Activos" TIMEOUT 1.5
| >CREATE SQL VIEW vsocios_activos AS ;
| >SELECT * ;
| >FROM ;
| > DBC!socios ;
| >WHERE cstatus == 'ACTIVO';
| >ORDER BY nid_socios
|
| >ÛSETPROP("vsocios_activos","VIEW","TABLES","DBC!socios")
| >ÛSETPROP("vsocios_activos.nid_socios","Field","KeyField",.T.)
| >ÛSetProp("vsocios_activos","View","UpdateType",1)
|

ÛSETPROP("vsocios_activos.nid_socios","Field","UpdateName","socios.nid_so


cios")
| >ÛSETPROP("vsocios_activos.nid_socios","Field","Updatable",.F.)
|

ÛSETPROP("vsocios_activos.ctitulo","Field","UpdateName","socios.ctitulo")
| >ÛSETPROP("vsocios_activos.ctitulo","Field","Updatable",.T.)
|
| >--
| >Leopoldo Sánchez
| >Monterrey, México



ž,ø€º°`°º€ø,žž,ø€º°`°º€ø,žž,ø€º°`°º€ø,žž,ø€º°`°º
Espartaco Palma Martínez
SysOp PortalFox.com
Acapulco, México
email:mexicoSINSPAM[Arroba]portalfox.com


PortalFox :: Nada corre como un zorro
http://www.portalfox.com

PortalFox - NNTP Forum Gateway
Respuesta Responder a este mensaje
#7 Victor B.
16/11/2004 - 19:05 | Informe spam
Ok. Esparta, tus argumentos son convincentes, al menos en lo que respecta al
DBC Bloat. Aunque el mantenimiento al que haces referencia se resuma a una
sencilla instrucción Pack. En cualquier caso, como tú bien dices, cada uno
en su experiencia asume su propio calvario, es por ello que me gusta beber
de otras fuentes.
En ocasiones me dejo llevar y hago de abogado del diablo. A ver si encuentro
argumentos y respuestas a temas que aun considerando resueltos, me confirmen
más si cabe mis sospechas. En este caso concreto y, bajo determinadas
situaciones, considero que la proporción del coste sobre los beneficios que
se obtienen es claramente a favor de estos últimos.
Si me lo permites.

Saludos.


Víctor Brasó
Desarrollador independiente

"Esparta Palma" escribió en el
mensaje news:eSq$Dy$
Las vistas son consultas SQL con propiedades que hacen actualizables,
éstas se envian a través de sentencias SQL.
Quizas no se me ocurre que las BDs debieran estar afectadas por el
lenguaje en que son presentadas las aplicaciones, ya que son y/o deberían
ser independiente, pero si tus necesidades especifican esto, pues


adelante.

Siempre he promovido el que las vistas remotas deberían ser estáticas, o
por lo menos poco dinámicas, ya que si necesitas cambiarlas frecuentemente
entonces podrías utilizar otros métodos como son las sentencias SQL, y de
ser posible hacer dichas cursores resultantes en actualizables (cosa que
no es posible si no fueren los producidos por SPT).

Por qué no recomiendo hacer "dinámicas" las vistas? , debido a que se cae
en algo llamado DBC Bloat, es decir, empiezas a llenar y borrar las BDs al
mismo ritmo (o quizás menor) que una tablaX, esto lleva consigo el que
pudieras terminar con DBCs enormes y lentos como un elefante, esto,
obviamente después de un tiempo, por lo que ahora tambien necesitas
rutinas de mantenimiento tambien de DBCs.

En resumen, a cada quien le toca vivir su propio calvario, esas son mis
recomendaciones, obviamente no estoy en contra de la dinamicidad, como
dirían por ahí: "Nada con exceso, todo con medida".



>Hola Esparta, discrepo contigo respecto al uso que deberían tener las
>vistas. Si bien es cierto que las vistas se crean para que funcionen en
>determinadas situaciones(llámense X o Y), no es menos cierto que una


vista
>no es más que una consulta SQL. Mis mejores razones para seguir usando


VFP
>son la potencia de su lenguaje para implementar vistas y manejar su base


de
>datos. El uso de vistas "dinámicas" en una aplicación resulta enormemente
>ventajoso. Un caso de ejemplo: se tiene una aplicación que es capaz de


leer
>la información en varios idiomas, hay una tabla para cada idioma con la
>misma estructura en todas ellas, sin embargo, en el código de las formas,
>reportes etc. hago referencia a una vista llamada miVista, esta vista es
>creada dinámicamente en función del idioma elegido, algo que se puede


hacer
>durante la ejecución del programa sin necesidad de cerrar la aplicación y
>volver ejecutar. Creo que así simplifico mucho el código necesario. ¿Qué


te
>parece este comentario?.

>Saludos.

>Víctor Brasó
>Desarrollador independiente

"Esparta Palma" escribió en el
mensaje news:%
> Veamos, creo que o no entendí bien o algo no está claro.
>
> >Las vistas las creo para no trabajar directamente con las tablas,
>
> Perfecto, esa si es parte de la idea.
>
> >y las creo al inicio de la aplicación, creo que lo que me falta


incluir
un
> proceso para
> >checar si existen las vistas y crearlas si no.
>
> Eso está bien, a medias, si sería bueno tener una rutina para revisar


que
> estuvieren, pero de ninguna manera es bueno crearlas cáda que inicias la
> aplicación, se supone que las vistas las has diseñado para que sean


útiles
> en X o Y situación, utilizarlas en Formularios, Reportes o Procesos
> específicos. Y no necesitará cambiarse dentro del ciclo de vida de la
> aplicación, sino hasta que se presente alguna modificación, es más, las
> BDs (.DBC y archivos asociados) podrían marcarse como sólo lectura, ya
> que una vez diseñada, no necesitará cambios, a menos de que se
> especifiquen.
>
> Así pues, está bien revisars, pero, por qué razón no estaría dicha
> vista(s)? Si nadie las borra.
>
>
> >Leopoldo Sánchez
> >Monterrey, México
>
>
>
> "Esparta Palma" escribió en el
> mensaje news:
> | Estás creando las vistas cada que se ejecuta algo??
> | No es una de las prácticas más recomendadas, de hecho *no* se debería
> | hacer, las vistas están pensadas para crearse una vez y usarse el


tiempo
> y
> | lugares que sea necesario. El que se tenga un comando para crearlas


por
> | código es para que se pueda recrear cuando no se tenga.
> | Ahora bien, mejor explícanos por o para que las estás creando, es


decir,
> | cual es el objetivo de esto?
> |
> |
> |
> | >Buenos días, alguien podría ayudarme con un detalle, genero vistas
> locales
> | >al inicio de mi aplicación por código, pero cuando corro la


aplicación
> desde
> | >el exe, me pregunta si quiero re escribir las vistas, como puedo


quitar
> esa
> | >pregunta, se puede usar el readwrite como con los cursores?
> |
> | >Este es parte del código que uso:
> |
> | >*************************************************
> | >* CREA LA VISTA LOCAL DE SOCIOS *
> |
>

***************************************************************************
*******
> | >WAIT WINDOW "Identificando Socios Activos" TIMEOUT 1.5
> | >CREATE SQL VIEW vsocios_activos AS ;
> | >SELECT * ;
> | >FROM ;
> | > DBC!socios ;
> | >WHERE cstatus == 'ACTIVO';
> | >ORDER BY nid_socios
> |
> | >ÛSETPROP("vsocios_activos","VIEW","TABLES","DBC!socios")
> | >ÛSETPROP("vsocios_activos.nid_socios","Field","KeyField",.T.)
> | >ÛSetProp("vsocios_activos","View","UpdateType",1)
> |
>

ÛSETPROP("vsocios_activos.nid_socios","Field","UpdateName","socios.nid_so
cios")
> | >ÛSETPROP("vsocios_activos.nid_socios","Field","Updatable",.F.)
> |
>

ÛSETPROP("vsocios_activos.ctitulo","Field","UpdateName","socios.ctitulo")
> | >ÛSETPROP("vsocios_activos.ctitulo","Field","Updatable",.T.)
> |
> | >--
> | >Leopoldo Sánchez
> | >Monterrey, México

¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø,¸¸,ø¤º°`°º
Espartaco Palma Martínez
SysOp PortalFox.com
Acapulco, México
email:mexicoSINSPAM[Arroba]portalfox.com


PortalFox :: Nada corre como un zorro
http://www.portalfox.com

PortalFox - NNTP Forum Gateway
Respuesta Responder a este mensaje
#8 Esparta Palma
16/11/2004 - 19:37 | Informe spam
Lo que no me queda claro es por qué el lenguaje de la capa de presentación
deba afectar a la capa de base de datos, se está cayendo en otro problema
clásico de programación, éste es llamado "Coupling" (si mal no recuerdo),
es decir, estás llevando de la mano y haciendo cáda vez más monolítica tu
aplicación, misma que a la hora de un cambio de cualquier tipo, llámese
lenguaje de programación, plataforma de soporte, sistema operativo,
tendrá problemas exponenciales.

También en lo personal, considero que al momento de por ejemplo, hacer un
upsizing, la práctica (que aunque funciona en BDCs de VFP) ya no podrá
llevarse a cabo con el mismo enfoque, lo que contribuye a la reescritura
de todos tus procedimientos.


Ok. Esparta, tus argumentos son convincentes, al menos en lo que respecta al
DBC Bloat. Aunque el mantenimiento al que haces referencia se resuma a una
sencilla instrucción Pack. En cualquier caso, como tú bien dices, cada uno
en su experiencia asume su propio calvario, es por ello que me gusta beber
de otras fuentes.
En ocasiones me dejo llevar y hago de abogado del diablo. A ver si encuentro
argumentos y respuestas a temas que aun considerando resueltos, me confirmen
más si cabe mis sospechas. En este caso concreto y, bajo determinadas
situaciones, considero que la proporción del coste sobre los beneficios que
se obtienen es claramente a favor de estos últimos.
Si me lo permites.

Saludos.

Víctor Brasó
Desarrollador independiente



"Esparta Palma" escribió en el
mensaje news:eSq$Dy$
Las vistas son consultas SQL con propiedades que hacen actualizables,
éstas se envian a través de sentencias SQL.
Quizas no se me ocurre que las BDs debieran estar afectadas por el
lenguaje en que son presentadas las aplicaciones, ya que son y/o deberían
ser independiente, pero si tus necesidades especifican esto, pues


adelante.

Siempre he promovido el que las vistas remotas deberían ser estáticas, o
por lo menos poco dinámicas, ya que si necesitas cambiarlas frecuentemente
entonces podrías utilizar otros métodos como son las sentencias SQL, y de
ser posible hacer dichas cursores resultantes en actualizables (cosa que
no es posible si no fueren los producidos por SPT).

Por qué no recomiendo hacer "dinámicas" las vistas? , debido a que se cae
en algo llamado DBC Bloat, es decir, empiezas a llenar y borrar las BDs al
mismo ritmo (o quizás menor) que una tablaX, esto lleva consigo el que
pudieras terminar con DBCs enormes y lentos como un elefante, esto,
obviamente después de un tiempo, por lo que ahora tambien necesitas
rutinas de mantenimiento tambien de DBCs.

En resumen, a cada quien le toca vivir su propio calvario, esas son mis
recomendaciones, obviamente no estoy en contra de la dinamicidad, como
dirían por ahí: "Nada con exceso, todo con medida".



>Hola Esparta, discrepo contigo respecto al uso que deberían tener las
>vistas. Si bien es cierto que las vistas se crean para que funcionen en
>determinadas situaciones(llámense X o Y), no es menos cierto que una


vista
>no es más que una consulta SQL. Mis mejores razones para seguir usando


VFP
>son la potencia de su lenguaje para implementar vistas y manejar su base


de
>datos. El uso de vistas "dinámicas" en una aplicación resulta enormemente
>ventajoso. Un caso de ejemplo: se tiene una aplicación que es capaz de


leer
>la información en varios idiomas, hay una tabla para cada idioma con la
>misma estructura en todas ellas, sin embargo, en el código de las formas,
>reportes etc. hago referencia a una vista llamada miVista, esta vista es
>creada dinámicamente en función del idioma elegido, algo que se puede


hacer
>durante la ejecución del programa sin necesidad de cerrar la aplicación y
>volver ejecutar. Creo que así simplifico mucho el código necesario. ¿Qué


te
>parece este comentario?.

>Saludos.

>Víctor Brasó
>Desarrollador independiente

"Esparta Palma" escribió en el
mensaje news:%
> Veamos, creo que o no entendí bien o algo no está claro.
>
> >Las vistas las creo para no trabajar directamente con las tablas,
>
> Perfecto, esa si es parte de la idea.
>
> >y las creo al inicio de la aplicación, creo que lo que me falta


incluir
un
> proceso para
> >checar si existen las vistas y crearlas si no.
>
> Eso está bien, a medias, si sería bueno tener una rutina para revisar


que
> estuvieren, pero de ninguna manera es bueno crearlas cáda que inicias la
> aplicación, se supone que las vistas las has diseñado para que sean


útiles
> en X o Y situación, utilizarlas en Formularios, Reportes o Procesos
> específicos. Y no necesitará cambiarse dentro del ciclo de vida de la
> aplicación, sino hasta que se presente alguna modificación, es más, las
> BDs (.DBC y archivos asociados) podrían marcarse como sólo lectura, ya
> que una vez diseñada, no necesitará cambios, a menos de que se
> especifiquen.
>
> Así pues, está bien revisars, pero, por qué razón no estaría dicha
> vista(s)? Si nadie las borra.
>
>
> >Leopoldo Sánchez
> >Monterrey, México
>
>
>
> "Esparta Palma" escribió en el
> mensaje news:
> | Estás creando las vistas cada que se ejecuta algo??
> | No es una de las prácticas más recomendadas, de hecho *no* se debería
> | hacer, las vistas están pensadas para crearse una vez y usarse el


tiempo
> y
> | lugares que sea necesario. El que se tenga un comando para crearlas


por
> | código es para que se pueda recrear cuando no se tenga.
> | Ahora bien, mejor explícanos por o para que las estás creando, es


decir,
> | cual es el objetivo de esto?
> |
> |
> |
> | >Buenos días, alguien podría ayudarme con un detalle, genero vistas
> locales
> | >al inicio de mi aplicación por código, pero cuando corro la


aplicación
> desde
> | >el exe, me pregunta si quiero re escribir las vistas, como puedo


quitar
> esa
> | >pregunta, se puede usar el readwrite como con los cursores?
> |
> | >Este es parte del código que uso:
> |
> | >*************************************************
> | >* CREA LA VISTA LOCAL DE SOCIOS *
> |
>

***************************************************************************
*******
> | >WAIT WINDOW "Identificando Socios Activos" TIMEOUT 1.5
> | >CREATE SQL VIEW vsocios_activos AS ;
> | >SELECT * ;
> | >FROM ;
> | > DBC!socios ;
> | >WHERE cstatus == 'ACTIVO';
> | >ORDER BY nid_socios
> |
> | >ÛSETPROP("vsocios_activos","VIEW","TABLES","DBC!socios")
> | >ÛSETPROP("vsocios_activos.nid_socios","Field","KeyField",.T.)
> | >ÛSetProp("vsocios_activos","View","UpdateType",1)
> |
>

ÛSETPROP("vsocios_activos.nid_socios","Field","UpdateName","socios.nid_so
cios")
> | >ÛSETPROP("vsocios_activos.nid_socios","Field","Updatable",.F.)
> |
>

ÛSETPROP("vsocios_activos.ctitulo","Field","UpdateName","socios.ctitulo")
> | >ÛSETPROP("vsocios_activos.ctitulo","Field","Updatable",.T.)
> |
> | >--
> | >Leopoldo Sánchez
> | >Monterrey, México



ž,ø€º°`°º€ø,žž,ø€º°`°º€ø,žž,ø€º°`°º€ø,žž,ø€º°`°º
Espartaco Palma Martínez
SysOp PortalFox.com
Acapulco, México
email:mexicoSINSPAM[Arroba]portalfox.com


PortalFox :: Nada corre como un zorro
http://www.portalfox.com

PortalFox - NNTP Forum Gateway
email Siga el debate Respuesta Responder a este mensaje
Ads by Google
Help Hacer una pregunta AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida