Ya algunas veces he hablado sobre el spam que recibo en mis cuentas de correo, que si compras tal o cual cosa, que me dejaron tantos millones de herencia, que si hay que salvar a no se cuantos niños con cancer, que si te crece tantos centímetros, que si me vendes a Nigeria, y quien sabe cuantas cosas mas, en fin, una plaga que no se acabará si no hasta que deje de servir, hasta que la gente que los recibe deje de dar clic, deje de comprar a esas empresas.

Pero hoy voy a hablar de otra modalidad de spam, que llamare “spam telefónico”, ese spam que recibes en tu casa proveniente de una persona vendiendo algo, ofreciendo algún servicio o en el peor de los casos tratando de estafarte, esto viene a colación de una noticia que escuche hace algunos días y después encontré en internet:

Durante la primera semana de operaciones del Registro Público de Consumidores (RPC) han sido inscritos un total de 18 mil 700 números de teléfonos fijos y celulares de todo el país, por personas que no quieren recibir publicidad de los sectores comercial, turístico y de telecomunicaciones.

Noticia completa

Seguramente algunas personas no le encuentran el pero al asunto, pero otras con un poquito de atención se darán cuenta que: ¿Por que demonios debo de registrarme para NO RECIBIR algo que NO SOLICITE?, se dan cuenta, es la misma cuestión que el spam, me envían un correo a mi cuenta que no solicite, y siguiendo el mismo circulo vicioso del spam, aparte me tengo que registrar para no seguir recibiendo spam, muchos sabrán que los links en el spam que supuestamente sirven para dejar de recibir correos en realidad no son mas que la vía de los spameros para confirmar que la cuenta existe y esta activa, y no contentos, no puedo decir dejen de joder y no quiero nunca su basura, nooo, tengo que “renovar mi inscripción” cada tres años, seguramente en tres años ya pudiera si querer que me hablen para venderme algo.

Lo lógico ideal no era al contrario? Esta prohibido llamar a la gente para ofrecerle algo sin que él expresamente lo haya solicitado, o sea, crear el sistemita que dicen para que la gente que quiera recibir publicidad se de de alta?, el mismo ideal que si se siguiera no existiría el spam?

Pero no, sabemos que en México los ideales y la lógica son parte de los muchos conceptos que van quedando en el olvido, dejando paso a la avaricia y al lo que sea por dinero, y es que si no le encontraban por donde estaba el gato encerrado, igual no acabaron de leer la nota:

El registro está disponible también para proveedores y empresas de telemercadeo que hayan presentado una solicitud de consulta, pero deberán pagar 66.3 mil pesos por la consulta anual o bien de 35.3 mil pesos por la semestral de todos los números del RPC inscritos en todo el país. Si desean consultar la base de datos de un solo estado los precios varían

Ya se me hacia raro un poquito (muy poquito) de ayuda a los consumidores de parte de la profeco, realmente la idea es ganarle un billetito al asunto y aparte no contentos será de forma anual o semestral y es que para los que no sepan, una base de datos de clientes como las que también venden los bancos valen un buen billetito, y entre mas datos que puedan identificar mejor al cliente como la de un banco más, entonces ahora las empresas formales que se dedican al marketing telefónico se tendrán que comprar su base de datos para trabajar, la única diferencia será que ya sabrán quien es mas renuente a las compras por teléfono.

Y al final, como muchas otras cosas, la cosa solo quedará en los buenos deseos (buenos deseos de nosotros los consumidores) por que las llamadas queriendo vender algo van a seguir, provenientes ahora de números privados, o de números de telefonía IP o los mas osados de los mismos números que actualmente usan, por que, por el otro lado, que va a pasar cuando quieras denunciar a alguna de esas empresas? Ahí va a estar la profeco para que pierdas tu tiempo y de tapadera de las empresas como actualmente lo es.

