Preparacin para examen de Instructor GeneXus Consideraciones generales

Necesariamente quien se presenta a esta instancia ha aprobado en una instancia anterior la certificacin de Analista Senior, por lo que ya se lo ha evaluado tcnicamente y ha probado tener incorporada la lgica de la herramienta para poder resolver adecuadamente problemas con GeneXus.

Qu es lo ms importante cuando enseamos GeneXus?

GeneXus tiene una lgica inteligente, que le permite sobreentendidos con el programador y tomar acciones en base al contexto que es capaz de interpretar, sin tener que explicitarlo todo el tiempo. Toda aplicacin se desarrolla para una realidad. Toda aplicacin cuenta, por tanto, con aspectos que son conceptuales, inherentes a la realidad, y aspectos que son concretos, de bajo nivel, propios de la implementacin material de la misma. En otras herramientas ambos aspectos estn entremezclados, y resultan indiscernibles. En GeneXus no. Ensear GeneXus es bsicamente lograr transmitir ese lenguaje conceptual, lograr transmitir su manera de pensar, sus reglas de inferencia, sus suposiciones. La implementacin material corre por su cuenta. Esto es lo fundamental (transmitir el lenguaje conceptual), mucho ms importante que ensear exactamente qu valor debe tener una propiedad o si hay que poner punto y coma para finalizar una regla. Logrando que el alumno interiorice la lgica de la herramienta (no necesariamente en forma consciente) habremos logrado que ingrese al mundo GeneXus, armado de las herramientas necesarias para, a partir de all, moverse solo.

Qu evaluamos en un instructor?
Por lo dicho antes, debemos concentrarnos en evaluar si el postulante es capaz de transmitir la lgica de la herramienta a un supuesto alumno. No debemos confundir la enunciacin del conocimiento terico, con la transmisin de qu significa eso que se enuncia. Lo importante es esto ltimo. Ejemplo: decirle a un alumno la tabla base de un for each es la mnima tabla extendida que contiene a todos los atributos mencionados no significa precisamente ensearle GeneXus; es bien posible que el alumno no tenga la menor idea de qu significa eso que le acabamos de decir,

por ms que sea capaz de repetirlo en cualquier examen. Es mucho ms importante que el instructor pueda explicarle: tens un for each, eso significa que vas a buscar informacin repetitiva, por ejemplo, los clientes de tu sistema. Y all adentro del for each, focalizs en la info de cada uno de ellos que te interesa (su nombre, telfono, pas, etc.). Que esa info est en la misma tabla, o est en varias (en una extendida) es accesorio, porque en realidad el for each captura el concepto recorrer informacin homognea (repetitiva) de esta realidad que estoy modelando. La informacin conceptual (lo relativo al cliente) est desperdigada en varias tablas, slo a los efectos de la normalizacin, pero tenemos una forma de abstraerla en GeneXus, que es trabajar con el concepto de tabla extendida. Por eso el concepto de tabla extendida no es un concepto menor. Es fundamental, pues es el que permite mantener el nivel conceptual, es decir, mantenernos ms cerca de la manera en que pensamos nuestras realidades, y ms lejos de los detalles (enmaraados) de la implementacin. Con este ejemplo, pretendemos mostrar que lo importante es lograr integrar los temas que se van enseando en el curso, encarndolos desde el punto de vista conceptual, que es lo mismo que decir: desde un punto de vista mucho ms cercano a la forma en que pensamos, y mucho ms lejano a la forma en que terminan implementados los sistemas. El examen oral, por tanto, deber concentrarse en evaluar si el postulante tiene estrategias para lograr la transmisin efectiva de esta lgica a un alumno, y la capacidad discursiva y comunicativa en general, para llevarlas a cabo. Debe poder:
Jerarquizar:

abstrayendo lo importante y desechando lo secundario o dejndolo para una segunda aproximacin al tema. Por ejemplo, al exponer el tema web panel, no podemos dar todo a la vez. Hay aspectos que debemos posponer para ms adelante, cuando ya se han afianzado los conocimientos ms gruesos. No tenemos por qu dar, a la vez que estamos explicando un grid con atributos, todos los eventos que ocurren en un get o post, sumado a todas las variaciones que pueden presentarse. Hay que seleccionar lo importante, concentrarse en eso y luego pasar a profundizar, en etapas sucesivas. Ser evaluada la capacidad del postulante de jerarquizar lo que le ensear a sus alumnos en cada oportunidad. una pregunta o duda del alumno, lograr identificar el problema, qu es lo no est entendiendo o est entendiendo errneamente, para poder enfocar la respuesta a la clarificacin de eso (y no de otra cosa). Muchas veces los alumnos en su confusin, no logran expresar con claridad su problema y hay que poder identificarlo de lo poco o mucho que expresen. enftico en todas las cuestiones que hacen a la inteligencia de GeneXus, incluso cuando a nivel prctico no sean tan importantes. Por ejemplo, si para implementar un caso de join en for eachs anidados el alumno utiliza una variable para hacerlo explcitamente, si bien no tiene repercusiones en la prctica, s las tiene en su asimilacin de la forma de pensar de GeneXus. Es un ejemplo bien sintomtico de que

Ante

Ser

no est entendiendo o no est confiando en el poder de inferir de GeneXus en base al contexto. Es importantsimo no dejar pasar este hecho, aunque pragmticamente parezca un asunto menor.
Ser

claro con el uso terminolgico; cuando se lo utiliza hacerlo con toda precisin. Es preferible no utilizar trminos tcnicos si se los va a emplear ambiguamente. un discurso claro, correctamente elaborado, del que se pueda entender de dnde se parte y hacia dnde se va.

Tener

Algunos ejemplos para la preparacin

A continuacin aparecen algunas preguntas, similares a las que se pueden encontrar en algunos exmenes de Analista Senior (stas pueden resultar un poco ms complejas), con una discusin de las respuestas. Es un buen ejercicio para prepararse para el examen de instructor, imaginar que un alumno intent contestarlas y viene con dudas acerca de cada una, que el instructor debe intentar aclararle. Las respuestas intentan esa aclaracin. Las preguntas fueron hechas pensando en una nica opcin correcta. En algunos casos podrn existir varias opciones que producen el resultado deseado, pero siempre habr una que ser la ms completa, mejor programada, ms eficiente, etc.

1. Se tiene una aplicacin GeneXus para un casino. La misma cuenta con transacciones para registrar los slots (mquinas de juegos) as como los tcnicos encargados de repararlos. Sabiendo que un slot (Slot) puede ser reparado por varios tcnicos (Technician), y que un mismo tcnico puede reparar varios slots, determine la opcin correcta para el diseo de estas transacciones. a)
Slot { SlotId* SlotDescription Technician { TechnicianId* TechnicianName } }

b)
Slot { SlotId* SlotDescription Technician { TechnicianId* TechnicianName } } Technician { TechnicianId* TechnicianName }

c)
Slot { SlotId* SlotDescription } Technician { TechnicianId* SlotId* TechnicianName }

d)
Slot { SlotId* SlotDescription TechnicianId* TechnicianName } Technician { TechnicianId* TechnicianName SlotId* SlotDescription }

e) Ninguna de las anteriores

Respuesta: b) Obsrvese que las soluciones a) y c) son equivalentes y representan una relacin entre las entidades de la realidad Slot y Technician diferente, una relacin 1-N, donde Technician no existira por s slo, de forma independiente de los Slots (es decir, Technician sera una entidad dbil, que para existir depende de la existencia del Slot al cual est relacionado). Esto se deduce del hecho de que no exista una transaccin con identificador TechnicianId solo.

Puede pensarse de otro modo: cmo se ingresara al sistema, en estas alternativas a) y c), un tcnico sin asociarlo inmediatamente a un slot? Recordemos que es imposible dejar una clave primaria sin valor (porque en ese caso cmo identificaramos el registro?). SlotId es parte de la clave primaria de la tabla que registra los tcnicos. Sera imposible por tanto ingresar un tcnico sin dar valor al slot al que est asociado. Si esto es as, si no es posible ingresar un tcnico sin asociarlo a un slot, cmo haramos para que ese tcnico est asociado adems a otros slots? Por ejemplo, ingresamos al tcnico David Roberts, en el grid del slot 3 The Super Wizard. Cmo le asociaramos a ese tcnico otro slot, si el tcnico para existir depende del slot 3? El problema es que con estos diseos (a y c) no estamos modelando una relacin N a N. Por otro lado, la solucin d) no puede ser, porque aqu los slots y los tcnicos slo existen vinculados. Ninguno existe independientemente del otro. Son la misma entidad (GeneXus crear una nica tabla para las transacciones Slot y Technician. Por qu?)

2. Se tiene una aplicacin GeneXus para un casino. La misma cuenta con transacciones para registrar los slots as como los tipos de slot existentes. Sabiendo que cada slot (Slot) corresponde a un tipo determinado (Type) y slo uno, y que pueden haber muchos slots del mismo tipo, determine la opcin correcta para el diseo de estas transacciones.

a)

Type { TypeId* TypeDescription Slot { SlotId* SlotDescription } }

b)

Type { TypeId* TypeDescription Slot { SlotId* SlotDescription } }

Slot { SlotId* SlotDescription }

c)

Type { TypeId* TypeDescription }

Slot { SlotId* SlotDescription TypeId TypeDescription }

d)

Type { TypeId* TypeDescription SlotId SlotDescription }

Slot { SlotId* SlotDescription }

e) Ninguna de las anteriores

