Correccion de Sintanxis

[sierraja]

Buenos dias,

Estoy totalmente de acuerdo con guillotmarc, olvidemonos de delphi por el momento, cada vez que ejecuto un SP confirmo la transaccion y luego consulto, y no actualiza, ahora bien, he tratado de armar la consulta lo mas especificamente posible (corrigeme si es mala practica), para tratar de ir al registro especificamente y hacer el cambio respectivo y si lo ejecuta, pero, cuando intente en una de las pruebas hacerlo por lote de registro es ahi el problema que no lo hace. Inclusive he creado una tabla con menos de la cantidad de registro de la actual (380000), por decir, de los ultimos dos years y no ha funcionado.

He cambiado el nombre SP y coloque act_impuesto:

======================

Código SQL [-]
SET TERM ^ ;
CREATE PROCEDURE ACT_IMPUESTO (
    X_TIPO_TARIFA VARCHAR(30),
    X_TIPO_FACTURA VARCHAR(10),
    X_MES INTEGER,
    X_YEAR INTEGER)
AS
begin
  update facturacion
  set base_imponible = cloaca
  where tipo_tarifa=:x_tipo_tarifa and tipo_factura=:x_tipo_factura and extract(month from fecha)=:x_mes and extract(year from fecha)=:x_year;
end^
SET TERM ; ^
GRANT SELECT,UPDATE ON FACTURACION TO PROCEDURE ACT_IMPUESTO;
GRANT EXECUTE ON PROCEDURE ACT_IMPUESTO TO SYSDBA;

=========================
Como veran tambien he quitado el suspend; de la ultima linea de SP. Y no hace los cambios todavia. Segun recomienda Casimiro

Lo unico que no he hecho es hacer las pruebas en flamerobin. Y un detalle que no se si valga la pena, es que cuando ejecuto el SP lo hago desde el icono que me indica ibexpert que ejecuta el procedimiento o en su defecto F9

[Casimiro Noteví]

Pero lo ejecutas así:

execute procedure COMOSELLAME("Residencial","Consumo",1,2010)

No entiendo lo de ejecutar por lotes, no tienes más que ejecutar esa línea anterior, con el mes y año que quieras.

[sierraja]

Hola, claro! lo ejecuto como me indicas. Y cuando hablaba de por lotes, me referia a que utilizaba un grupo de registros mas peque#os pero sobre la misma tabla....

[Casimiro Noteví]

Es igual si tienes un registro o si tienes mil millones de registros, pero si haces esto:

update facturacion
set base_imponible = cloaca
where tipo_tarifa= :x_tipo_tarifa
and tipo_factura= :x_tipo_factura
and extract(month from fecha)= :x_mes
and extract(year from fecha)=:x_year;

estás asignando el valor que tenga el campo 'cloaca' al campo 'base_imponible', es IMPOSIBLE que no te actualice a tí, salvo que pongas unos parámetros que no existan registros con ese filtro.

Te has fijado en la imagen que puse antes, justo debajo del "execute procedure" verás que hay un select, si lo ejecutas verás los registros que te devuelve, todos esos registros son los que se actualizarán ejecutando el procedimiento almacenado.
Pruébalo y mira cuántos registros devuelve.

[guillotmarc]

Hola.

En un caso tan sencillo, yo no utilizaría ningún procedimiento almacenado, ejecutaría directamente la sentencia update :

  update facturacion
  set base_imponible = cloaca
  where tipo_tarifa=:x_tipo_tarifa and tipo_factura=:x_tipo_factura and extract(month from fecha)=:x_mes and extract(year from fecha)=:x_year;

Aunque realmente empezaría con un :

  update facturacion
  set base_imponible = cloaca

Y si esta consulta funciona correctamente (no se me ocurre como podría no funcionar bien), empezaría a agregar cláusulas SQL, una a una, hasta encontrar la que ocasiona el problema.

Siguiente prueba :

  update facturacion
  set base_imponible = cloaca
  where tipo_tarifa=:x_tipo_tarifa

Siguiente :

  update facturacion
  set base_imponible = cloaca
  where tipo_tarifa=:x_tipo_tarifa and tipo_factura=:x_tipo_factura

etc. ...

NOTA: entre prueba y prueba, hazte una copia del archivo de datos, para no machacar facturas que no debiera.

Una vez sepamos cual es la cláusula que no hace lo que se espera de ella, debería ser muy fácil solucionarlo. Y es que como dice Casimiro, el problema tiene que estar en la cláusula WHERE y los parámetros que se le pasan.

Saludos.

[sierraja]

Aunque realmente empezaría con un :


