VB problema al guardar un MEDIUMTEXT en un dataset desde MySQL

[410n5o]

Hola todos,

Estoy haciendo una aplicación en vb.net 2008 con MySQL 5.1, en la BD guardo un campo tipo MEDIUMTEXT ya que necesito que sea muy grande, y necesito pasar ese dato a un dataset de la aplicacion para luego llenar un datagrid, pero el problema es que como los datos se guardan en binario al pasarlos al dataset obtengo un error, no puedo convertirlo a varchar porque si el texto excede los 255 caracteres perderia información, qué puedo hacer?

Gracias de antemano

[gnzsoloyo]

¿Usaste un MEDIUMTEXT para guardar un binario?

Me parece que la cosa está mal de entrada, porque un TEXT o MEDIUMTEXT guarda caracteres, no necesariamente binarios. Lo que sí se usa para guardar binarios es el BLOB (cualquiera de sus variantes).

Según el manual:

Las columnas BLOB se tratan como cadenas de caracteres binarias (de bytes). Las columnas TEXT se tratan como cadenas de caracteres no binarias (de carácateres). Las columnas BLOB no tienen conjunto de caracteres, y la ordenación y la comparación se basan en los valores numéricos de los bytes. Las columnas TEXT tienen un conjunto de caracteres y se ordenan y comparan en base de la colación del conjunto de caracteres asignada a la columna desde MySQL 4.1.

En cualquier caso, mira este artículo: Visual Basic / MySQL Datatypes

[410n5o]

Iniciado por gnzsoloyo

¿Usaste un MEDIUMTEXT para guardar un binario?

Me parece que la cosa está mal de entrada, porque un TEXT o MEDIUMTEXT guarda caracteres, no necesariamente binarios. Lo que sí se usa para guardar binarios es el BLOB (cualquiera de sus variantes).

Según el manual:

En cualquier caso, mira este artículo: [URL="http://dev.mysql.com/tech-resources/articles/visual-basic-datatypes.html"]Visual Basic / MySQL Datatypes[/URL]

Gracias por tu respuesta,

Sí los MEDIUMTEXT almacenan caracteres solo que habia leido que los almacena de manera binaria o cifrada algo asi entonces al pasarla a la aplicacion de .net obtengo basura y no la puedo guardar en mi dataset.
Ese es el problema, yo podría guardar ese MEDIUMTEXT en un string de vb pero lo necesito guardar en un dataset y ahi es donde sale el problema, un varchar no me sirve porque es muy pequeño.

[gnzsoloyo]

Explicame esto:
Yo tengo una aplicación que simplemente consulta una tabla donde se almacena una serie de datos y un campo TEXT (obviamente más grande que el MEDIUMTEXT). Cuando realizo la consulta a la tabla, el contenido del campo se carga dentro de un campo String, y la tabla queda luego en el DataSet...
No tengo problemas.
¿Por qué dices que lo cargas en un VARCHAR? El VARCHAR es un campo de una tabla MySQL, no de una columna en una DataTable de un DataSet...

En cualquier caso, si estás guardando un texto como binario dentro de un MEDIUMTEXT (cosa extraña), solamente te queda recuperarlo como matriz de bytes, y luego convertirlo a un String...
Pero la limitación del VARCHAR seguirá existiendo.

Lo que no termino de entender es qué tiene que ver el campo VARCHAR de un DataTable con un MEDIUMTEXT de una tabla en MySQL.
El dato ingresado originalmente ¿qué longitud tenía en caracteres?

[410n5o]

Iniciado por gnzsoloyo

Explicame esto:
Yo tengo una aplicación que simplemente consulta una tabla donde se almacena una serie de datos y un campo TEXT (obviamente más grande que el MEDIUMTEXT). Cuando realizo la consulta a la tabla, el contenido del campo se carga dentro de un campo String, y la tabla queda luego en el DataSet...
No tengo problemas.
¿Por qué dices que lo cargas en un VARCHAR? El VARCHAR es un campo de una tabla MySQL, no de una columna en una DataTable de un DataSet...

En cualquier caso, si estás guardando un texto como binario dentro de un MEDIUMTEXT (cosa extraña), solamente te queda recuperarlo como matriz de bytes, y luego convertirlo a un String...
Pero la limitación del VARCHAR seguirá existiendo.

Lo que no termino de entender es qué tiene que ver el campo VARCHAR de un DataTable con un MEDIUMTEXT de una tabla en MySQL.
El dato ingresado originalmente ¿qué longitud tenía en caracteres?