Respuesta: c) pues se pide implementar una relacin 1-N fuerte (este dato lo deducimos de nuestro conocimiento de la realidad, pues no se ha explicitado en la letra del ejercicio. Ver dos prrafos ms adelante qu significa). En esta representacin c), cada slot tendr un slo tipo, debido a que en la transaccin Slot el atributo TypeId aparece en el mismo nivel que el identificador SlotId. De esta manera, as como un slot dado identificado por SlotId tendr una nica descripcin SlotDescription, tambin tendr un nico TypeId. Por otro lado, nada impide que otro slot tenga el mismo TypeId que uno dado (pues el atributo no es clave en esta transaccin). Se cumple, pues, lo que se pide. La opcin a) no puede ser, debido a que si bien la relacin tambin es 1-N, sin embargo no es fuerte. Qu quiere esto decir? Si eligiramos la opcin a) estaramos diciendo que los Slots slo tienen existencia en la medida en que existe un tipo de slot del cual dependen. Para identificar un slot se necesitara indicar cul es su TypeId. No ser posible siquiera ingresar un Slot sin haber especificado previamente su TypeId. Dicho de otro modo, bajo esta representacin, deduciramos que la entidad del mundo real Slot, depende absolutamente para existir del tipo de Slot, lo que contradice la realidad que queremos modelar. En ella, el Tipo de Slot y el Slot son entidades relacionadas pero de existencia propia. Cada una se identifica ms all de la otra. Eventualmente incluso, si se admitieran nulos para TypeId en Slot (de solucin c), podran ingresarse slots sin ingresar su tipo.

La opcin b) claramente representa una relacin N-N (en este caso para cada tipo de slot, pueden ingresarse muchos slots asociados, y a la vez, cada slot, representado por la transaccin Slot, e identificado con el atributo SlotId, puede encontrarse repetido para muchos tipos de slot (el slot 1 lo podr mostrar en su grid, as como el slot 2, etc.). Esto claramente no corresponde con la realidad planteada. La opcin d) est representando una relacin 1-N pero opuesta a la que se pide. Obsrvese que aqu un tipo de slot tiene asociado un nico slot y otro tipo de slot podr tener asociado el mismo slot que el anterior. Por esta razn, aqu estamos diciendo que cada slot podr tener muchos tipos, y que a un tipo solo le corresponde un slot. Resumen de entidad fuerte vs dbil: una entidad es fuerte, cuando se puede identificar independientemente de las otras, aunque mantenga relacin con ellas. En cambio, ser dbil, cuando no existe con independencia de otra entidad. Para existir requiere de la existencia de la otra. El caso tpico es el de los telfonos de clientes. No tiene sentido tener un telfono independiente del cliente al que pertenece.

3. Se tiene una aplicacin GeneXus para un casino. Dados las siguientes transacciones determine la relacin entre los actores de la realidad Slot y SlotPrize (premio del slot).
Slot { SlotId* SlotDescription TechnicianId TechnicianName Prize { PrizeId* PrizeDescription } } Technician { TechnicianId* TechnicianName }

a) Relacin 1 a 1 (por cada slot hay un slo premio y por cada premio un slot que lo brinda) b) Relacin 1 a N (por cada slot hay varios premios, pero donde cada premio corresponde nicamente a ese slot y no a otro) siendo ambas entidades fuertes.

c)

Relacin 1 a N (por cada slot hay varios premios, pero donde cada premio corresponde nicamente a ese slot y no a otro) siendo la entidad Slot fuerte pero SlotPrize dbil. d) Relacin N a N (por cada slot hay muchos premios y cada premio puede ser brindado por muchos slots).

Respuesta: c) Qu significa decir que SlotPrize es una entidad dbil respecto a Slot? Que no existir como entidad independiente. Su relacin con Slot es de dependencia absoluta. Un premio determinado, slo existe en la medida en que se indica el Slot al que est asociado. Es el premio tal del slot tal. Nunca podr decirse es el premio tal, a secas. Siempre deber indicarse de qu slot se trata. Si en cambio la relacin fuera 1-N fuerte, el premio existira como entidad independiente, identificable por s misma, sin tener que indicar el slot para lograr saber de qu premio estamos hablando.

4. Se tiene una aplicacin GeneXus para un casino. La misma cuenta con transacciones para registrar los clientes as como las tarjetas VIP que se emiten para los mismos. Sabiendo que cada cliente (Customer) puede tener una nica tarjeta VIP (VIPCard) y que cada tarjeta VIP slo puede pertenecer a un cliente, determine la opcin correcta para el diseo de estas transacciones.

a)
Customer { CustomerId* CustomerName } VIPCard { VIPCardId* VIPCardObservations CustomerId CustomerName }

b)
Customer { CustomerId* CustomerName VIPCardId VIPCardObservations } VIPCard { VIPCardId* VIPCardObservations CustomerId CustomerName }

c)
Customer { CustomerId* CustomerName } VIPCard { VIPCardId* VIPCardObservations CustomerId CustomerName }

Unique Index

d)
Customer { CustomerId* CustomerName } VIPCard { VIPCardId* VIPCardObservations VIPCardCustomerId VIPCardCustomerName }

Subtype group: VIPCardCustomer VIPCardCustomerId subtype of VIPCardCustomerName subtype of

CustomerId CustomerName

e) Ninguna de las anteriores

Respuesta: c) Se nos pide una relacin 1 a 1 entre ambas entidades (que deben existir independientemente la una de la otra, es decir, necesariamente deben tener un identificador propio cada una; de lo contrario, alcanzara con colocar los atributos de tarjeta como secundarios en la transaccin Customer, teniendo una sola transaccin). Si no especificramos en la tabla base de la transaccin VIPCard un ndice unique para el atributo CustomerId, entonces nos quedara una relacin 1 a N entre clientes y tarjetas. Es decir, un mismo cliente podra tener varias tarjetas. Al ser CustomerId una clave fornea en VIPCARD a la tabla CUSTOMER, se podrn repetir sus valores para distintos registros. Sin embargo, al crear un ndice unique para ese atributo en esa tabla, estamos indicando que adems de clave fornea, se trata de una clave candidata, es decir, que sus valores no se pueden repetir. Con eso restringimos la relacin 1 a N, que pasa a ser 1 a 1. Yendo a lo ms fino, tambin obsrvese que pueden existir clientes sin tarjetas. Lo que no podr suceder es que una tarjeta no tenga especificado un cliente. Una buena pregunta a contestarse es cmo se hara para evitar esto, es decir, para que cada cliente tenga necesariamente una tarjeta (este tema se enlaza con el de UTL. Una

posibilidad sera escribir la siguiente regla en la transaccin Customer: CretateVIPCard.call( CustomerId ) on AfterInsert siendo CreateVIPCard un procedimiento que inserte un nuevo registro a travs del business component de VIPCard. Recurdese que en aplicaciones web no puede extenderse la UTL conformada por los registros manipulados por una instancia de iteracin de transaccin para abarcar tambin los registros manipulados por otra transaccin) La opcin a) claramente representa una relacin 1 a N por lo que no es vlida. La opcin b) convendra estudiarla con detenimiento. En un primer golpe de vista, mirando la transaccin Customer estamos diciendo que un cliente tiene una nica VIPCard y mirando independientemente la transaccin VIPCard decimos que una tarjeta tiene un nico Cliente. Habr quienes no sigan mirando y se conformen con este anlisis. Sin embargo, las transacciones operan en conjunto y no solas. Siguiendo un poco ms all con este anlisis, y mirando un poco el conjunto, podramos decir que entonces VIPCardId sera una clave fornea en la tabla CUSTOMER, y que, simtricamente, CustomerId sera una clave fornea en la tabla VIPCARD. Y podramos aventurar que el error de este diseo, es que si bien se cumple que un cliente tenga una sla tarjeta y que una tarjeta tenga un slo cliente, no se cumple que coincidan cliente y tarjeta en cambas tablas.
Customer { CustomerId* CustomerName VIPCardId VIPCardObservations } VIPCard { VIPCardId* VIPCardObservations CustomerId CustomerName }

Es decir: el cliente 1 puede tener VIPCardId 5, pero cuando vamos a VIPCardId 5, resulta que sta podra tener CustomerId 3, por ejemplo. Un momento! No nos dimos cuenta que ni siquiera podrn ingresarse estos registros, debido a los controles de integridad referencial. Cmo hago para ingresar el cliente 1 con la tarjeta 5, si antes no la ingres? Pero para ingresarla, cmo hago, si todava no existe el cliente? Bueno, podra solucionarse permitiendo que VIPCardId en CUSTOMER, as como CustomerId en VIPCard admitan nulos. As, la primera vez ingreso el cliente sin especificarle la tarjeta, y luego ingreso la tarjeta, especificando el cliente y vuelvo al cliente en update para ahora s especificarle la tarjeta. Sin embargo, todo el anlisis anterior parti de una premisa falsa. Estamos tan seguros de que GeneXus crear 2 tablas? Recordemos que antes que nada, GeneXus normaliza. Si observamos, al tener las referencias cruzadas estamos diciendo por un

lado que CustomerId determina a VIPCardId y por otro que a su vez VIPCardId determina a CustomerId. As que estas 2 transacciones darn lugar a una nica tabla que tendr la composicin de cualquiera de las 2 transacciones (en las pruebas efectuadas, tom la ltima definida, pero eso no importa). Y esto, si lo pensamos, es completamente lgico. En este caso, si toma la ltima, la tabla coincidir con la estructura de VIPCard, pero donde adems crear un ndice primario tambin por CustomerId (es decir, no permitir ingresar para dos tarjetas distintas el mismo cliente). Un alumno podra entonces preguntar por qu esta solucin no sera correcta. Por qu no lo es? es que el cliente no existira como entidad (as, no podramos relacionar las facturas con un cliente, porque CustomerId no podra ser clave fornea en ninguna tabla, ya que no existe como clave primaria en ninguna otra). La opcin d) es una variacin de la a). Sigue representando una relacin 1 a N (donde es completamente innecesaria la definicin de subtipos).

5. Se tiene una aplicacin GeneXus para un casino. Dado el siguiente diseo de transacciones, determine la estructura fsica de las TABLAS que GeneXus disear y crear.
Slot { SlotId* SlotDescription TechnicianId TechnicianName } Technician { TechnicianId* TechnicianName } Registration { RegistrationId* RegistrationDate Fx RegistrationAmount Slot { SlotId* SlotDescription TechnicianId TechnicianName } }