Desde hace algunos años recuerdo haber oído comentarios de que la gasolina subía cada mes unos centavos, que era un política de PEMEX y no se que, recuerdo todavía no hace mucho los precios del petróleo que estaban en lo que llamaría precios normales, por ahí de los 60-80 USD.

Fue hace unos meses que recuerdo los precios del petróleo empezaron a subir y subir, recuerdo haber escuchado que el precio del barril ya andaba por los 100 o 110 USD mas o menos.

Uno pensaría en ese momento, que padre, producimos mucho petróleo entonces la gasolina va a bajar de precio, jejejejeje, ilusos, inocentes de nosotros que todavía nos guiamos por la lógica de la gente común y corriente y no por la lógica política.

Aprovechando esos altos precios del petróleo salían nuestros buenazos políticos a anunciar un aumento en el precio de la gasolina, esto decían por allá a principios de agosto:

La secretaria de Energía, Georgina Kessel, advirtió que continuarán los ajustes mensuales a los precios de las gasolinas y otros combustibles debido a los altos costos de los energéticos a nivel internacional.

Noticia completa

Que mala onda se decía uno, uno pensando que resulta venéfico y cual?, nos afecta que suba el petróleo, y pues no hay de otra, o le hechas gasolina a tu coche o no sales con el, simple y llanamente.

Después de eso el precio del petróleo empezaba a bajar, pero nuevamente salían nuestros políticos a anunciar que la gasolina seguiría subiendo, y ahora porque? A pues para “equiparar” los precios con los precios de la gasolina en otros países, esto decían por ahí de septiembre:

El secretario de Hacienda, Agustín Carstens, admitió que los precios de las gasolinas tendrán diversas alzas “reducidas” semanalmente en los próximo meses a fin de que los precios “vayan convergiendo poco a poco” con los costos de las gasolinas internacionales.

Noticia completa

Por estos días los precios del petróleo han caído por ahí de los 50 USD, uno ahora dice, bueno pues ya bajo de 100 USD a 50 USD pues ahora si va a bajar la gasolina no? Jejejeje nuevamente, les acabo de decir, nuestra lógica es muy muy diferente a la de los políticos, al contrarío de bajar, van a seguir subiendo, pero y ahora por que? A pues ahora es para “reducir el subsidio” que actualmente tiene la gasolina:

Según la última declaración del titular de la Secretaría de Hacienda y Crédito Público, Arturo Carstens, es que el precio de la gasolina Magna se venderá en nueve pesos el litro antes de que concluya el año lo cuál impacta de manera considerable a los empresarios gasolineros pues éste es el combustible que más se consume.

Castrens también señaló que el subsidio seguirá existiendo aunque con una reducción lo cual es positivo ya que su supresión representaría un problema para la economía debido a que se elevaría la inflación y la gasolina ya no se pagaría a ocho 50 o nueve pesos sino que alcanzaría un costo de hasta 11 pesos por litro, refirió García Castañeda.

Noticia completa

En conclusión, si esta caro el petróleo, sube la gasolina, si esta barato sube la gasolina, que si los costos, que si los precios de otros países, que si el subsidio, o sea, vale pa madres que seamos un país productor de petróleo (por ahí escuchaba que somos el 6 país productor mundialmente), que si esta caro la subimos por que nos cuesta mas, que si en otros países la venden mas cara a pues nosotros también, que si esta barato a pues se tiene que eliminar el subsidio, o sea, de todas maneras tomen sus aumentos.

Lo peor de todo saben que va a ser? Que cuando ya tengamos precios “equiparables” a otros países, que cuando ya no exista un subsidio a las gasolinas, que cuando ya no exista un elevado precio del petróleo, o los pretextos que se acumulen en los próximos meses, van a seguir subiendo los precios de la gasolina, pretextos van a sobrar, y a nosotros otra vez no nos va a quedar de otra que bajarnos los pantalones y empinarnos.

En mi actual proyecto se necesitaba leer la información contenida en un campo de tipo BLOB, que no era más que a fin de cuentas una cadena XML pero guardada en un campo de la base de datos.

