FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#21
|
||||
|
||||
Esta es la instruccion que ejecuto directamente desde delphi:
|
#22
|
||||
|
||||
jajaja... ahora un método nuevo, con este ya van 3 formas distintas.
|
#23
|
||||
|
||||
Mas informacion:
.- Utilizo Firebird 1.5 sobre un servidor Linux Ubuntu 8.04. .- Las estaciones de trabajo esta corriendo sobre win xp .- EL programa esta hecho en delphi 7 con todos los componentes basicos (no tercertos). .- Utilizo los components IBX para que trae delphi 7 para accesar la data. Gracias. |
#24
|
||||
|
||||
ja ja ja Pido disculpas por no saber expresarme mejor, pero creeme lo intento. ja ja ja
|
#25
|
||||
|
||||
Es que en cada uno de las 3 formas... no nos has dado toda la información.
De todas formas lo de emplear "Consumo", "Residencial", etc. es una muy mala idea porque influyen varios factores que pueden hacer que no funcione, si pones "consumo", por ejemplo, ya no funcionará, tampoco funcionará dependiendo del tipo de dato usado en crear el campo, que tampoco nos has puesto la estructura de la tabla. Por ejemplo, si usas un campo de cadena fija, digamos que un char(20) y almacenas el valor "Consumo" que tiene 7 caracteres, realmente no se está almacenando "Consumo" sino "Consumo ", así que cuando vas a hacer el filtro por ese campo, nunca te funcionará. Si usas varchar(20) no habrá problema porque él sólo quita los espacios... o no, depende de la versión de firebird/interbase que uses, porque en las versiones antiguas, la firebird 1.0 todavía no tenía solucionado el fallo de que los varchar se guardaban también con los espacios. Estos son simples ejemplos de por lo qu einsistimos mucho que necesitamos mucha más información, lo más completa posible, para poder ayudar. |
#26
|
||||
|
||||
Wow, cada vez uno aprende mas:
En la captura de datos se valida la entrada de los mismo, es decir, cuando defines el tipo de factura se validan: "Consumo" y/o "Servicios" Cualquiera de los dos, el usuario no lo escribe, solo lo selecciona. En lo que respecta a tipo de tarifa, igualemente valido que sea: "Residencial" o "Especial" o "Comercial" o "Industrial A" y "Industrial B". Igualmente como el anterior, el usuario no lo escribe, y solo lo selecciona. De esta manera estan almacenados en la base de datos. El tipo de datos en la base de datos para los dos campos es Varchar(10) y varchar (30) respectivamente. El sistema consiste en un sistema de facturacion del servicio de agua potable y tiene tres years funcionando, pero cada dia se le han agregado cosas nuevas. Desde el year pasado se le agrego los impuestos cuyo desgloce consiste en base imponible y cantidad excenta, eso es lo que estamos tratando de arreglar. Este es una peque#a explicacion de lo que hace el sistema. he realizado varias pruebas que no han resultado y solo he tenido ese problema con ella, he realizado varias pruebas con los ultimos cuatro meses y no he tenido exito. Tambien he realizado chequeos de otras transacciones de consulta que se activen fantasmalmente y no he encontrado nada. He filtrado la data con pocos registro y tampoco he tenido exito. Hast el momento se tiene 380000 registro en la tabla de facturacion que estamos manejando. Si quieren mas informacion hasta les puedo enviar la misma base de datos, para que realicen sus prueba. |
#27
|
||||
|
||||
Cita:
Centrémonos en un método determinado, ¿te parece bien el procedimiento almacenado?, creo que es la mejor opción. Pon aquí el código completo del mismo y haremos una prueba desde el ibexpert. Además pon aquí el código completo de la estructura de la tabla, ok? |
#28
|
||||
|
||||
EL SP, me parece buenisimo:
Código SQL [-] SET TERM ^ ; CREATE PROCEDURE "UPDATE" ( 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; update facturacion set excento = consumo_agua 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; suspend; end^ SET TERM ; ^ GRANT SELECT,UPDATE ON FACTURACION TO PROCEDURE "UPDATE"; GRANT EXECUTE ON PROCEDURE "UPDATE" TO SYSDBA; ======================== Código:
/******************************************************************************/ /**** Generated by IBExpert 26/04/2010 07:19:48 p.m. ****/ /******************************************************************************/ SET SQL DIALECT 3; SET NAMES NONE; /******************************************************************************/ /**** Tables ****/ /******************************************************************************/ CREATE TABLE FACTURACION ( ID_SUSCRIPTOR VARCHAR(30), STATUS_FACTURA VARCHAR(15), RUTA INTEGER, NUMERO_FACTURA INTEGER, NUMERO_FACTURA_A VARCHAR(30), NUMERO_FACTURA_IMPRESA INTEGER, CODIGO_SUSCRIPTOR INTEGER, CODIGO_SUSCRIPTOR_A VARCHAR(30), LECTURA_ANTERIOR INTEGER, LECTURA_ACTUAL INTEGER, CONSUMO NUMERIC(15,2), FECHA_INICIO DATE, FECHA_INICIO_A VARCHAR(20), FECHA_FIN DATE, FECHA_FIN_A VARCHAR(20), FECHA_FACTURACION DATE, FECHA_FACTURACION_A VARCHAR(20), FECHA_VENCIMIENTO DATE, FECHA_VENCIMIENTO_A VARCHAR(20), MONTO_TARIFA NUMERIC(15,2), MONTO_TARIFA_EXCESO NUMERIC(15,2), ALICUOTA_IVA NUMERIC(15,2), CARGO_FIJO NUMERIC(15,2), CARGO_VARIABLE NUMERIC(15,2), CARGO_EXCESO_CONSUMO NUMERIC(15,2), CONSUMO_AGUA NUMERIC(15,2), CLOACA NUMERIC(15,2), PORCENTAJE_CLOACA NUMERIC(15,2), MONTO_CONCEPTO NUMERIC(15,2), MONTO_FACTURADO NUMERIC(15,2), MONTO_IVA NUMERIC(15,2), DEUDA_ANTERIOR NUMERIC(15,2), TIPO_TARIFA VARCHAR(30), ESTADO VARCHAR(20), AVISO_CORTE VARCHAR(2), FECHA_PAGO_FACTURA DATE, FECHA_PAGO_FACTURA_A VARCHAR(20), FORMA_PAGO VARCHAR(20), PORCENTAJE_DESCUENTO NUMERIC(15,2), MONTO_DESCUENTO NUMERIC(15,2), DESCUENTO_AUTORIZADO VARCHAR(30), NUMERO_CHEQUE VARCHAR(30), CUENTA_CHEQUE VARCHAR(30), NOMBRE_BANCO VARCHAR(30), USUARIO VARCHAR(10), FECHA DATE, FECHA_A VARCHAR(10), PRECIO_UNITARIO NUMERIC(15,2), SUB_TOTAL NUMERIC(15,2), CONTADOR INTEGER, LITERAL_EXCENTO VARCHAR(10), MONTO_PAGADO NUMERIC(15,2), VUELTO NUMERIC(15,2), NUMERO_TARJETA VARCHAR(30), TIPO_TARJETA_CREDITO VARCHAR(30), NOMBRE_BANCO_TARJETA VARCHAR(30), TIPO_FACTURA VARCHAR(10), RECIBO VARCHAR(2), PRECIO NUMERIC(15,2), BASE_IMPONIBLE NUMERIC(15,2), FACTURAR_LOTE VARCHAR(10), CODIGO_STATE_ACCOUNT VARCHAR(10), EXCENTO NUMERIC(15,2), STATUS_TARIFA VARCHAR(20), CAMPO1 VARCHAR(50), CAMPO2 VARCHAR(100), STATUS_2 VARCHAR(30), STATUS_3 VARCHAR(30), STATUS VARCHAR(30), CODIGO_LECTURA INTEGER, PENDIENTES INTEGER ); /******************************************************************************/ /**** Indices ****/ /******************************************************************************/ CREATE INDEX FACTURACION_CODIGO_CLIENTE ON FACTURACION (CODIGO_SUSCRIPTOR); CREATE INDEX FACTURACION_IDX1 ON FACTURACION (DEUDA_ANTERIOR); /* Fields descriptions */ DESCRIBE FIELD STATUS_FACTURA TABLE FACTURACION 'Si indica "Si" es que esta facturado'; DESCRIBE FIELD FECHA_INICIO TABLE FACTURACION ' fecha inicio de periodo a facturar'; DESCRIBE FIELD FECHA_FIN TABLE FACTURACION ' fecha fin de periodo a facturar'; DESCRIBE FIELD CARGO_FIJO TABLE FACTURACION ' cargo fijo para la tarifa comercial'; DESCRIBE FIELD CARGO_VARIABLE TABLE FACTURACION 'cargo variable tarifa comercial'; DESCRIBE FIELD CARGO_EXCESO_CONSUMO TABLE FACTURACION ' cargo consumo tarifa comercial'; DESCRIBE FIELD CONSUMO_AGUA TABLE FACTURACION ' consumo mas tarifa mensual'; DESCRIBE FIELD MONTO_CONCEPTO TABLE FACTURACION ' monto por concepto debito o credito de la facturacion mensual'; DESCRIBE FIELD MONTO_FACTURADO TABLE FACTURACION ' monto facturado es la suma de agua,cloaca, exceso, cargo fijo, debido o credito'; DESCRIBE FIELD ESTADO TABLE FACTURACION 'status operacional= 1 activo, 2 cortado, 3 suspendido'; DESCRIBE FIELD AVISO_CORTE TABLE FACTURACION 'Verdadero si y falso no'; /******************************************************************************/ /**** Privileges ****/ /******************************************************************************/ |
#29
|
||||
|
||||
perdon siempre se me salta este error:
Este es el procedimiento. Lo acabo de crear. |
#30
|
||||
|
||||
¿La tabla no tiene clave primaria?
|
#31
|
||||
|
||||
Hasta ahora no!, pero si ha de tenerla seria el codigo_suscriptor+fecha. La tabla contiene una factura mensual por cada suscriptor, es decir, un mismo codigo_suscriptor va a tener doce registros por year y no su pueden repetir un mismo suscriptor tenga dos registros en el mismo mes. No se si me entiendes.
|
#32
|
||||
|
||||
Pues sí, es necesario que tenga su clave primaria.
Bueno, mira he creado la tabla a la que le he añadido una clave primaria: Código:
CREATE TABLE FACTURACION( ID Integer NOT NULL, <-- tú le pones la clave que te venga mejor ID_SUSCRIPTOR Varchar(30), STATUS_FACTURA Varchar(15), RUTA Integer, NUMERO_FACTURA Integer, NUMERO_FACTURA_A Varchar(30), NUMERO_FACTURA_IMPRESA Integer, etc... ... Código:
CREATE PROCEDURE ACTUALIZAR ( 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; etc... /* por cierto, el "suspend" aquí no sirve para nada */ end Código:
execute procedure ACTUALIZAR("Residencial","Consumo",1,2010) Y el resultado es, como se supone, correcto: |
#33
|
||||
|
||||
Perfecto.
Cita:
Cita:
Olvídate de Delphi por ahora, y céntrate en el caso más simple posible, en hacerlo funcionar como consulta en IB-Expert. Una vez te funcione la consulta, ya lo puedes empaquetar en el procedimiento almacenado y probarlo, para finalmente ejecutarlo en Delphi. Así pues volvamos a las transacciones en IB-Expert. La única forma en que eso te va a funcionar es que cuando lances el Update, confirmes la transacción. Una vez confirmada la transacción del Update, ya puedes abrir una consulta nueva, con una transacción nueva, para comprobar si se han modificado los registros. Si no sigues estos pasos (si no confirmas la transacción de modificación o si no abres la transacción de consulta después de haber confirmado la de modificación), no podrás ver los datos modificados. Asegúrate de descartar que no tengas el problema simplemente por un mal uso de las transacciones, y una vez descartemos esa posibilidad podremos investigar otras causas. NOTA: Si el problema no es la transacción, yo te recomiendo simplificar la consulta al máximo, hasta tener una consulta mínima que funcione (aunque evidentemente no hará todo lo que necesitas). Y una vez tengas como partida una consulta funcionando, que modifica correctamente datos, entonces le vas agregando poco a poco cláusulas SQL en el WHERE, probando su comportamiento a cada modificación, para identificar cual es la que hace que no funcione como tu esperas. Saludos.
__________________
Marc Guillot (Hi ha 10 tipus de persones, els que saben binari i els que no). |
#34
|
||||
|
||||
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: ======================
========================= 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 |
#35
|
||||
|
||||
Pero lo ejecutas así:
Código:
execute procedure COMOSELLAME("Residencial","Consumo",1,2010) |
#36
|
||||
|
||||
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....
|
#37
|
||||
|
||||
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.
__________________
La otra guía de estilo | Búsquedas avanzadas | Etiquetas para código Únete al grupo Teaming clubdelphi | Colabora mediante Paypal Última edición por Casimiro Notevi fecha: 27-04-2010 a las 19:44:09. Razón: error ortográfico |
#38
|
||||
|
||||
Hola.
En un caso tan sencillo, yo no utilizaría ningún procedimiento almacenado, ejecutaría directamente la sentencia update : Código:
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; Código:
update facturacion set base_imponible = cloaca Siguiente prueba : Código:
update facturacion set base_imponible = cloaca where tipo_tarifa=:x_tipo_tarifa Código:
update facturacion set base_imponible = cloaca where tipo_tarifa=:x_tipo_tarifa and tipo_factura=:x_tipo_factura 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.
__________________
Marc Guillot (Hi ha 10 tipus de persones, els que saben binari i els que no). Última edición por guillotmarc fecha: 27-04-2010 a las 19:24:20. |
#39
|
||||
|
||||
Cita:
Cita:
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. |
#40
|
||||
|
||||
Perdona que sea un poco bruto, pero: NO ME LO PUEDO CREER
Ten en cuenta que estamos hablando de algo muy básico. |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Correccion de Sintaxis | sierraja | Firebird e Interbase | 9 | 28-10-2008 23:34:14 |
Correccion ortografica | Iskariote0087 | Varios | 4 | 23-02-2008 10:42:09 |
Una pequeña corrección | Faust | Varios | 1 | 07-07-2006 07:10:39 |
|