a)
TECHNICIAN TechnicianId* TechnicianName SLOT SlotId* SlotDescription TechnicianId REGISTRATION RegistrationId* RegistrationDate REGISTRATIONSLOT RegistrationId* SlotId* TechnicianId

b)

TECHNICIAN TechnicianId* TechnicianName

SLOT SlotId* SlotDescription TechnicianId

REGISTRATION RegistrationId* RegistrationDate RegistrationAmount

REGISTRATIONSLOT RegistrationId* SlotId* TechnicianId

c)

TECHNICIAN TechnicianId* TechnicianName

SLOT SlotId* SlotDescription TechnicianId

REGISTRATION RegistrationId* RegistrationDate

REGISTRATIONSLOT RegistrationId* SlotId*

d)

TECHNICIAN TechnicianId* TechnicianName

SLOT SlotId* SlotDescription TechnicianId

REGISTRATION RegistrationId* RegistrationDate RegistrationAmount

REGISTRATIONSLOT RegistrationId* SlotId*

e) Ninguna es correcta

Respuesta: c) El atributo: TechnicianName es inferido en la transaccin Slot a partir de la clave fornea TechnicianId. TechnicianId es inferido en el segundo nivel de la transaccin Registration, a travs de la clave fornea SlotId (cuidado con creer que porque un atributo es clave primaria en una tabla, eso ya lo convierte en clave fornea en toda otra tabla en que aparezca! Cmo hara para que el segundo nivel de Registration permita registrar un tcnico independiente del del slot? Aqu la solucin viene por el lado del uso de subtipos. Piense la solucin. Vea respuesta d) a pregunta 10). RegistrationAmount es frmula, por lo que no est presente en ninguna tabla (a menos que explcitamente se lo defina como redundante).

6. Se tiene una aplicacin GeneXus para un casino. La misma cuenta con un conjunto de transacciones para registrar los slots (Slot), clientes (Customer) y reserva de slots (Reservation) segn se muestra. Determine la tabla extendida de la tabla RESERVATIONSLOT
Slot { SlotId* SlotDescription } Customer { CustomerId* CustomerName } Reservation { ReservationId* ReservationDate CustomerId CustomerName Slot { SlotId* SlotDescription } }

a) b) c) d)

RESERVATIONSLOT + RESERVATION RESERVATIONSLOT + SLOT RESERVATIONSLOT + RESERVATION + SLOT RESERVATIONSLOT + RESERVATION + SLOT + CUSTOMER

Respuesta: d) El concepto de tabla extendida es bien importante en GeneXus, porque toda su lgica se basa en abstraer la visin de tablas fsicas, y pasar a una visin ms conceptual (de informacin unvocamente relacionada, que est desperdigada en distintas tablas fsicas slo a los efectos de la normalizacin, pero que no obstante conforma lgicamente una unidad). De ah que el for each permita trabajar casi por igual con todos los atributos de tabla extendida (y no slo de tabla base), as como los grids, grupos de Data Providers, reglas de transacciones, etc. Para qu se normaliza una base de datos? Para evitar la duplicacin de datos, que traera el consabido riesgo de tener datos inconsistentes. De no tener la necesidad de evitar la duplicacin, tendramos una nica tabla para los slots de las reservas, con clave primaria {ReservationId, SlotId}. Qu atributos tendra esa tabla? Tendra adems de la clave primaria, la descripcin del slot (SlotDescription), la fecha de la reserva (ReservationDate), el cliente de la reserva (CustomerId) con su nombre (CustomerName). Toda esa informacin estara junta en una tabla, a la que llamamos tabla extendida. Fsicamente no existe, pero s como herramienta conceptual.

7. Se tiene una aplicacin GeneXus para un Casino. La misma cuenta con un conjunto de transacciones para registrar los slots (Slot), y la reserva de slots (Reservation), por parte de los clientes (Customer) segn se muestra. En algunas ocasiones se realizan reservas sin la necesidad de especificar el cliente (CustomerId). A partir del diseo propuesto, indique la afirmacin que considere correcta:
Slot { SlotId* SlotDescription } Customer { CustomerId* CustomerName } Reservation { ReservationId* ReservationDate CustomerId CustomerName Slot { SlotId* SlotDescription } }

Nullable = yes

a) A pesar de declarar que el atributo CustomerId (clave fornea) en la tabla RESERVATION admite nulos (o sea, admite un valor no especificado a nivel de la base de datos), GeneXus siempre disparar los correspondientes controles de integridad referencial contra la tabla CUSTOMER, y no admitir que no se ingrese un valor vlido para CustomerId. b) Al momento de declarar que el atributo CustomerId (clave fornea) en la tabla RESERVATION admite nulos (o sea, admite un valor no especificado a nivel de la base de datos), entonces si no se ingresa un valor en dicha clave fornea, GeneXus no dispara los controles de integridad referencial contra la tabla CUSTOMER, pero si se ingresa un valor en dicha clave fornea, GeneXus s disparar los controles de integridad referencial contra la tabla CUSTOMER. c) Ninguna de las opciones anteriores es correcta Respuesta: b)

8. Se tiene una aplicacin GeneXus para un casino. Dado el siguiente diseo de transacciones, determine qu ndice es utilizado para validar con eficiencia al momento de intentar eliminar un tcnico (Technician) a travs de la transaccin, que no existan slots que lo tengan asignado.

Slot { SlotId* SlotDescription TechnicianId TechnicianName } Technician { TechnicianId* TechnicianName }

Reservation { ReservationId* ReservationDate CustomerId CustomerName Slot { SlotId* SlotDescription TechnicianId TechnicianName } }

Customer { CustomerId* CustomerName }

a) b) c) d)

ndice por TechnicianId en la tabla TECHNICIAN ndice por TechnicianId en la tabla SLOT ndice por SlotId en la tabla SLOT Ninguna de las anteriores es correcta

Respuesta: b) Esta pregunta no es tan importante para el alumno, cuanto para el instructor (difcilmente la encuentre en preguntas de examen reales). Al momento de pretender eliminar un registro de la tabla TECHNICIAN a travs de la transaccin, como sabemos, se incluye lgica en la misma para acceder a todas las tablas que tengan a TechnicianId (clave primaria) como clave fornea, es decir, a todas las tablas subordinadas, que la referencian. Debe accederse a cada una de estas tablas, para corroborar que no exista ningn registro que referencie al que quiere ser borrado. En este ejemplo hay slo una subordinada: la tabla SLOT. Cmo acceder a esta tabla para saber si existe un registro con el valor para el atributo clave fornea TechnicianId igual al del registro que quiere borrarse de TECHNICIAN? Los ndices son los mecanismos eficientes para realizar estas bsquedas, por lo que GeneXus utilizar el ndice por clave fornea definido en la tabla SLOT, sobre el atributo clave fornea TechnicianId. De hecho, es para hacer eficientes los controles de integridad referencial en la eliminacin que los ndices por clave fornea son creados por GeneXus automticamente en la base de datos. Es comn confundirse y pensar que la respuesta correcta hubiera sido la a), pero razonando se entiende que el ndice por TechnicianId en la tabla TECHNICIAN lo que hace es acceder a la tabla TECHNICIAN, donde no hay nada que buscar. La bsqueda debe efectuarse sobre SLOT. Este es un tema complejo, porque en la realidad depende un

poco del DBMS las estrategias de acceso a las tablas utilizadas. Pero la lgica conceptual de GeneXus sera la indicada.
9. Se tiene una aplicacin GeneXus para un casino. Esta cuenta con un conjunto de transacciones para registrar los slots (Slot) y los tcnicos encargados de las reparaciones (Technician). Cada vez que se ingresa un nuevo slot se le debe asociar un tcnico responsable y uno suplente. El sistema deber controlar que no sea el mismo. Determine si es verdadero o falso que la siguiente alternativa resuelve correctamente el requerimiento anterior.
Slot { SlotId* SlotDescription TitularTechnicianId TitularTechnicianName SubstituteTechnicianId SubstituteTechnicianName }

Technician { TechnicianId* TechnicianName }

Subtype group: SlotTechnicians TitularTechnicianId subtype of TitularTechnicianName subtype of SubstituteTechnicianId subtype of SubstituteTechnicianName subtype of

TechnicialId TechnicianName TechnicianId TechnicianName

Slot Rules: Error( Invalid Substitute Technician) if TitularTechnicianId =SubstituteTechnicianId;

Respuesta: Falso De definirse subtipos para el tcnico titular y para el suplente, deben definirse en dos grupos distintos, para indicar el conjunto de informacin que se maneja conjuntamente. En la pregunta se defini un solo grupo de subtipos, donde se colocaron tanto los subtipos que corresponden al titular como al suplente, mezclados. Esto es claramente incorrecto. Por qu?

10. Se tiene una aplicacin GeneXus para un casino. Esta cuenta con un conjunto de transacciones para registrar los slots (Slot) y los tcnicos encargados de las reparaciones (Technician). Un slot puede ser reparado por un solo tcnico y cada tcnico tiene asignados varios slots para reparar en caso que as lo requieran. Es as que a la hora de facturar los servicios de un tcnico (Invoice) se debe verificar que los slots detallados efectivamente estn a cargo del tcnico de la factura. Determine de las siguientes opciones la que implementa este requerimiento.

a)

Slot { SlotId* SlotDescription TechnicianId TechnicianName } Technician { TechnicianId* TechnicianName }

Invoice { InvoiceId* InvoiceDate TechnicianId TechnicianName InvoiceAmount Slot { SlotId* SlotDescription InvoiceSlotAmount } }

b)

Slot { SlotId* SlotDescription TechnicianId TechnicianName } Technician { TechnicianId* TechnicianName }

Invoice { InvoiceId* InvoiceDate TechnicianId TechnicianName InvoiceAmount Slot { SlotId* SlotDescription TechnicianId TechnicianName InvoiceSlotAmount } }