Conocía poco del tema pero San Google hace milagros y me tope fácilmente con el paquete DBMS_LOB, dentro de él existe la función SUBSTR que al igual que substr aplicado a una cadena normal regresa una porción de ella definida por los dos siguientes parámetros, aunque varia un poco su uso. (No hablare a detalle del uso del paquete en este post).

Pero resulta que al utilizar esta función el resultado no es el esperado:

1
2
3
4
5
6
7

SQL> SELECT DBMS_LOB.SUBSTR(campo_blob, 100, 1) campo_blob
  2    FROM tabla_con_campo_blob
  3   WHERE identificador = 1;
 
CAMPO_BLOB
--------------------------------------------------
3C3F786D6C2076657273696F6E3D22312E302220656E636F64

Lo que pasa es que la función dbms_lob.substr regresa una cadena de tipo RAW (tampoco hablare mucho al respecto) otra vez pidiendo ayuda a san google me tope con un paquete para convertir mi cadena raw a una cadena legible tipo varchar2, solo la adapte un poquito a lo que necesitaba, acá se las dejo:

1
2
3
4
5
6
7
8
9

CREATE OR REPLACE PACKAGE rawtochar IS
 
  FUNCTION hextonum(v_hex VARCHAR2) 
    RETURN NUMBER;
 
  FUNCTION rawtochar(p_raw_data VARCHAR2) 
    RETURN VARCHAR2;
 
END;

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72

CREATE OR REPLACE PACKAGE BODY rawtochar IS
 
  FUNCTION hextonum(v_hex VARCHAR2) 
   RETURN NUMBER IS 
 
    hex          VARCHAR2(4);
    num          NUMBER;
    num1         NUMBER;
    num2         NUMBER;
 
  BEGIN
 
    hex := SUBSTRB(v_hex,1,1);
 
    IF ( hex >= '0' AND hex < = '9' ) THEN 
      num1  := TO_NUMBER(hex);
    END IF; 
    IF hex = 'A' THEN num1 := 10; END IF; 
    IF hex = 'B' THEN num1 := 11; END IF; 
    IF hex = 'C' THEN num1 := 12; END IF; 
    IF hex = 'D' THEN num1 := 13; END IF; 
    IF hex = 'E' THEN num1 := 14; END IF; 
    IF hex = 'F' THEN num1 := 15; END IF; 
 
    hex := SUBSTRB(v_hex,2,1);
 
    IF ( hex >= '0' AND hex < = '9' ) THEN 
      num2  := TO_NUMBER(hex);
    END IF; 
    IF hex = 'A' THEN num2 := 10; END IF; 
    IF hex = 'B' THEN num2 := 11; END IF; 
    IF hex = 'C' THEN num2 := 12; END IF; 
    IF hex = 'D' THEN num2 := 13; END IF; 
    IF hex = 'E' THEN num2 := 14; END IF; 
    IF hex = 'F' THEN num2 := 15; END IF; 
 
    num := (num1*16)+num2;
 
    RETURN num;
 
  END;
 
  FUNCTION rawtochar(p_raw_data  VARCHAR2) 
   RETURN VARCHAR2 IS
 
    raw_data          LONG RAW;
    rawlen            NUMBER;
    hex_data          VARCHAR2(32760);
    char_data         VARCHAR2(32760);
    loop_counter      NUMBER;
 
  BEGIN
 
    raw_data := p_raw_data;
 
    -- Convert the raw data to hex.    
    hex_data := RAWTOHEX(raw_data);
    rawlen := LENGTH(hex_data);
 
    loop_counter := 1;
 
    -- Loop through and convert the hex to characters.
    WHILE loop_counter <= rawlen LOOP
        char_data := char_data || CHR(HEXTONUM(SUBSTRB(hex_data,loop_counter,2)));
        loop_counter := loop_counter + 2;
    END LOOP;
 
    RETURN char_data;
 
  END;
 
