PIENSOPIENSO - Que objetos tienen variables N(16)?
Ruben me planteo un problema, sobre una tabla Viajes que tiene varios millones de registros.
Habia sentencias en la base de datos que andaban muy lentas porque hacian muchas lecturas y eran de la forma
SELECT ViajeID,ViajeDsc FROM Viajes WHERE ViajeID = &VAR
ViajeID es N(14) y es la clave primaria y tiene un índice único generado.
Si &VAR era N(14) todo funcionaba correctamente y muy rápido.
Si &VAR era N(16) la consulta andaba lentisimo por un problema de conversión de tipos (cast) de SQLServer 2000.
La KB tiene unos 5000 objetos y esta en GeneXus 9.0.
El problema es el siguiente:
Hacer una lista de todos los objetos que tengan definida alguna variable de tipo N(16) y usara la tabla Viajes.
Se pueden usar cualquier herramienta disponible o desarrollar alguna.
Hola Enrique!
ResponderBorrarYo he trabajado durante unos 2 años con SQL Server 2000 (ahora 2005). El problema que tu cuentas es lo que se llama Type Clash.
Esto ocurre cuando tienes un indice por cierto campo
Ej:
create table tabla1 (
campo1 numeric(16),
txt1 varchar(50)
)
create index ix_tabla1_campo1 on tabla1(campo1)
Si realizas una consulta con una variable definida como
declare @var1 numeric(10)
select * from tabla1 where campo1 = @var1
Aqui ocurre un type clash, y si la tabla es muy grande (pasando las 500.000 ya es considerable) te ocurre que la consulta es lentisima!
Porque ?
Porque si haces un Query Plan de la misma, vas a ver que no te agarra indice! Eso lo arreglas definiendo la variable con el tipo correcto de la tabla!
Ahora, no entendi bien la pregunta.. pero si quieres buscar variables definidas con ese tipo en Stored Procedure podes recurrir una tabla del sistema "syscomments"
y buscar por el campo "text" algo asi :
select * from syscomments where text like '%N(16)%
No se si te sirvió, cualquier cosa a las órdenes!
Saludos,
Andrés
Andruxuy:
ResponderBorrarGracias por el aporte.
El sintoma del problema que planteo es el que vos indicas y la causa es el Type Clash.
Lo que estoy buscando es alguna solucion para identificar cuales son los objetos Genexus que lo causan.
Yo tengo 3 soluciones diferentes, pero queria ver si algun lector del blog tenia alguna que fuera mas bonita que las mias.
Si en un par de dias no salta alguna solucion, voy a publicar las mias, pero confio que alguien pueda encontrar alguna mejor.
Existen varias formas posibles pero voy a comentarte la que pienso que es más viable
ResponderBorrarInspección de Código GeneXus
Puedes crearte en 2 etapas la selección de quienes son los posibles culpables de la siguiente forma.
1 - Corres una especificación con GXPublic y te quedas con el resultado de la Spec para luego parsearlo.
2 - Recorres todas las Spec en donde acceden en los Where al atributo que quieres buscar y luego te fijas con que atributo o variable acceden al mismo.
Luego comparas las definiciones de cada uno de ellos (Atributos y Variables mediante GXPublic)
Con eso realizas una comprobación fuerte del tipo de dato.
Hace unos años implementé una herramienta que hacía un trabajo similar (ni idea en donde tendré los fuentes), por lo que pienso que es 100% viable y te daría más información que el simple control de quienes son los que tienen un N16 asignando a un N14.
Lo bueno es que no generaría ninguna "intrusión" a la aplicación, lo podrías incorporar como un módulo más a KBDoctor. ;)
Saludos
David
David:
ResponderBorrarMuy buena solucion!.
En la practica buscaría una que no demorara tanto, pues el especificación de todo el modelo demora algunas horas, aunque en la practica ya lo tendría especificado.
En el KBTools ya tenemos un programa que mira las spec, para poder hacer un referencia cruzada entre tablas y objetos. Se podria modificar para hacer lo que vos planteas.
Gracias!
Enrique
La búsqueda de soluciones mas sencillas continua.....