Invoice Rules: Error( Invalid Slot) if TechnicianId <> TechnicianId;

c)

Slot { SlotId* SlotDescription TechnicianId TechnicianName } Technician { TechnicianId* TechnicianName }

Invoice { InvoiceId* InvoiceDate InvoiceTechnicianId InvoiceTechnicianName InvoiceAmount Slot { SlotId* SlotDescription TechnicianId TechnicianName InvoiceSlotAmount } }

Subtype group: InvoiceTechnician InvoiceTechnicianId subtype of InvocieTechnicianName subtype of

TechnicialId TechnicianName

Invoice Rules: Error( Invalid Slot) if TechnicianId <> InvoiceTechnicianId ;

d)

Slot { SlotId* SlotDescription TechnicianId TechnicianName } Technician { TechnicianId* TechnicianName }

Invoice { InvoiceId* InvoiceDate TechnicianId TechnicianName InvoiceAmount Slot { SlotId* SlotDescription InvoiceSlotTechnicianId InvoiceSlotTechnicianName InvoiceSlotAmount } }

Subtype group: InvoiceSlotTechnician InvoiceSlotTechnicianId subtype of InvocieSlotTechnicianName subtype of

TechnicialId TechnicianName

Invoice Rules: Error( Invalid Slot) if TechnicianId <> InvoiceSlotTechnicianId ;

e) Ninguna de las anteriores

Respuesta: c) Si bien hay otras formas de implementarlo, la nica de las opciones presentadas que lo logra es la c). Obsrvese que en el caso de la d), como el subtipo InvoiceSlotTechnicianId no est en un grupo con un subtipo de SlotId, ser un tcnico independiente del que viene inferido del Slot.

11. Se tiene una aplicacin GeneXus para un casino. Entre la informacin que se necesita registrar, est la de los tcnicos que reparan los slots, as como la de los clientes del casino. Como tanto los tcnicos como los clientes son personas, de las que se registra un conjunto de informacin comn (nombre y telfono), se desea registrar la info general una sola vez, y luego slo registrar la informacin particular (por ejemplo, si la persona es un cliente, entonces se desea registrar si es un cliente VIP y el crdito que le proporciona el casino, y si es un tcnico, su salario). Determine si es verdadero o falso que la siguiente solucin resuelve este caso de especializacin adecuadamente en GeneXus.

Person { PersonId* PersonName PersonPhone }

Customer { CustomerId* CustomerName CustomerPhone CustomerIsVIP CustomerCredit PersonId }

Technician { TechnicianId* TechnicianName TechnicianPhone TechnicianSalary PersonId }

ndice Unique en esta tabla compuesto por PersonId

ndice Unique en esta tabla compuesto por PersonId

Respuesta: Falso

Si bien al definir el ndice Unique sobre PersonId en la tabla CUSTOMER se establece una relacin 1-1 con PERSON, en verdad no estamos representando que se trata de la misma entidad que debi separarse en dos tablas para que en la especializada slo aparezcan los atributos que no son comunes a los tcnicos. Por el contrario, lo que se est diciendo es que son dos entidades diferentes, con una relacin 1 a 1, como podra ser la de un cliente con su tarjeta VIP (ver pregunta 4). Aqu no estamos diciendo que la relacin 1 a 1 existente entre Person y Customer es una especial, donde el cliente es una persona. Para ello, obsrvese que la persona tendr un atributo para almacenar el nombre (PersonName) y que el cliente que tenga asociada esa persona, podr tener otro nombre (CustomerName). El mismo anlisis puede hacerse entre Person y Technician. La solucin a este problema de especializacin lo dan los grupos de subtipos. Cmo sera? Por qu definir a CustomerId como subtipo de PersonId resuelve el problema para Customer? Piense que decir que es un subtipo lo convierte en una clave fornea. Pero adems, el decir que es identificador de la transaccin Customer, lo convierte en clave primaria. Por tanto, CustomerId termina siendo clave primaria que adems es fornea. Por lo que finalmente establece una relacin 1-1, por clave, y esto ltimo es lo que provoca la relacin es. Anlogo anlisis para Technician.

12. Se tiene una aplicacin GeneXus para un casino. Se cuenta con un conjunto de transacciones para registrar los slots (Slot), los clientes (Customer) y las reservas de slots (Reservation), segn se muestra. Suponga que en la transaccin Reservation se declar la regla: ReservationDate = Today() on AfterInsert; Decida si es verdadero o falso que esta regla es correcta.
Slot { SlotId* SlotDescription } Customer { CustomerId* CustomerName } Reservation { ReservationId* ReservationDate CustomerId CustomerName Slot { SlotId* SlotDescription ReservationSlotTime } }

Respuesta: Falso Al momento de ejecutarse la regla, por estar condicionada a AfterInsert, el registro correspondiente al cabezal de la reserva acaba de ser insertado en la base de datos, por lo que ya es demasiado tarde para darle valor a un atributo de ese registro. Con qu valor quedar en la base de datos el atributo ReservationDate para ese registro? Si el usuario le ingres un valor a travs del form, con ese valor. De lo contrario, quedar vaco.

13. Se tiene una aplicacin GeneXus para un casino, que cuenta con un conjunto de transacciones para registrar los slots (Slot), los clientes (Customer) y las reservas de slots (Reservation), segn se muestra. Suponga que en la transaccin Reservation se declar la regla: ReservationSlotTime += 60 if SlotId >100 on AfterUpdate; Decida si es verdadero o falso que esta regla es correcta
Slot { SlotId* SlotDescription } Customer { CustomerId* CustomerName } Reservation { ReservationId* ReservationDate CustomerId CustomerName Slot { SlotId* SlotDescription ReservationSlotTime } }

Respuesta: Falso Suponiendo que x lneas se han modificado, por cada una de ellas, si el Id del slot es mayor a 100, se disparar la regla. Pero cundo? Se disparar inmediatamente despus de actualizarse en la base de datos el registro de la lnea modificada, es decir, ya ser tarde.

14. Se tiene una aplicacin GeneXus para un casino, que cuenta con un conjunto de transacciones para registrar los slots (Slot), los clientes (Customer) y las reservas de slots (Reservation), segn se muestra. Suponga que en la transaccin Reservation se podran declarar las siguientes reglas para invocar al procedimiento Something: 1. Something.call( SlotId ) on BeforeComplete; 2. Something.call( SlotId ) on AfterLevel Level SlotId; Cul de las siguientes aseveraciones es la correcta?
Slot { SlotId* SlotDescription } Customer { CustomerId* CustomerName } Reservation { ReservationId* ReservationDate CustomerId CustomerName Slot { SlotId* SlotDescription ReservationSlotTime } }

a) b) c) d)

Ambas reglas son correctas, y podra utilizarse cualquiera de ellas. La regla 1 es correcta pero la 2 no. La regla 2 es correcta pero la 1 no. Ninguna de las dos reglas son correctas.

Respuesta: d) Observemos que en ambas reglas aparece el atributo SlotId del segundo nivel, que se intenta pasar como parmetro al procedimiento Something. De no existir evento de disparo, esta regla se disparara una vez por cada lnea ingresada. Sin embargo, los eventos de disparo de ambas reglas suceden luego de haber trabajado (insertado/modificado/eliminado) con todas las lneas, inmediatamente despus de esto para el afterlevel e inmediatamente antes del commit para el before complete. Por tanto, qu SlotId se le pasar a este procedimiento? El de cul de las lneas trabajadas? Ambas reglas estn mal declaradas.

15. Se tiene una aplicacin GeneXus para un casino, que cuenta con un conjunto de transacciones para registrar los slots (Slot), los clientes (Customer) y las reservas de slots (Reservation), segn se muestra. Suponga que en la transaccin Reservation se declara la regla: Proc.call( ReservationId ) Qu diferencia hay entre invocar al Proc con if Insert y hacerlo con on AfterInsert? Determine si es verdadera o falsa la siguiente respuesta a la pregunta anterior: If Insert: se dispara en el cliente ni bien el usuario sale del campo ReservationId del form y antes de ingresar valor para ReservationDate, una vez que el programa detecta que se est ingresando una reserva nueva. Luego de ingresados todos los datos de cabezal y lneas por el usuario, y confirmada esa informacin, en el servidor se vuelve a ejecutar, en el mismo orden en el que se ejecut en el cliente (luego de validar ReservationId). On AfterInsert: no se ejecutar en el cliente, puesto que all no se insertan registros en tablas. Recin se ejecutar en el servidor, luego de validarse todos los campos del cabezal (ReservationId, seguido por ReservationDate y luego por CustomerId), y de insertarse el registro en la tabla RESERVATION.

Slot { SlotId* SlotDescription }

Customer { CustomerId* CustomerName }

Reservation { ReservationId* ReservationDate CustomerId CustomerName Slot { SlotId* SlotDescription ReservationSlotTime } }

Respuesta: Verdadero

16. Se tiene una aplicacin GeneXus para un casino, que cuenta con un conjunto de transacciones para registrar los slots (Slot), los clientes (Customer) y las reservas de slots (Reservation), segn se muestra. Dado el siguiente conjunto de reglas declaradas en la transaccin Reservation, determine el orden en el cual sern ejecutadas.
Slot { SlotId* SlotDescription } Reservation { ReservationId* ReservationDate CustomerId CustomerName CustomerIsVIP Slot { SlotId* SlotDescription ReservationSlotTime } }

Customer { CustomerId* CustomerName CustomerIsVIP }

Reservation rules: a. Msg( VIP Customer Registration) if CustomerIsVIP on AfterComplete; b. ReservationDate = Today() on BeforeInsert; c. ProcA.call( SlotId ) on AfterInsert; d. ProcB.call( ResrevationId ) on BeforeComplete; e. ProcC.call( ReservationId) on AfterLevel Level ReservationSlotTime;

a) b) c) d)

