I have the following scenario, in which I need to enter all of them UBI_ID_UBICACION
into a textarea, for each enter the script recognizes that it is a location and adds what is necessary to place it inside the IN function, the bad thing is that it can be escaped (by the user ) a character that is not a number.
However, if I use the IN function, it gives me the following "error":
SELECT
STA_INV_ID,
STA_INV_NOMBRE,
UBI_ID,
CONCAT(
UBI_ID_UBICACION,
' ',
UBI_NOMBRE
) AS UBICACION,
UBI_ID_UBICACION
FROM
cat_status_inventario
INNER JOIN cat_per_ubicaciones
WHERE
STA_INV_ID = 1
AND UBI_ID_UBICACION IN ('6333dsds')
AND UBI_ID_UBICACION <> '0'
GROUP BY
STA_INV_ID,
STA_INV_NOMBRE,
UBI_ID
This query brings me the following record, which should NOT do it since in the IN I look for '6333dsds', that UBI_ID_UBICACION does not exist.
-----------------------------------
UBICACION | UBI_ID_UBICACION
-----------------------------------
6333 BBB-1-6-2 | 6333
The curious thing is that, if I put it in the following way IN ('dsds6333')
, it returns NULL, which is ideal, since that UBI_ID_UBICACION does not exist in the table.
-----------------------------------
UBICACION | UBI_ID_UBICACION
-----------------------------------
NULL | NULL
The correct location would be just IN ('6333')
to bring me the record. [![enter image description here][3]][3]
As a fact, all locations are just numbers.
Do you know what could be the problem and how could I solve it?
Greetings, In your case the problem is that you try to evaluate an alphanumeric expression against a numeric one, of course it will not return any result. In your case, what I would do is create a function similar to the one you will find below, which extracts integers from an expression:
I would then modify your query as follows:
I changed the IN to = since if you evaluate a single expression it is not recommended to use IN, since it decreases the efficiency of the query.
I hope my contribution will help you. Here is a link that may be useful to you. Functions to extract numbers See you!
The solution to my problem was to use the CAST function and within it the UBI_ID_UBICACION field 'convert' it to CHAR so that when evaluating, it takes it as a string and not as the data type it has by default (INT).