gx-l |
| Luis Cabrera56858 | |
Buenas tardes, Tengo un problema con la herramienta de ingeniería Inversa, estoy en GX 16 java y MSSQL. En una BD externa tengo una tabla "Agenda" la cual le apliqué ingeniería inversa, eso me creó correctamente un DataView "Agenda" y una trn del mismo nombre con una tabla asociada.también llamada "Agenda", la cual queda generada y cargada con los datos en mi BD de la KB. Asimismo, para darle usabilidad le generé un índice que lo crea local a mi BD GX. Sólo lo uso para consultas. Todo funciona muy bien, hasta que se levanta un respaldo de la BD externa. Ahí ya me quedan los datos desactualizados de la tabla en mi KB. ¿Qué debería hacer para siempre tener los datos actualizados? -- Saludos, Luis Cabrera ----------------------------------------- Para Suscribirse/Desuscribirse: http://www.gxtechnical.com/cgi-bin/hforum.exe?2,3,30,1 Por consultas owner-gx-l@gxtech.com.uy |
|
|
| | |
leandro79337933 | |
Hola Luis, creo que hay una confusión en alguna parte. El objeto DataView
es el que te permite vincular una tabla externa a una TRN de tu KB para que
puedas accederla. Aqui esta bien explicado:
https://wiki.genexus.com/commwiki/servlet/wiki?1914,Category%3AData+View+object
,
De esta manera, con GX podemos acceder a tablas de otros sistemas. Estas
tablas no son administradas por GX, o sea, no podes agregarles índices, ni
campos, ni nada. Lógico, ya que no son tablas propias.
Cuando creas una TRN, GX crea una tabla en tu base de datos. El tema es que
esta tabla que queres acceder es de otro sistema y está en otra base de
datos. Ahí es donde entra a jugar el objeto DataView. El DataView le indica
a GX que en realidad esa tabla no es propia sino que es de otro sistema. En
el DataView definis el mapeo de la composición y los índices de la tabla
tuya y la externa, y definis la plataforma, o sea los datos de conexión
para que GX pueda accederla.
Todo esto hace mucho se hacia a mano. Creabas la TRN, el DataView y
asociabas la tabla. Desde hace algún tiempo existe la herramienta "Database
Reverse Engineering" que nos ahorra mucho tiempo. Pero la idea sigue siendo
la misma.
Mi confusión viene por 2 puntos tuyos:
*"Asimismo, para darle usabilidad le generé un índice que lo crea local a
mi BD GX."*
Creaste un índice con GX? o creaste un índice en la tabla externa? Por
ultimo, no es necesario crear indices para darle usabilidad.
*"Todo funciona muy bien, hasta que se levanta un respaldo de la BD
externa.*
*Ahí ya me quedan los datos desactualizados de la tabla en mi KB."*
Aquí me perdí del todo. Se supone que GX tiene los datos de conexión a la
base de datos externa en el DataView. Si se restaura la base de datos, GX
se conecta y lee lo que hay en la tabla.
Slds
On Sat, Apr 10, 2021 at 6:32 PM Luis Cabrera |
|
|
Luis Cabrera56858 | |
Leandro, mil gracias por responder, porque yo estoy muy confundido. Lo que
tú explicas es lo que yo quería hacer en primer término.
Pero cuando le apliqué "Database Reverse Engineering" a esa tabla
externa, me creó una tabla igual en mi BD, la pobló de datos... y ahí me
perdí.
Lo de "usabilidad" lo puse porque cuando yo intentaba acceder al DataView
para rellenar un grid, lo hacía con xFor Each... y eran miles de
registros... y ahí fue que veo que me fui a la bartola porque le creé un
índice con GX definiéndolo en la TRN (que lo hizo en la tabla de mi BD)
¿Es parte de lo que hace "Database Reverse Engineering" crear una tabla
idéntica en la BD GX y rellenarla con los datos, o fue algún parámetro que
usé y no debería haberlo hecho?
y ¿Cómo acceder a los datos provistos por el DAtaView pero en forma
optimizada para aplicarle filtros (cliente, entre fechas, etc.) a los
efectos de rellenar un grid?
Quizás si mejor explico qué quise hacer, aclaro más mi problema. Preciso
leer una tabla de una BD externa, y presentarla en un grid luego de aplicar
cinco o seis filtros. Nada más que eso...
El sáb, 10 abr 2021 a las 20:20, Leandro Minatel () |
|
|
leandro79337933 | |
Hola Luis, no te preocupes, el tema DataView presta a confusión. El
conjunto de comandos "Xfor each"/"Xfor first"/"Xnew" formaron parte del
primer intento de poder acceder a tablas de otros sistemas. No existía el
objeto DataView, así que tenias que definir todo en las Rules del objeto,
creo que era con XIndex y no recuerdo la otra regla para la estructura,
quizás algún memorioso se acuerde. Estamos hablando de GeneXus para DOS!
Esto tenía varios inconvenientes: el primero era que tenias que copiar y
pegar las definiciones en cada objeto GX donde necesitabas acceder a la
tabla. El otro era que, si cambiaba la definición (estructura/índices) de
la tabla externa, tenias que ir a buscar todos los objetos donde estaban
esas definiciones para modificarlas. Para subsanar esto, implementaron el
FileView, el predecesor del DataView. Se llamaba distinto pero ahí nació la
idea que explique en el mail anterior. Tener un objeto GX donde
pudiésemos definir la estructura, índices y datos de conexión a la tabla
externa para ser reutilizados en diferentes objetos. En versiones
posteriores se renombró a DataView.
Ahora bien, para no perder la compatibilidad hacia atrás, los comandos "X"
continuaron trabajando de la misma manera, y le agregaron la opción de que
en lugar de definir estructuras e índices en las Rules de cada objeto, a
partir de esa version de GX que trajo los File Views, puedas usar esas
definiciones.
La clave aquí es ver si el DataView tiene o no tabla asociada. Por ejemplo,
estas son las propiedades de un DataView mio:
[image: image.png]
En mi KB, tengo una TRN que se llama *TRN_wsEntidades *que tiene una tabla
(dentro de GX) que se llama *wsEntidades*. Al estar asociada en el
DataView, GX entiende que no es propia, (no creo esa tabla dentro de mi
base de datos SQL). Cuando GX tenga que acceder a esa tabla, va a ir a
buscar los datos de conexión al Datastore "WSPENT (SQL Server)", datos como
el tipo de motor (sql, mysql, oracle, etc.), direccion del server, nombre
de la base de datos, usuario y password entre otros. Y a qué tabla va a
buscar los datos? A la que tenga definida en el Datastore del DataView:
[image: image.png]
En mi caso, la tabla del sistema externo se llama "*Entidades*". Entonces
GX va a hacer un SELECT * FROM dbo.Entidades en el servidor y base de datos
indicados en el DataStore de la KB.
Ahora bien, el DataView puede trabajar de 2 maneras: *Sin tabla asociada*,
en este caso deberás acceder a la misma con los comandos "X". *Con tabla
asociada*, entonces podes usar todas las herramientas de GX tal como si
fuese una tabla tuya.
Si me preguntas a mi, yo te recomiendo crear la TRN, el DataView,
asociar la tabla y utilizarla como si fuese tuya. Ya sea utilizando la
"Database Reverse Engineering Tool" o a mano.
Respecto de tus preguntas:
*¿Es parte de lo que hace "Database Reverse Engineering" crear una tabla
idéntica en la BD GX y rellenarla con los datos, o fue algún parámetro que
usé y no debería haberlo hecho?*
No, bah, creo que no, casi con seguridad, hace bastante que no la uso pero
"no debería" hacer eso. Esta tool solo debería crear la TRN, el DV y
asociar la tabla en cuestión. Obvio, hay parametros pero para modificar ese
comportamiento, pero no para copiar datos de una tabla externa a una tuya,
que yo sepa...
*¿Cómo acceder a los datos provistos por el DAtaView pero en forma
optimizada para aplicarle filtros (cliente, entre fechas, etc.) a los
efectos de rellenar un grid?*
Como te comentaba, la tabla externa no la administra GX. Crear un indice en
GX sobre un DataView en realidad no hace nada físico, solo le dice a GX que
el índice existe y si hay un objeto accediendo por esa clave entonces no te
muestra el Warning de "poor performance...". Pero si el índice no está
creado físicamente en la tabla, entonces la performance se verá afectada.
Slds
On Sat, Apr 10, 2021 at 9:38 PM Luis Cabrera |
|
|
|
|
Back to gx-l |
|