Las reglas se disparan en el orden en el que han sido declaradas El orden de ejecucin ser: a. - b. - e. - c. - d. El orden de ejecucin ser: b. - c. - e. - d. - a. El orden de ejecucin ser: b. - d. - e. - c. - a.

Respuesta: c)

17. En las reglas de las transacciones slo se pueden actualizar atributos que pertenecen fsicamente a la tabla base de cada nivel, y no a su extendida. Esta aseveracin es verdadera o falsa?

Respuesta: Falsa. Podrn actualizarse tambin atributos de la tabla extendida de cada nivel que estn declarados en la estructura de la transaccin (sern atributos inferidos). Aqu se aprecia otra vez la importancia del concepto de tabla extendida.
18. Se tiene una aplicacin GeneXus para un casino. Esta cuenta con transacciones para registrar los slots (Slot), y la reserva de los slots (Reservation) por parte de los clientes (Customer) Dado el siguiente source de un procedimiento, determine la tabla de partida y la de evaluacin (la que se recorre para contar registros) de la frmula local declarada.
Slot { SlotId* SlotDescription } Customer { CustomerId* CustomerName } Reservation { ReservationId* ReservationDate CustomerId CustomerName Slot { SlotId* SlotDescription ReservationSlotTime } }

Source: For each &SlotsQuantity = Count( ReservationSlotTime) Print printblock1 // ReservationDate, CustomerName, &SlotsQuantity endfor

a) b) c) d)

Tabla de partida: RESERVATION Tabla de evaluacin: RESERVATIONSLOT Tabla de partida: RESERVATION Tabla de evaluacin: RESERVATION Tabla de partida: CUSTOMER Tabla de evaluacin: RESERVATION Tabla de partida: RESERVATIONSLOT Tabla de evaluacin: RESERVATIONSLOT

Respuesta: a) Cualquier cosa que se encuentre dentro de un for each, por el slo hecho de estar all dentro, refiere a una iteracin del mismo, por lo que tiene como contexto el registro de la iteracin en el que se encuentra trabajando la ejecucin en un momento dado. La tabla base del for each se calcula con los atributos que se encuentren dentro del for each sueltos (no los que estn dentro de una frmula aggregate, como la Count, o los que estn dentro de un for each anidado a ste, u otro comando que tenga su propia resolucin, como un new, por ejemplo). En este caso sern los del print block, por lo que la tabla base ser RESERVATION. Por tanto el for each iterar sobre esa tabla, y por cada reserva, se dispara la frmula count. Entonces existir tabla de partida de la frmula, que es el contexto que tiene al dispararse (estamos posicionados en una reserva). Qu se cuenta? Los registros donde se encuentra ReservationSlotTime. En qu tabla est ese atributo? En RESERVATIONSLOT. Pero al dispararse la frmula, en una iteracin del for each, tenemos un ReservationId instanciado (el del registro en el que nos encontramos trabajando). Por lo que contar los registros relacionados, los que corresponden a esta reserva. Siempre que la frmula no tenga un contexto (por ejemplo, si est suelta dentro del Source) no tendr tabla de partida. Por ese motivo, en este caso, contara todos los registros de la tabla de evaluacin (RESERVATIONSLOT), justamente porque no hay un contexto que permita especializar el clculo. El contexto es fundamental en GeneXus y lo que lo hace inteligente. Porque puede inferir cosas en base a ese contexto, sin tener que explicitarlo, ahorrndonos trabajo de programacin.

19. Se tiene una aplicacin GeneXus para un casino, que cuenta con un conjunto de transacciones para registrar los slots (Slot), los clientes (Customer) y las reservas de slots (Reservation), segn se muestra. Dado el siguiente par de for eachs anidados, determine sus tablas base.

Slot { SlotId* SlotDescription }

Customer { CustomerId* CustomerName }

Reservation { ReservationId* ReservationDate CustomerId CustomerName ReservationAmount Slot { SlotId* SlotDescription ReservationSlotAmount } }

SUM( ReservationSlotAmount)

For each Print printblock1 // ReservationId, ReservationDate y SlotDescritpion For each Print printblock2 // CustomerName endfor Endfor

a) For each externo: RESERVATIONSLOT For each interno: CUSTOMER b) For each externo: RESERVATION For each interno: CUSTOMER c) For each externo: SLOT For each interno: CUSTOMER d) For each externo: RESERVATIONSLOT For each interno: RESERVATIONSLOT

Respuesta: d) Este es un caso de confusin tpico. Por qu la tabla base del for each anidado es RESERVATIONSLOT y no CUSTOMER? Porque para determinar la tabla base del for each anidado, GeneXus trata de detectar si los atributos de este for each pertenecen a la tabla extendida del for each principal, cuya tabla base determin en el paso anterior. Si este es el caso, entonces determina que se trata de la misma tabla base, resultando un corte de control. De lo contrario, qu sentido tendra tener un for each (estructura repetitiva) para recorrer un solo registro, de la extendida del for each principal? No ser un caso muy comn, pero puede suceder que le ocurra a un alumno que tiene algunos conceptos equivocados. Por ejemplo, supongamos que el alumno no entendi que dentro de un for each pueden actualizarse atributos tanto de la tabla base como de la tabla extendida. Y supongamos que entonces, por cada reserva quera imprimirla y adems si el cliente es el 2, actualizar su nombre. Un buen programador escribira: For each Print printblock1 // ReservationId, ReservationDate If CustomerId = 2 CustomerName = Unknown Endif Endfor Pero el que no comprendi que GeneXus abstrae todo lo que puede, permitindonos entonces actualizar directamente la informacin de la tabla extendida (y alivindonos de estar preocupados por las tablas fsicas donde se encuentra cada atributo), puede intentar hacer:

For each Print printblock1 // RservationId, ReservationDate For each where CustomerId = 2 CustomerName = Unknown Endfor Endfor Nuestro alumno no entender por qu el listado de navegacin le estar reportando un corte de control.

20. Se tiene una aplicacin GeneXus para un casino, que cuenta con un conjunto de transacciones para registrar los slots (Slot), los tipos de slots (SlotType), clientes (Customer) y las reservas de slots (Reservation), segn se muestra. Se desea generar un listado de reservas de slots como se muestra (es decir por tipo de slot, para cada cliente listar sus reservas; y no se desea que salgan tipos de slots y clientes si no hay reservas para los mismos). Determine la opcin de implementacin que considere correcta.

SlotType { SlotTypeId* SlotTypeDescription }

Slot { SlotId* SlotDescription SlotTypeId SlotTypeDescription }

Customer { CustomerId* CustomerName }

Slot Type: 1 Wizards Customer: 15 Ann Smith Reservtion Id

.. .. ..

Date
. . .

Slot Description
. . .

Reservation { ReservationId* ReservationDate CustomerId CustomerName Slot { SlotId* SlotDescription } }

Customer: 120 Peter Jones Reservtion Id

.. ..

Date
. .

Slot Description
. .

Slot Type: 1 Wizards Customer: 15 Ann Smith Reservtion Id

..

Date
.

Slot Description
.

a)
For each order SlotTypeId Print TypePB // SlotTypeId, SlotTypeDescription For each order CustomerId Print CustomerPB // CustomerId, CustomerName For each order ReservationId Print ReservationPB // ReservationId, ReservationDate, SlotDescription Endfor Endfor Endfor

b)

For each order SlotTypeId, CustomerId, ReservationId Print TypePB // SlotTypeId, SlotTypeDescription For each Print CustomerPB // CustomerId, CustomerName For each Print ReservationPB // ReservationId, ReservationDate, SlotDescription Endfor Endfor Endfor

c) Ninguna de las anteriores

Respuesta: c) La solucin correcta sera:

For each order SlotTypeId Defined by ReservationDate Print TypePB // SlotTypeId, SlotTypeDescription For each order CustomerId Print CustomerPB // CustomerId, CustomerName For each order ReservationId Print ReservationPB // ReservationId, ReservationDate, SlotDescription Endfor Endfor Endfor

Recordemos que lo que determina que for eachs anidados correspondan a un corte de control, es que compartan la misma tabla base. Es en el orden de cada for each (salvo para el ms interno) que se determina el criterio de agrupamiento de la informacin.

La recorrida de la tabla se realizar secuencialmente, una sola vez (por ms que haya 3 for eachs). Para representar visualmente esto veamos la tabla RESERVATIONSLOT, tabla base del corte de control. Con las clusulas orden que especificamos estamos diciendo que ordene la tabla por la concatenacin de los orders que aparecen (en este caso por {SlotTypeId, CustomerId, ReservationId} )y adems, le estamos diciendo que agrupe de esta manera que sigue: Mientras no cambie el SlotTypeId imprima el print block TypePB Mientras no cambie el CustomerId Imprima el print block CustomerPB Mientras no cambie el SlotTypeId, CustomerId Imprima el print block ReservationPB

Obsrvese que el order del for each ms interno no tiene ninguna repercusin para el corte de control. Este order simplemente servir para que la informacin ya agrupada, salga ordenada por ReservationId. Si no se hubiese colocado, de todos modos se estara implementando este corte de control. El hecho de que el primer for each ordene por SlotTypeId determina que se agrupe primeramente por este criterio, se impriman SlotTypeId y SlotTypeDesciption en la salida, y luego, mientras no cambie el SlotTypeId, se ingrese a iterar en el segundo for each, como se indica en las imgenes que siguen (piense qu pasara si en el order del primer for each apareciera el par: SlotTypeId, CustomerId; el corte sera otro, porque se estara agrupando en primera instancia por el par):

21. Se tiene una aplicacin GeneXus para un casino, que cuenta con un conjunto de transacciones para registrar los slots (Slot), los clientes (Customer) y las reservas de slots (Reservation), segn se muestra. Dada la implementacin del procedimiento que figura a continuacin, determine cul ser el resultado de su ejecucin.
Slot { SlotId* SlotDescription } Reservation { ReservationId* ReservationDate CustomerId CustomerName Slot { SlotId* SlotDescription } }

