Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[OT] - SQL caracter ñ

2 views
Skip to first unread message

Guido Ignacio

unread,
Mar 6, 2015, 11:20:02 AM3/6/15
to
Gente me topé con una base la cual en una de sus bases tiene una
columna con ñ, más precisamente la columna se llama Año_registro

La cuestión es que al correr para sacar un listado:

SELECT CONCAT(usuario,'--> ',Año_registro)
FROM usuarios

No me encuentra la columna Año_registro.

Estuve buscando y no encontré info al respecto

Alguien tiene idea?


--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/CA+wiXxjswWayAsw9maj2sZSJ...@mail.gmail.com

Camaleón

unread,
Mar 6, 2015, 11:40:03 AM3/6/15
to
El Fri, 06 Mar 2015 13:11:04 -0300, Guido Ignacio escribió:

> Gente me topé con una base la cual en una de sus bases tiene una
> columna con ñ, más precisamente la columna se llama Año_registro
>
> La cuestión es que al correr para sacar un listado:
>
> SELECT CONCAT(usuario,'--> ',Año_registro)
> FROM usuarios
>
> No me encuentra la columna Año_registro.

¿Qué error te saca exactamente? ¿O no te devuelve nada?

> Estuve buscando y no encontré info al respecto
>
> Alguien tiene idea?

Pues si la bdd/tabla y el terminal desde donde ejecutas la consulta están
en utf-8 no debería tener problemas.

¿Te funciona la consulta usando caracteres comodín (p. ej., filtrando por
la columna "*_registro")? ¿O qué te devuelve una consulta por tablas
(show columns from table;).

Saludos,

--
Camaleón


--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/pan.2015.03...@gmail.com

Carlos Zuniga

unread,
Mar 6, 2015, 12:00:04 PM3/6/15
to
2015-03-06 11:11 GMT-05:00 Guido Ignacio <guidoi...@gmail.com>:
> Gente me topé con una base la cual en una de sus bases tiene una
> columna con ñ, más precisamente la columna se llama Año_registro
>
> La cuestión es que al correr para sacar un listado:
>
> SELECT CONCAT(usuario,'--> ',Año_registro)
> FROM usuarios
>
> No me encuentra la columna Año_registro.
>
> Estuve buscando y no encontré info al respecto
>
> Alguien tiene idea?
>

¿Qué base de datos? Si es mysql prueba colocar el nombre de tus
columnas entre backticks ("`"): `Año_registro`. Mysql convierte los
identificadores a unicode internamente.

Si es otra... revisa la documentación.


--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/CAABYcjNf9Y4TfEwBVR6X1NY8...@mail.gmail.com

Gerardo Diez García

unread,
Mar 6, 2015, 5:10:05 PM3/6/15
to
El 06/03/15 17:11, Guido Ignacio escribió:
> Gente me topé con una base la cual en una de sus bases tiene una
> columna con ñ, más precisamente la columna se llama Año_registro
>
> La cuestión es que al correr para sacar un listado:
>
> SELECT CONCAT(usuario,'--> ',Año_registro)
> FROM usuarios
>
> No me encuentra la columna Año_registro.
>
> Estuve buscando y no encontré info al respecto
>
> Alguien tiene idea?
>
>
Un compañero con un problema similar lo soluciona empleando:
SET character_set_client = utf8;
A ver qué tal te funciona.


--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/54FA2377...@gmail.com

Angel Claudio Alvarez

unread,
Mar 8, 2015, 7:30:03 PM3/8/15
to
El Fri, 6 Mar 2015 13:11:04 -0300
Guido Ignacio <guidoi...@gmail.com> escribió:

> Gente me topé con una base la cual en una de sus bases tiene una
> columna con ñ, más precisamente la columna se llama Año_registro
>
> La cuestión es que al correr para sacar un listado:
>
> SELECT CONCAT(usuario,'--> ',Año_registro)
> FROM usuarios
>
> No me encuentra la columna Año_registro.
>
> Estuve buscando y no encontré info al respecto
>
> Alguien tiene idea?
>

Si, preguntar en la lista correta
Esto ni siquiera califica como OT
>
> --
> To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
> Archive: https://lists.debian.org/CA+wiXxjswWayAsw9maj2sZSJi0=JK6zaA3-uOa...@mail.gmail.com
>


--
Angel Claudio Alvarez <an...@angel-alvarez.com.ar>


--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/20150308202433.3c5f...@angel-alvarez.com.ar

Roberto José Blandino Cisneros