Código:
update facturacion set base_imponible = cloaca
Y si esta consulta funciona correctamente (no se me ocurre como podría no funcionar bien), empezaría a agregar cláusulas SQL, una a una, hasta encontrar la que ocasiona el problema.

Ok de hecho una de mis pruebas fue asi de sencilla y lo hizo muy bien, pero el problema consiste en que antes del year 2009 no se tenia impuesto en esas facturas y por lo tanto se debria colocar.

estás asignando el valor que tenga el campo 'cloaca' al campo 'base_imponible', es IMPOSIBLE que no te actualice a tí, salvo que pongas unos parámetros que no existan registros

Pensando en las lineas anteriores de lo IMPOSIBLE, revisé los campos de ese registro que no se actualiza y está dentro de las condiciones que se exigen.

Bueno de hecho lo que me queda realizar es un select con lsa condiciones y de seguro que salen los registros deseados y hacer la actualizacion a pie como se le dice en mi pais. No veo otra salida.

Hemos utilizado una simple instruccion a nivel del ibexpert sin necesidad de SP y tampoo los realiza pero con un select si aparecen pero sin los cambios.

[Casimiro Noteví]

Perdona que sea un poco bruto, pero: NO ME LO PUEDO CREER
Ten en cuenta que estamos hablando de algo muy básico.

[sierraja]

Es tan sencillo esta instruccion que no se cree, pero tengo varios meses y cuando digo varios meses, es en serio, (son varios meses ) he realizado bastantes pruebas buscando una justificacion para esto y no la encuentro, pero debe ser algun contenido que no entra en el filtro, tal y cual como lo dice el amigo Casimiro. Solo me falta eliminar dicho registro y volverlo a crear (no se si teine sentido o no ). Tambien aclaro que la inclusion de los nuevos meses ya viene con los datos de base imponible y excento con su justo valor.

[Casimiro Noteví]

Veamos, amigo, esto es fácil, ejecuta este select:

select count(*)
from facturacion
where tipo_tarifa= "Residencial"
and tipo_factura= "Consumo"
and extract(month from fecha)= 1   
and extract(year from fecha)= 2010

¿Cuntos registros dice que devuelve?.


Pues toda esa cantidad de registros son los que se modificarán si ejecutas el procedimiento almacenado con los mismos valores:

execute procedure COMOSELLAME("Residencial","Consumo",1,2010)

Si en el select te dijo que '0' (cero), quiere decir que el select no trae nada con esos parámetros, así que tendrás que probar quitando parámetros, ejemplo, para empezar, quita el año:

select count(*)
from facturacion
where tipo_tarifa= "Residencial"
and tipo_factura= "Consumo"
and extract(month from fecha)= 1

Si te dice que 0 (cero), entonces quita el mes:

select count(*)
from facturacion
where tipo_tarifa= "Residencial"
and tipo_factura= "Consumo"

Si te dice que 0 (cero), entonces quita tipo_factura:

select count(*)
from facturacion
where tipo_tarifa= "Residencial"

Si te dice que 0 (cero), entonces quita tipo_tarifa:

select count(*)
from facturacion

Si te dice que 0 (cero), entonces es que !!!no tienes ningún registro!!!

Haz estas pruebas y nos cuentas, pero tal y como te lo he puesto, ok?

[guillotmarc]

Empezado por sierraja

Ok de hecho una de mis pruebas fue asi de sencilla y lo hizo muy bien, pero el problema consiste en que antes del year 2009 no se tenia impuesto en esas facturas y por lo tanto se deberia colocar.

El truco está en meter las condiciones del WHERE (como la del año 2009), una a una, así llegas a saber sin la menor duda cual es la cláusula que ocasiona el conflicto, y con ello es muchísimo más fácil de solucionar.

Aunque Casimiro tiene toda la razón en que va a ser mucho más rápido detectar el conflicto dentro de la cláusula WHERE utilizando sentencias SELECT y no UPDATES.

Saludos.

[sierraja]

Buen dia a todos, efectivamente a medida que vamos cerrando las condiciones del WHERE vamos determinando cual de los filtros tiene el problema (estoy utilizando select en vez de update). En las diferentes pruebas me he dado cuenta que los registros con tarifas "Especial" salen en el select pero no se actualizan en el update, la prueba estuvo centrada en el year 2009 mes diciembre y tarifa "Especial". Tambien les informo, que por casualidad el registro que siempre verificaba es el de tarifa "Especial" y es el que no entra en el filtro. Ahora bien, el contenido del registro cumple con lsa condiciones del filtro, pero no hace caso al mismo. Inclusive lo he eliminado y vuelto a crear pero persiste.

[Casimiro Noteví]

Vas a tener que pasarnos la base de datos