Customer { CustomerId* CustomerName }

For each Print printblock1 // CustomerName For each Print printblock2 // ReservationId, ReservationDate y SlotDescritpion endfor Endfor a) Producto cartesiano: se listan todos los clientes de la tabla CUSTOMER y todos los slots registrados en la tabla RESERVATIONSLOT, sin hacer ningn filtro en la informacin. Es decir, saldr por cada cliente, todos los slots de todas las reservas. b) Join: se listan todos los clientes de la tabla CUSTOMER y por cada cliente, se listan slo los slots registrados en la tabla RESERVATIONSLOT que corresponden a reservaciones del cliente (se filtra automticamente por CustomerId) c) Corte de control: se imprimen solamente los clientes de la tabla extendida de RESERVATIONSLOT, es decir, solamente los clientes que tienen reservas, y para cada uno de de estos se listan los slots presentes en esas reservas. d) Ninguna de las anteriores

Respuesta: b) Este es un caso de relacin 1-N indirecta. Aqu la tabla base del primer for each est incluida en la tabla extendida del anidado, por lo que indirectamente se establece esta relacin. Obsrvese que el atributo relacin, CustomerId, est en la tabla intermedia que las vincula, RESERVATION.

22. Se tiene una aplicacin GeneXus para un casino, que cuenta con un conjunto de transacciones para registrar los slots (Slot), los clientes (Customer) y las reservas de slots (Reservation), segn se muestra. Se solicita un listado que muestre todos los clientes y para cada uno sus reservas de slots. (Interesa que salgan todos los clientes, aunque no haya reservas para ellos) Determine cul es la implementacin que resuelve ms adecuadamente este requerimiento.
Slot { SlotId* SlotDescription } Reservation { ReservationId* ReservationDate CustomerId CustomerName ReservationAmount Slot { SlotId* SlotDescription ReservationSlotAmount } }

SUM( ReservationSlotAmount)

Customer { CustomerId* CustomerName }

a) For each order CustomerId defined by ReservationDate Print printblock1 // CustomerId, CustomerName For each Print printblock2 // ReservationId, ReservationDate y ReservationAmount endfor Endfor b) For each Print printblock1 // CustomerId, CustomerName &customerId = CustomerId For each where CustomerId = &CustomerId Print printblock2 // ReservationId, ReservationDate y ReservationAmount endfor Endfor

c) For each Print printblock1 // CustomerId, CustomerName For each Print printblock2 // ReservationId, ReservationDate y ReservationAmount endfor Endfor

d) Ninguna es correcta

Respuesta: c) Si bien la opcin b) resuelve el requerimiento, no est bien programada en GeneXus. Implementar de esta manera un join es un sntoma claro de que no se ha comprendido la nocin de Join automtico que realiza GeneXus, el de la opcin c). No es un detalle menor, porque da la pauta de que el alumno no entendi la lgica de GeneXus o no confa en la misma. Es importante entonces llamar la atencin sobre este hecho, para poder transmitir adecuadamente la forma de pensar de la herramienta y su inteligencia para ahorrarnos el trabajo de tener que estar explicitando todo.

23. Se tiene una aplicacin GeneXus para un casino, que cuenta con un conjunto de transacciones para registrar los slots (Slot), los clientes (Customer) y las reservas de slots (Reservation), segn se muestra. Sabiendo que una consulta frecuente ser recuperar de un slot en una fecha determinada todas sus reservas, se implement el data selector que se muestra. Determine si es verdadero o falso que un web panel implementado como se muestra abajo, al ejecutarse desplegar en el grid los nombres de los clientes que tienen reservas para el slot 1 en la fecha de hoy.

Slot { SlotId* SlotDescription } Customer { CustomerId* CustomerName }

Reservation { ReservationId* ReservationDate CustomerId CustomerName Slot { SlotId* SlotDescription } }

Data Selector: SlotReservation Parameters: &date &slot Conditions: ReservationDate = &date SlotId = &slot

Web Panel Form:

Respuesta: Verdadero Para determinar la tabla base del grid, se tendrn en cuenta no slo los atributos presentes en el grid, los que estn en sus propiedades Order y Conditions, sino tambin los del Data Selector utilizado (adems, tambin, de los atributos que aparezcan sueltos en Eventos, fuera de For each). Es anlogo al caso de la determinacin de la tabla base de un for each. Por este motivo, la tabla base del grid no ser CUSTOMER, sino RESERVATIONSLOT, cuya extendida contiene a todos los atributos involucrados (CustomerName, ReservationDate y SlotId). Si se entiende la lgica de GeneXus, no hay por qu memorizar nada. Vea la explicacin a la pregunta 31 para ahondar en esto.

24. Se tiene una aplicacin GeneXus para un casino, que cuenta con un conjunto de transacciones para registrar los slots (Slot), los clientes (Customer) y las reservas de slots (Reservation), segn se muestra. Sabiendo que una consulta frecuente ser recuperar de un slot en una fecha determinada todas sus reservas, se implement el data selector que se muestra. Si se tiene un procedimiento implementado como se muestra abajo, a la hora de ejecutarlo, determine de las opciones que siguen, la correcta.

Slot { SlotId* SlotDescription } Customer { CustomerId* CustomerName }

Reservation { ReservationId* ReservationDate CustomerId CustomerName Slot { SlotId* SlotDescription } }

Data Selector: SlotReservation Parameters: &date &slot Conditions: ReservationDate = &date SlotId = &slot

Procedure Source: For each using SlotReservation( &today, 1 ) Print printblock1 // CustomerName endfor

a) Desplegar los nombres de los clientes que tienen reservas para el slot 1 en la fecha de hoy, pues la tabla base del for each ser RESERVATIONSLOT b) Desplegar los nombres de todos los clientes, pues tabla base del for each ser CUSTOMER c) El for each no admite clusula using (por lo que dar un error) d) Ninguna de las anteriores Respuesta: a)

Tener la clusula using dentro del for each, convierte al Data Selector en una especie de macro. Es decir, es como si hubiramos escrito directamente las condiciones del Data Selector en sendas clusulas where dentro del for each (si tuviera Order y Defined by, se agregaran al for each al expandir la macro. Distinto es el caso de utilizacin del Data Selector con el operador IN. En ese caso, el Data Selector se convierte en una consulta a la base de datos (deja de ser simplemente cdigo reutilizable)).
25. Se tiene una aplicacin GeneXus para un casino, que cuenta con un conjunto de transacciones para registrar los slots (Slot), los clientes (Customer) y las reservas de slots (Reservation), segn se muestra. Sabiendo que una consulta frecuente ser recuperar de un slot en una fecha determinada todas sus reservas, se implement el data selector que se muestra. Si se tiene un Data Provider implementado como se muestra abajo, que devuelve una instancia del SDT mostrado, determine de las opciones que siguen, la correcta.

Slot { SlotId* SlotDescription } Customer { CustomerId* CustomerName }

Reservation { ReservationId* ReservationDate CustomerId CustomerName Slot { SlotId* SlotDescription } }

Data Selector: SlotReservation Parameters: &date &slot Conditions: ReservationDate = &date SlotId = &slot

Data Provider Source: Customers using SlotReservation( &today, 1 ) { SlotCustomer { Id = CustomerId Name = CustomerName } }

a) Devolver una coleccin con los identificadores y nombres de los clientes que tienen reservas para el slot 1 en la fecha de hoy, pues la tabla base del grupo ser RESERVATIONSLOT b) Desplegar los nombres de todos los clientes, pues la tabla base del grupo ser CUSTOMER c) Los grupos no admiten clusula using (por lo que dar un error) d) Ninguna de las anteriores

Respuesta: a) Es idntico al caso de un for each.

26. Se tiene una aplicacin GeneXus para un casino, que cuenta con un conjunto de transacciones para registrar los slots (Slot), los clientes (Customer) y las reservas de slots (Reservation), segn se muestra. Se necesita obtener una coleccin de datos, estructurados como se muestra en el SDT de abajo, que se cargar con los clientes del Casino. De cada cliente se recuperar adems una lista de los slots que tiene reservados a partir de una fecha dada. Indique si es verdadero o falso que la solucin propuesta abajo corresponde a una implementacin correcta del requerimiento.

Slot { SlotId* SlotDescription } Customer { CustomerId* CustomerName }

Reservation { ReservationId* ReservationDate CustomerId CustomerName Slot { SlotId* SlotDescription } }

Data Provider Source: Client {

Rule: parm( &dateFrom);

Id = CustomerId Name = CustomerName SlotsAmount = Count( SlotId, ReservationDate >= &dateFrom) SlotsReserved where ReservationDate >= &dateFrom { Slot { Description = SlotDescription } } }

Respuesta: verdadero la solucin ms apropiada de este requerimiento es utilizar un Data Provider como el que se indica, que puede implementarse arrastrando el SDT al Source del DP, rellenando los espacios en blanco a la derecha del igual (=), y pasando a true la propiedad Collection para indicar que lo devuelto es una coleccin de ese SDT.

27. Se tiene una aplicacin GeneXus para un casino, que cuenta con un conjunto de transacciones para registrar los slots (Slot), los clientes (Customer), las reservas de slots (Reservation) por las que se les cobrar. Interesa generar y grabar automticamente una factura por cliente, con el total por concepto de reservas de slots en un perodo de facturacin determinado. Para ello se declara el Data Provider GetInvoices que se indica abajo. Indique si es verdadero o falso que: el Data Provider (DP) slo permite cargar datos estructurados, pero no permite grabar en la base de datos. Para grabar la informacin deber invocarse al DP desde otro objeto y grabar explcitamente, como se muestra abajo.

Slot { SlotId* SlotDescription SlotReservationPrice } Customer { CustomerId* CustomerName }

Reservation { ReservationId* ReservationDate CustomerId CustomerName Slot { SlotId* SlotDescription SlotReservationPrice } }