Bueno yo lo que estoy guardando son caracteres nada más, lo que lei fue que el motor de MySQL en ese tipo de datos MEDIUMTEXT almacena los caracteres de manera binaria (no entiendo como pero eso decia) y al pasarlo al dataset genera un error.
Yo utilizo un dataadapter para llenar un dataset directamente en mi aplicación.
A lo que me referia con lo de VARCHAR era que si cambiaba en la base de datos el tipo MEDIUMTEXT por VARCHAR no da ningún problema a la hora de llenar el dataset pero el VARCHAR es muy corto para lo que voy a guardar.
Me explico mejor? Gracias

[gnzsoloyo]

Ahora si se entiende.
La pregunta esencia sería saber cuál es la longitud máxima esperada para ese dato. Pero si quieres guardar más de 255, y eventualmente puedes usar hasta 65535, correspondería TEXT.

El espacio de cada tipo sería:
TINYTEXT = 255
TEXT = 65.535
MEDIUMTEXT = 16777216
LONGTEXT = 4294967296

En teoría, si usas MySQL Server 5.0.3 o superior, el VARCHAR se peude definir como de una longitud de gasta 65.535 caracteres.
Esto, por ejemplo, está creado sobre MySQL Server 5.0.67, usando MySQL Query Browser:

Código MySQL:

DROP TABLE IF EXISTS `test`.`prueba`;
CREATE TABLE  `test`.`prueba` (
  `ID` int(10) unsigned default NULL,
  `TEXTO` varchar(2000) default NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
 

Y esto lo que le cargué:

Código MySQL:

insert into test.prueba values(1, '012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789');
 
SELECT length(trim(texto)) FROM test.prueba p;
+---------------------+
| length(trim(texto)) |
+---------------------+
|                1200 |
+---------------------+
1 row in set (0.00 sec)
 

Por lo que debería poder funcionar, en tanto le indiques el tamaño requerido y la versión sea correcta.

[410n5o]

Muchas gracias por tu ayuda gnzsoloyo, simplemente usé un VARCHAR de 65000 y fue suficiente!

Disculpando el abuso una pequeña duda con una conversión de tipo de datos en vb .net
Estoy pasando de SINGLE con decimales a STRING pero el problema es este:
Al pasar un número como "12.345" a string lo que queda es: "12,345" y lo que necesito es que me quede el punto en lugar de la coma, he intentado de muchas maneras y siempre convierte el punto a la coma y yo necesito el punto, alguna sugerencia?

[gnzsoloyo]

Necesitas:
1) El Namespace System.Globalization

Código vb.net:

Imports System.Globalization
 

2) Crear un objeto de la clase System.Globalization.CultureInfo.NumberFormatInfo. Es preferible crearlo en el módulo como Friend para poder usarlo en cualquier parte:

Código vb.net:

Friend nFI As NumberFormatInfo = New CultureInfo("en-US", False).NumberFormat
 

3) Usar ese objeto cuando conviertes un valor de punto flotante a string:

Código vb.net:

Dim oVarDouble as string = oDato.ToString("f", nfi)
 

En este ejemplo, oDato es una variable de tipo Double, que puede contener cualquier tipo de valor.

El problema surge cuando la region declarada en el sistema es de tipo "es-XX", donde "XX" en el sufijo de cualquier país de habla española.
Esto hace que cualquier conversión de Double a String use los símbolos regionales de decimal y de grupos de miles. Como en Español estos son, respectivamente, la coma y el punto, hay que usar alguna de las regionalizaciones de inglés. De allí que use "en-US", o sea, Inglés - Estados Unidos.
A su vez, si el dato está viniendo de la base, por ejemplo, en su formato natural (como DECIMAL, FLOAT, DOUBLE o lo que sea), para que puedas representarlo con coma en lugar de punto decimal, debes usar un objeto de regionalización en español, por ejemplo:

Código vb.net:

Friend oEsI As NumberFormatInfo = New CultureInfo("es-MX", False).NumberFormat
 

Este caso es Español - México.

Nunca debes dejar que la representación y las conversiones estén en manos del sistema, porque tendrás problemas de portabilidad entre diferentes PCs. Piensa que la mayoría de la gente ni siquiera mira qué región tienen declarada en el formato de fechas y números... (la vagancia es universal)
Cuando dejas que el sistema regule todo, o tienes problemas con los usuarios, que no comprenden lo que se les presenta en la pantalla, o tienes errores de Excepciones no controladas, por defectos de conversión... Y eso nunca debe suceder.
No te olvides que los clientes no quieren explicaciones, quieren que las cosas funcionen bien.

[410n5o]

Excelente ya lo logré con el formato US, no había pensado en eso, era lo que necesitaba.
Muchisimas gracias por tu ayuda gnzsoloyo!

[gnzsoloyo]