END;

Listo, ahora solo le aplico esta función y ya veo información más acorde:

1
2
3
4
5
6
7
8

SQL> SELECT rawtochar.rawtochar(DBMS_LOB.SUBSTR(campo_blob, 100, 1)) campo_xml
  2    FROM tabla_con_campo_blob
  3   WHERE identificador = 1;
 
CAMPO_XML
--------------------------------------------------------------------------------
< ?xml version="1.0" encoding="UTF-8"?>
< !DOCTYPE workflow PUBLIC "-//...

Para los que acabaron de leer el post y llegaron hasta acá, como moraleja déjenme decirles que no se vallan con la primera solución que encuentren, siempre habrá mejores maneras de hacer las cosas, algo que ya sabia pero que en esta ocasión por las prisas no considere, resulta que después de solucionado el problema me quede con la espinita, realmente no habrá pensado oracle en este problema ya?, la lógica me decía que seguramente si, y que creen? Así era, ya existe la manera de convertir un raw a varchar2 por lo que la función rawtochar no era necesaria:

1
2
3
4
5
6
7
8

SQL> SELECT UTL_RAW.cast_to_varchar2(DBMS_LOB.SUBSTR(campo_blob, 100, 1)) campo_xml
  2    FROM tabla_con_campo_blob
  3   WHERE identificador = 1;
 
CAMPO_XML
--------------------------------------------------------------------------------------
< ?xml version="1.0" encoding="UTF-8"?>
< !DOCTYPE workflow PUBLIC "-//...

El como realizar un autoincremental en oracle del que platique en mi post anterior surgió más bien de la necesidad de obtener ese mismo número al realizar un “insert” a la tabla, pero aproveche para hablar específicamente de el sin mezclar temas.

Ya platicaba en ese post de que al hacer el insert ya no es necesario especificar el campo del identificador por que el trigger lo generaría automáticamente, pero entonces ahora surge el problema, que pasa si en realidad se necesita durante el proceso conocer ese número ya que, por ejemplo, se trata de una tabla “maestro” y después se inserta en otra tabla “detalle” otra información incluyendo ese identificador único.

Mi respuesta hasta ayer hubiera sido realizar otro “select” a la tabla obteniendo el ultimo identificador generado, o de menos, que el mismo proceso realice la misma acción del trigger para obtener el identificador, ninguna de las dos es muy limpia solución que digamos, pero no se me ocurría otra manera de hacerlo hasta hoy.

El día de hoy me comentaban de una nueva funcionalidad, al menos para mi (no se exactamente en que versión de Oracle fue introducida) que te permite obtener el valor de los campos de una tabla después de un DML (insert, delete, update) sin necesidad de generar otra consulta.

Para este ejemplo utilizare la tabla “employees” que generé en el post anterior por lo que regresen al post anterior antes de comenzar a probar, considerando que ya se tiene esa tabla creada, con su llave primaria y su trigger “emulador” de autoincremental veamos el ejemplo del returning.

En este ejemplo se utilizo un “type” aunque en el segundo ejemplo se ve que no es necesario, todo depende de la necesidad en especifico, al realizar el insert junto con la cláusula “returning into” se obtiene el valor que se genero para el identificador sin necesidad de otra cosa:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

SQL> DECLARE
  2  
  3     TYPE EmpRec IS RECORD (employee_id   employees.employee_id%TYPE);
  4  
  5     emp_info EmpRec;
  6  
  7  BEGIN
  8  
  9     INSERT INTO employees VALUES (NULL,'otro mas','otro',6000)
 10        RETURNING employee_id INTO emp_info;
 11  
 12     DBMS_OUTPUT.PUT_LINE('Se inserto nuevo registro con id ' || emp_info.employee_id);
 13  
 14  
 15  END;
 16  /
Se inserto nuevo registro con id 1
 
PL/SQL PROCEDURE successfully completed.