Business Component = True Invoice { InvoiceId* Autonumber = True InvoiceDate CustomerId CustomerName InvoiceStartPeriodDate InvoiceEndPeriodDate InvoiceAmount }

Data Provider: GetInvoices

Parm( in: &startDate, in: &endDate ); ----------------------------------------------------------------------------------------------Invoice
{

InvoiceDate = Today() CustomerId InvoiceStartPeriodDate = &startDate InvoiceEndPeriodDate = &endDate InvoiceAmount = Sum( SlotReservationPrice, ReservationDate >= &start and ReservationDate <= &end) }

For &invoice in GetInvoices( #2011-01-01#, #2011-01-31#) &invoice.Save() If &invoice.Success() Commit else Rollback endif endfor

Respuesta: verdadero
28. Se tiene una aplicacin GeneXus para un casino, que est abierto al pblico las 24 horas del da. Para facilitar a los clientes la utilizacin de los slots, se divide el da en 12 turnos de 2 horas cada uno, y se permite que los clientes hagan reservas en estos turnos. Para ello se definen las transacciones Customer (clientes), Shift (turnos) y Slot (con sus reservas). En Slot se definen la frmula y reglas que se muestran. Supongamos que se compra un nuevo slot, The Wizard, a pedido de un cliente importante y hay que ingresarlo al sistema con el Id 100. Se desea junto con su ingreso, reservarle a ese cliente el slot en la fecha en que se ponga en funcionamiento, para los turnos 1 y 7, que son los que l frecuenta. Se crea un procedimiento en el que se programan las Reglas y Source como se Indica en las siguientes opciones (y todo lo dems se deja con los valores por defecto). Suponga que la propiedad Declare Referential integrity est en No, por lo que el DBMS no realizar control de integridad referencial. Elija la opcin correcta y mejor programada en GeneXus (que hace mejor utilizacin de las funcionalidades) para resolver este requerimiento asegurando que no se viole ninguna regla del negocio.

Customer { CustomerId* CustomerName } Shift { ShiftId* ShiftDescription ShiftStartTime ShiftEndTime }

Slot Business Component = True { SlotId* SlotDescription Reservation { SlotReservationDate* ShiftId* ShiftDescription CustomerId CustomerName SlotReservationBonus = True if ShiftId < 5; } False otherwise

Error( Invalid reservation date ) if ReservationSlotDate < Today(); &reservations = CountCustomerReservation.udp( ReservationSlotDate, CustomerId ); Error( Number of reservations exceeded) if &reservation > 12;

Msg( Customer has extra bonus ) if SlotReservationBonus;

a)

parm( in: &customerId, in: &date);

// &slot data type: Slot // &reservation data type: Slot.Reservation &slot.SlotId = 100 &slot.SlotDescription = The Wizard &reservation.SlotReservationDate = &date &reservation.ShiftId = 1 &reservation.CustomerId = &customerId &slot.Reservation.Add( &reservation ) &reservation = new () &reservation.SlotReservationDate = &date &reservation.ShiftId = 7 &reservation.CustomerId = &customerId &slot.Reservation.Add( &reservation )

b)

parm( in: &customerId, in: &date); // &slot data type: Slot // &reservation data type: Slot.Reservation &slot.SlotId = 100 &slot.SlotDescription = The Wizard &reservation.SlotReservationDate = &date &reservation.ShiftId = 1 &reservation.CustomerId = &customerId &slot.Reservation.Add( &reservation ) &reservation = new () &reservation.SlotReservationDate = &date &reservation.ShiftId = 7 &reservation.CustomerId = &customerId &slot.Reservation.Add( &reservation ) &slot.Save() if &slot.Success() Commit else Rollback endif

c)

parm( in: &customerId, in: &date);

// &slot data type: Slot // &reservation data type: Slot.Reservation &reservationsQty = CountCustomerReservation.udp( &date, &customerId) If &date >= Today() and &reservationsQty <=12 &slot.SlotId = 100 &slot.SlotDescription = The Wizard &reservation.SlotReservationDate = &date &reservation.ShiftId = 1 &reservation.CustomerId = &customerId &reservation.SlotReservationBonus = True &slot.Reservation.Add( &reservation ) &reservation = new () &reservation.SlotReservationDate = &date &reservation.ShiftId = 7 &reservation.CustomerId = &customerId &reservation.SlotReservationBonus = False &slot.Reservation.Add( &reservation ) &slot.Save() if &slot.Success() Commit else Rollback endif endif

d)

parm( in: &customerId, in: &date);

new SlotId = 100 SlotDescription = The Wizard new SlotReservationDate = &date ShiftId = 1 CustomerId = &customerId endnew new SlotReservationDate = &date ShiftId = 7 CustomerId = &customerId endnew endnew

e)

parm( in: &customerId, in: &date);

&reservationsQty = CountCustomerReservation.udp( &date, &customerId) If &date >= Today() and &reservationsQty <=12 new SlotId = 100 SlotDescription = The Wizard new SlotReservationDate = &date ShiftId = 1 CustomerId = &customerId endnew new SlotReservationDate = &date ShiftId = 7 CustomerId = &customerId endnew endnew endif

Respuesta: b) Aqu es bien importante tener presente que el BC se compone de dos partes: 1) la estructura de la transaccin, como SDT, y 2) la lgica de la transaccin que no tiene que ver con la interfaz. En este sentido, las frmulas y reglas del negocio, estn incluidas en el BC, por lo que no hay que preocuparse, al insertar info por su intermedio, de que se disparen y cumplan. Esto est asegurado, al igual que ocurre cuando se ingresa a travs de la transaccin. Y al igual que en la transaccin, tambin estn contemplados los controles de unicidad y de integridad referencial. De estas cuestiones, slo los controles de unicidad son realizados por el comando new (si no est prendida la propiedad que da el control al DBMS de controlar la integridad referencial), por lo que la eleccin en este caso de la solucin por BC es inmediata. Cundo se elegira la solucin con new? Cuando es info masiva la que estamos ingresando (el new es ms eficiente, evidentemente), cuando no necesitamos se disparen las reglas del negocio ni los controles de IR. Para trabajar con un BC, hay que cumplir tres pasos: 1) cargar su estructura (ya sea manualmente como en este ejercicio o a travs de un Data Provider) y 2) grabar en la base de datos 3) revisar si hubo errores, y si no fue as, realizar explcitamente el commit, ya que no se hace automticamente (independientemente del valor que asuma la propiedad Commit on Exit de la transaccin). En caso contrario el Rollback.
29. Se tiene una aplicacin GeneXus web para un casino, que cuenta con transacciones para registrar los slots (Slot) y los tipos de slots (SlotType), segn se muestra. Cada vez que se ingresa un nuevo tipo de slot al sistema es porque ya se cuenta con un slot de ese tipo, que debe ingresarse inmediatamente, de manera tal que no quede un tipo de slot sin slot registrado (comparten la misma UTL). Indique, de las siguientes, la opcin correcta (de haber ms de una, la ms completa).

SlotType { SlotTypeId* SlotTypeDescription }

Slot { SlotId* SlotDescription SlotTypeId SlotTypeDescription }

a)- 1) Invocar desde la transaccin SlotType, antes del Commit, a la transaccin Slot pasndole el valor de SlotTypeId como parmetro. b)- 2) Invocar desde la transaccin SlotType, inmediatamente antes del Commit, a un procedimiento que ingrese el slot, pasndole el valor de SlotTypeId por parmetro. Se deshabilita el Commit on Exit del procedimiento. c)- 3) Crear un web panel con dos variables: una de tipo de datos el business component SlotType y otra de tipo de datos el business component Slot, insertndolas en el form y asociando a un botn de confirmacin un evento que realiza las dos grabaciones (Save) y que en caso de no detectarse errores manda a un proc hacer Commit. d)- 1) y 2) son correctas (y las nicas correctas). e)- 2) y 3) son correctas (y las nicas correctas). f) Ninguna de las anteriores es correcta

Respuesta: e) En el caso de la opcin 2), no necesita deshabilitar el commit del proc, siempre y cuando a la vuelta del mismo no se realice otra cosa que el commit automtico de la transaccin. Dos commits inmediatos sin ninguna operacin sobre la base de datos entre medio, tiene exactamente el mismo efecto que uno solo de esos commits, por lo que sera inocuo el doble commit. Estas no son las nicas soluciones posibles. De hecho no sera necesario implementar el web panel de la solucin 3) para dar de alta interactivamente la informacin. Podra aprovecharse la propia transaccin SlotType e insertarse en su form una variable BC Slot y luego del insert, hacer el Save. La opcin 1) de ninguna manera es correcta en interfaz web. Recurdese que con esta tecnologa, cada transaccin es un thread de ejecucin independiente.

30. Se tiene una aplicacin GeneXus web para un casino. Se desea disear un web panel que muestre en un grid Freestyle cada tcnico, con los slots que tiene asignados para reparar, y abajo la cantidad de esos slots. Determine la opcin de implementacin que considere correcta.

Technician { TechnicianId* TechnicianName }

Slot { SlotId* SlotDescription TechnicianId TechnicianName }

Freestyle Grid: Grid1 Grid: Grid2

a)

b)

c)

d)

e) Ninguna de las anteriores

Respuesta: c) Hay que tener presente que el caso de grids anidados es anlogo al de for eachs anidados. El orden de los eventos y la cantidad de veces que se disparan ser: Grid1.Refresh Grid1.Load Grid2.Refresh

Grid2.Load Grid2.Load hasta agotar todas las lneas del Grid2 para la del Grid 1 que se est cargando Grid1.Load Grid2.Refresh Grid2.Load Grid2.Load hasta agotar todas las lneas del Grid2 para la del Grid 1 que se est cargando hasta agotar todas las lneas del Grid1 Por tanto, si cada vez que se va a cargar una lnea de Grid1, es decir, un tcnico, se realiza el count( SlotId ), entonces para ese tcnico se contarn sus slots asociados (recurdese que las frmulas locales cuando tienen un contexto tabla de partida- cuentan los registros relacionados a ese contexto). Antes, cuando no existan las frmulas locales, habramos programado: Event Grid1.Refresh &SlotsQuantity.setEmpty() Endevent Event Grid2.Load &SlotsQuantity += 1 endevent