unread,
Mar 11, 2015, 12:40:03 PM3/11/15
to
Cambie la columna de Año_registro a Anio_registro.
--
================

Camaleón

unread,
Mar 11, 2015, 1:00:04 PM3/11/15
to
El Wed, 11 Mar 2015 10:38:24 -0600, Roberto José Blandino Cisneros
escribió:

> 2015-03-06 10:11 GMT-06:00 Guido Ignacio <guidoi...@gmail.com>:
>
>> Gente me topé con una base la cual en una de sus bases tiene una
>> columna con ñ, más precisamente la columna se llama Año_registro
>>
>> La cuestión es que al correr para sacar un listado:
>>
>> SELECT CONCAT(usuario,'--> ',Año_registro)
>> FROM usuarios
>>
>> No me encuentra la columna Año_registro.
>>
>> Estuve buscando y no encontré info al respecto
>>
>> Alguien tiene idea?

> Cambie la columna de Año_registro a Anio_registro.

Paciente: "Me duele la rodilla"
Doctor: "Pues vamos a cortar la pierna"

:-D

Saludos,

--
Camaleón


--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/pan.2015.03...@gmail.com

Roberto José Blandino Cisneros

unread,
Mar 11, 2015, 1:30:03 PM3/11/15
to
Estamos claro que el problema es de dialogo entre la aplicación y la BD.

Sin embargo desde los inicios siempre se me enseño a no usar caracteres latinizados como acentos, eñes y caracteres especiales como comillas, paréntesis, llaves, etc.

La solución se puede hacer de dos formas:

1) Arreglando y ajustando la codificación en ambos lados.
2) No usando caracteres poco convencionales.
--
================

Camaleón

unread,
Mar 11, 2015, 1:50:03 PM3/11/15
to
El Wed, 11 Mar 2015 11:26:42 -0600, Roberto José Blandino Cisneros
escribió:

> 2015-03-11 10:52 GMT-06:00 Camaleón <noel...@gmail.com>:
>
>> El Wed, 11 Mar 2015 10:38:24 -0600, Roberto José Blandino Cisneros
>> escribió:

(...)

>> >> Alguien tiene idea?
>>
>> > Cambie la columna de Año_registro a Anio_registro.
>>
>> Paciente: "Me duele la rodilla"
>> Doctor: "Pues vamos a cortar la pierna"
>>
>> :-D

> Estamos claro que el problema es de dialogo entre la aplicación y la BD.
>
> Sin embargo desde los inicios siempre se me enseño a no usar caracteres
> latinizados como acentos, eñes y caracteres especiales como comillas,
> paréntesis, llaves, etc.

Pues imagina los pobres japoneses, chinos, coreanos... las deben de pasar
canutas para poner nombres a sus tablas. Hombre, esa sugerencia hace 10
años no te digo yo que no pero ahora mismo ya no debe ser un problema
salvo que estés migrando una bdd del pleistoceno o tengas alguna
restricción completamente justificada.

> La solución se puede hacer de dos formas:
>
> 1) Arreglando y ajustando la codificación en ambos lados.
> 2) No usando caracteres poco convencionales.

Efectivamente:

1) Haciendo una radiografía
2) Amputando

;-D

Aradenatorix Veckhom Vacelaevus

unread,
Mar 11, 2015, 2:00:03 PM3/11/15
to
Pues curiosamente lo que dice Roberto se remonta a los años de la
guerra fría en la que los Estados Unidos diseñaron el código ascii que
les pareció suficiente para comunicación básica en todas las lenguas
"oficiales" de la OTAN. Es un recuerdo tecnológico de la mentalidad de
"ellos y nosotros (los estadounidenses)". Con esto se deja de lado por
completo las necesidades de matemáticos, lingüistas y de millones de
ser humanos ¿normales? que usan el alfabeto latino para el checo,
galés, hausa, húngaro, letón, navajo, polaco, rumano, turco,
vietnamita, yoruba, español y muchos más. Lenguas donde usan muchos
otro caracteres no normales como parece ser la ñ.

Lamentablemente el software tipograficamente atrofiado y culturalmente
sectario sigue estando muy extendido aun en nuestros días como bien
señala Camaleón. Creo que el enfoque no es plegarse a las limitaciones
del software sino superarlas para poder escribir como se debe.
Esperemos que se pueda arreglar la codificación sin problemas.


--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/CAACnk7YYgf2M30oZhj017qEe...@mail.gmail.com

Roberto José Blandino Cisneros

