Ir al contenido


Foto

Base de datos definida sin chardset FB2.5

chardset

  • Por favor identifícate para responder
7 respuestas en este tema

#1 Nikolas

Nikolas

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 604 mensajes
  • LocationMar del Plata / Bs As / Argentina

Escrito 17 octubre 2015 - 05:55

Hola Gente, hace un tiempo creé una bdd con firefird 2.5 sin chardset, fui cambiando alguna tablas en la medida que necesitaba o generaba problemas.

Hace poco hice una traducción desde una tabla paradox y me aparecieron varios caracteres como "?", ellos son los tildes, la ñ, ° y algún otro.

 

¿como deberia encarar la solución?

 

1°- exporto los datos a un .txt

2° - defino el chardset para mi tabla

3°- importo los datos del .txt

 

Probe, definiendo el chardset con los datos puestos pero no los corrije.

(ISO8859_1 con ES_ES_CI_AI)

 

tambien podria encarar de esta forma:

por ejemplo:


php
  1. update articulos set detalle = replace(detalle,'¢','O')

gracias


  • 1

#2 enecumene

enecumene

    Webmaster

  • Administrador
  • 7.419 mensajes
  • LocationRepública Dominicana

Escrito 17 octubre 2015 - 06:49

Eso es codificación UTF-8, prueba cambiandola y volver hacer la migración.


  • 1

#3 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.295 mensajes
  • LocationArgentina

Escrito 17 octubre 2015 - 07:20

Si has estado haciendo una "migración" y cambiando de un collation a otro, y sobre todo si usas ES_ES_CI_AI Firebird tiene sus pequeños problemitas con esto...

Está documentado y justamente desde FB 2.1 cuenta con un comando/parámetro para que corrija tanto la metadata de la estructura de la base de datos, y otro comando más para metadata de los datos.

Los comandos de gback son -FIX_FSS_M[ETADATA] y -FIX_FSS_D[ATA]

 

Saludos,


  • 1

#4 Nikolas

Nikolas

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 604 mensajes
  • LocationMar del Plata / Bs As / Argentina

Escrito 17 octubre 2015 - 08:27

Eso es codificación UTF-8, prueba cambiandola y volver hacer la migración.

 

esto, no podrá ser porque ya tengo cambios realizados.

 

Si has estado haciendo una "migración" y cambiando de un collation a otro, y sobre todo si usas ES_ES_CI_AI Firebird tiene sus pequeños problemitas con esto...

Está documentado y justamente desde FB 2.1 cuenta con un comando/parámetro para que corrija tanto la metadata de la estructura de la base de datos, y otro comando más para metadata de los datos.

Los comandos de gback son -FIX_FSS_M[ETADATA] y -FIX_FSS_D[ATA]

 

Saludos,

 

voy a probar por aqui, luego comento.

 

gracias a ambos.


  • 0

#5 Nikolas

Nikolas

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 604 mensajes
  • LocationMar del Plata / Bs As / Argentina

Escrito 18 octubre 2015 - 05:28

Hice el gbak y restaure con las opciones que comentas pero no funciono. (lo muestra igual)

http://www.destructo...rebird/gbak.htm


  • 0

#6 cram

cram

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 832 mensajes
  • LocationMisiones, Argentina

Escrito 19 octubre 2015 - 06:52

Deberías saber primero bajo que norma se codificaron los datos en Paradox. Supongo que en UTF-8 como dice Enecumene.

ES_ES_CI_AI es solo el orden de los caracteres, no influye en algo.

 

Aquí te dejo un enlace de ClubDelphi, donde Marc escribe sobre el tema (dá una cátedra 8-| ). Quizás te sirva, al menos para entender mejor.

http://www.clubdelph...ead.php?t=70685

 

A mí, se me ocurre que pases los datos por un "filtro" hecho en un programa, que leas los datos (los lleves a memoria) y los modifiques desde ese programa según lo necesario y luego los vayas almacenando con una codificación conocida.

 

Saludos.


  • 1

#7 Nikolas

Nikolas

    Advanced Member

  • Miembro Platino
  • PipPipPip
  • 604 mensajes
  • LocationMar del Plata / Bs As / Argentina

Escrito 19 octubre 2015 - 05:00

Deberías saber primero bajo que norma se codificaron los datos en Paradox. Supongo que en UTF-8 como dice Enecumene.

ES_ES_CI_AI es solo el orden de los caracteres, no influye en algo.

 

Aquí te dejo un enlace de ClubDelphi, donde Marc escribe sobre el tema (dá una cátedra 8-| ). Quizás te sirva, al menos para entender mejor.

http://www.clubdelph...ead.php?t=70685

 

A mí, se me ocurre que pases los datos por un "filtro" hecho en un programa, que leas los datos (los lleves a memoria) y los modifiques desde ese programa según lo necesario y luego los vayas almacenando con una codificación conocida.

 

Saludos.

 

no me sirve porque ya estan trabajando con los datos nuevos, no puedo realizar migración nuevamente.

 

voy a buscar la vuelta para corregir de esta forma:


php
  1. begin
  2. dd = lpad(cast(extract(day from :f_nacimiento) as varchar(2)), 2, '0');
  3. mm = lpad(cast(extract(month from :f_nacimiento) as varchar(2)), 2, '0');
  4. aa = right(cast(extract(year from :f_nacimiento) as varchar(4)), 2);
  5. cadena = substring(a_paterno from 2);
  6. len = char_length(cadena);
  7. i = 1;
  8. while (i < len) do
  9. begin
  10. execute procedure proper_vowel(substring(cadena from 1 for 1))
  11. returning_values pv;
  12. if (pv in ('A', 'E', 'I', 'O', 'U')) then leave;
  13. cadena = substring(cadena from 2);
  14. i = i + 1;
  15. rfc = left(:a_paterno, 1) || pv || coalesce(left(:a_materno, 1), 'X') ||
  16. lef


  • 0

#8 Delphius

Delphius

    Advanced Member

  • Administrador
  • 6.295 mensajes
  • LocationArgentina

Escrito 19 octubre 2015 - 05:21

Ummm... no sabría dar muchos detalles pero hubiera jurado que el comando que expuse debería haber corregido la data. En teoría sirve para corregir justamente malformación de charsets.

¿Probaste creando un campo nuevo del charset necesario y volcando los datos a éste y luego borrar el original? No se si se pueda forzar en una operación CAST() a emplear un chartset, yo me imagino algo como copiar el texto del campo de origen y forzarlo a leer en UTF8, y luego pegar éste al campo destino con un cast hacia el charset ISO 8859-1 como tu esperas.

 

Podría funcionar algo así...

 

Saludos,


  • 0




IP.Board spam blocked by CleanTalk.