31. Se tiene una aplicacin GeneXus para un casino, que cuenta con una transaccin para registrar los tipos de slots (SlotType) y otra para registrar los slots (Slot). Se desea disear un web panel que permita seleccionar un tipo de slot y que a partir de all despliegue en un grid todos los slots existentes de ese tipo. Para ello alguien crea el web panel como se muestra. Determine de las opciones que siguen, la correcta.
SlotType { SlotTypeId* SlotTypeDescription } Slot { SlotId* SlotDescription SlotTypeId SlotTypeDescription }

a) El web panel funcionar correctamente, dado que por la presencia de los atributos SlotTypeId en las conditions y SlotId, SlotDescription en el evento Load GeneXus inferir que se le est pidiendo que encuentre una tabla base implcita, y sta resultar ser SLOT. Por haber tabla base implcita, no es necesario colocar comando Load dentro del evento Load, ya que el mismo se disparar una vez por slot de tipo de slot seleccionado. b) El web panel arrojar un error en la especificacin, dado que GeneXus entiende que por no haber atributos en el grid, ser sin tabla base, por lo que no tiene sentido que se quieran utilizar atributos en el evento Load, fuera de un comando For each. c) El web panel no arrojar un error, pero est mal programado, y no mostrar nada en el grid, dado que para GeneXus no hay tabla base implcita, por lo que faltara colocar un for each dentro del evento Load y luego un comando Load para cargar cada lnea en el grid. d) Ninguna de las anteriores

Respuesta: a) Si se entiende la lgica de GeneXus, no hay por qu memorizar, slo hay que razonar. Vemoslo con este ejemplo. Cul es nuestro punto de partida en un web panel con un grid? Bsicamente que querremos cargarlo con varias lneas de informacin extrada de algn lado. Qu es lo que GeneXus tiene capacidad de entender y ejecutar (en un a buen entendedor pocas palabras)? Que esa carga se corresponda con una tabla de la base de datos (y eventualmente su extendida). Es decir: a un grid, le corresponde una tabla. Si uno se pregunta si los atributos que aparezcan sueltos en los eventos (no dentro de un for each, o de una frmula local) influirn en que el grid tenga tabla base, la respuesta es evidente: s! De otro modo, qu sentido tendran esos atributos? Cul sera su contexto? De hecho, el que aparezcan all esos atributos, est ya proporcionando un contexto implcito a GeneXus (esas son las pocas palabras que le brindamos a este buen

entendedor). Lo mismo vale para los atributos que aparecen en las conditions, order o Data selector del grid. Si all aparecen atributos, es porque ya presuponemos un contexto en el que esos atributos se encuentran. Cul ser ese contexto? Ser la tabla base cuya extendida los abarque a todos. As nos entiende GeneXus. Si no le damos ningn contexto, entonces se declara incapaz de deducir nada, y all deja que nosotros explicitemos todo. Y ese es el caso de la carga de un grid sin tabla base. Por qu los atributos de la regla parm no son entendidos como contexto? Porque GeneXus nos da la libertad de poder programar muchos grids en un solo web panel (as como en un procedimiento nos permite incluir muchos for eachs). Si en 3 o 4 de esos grids necesitamos filtrar la info por el parmetro recibido, entonces nos brinda la facilidad de recibir en atributo, de manera de no tener que repetir el filtro en cada uno de esos grids. Pero de pronto algn otro grid no tiene nada que ver con ese parmetro recibido. Si el atributo recibido en la regla parm fuera considerado como parte del contexto de cada grid, entonces no podamos tener un grid que no tenga nada que ver con ese parmetro, lo cual no tiene ningn sentido. Cul es, por tanto, la informacin que corresponde a un grid particular y que determina, por tanto, su contexto? Sus columnas, las propiedades del grid (entre ellas estn las conditions, order, Data Selector), y los eventos relacionados (entre ellos el refresh y el load, que reflejan la carga del mismo, pero tambin los de usuario que trabajan sobre la informacin ya cargada). Con este anlisis, ser fcil contestarse si las conditions generales (las de la solapa Conditions del objeto Web Panel) influirn o no en la determinacin de la tabla base de un grid. La respuesta es no, por las mismas razones que en el caso de la regla parm.

32. Se tiene una aplicacin GeneXus para un casino, que cuenta con una transaccin para registrar los tipos de slots (SlotType) y otra para registrar los slots (Slot). Se desea disear un web panel que muestre todos los slots en un grid y debajo la cantidad de slots que son de los tipos 3, 5 y 7. Adems se desea que cuando el usuario seleccione una lnea del grid, se pueda invocar a otro web panel que muestre informacin del tipo de slot correspondiente. Para ello alguien crea el web panel como se muestra donde en el grid no se agrega ningn atributo no visible. Indique si lo siguiente es verdadero o falso: Se cargarn correctamente los slots y se mostrar correctamente la cantidad de slots de los tipos especificados, pero cuando el usuario elija una lnea del grid y presione View Type Info, el valor que se enviar al web panel invocado ser vaco.

SlotType { SlotTypeId* SlotTypeDescription }

Slot { SlotId* SlotDescription SlotTypeId SlotTypeDescription }

a) Se cargarn correctamente los slots y se mostrar correctamente la cantidad de slots de los tipos especificados, pero cuando el usuario elija una lnea del grid y presione View Type Info, el valor que se enviar al web panel invocado ser vaco. b) Se cargarn correctamente los slots, pero se mostrar incorrectamente la cantidad de slots de los tipos especificados (se mostrar 0) y adems cuando el usuario elija una lnea del grid y presione View Type Info, el valor que se enviar al web panel invocado ser vaco. c) Se cargar todo correctamente (slots y cantidad de slots de los tipos especificados) y cuando el usuario elija una lnea del grid y presione View Type Info, el valor que se enviar al web panel invocado ser el correspondiente.

Respuesta: a)

SlotTypeId en el evento Load se refiere al atributo del registro de la tabla SLOT de la base de datos que se est cargando en ese momento, por lo que no hay por qu ponerlo como oculto en el grid. Pero, en cambio, SlotTypeId en el evento de usuario no es el atributo de la base de datos, sino la columna del grid (que en nuestro caso no existe). Hay que transmitir a los alumnos que si bien nombramos siempre al atributo, en verdad slo en el contexto de la carga del grid realmente se trata del atributo de la base de datos, a la que estamos en ese momento accediendo. En cualquier otro caso, se trata del valor cargado en la columna del grid, no del atributo (all no se tiene ningn acceso a la base de datos).
33. Se tiene una aplicacin GeneXus para un casino, que cuenta con transacciones para registrar los slots (Slot), clientes (Customer) y reservas de slots (Reservation). Para mostrar todos los slots que tienen reservas para la fecha de hoy, junto con la cantidad de las mismas, se ha implementado el web panel que se muestra. Supongamos que solo los slots 15 y 20 tienen reservas para la fecha, y que para el primero hay 5 reservas y para el segundo 4. Determine la cantidad de veces que se disparar el evento Load del grid al ejecutar el web panel.

Slot { SlotId* SlotDescription }

Customer { Customerd* CustomerName }

Reservation { ReservationId* ReservationDate CustomerId CustomerName Slot { SlotId* SlotDescription } }

a) 9 veces b) 2 veces c) 11 veces d) Ninguna de las anteriores

Respuesta: d) Se disparar una sola vez Como sabemos, se trata de un grid sin tabla base, por lo que GeneXus no hace ninguna inferencia (no puede saber cuntas lneas han de cargarse en el grid) y la carga queda por entero en manos del programador. GeneXus nos ofrece el evento Load para all, en el momento (nico) en que se dispara, realizar manualmente toda la carga de las lneas que nos interesen. Por ello es fundamental en este caso colocar el comando Load, que es el que da la orden de cargar una nueva lnea en el grid, con el valor que asuman las variables (columnas del grid) en ese momento. As, si ponemos por error dos veces seguidas el comando Load, se repetir la lnea cargada.

34. Se tiene una aplicacin GeneXus para un casino, que cuenta con transacciones para registrar los slots (Slot), y sus tipos (SlotType) como se indica. Se desea implementar un web panel con dos grids paralelos, pero cuyas cargas estn relacionadas de la siguiente manera: en el primer grid se muestran los tipos de slots y en el segundo los slots, pero de manera tal que cuando el usuario selecciona un tipo de slot del grid1 (que tiene habilitada la seleccin, Allowselection), en el de los slots slo se muestran los de ese tipo. Determine de las siguientes, la implementacin correcta.
SlotType { SlotTypeId* SlotTypeDescription } Slot { SlotId* SlotDescription SlotTypeId SlotTypeDescription }

a) Como ambos grids tienen tabla base y estn relacionadas, GeneXus automticamente, una vez que el usuario elige una lnea del grid1, carga automticamente en el grid2 los slots relacionados.

Grid: Grid1

Grid: Grid2

b) Si bien ambos grids tienen tabla base y estn relacionadas, GeneXus no establece relacin al cargarlos, por lo que hay que implementarlo. Para ello alcanza con hacer lo que sigue y no es necesario que la variable &typeId est en pantalla.

c) La implementacin de la opcin b) sera correcta slo si se colocara la variable &typeId en pantalla (ocultndola con en el evento Start). d) Ninguna de las anteriores

Respuesta: b) dado que el valor de la variable se carga en el evento de usuario que produce el post y luego, cuando se va a cargar el grid2 (dentro de esa misma ejecucin del cdigo del web panel) se filtra utilizando la Condition. Es importante aqu reconocer el orden en que se ejecutan los eventos en el web panel, y sobre todo, tener presente que es en la misma ejecucin (en el mismo post) que se carga la variable y que se pregunta luego por su valor.