unread,
Mar 11, 2015, 6:30:03 PM3/11/15
to
2015-03-11 11:41 GMT-06:00 Camaleón <noel...@gmail.com>:
El Wed, 11 Mar 2015 11:26:42 -0600, Roberto José Blandino Cisneros
escribió:

> 2015-03-11 10:52 GMT-06:00 Camaleón <noel...@gmail.com>:
>
>> El Wed, 11 Mar 2015 10:38:24 -0600, Roberto José Blandino Cisneros
>> escribió:

(...)

>> >> Alguien tiene idea?
>>
>> > Cambie la columna de Año_registro a Anio_registro.
>>
>> Paciente: "Me duele la rodilla"
>> Doctor: "Pues vamos a cortar la pierna"
>>
>> :-D

> Estamos claro que el problema es de dialogo entre la aplicación y la BD.
>
> Sin embargo desde los inicios siempre se me enseño a no usar caracteres
> latinizados como acentos, eñes y caracteres especiales como comillas,
> paréntesis, llaves, etc.

Pues imagina los pobres japoneses, chinos, coreanos... las deben de pasar
canutas para poner nombres a sus tablas. Hombre, esa sugerencia hace 10
años no te digo yo que no pero ahora mismo ya no debe ser un problema
salvo que estés migrando una bdd del pleistoceno o tengas alguna
restricción completamente justificada.


No pues si yo estoy de acuerdo contigo, el problema es que siempre es recomendable iniciar con lo simple y luego en modo develop hacer todas estas pruebas.

Yo no e tenido problema con "ñ" en las bd, si seguro que no esta usando el mismo tipo de caracteres.

> La solución se puede hacer de dos formas:
>
> 1) Arreglando y ajustando la codificación en ambos lados.
> 2) No usando caracteres poco convencionales.

Efectivamente:

1) Haciendo una radiografía
2) Amputando


Estamos de acuerdo también por eso depende que lo que desea hacer si es desarrollo perfecto debe de hacer una radiografía. Pero si no tiene tiempo para hacer los ajustes que Ampute y vuelva a la vieja escuela.


;-D

Saludos,

--
Camaleón


--
To UNSUBSCRIBE, email to debian-user-s...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: https://lists.debian.org/pan.2015.03...@gmail.com




--
================

Camaleón

unread,
Mar 12, 2015, 10:50:03 AM3/12/15
to
El Wed, 11 Mar 2015 16:27:50 -0600, Roberto José Blandino Cisneros
escribió:

> 2015-03-11 11:41 GMT-06:00 Camaleón <noel...@gmail.com>:

(...)

>> > Sin embargo desde los inicios siempre se me enseño a no usar
>> > caracteres latinizados como acentos, eñes y caracteres especiales
>> > como comillas, paréntesis, llaves, etc.
>>
>> Pues imagina los pobres japoneses, chinos, coreanos... las deben de
>> pasar canutas para poner nombres a sus tablas. Hombre, esa sugerencia
>> hace 10 años no te digo yo que no pero ahora mismo ya no debe ser un
>> problema salvo que estés migrando una bdd del pleistoceno o tengas
>> alguna restricción completamente justificada.
>>
>>
> No pues si yo estoy de acuerdo contigo, el problema es que siempre es
> recomendable iniciar con lo simple y luego en modo develop hacer todas
> estas pruebas.

Hombre, el problema ya sabemos cuál es ¿no? Pocas pruebas hay que hacer
más allá de configurar correctamente la codificación de todos los
elementos que entran en juego, como en cualquier otra aplicación.

> Yo no e tenido problema con "ñ" en las bd, si seguro que no esta usando
> el mismo tipo de caracteres.

Yo también he tenido (tengo) problemas con la codificación pero esos
errores hay que solucionarlos no esquivarlos o maquillarlos. Porque
imagina que esa base de datos se consulta en miles de páginas web, si
cambias el nombre de una columna tienes que cambiar miles de consultas
que apuntan a ese registro lo cual no resulta factible.

>> La solución se puede hacer de dos formas:
>> >
>> > 1) Arreglando y ajustando la codificación en ambos lados.
>> > 2) No usando caracteres poco convencionales.
>>
>> Efectivamente:
>>
>> 1) Haciendo una radiografía 2) Amputando
>>
>>
> Estamos de acuerdo también por eso depende que lo que desea hacer si es
> desarrollo perfecto debe de hacer una radiografía. Pero si no tiene
> tiempo para hacer los ajustes que Ampute y vuelva a la vieja escuela.

Si amputas ya no hay marcha atrás, es punto final, la última de todas las
opciones (es decir, no es una solución) :-(
0 new messages