Este ejemplo es utilizando directamente el “%type”:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

SQL> DECLARE
  2  
  3     emp_info employees.employee_id%TYPE;
  4  
  5  BEGIN
  6  
  7     INSERT INTO employees VALUES (NULL,'otro mas','otro',6000)
  8        RETURNING employee_id INTO emp_info;
  9  
 10     DBMS_OUTPUT.PUT_LINE('Se inserto nuevo registro con id ' || emp_info);
 11  
 12  
 13  END;
 14  /
Se inserto nuevo registro con id 2
 
PL/SQL PROCEDURE successfully completed.

Y solo para probar que todo funcionó correctamente:

1
2
3
4
5
6

SQL> SELECT * FROM employees;
 
EMPLOYEE_ID FIRTS_NAME           LAST_NAME                SALARY
----------- -------------------- -------------------- ----------
          1 otro mas             otro                       6000
          2 otro mas             otro                       6000

Hace algún tiempo me preguntaban que como se realizaba un autoincremental en Oracle, para lo que saben poco, no es más que un atributo que se utiliza para generar un identificador único para cada nueva fila de una tabla, yo se que existe en Mysql simplemente especificando “AUTO_INCREMENT” en el campo al crear la tabla, generalmente en su llave primaria.

Mi respuesta fue, que hasta donde yo se, no existe este atributo en Oracle, aunque con un pequeño trigger se puede “emular” fácilmente la lógica de este atributo en oracle, pero veamos como, claro con un ejemplo sencillo para los menos versados en el tema.

Primero creamos la clásica tabla de pruebas llamada “employees”:

1
2
3
4
5

CREATE TABLE employees (
  employee_id      NUMBER  NOT NULL,
  firts_name       VARCHAR2(20),
  last_name        VARCHAR2(20),
  salary           NUMBER);

Le creamos su llave primaria en el campo “employee_id”:

1

ALTER TABLE employees add constraint "PKemployees" primary key (employee_id);

Creamos el susodicho trigger que generara automáticamente el identificador para cada nueva fila, por supuesto, también lo pudimos haber realizado en base a una secuencia pero este caso, por facilidad, lo crearemos con un simple max + 1:

1
2
3
4
5
6
7
8
9
10
11
12

CREATE OR REPLACE TRIGGER tr_pk_employees 
  before INSERT ON employees
  FOR each ROW
DECLARE
 
BEGIN
 
  SELECT NVL(MAX(employee_id),0) + 1
    INTO :NEW.employee_id
    FROM employees;
 
END;

Es todo, ahora al realizar un insert a la tabla solo necesitamos los valores para los demás campos, si lo queremos hacer sin especificar campos tendremos que ponerle “null” o en su defecto doble comilla simple:

1
2
3

INSERT INTO employees VALUES (NULL, 'pancho',  'lopez',1000);
INSERT INTO employees VALUES (NULL,   'juan',  'penas',2000);
INSERT INTO employees VALUES (NULL,  'nacho','vazquez',3000);

O especificando los campos sin necesidad del campo “employee_id”:

1
2
3

INSERT INTO employees (firts_name, last_name, salary) VALUES ('guicho','sanchez',4000);
INSERT INTO employees (firts_name, last_name, salary) VALUES ('rolando', 'calles',5000);
INSERT INTO employees (firts_name, last_name, salary) VALUES ('juan','gabriel',6000);

Y para corroborar que todo funcionó correctamente, revisamos los datos:

1
2
3
4
5
6
7
8
9
10

SQL> SELECT * FROM employees;
 
EMPLOYEE_ID FIRTS_NAME           LAST_NAME                SALARY
----------- -------------------- -------------------- ----------
          1 pancho               lopez                      1000
          2 juan                 penas                      2000
          3 nacho                vazquez                    3000
          4 guicho               sanchez                    4000
          5 rolando              calles                     5000
          6 juan                 gabriel                    6000