Actualizacion de un campo boleano con SQL

[cokete]

no se que estoy haciendo mal, el caso es que estoy intentando actualizar un registro que tiene un campo boleano y no hay manera, me da error siempre.
La base de datos es de access, y el campo es de tipo si/no y he probado de mil maneras y nada... me da el mismo error, me dice que no coinciden los tipos de datos. A ver si alguien me puede ayudar, aqui os dejo el codigo.
Un saludo y gracias.


strEnviada=False
SQL="UPDATE Noticias SET Fecha=#" & Day(strFecha) &"/" & Month(strFecha) &"/" & Year(strFecha) &" " & FormatDateTime(strFecha,vbShortTime) &"#, Titular='" & strTitular &"', Cuerpo='" & strCuerpo &"', PieNoticia='" & strPieFoto &"', Enviada='" & strEnviada & "'"

SQL=SQL & " WHERE CodNoticia=" & Request.Form("codnoticia") & ";"
Conn.Execute SQL

[u_goldman]

Bueno, pero como se llama el campo?? trataste de mandarle valores directamente? te recomiendo que si esstas tratando de madarle true/false, le mandes 1/0 mejor.

Salu2,

[Neuron_376]

No se en Acces, pero creo que el problema es que pones el campo entre comillas:

Enviada='" & strEnviada & "'"

Debe ser solo:

Enviada=" & strEnviada

Las consultas SQL deben quedar igaul como si las usaras directo en el administrador de bases de datos, es decir:

Enviada = 'False' >>> El interprete lo lee mal
Enviada = False >>> El interprete lo lee bien

Pero bueno, no se si sea igual en acces

Por que no necesita las comillas, la otra opcion es enviar el numeo 1 o 0, pero no es lo mas correcto en cuestion de logica de programacion.

[u_goldman]

la otra opcion es enviar el numeo 1 o 0, pero no es lo mas correcto en cuestion de logica de programacion.

Neuron, por que dices que no es lo mas correcto? Podrias abundar un poco mas en esto? en realidad a mi me parece que es lo mas correcto, finalmente un valor booleano no es mas que un entero que puede tomar dos valores.

Salu2,

[javopereira]

En Access, creo 0 = false y -1 = true

[Muzztein]

lo que es yo , me evito problemas y creo mi propio estandar haciendo un dominio y ya.

[Neuron_376]

En Acces no se... pero aun cuando el valor fuera el mismo como en la mayoria de los servidores de SQL....

Mira, 1 y 0 son enteros... True y False son booleanos, al final es correcto usar ambos porque representan o valen lo mismo...

Pero es como decir... en la vida normal, en mi pais Mexico, el dolar vale 10 pesos mexicanos, si yo quisiera decir 10 pesos, podria decir siempre 1 dolar verdad, valen lo mismo, pero no son la misma cosa...

Es una manera de explicarlo, dentro de programacion debes seguir un orden que al final de cuentas te hace las cosas mas claras y faciles... supon este caso muy rapido.

tienes 5 variables en tu script:

var1 = 1 //esta realmente la usas para valores enteros
var2 = 0 //esta realmente la usas para valores enteros
var3 = 1 //esta realmente la usas para valores booleanos
var4 = 0 //esta realmente la usas para valores booleanos

Como identificas los diferentes tipos de variables que estas usando ?, yo hago esto:

intVar1 = 1
intVar2 = 1
blnVar1 = 1
blnVar1 = 1

Pero ???? si tengo bln = Booleano, entonces porque utilizo enteros ?, porque no seguir el verdadero orden y decir True y False? es un punto negativo en mi codigo, una contradiccion de valores.

Luego, si tu te acostumbras a mandar valores enteros en tus consultas, como identificas facilmente el tipo de datos que estas utilizando.

Ejemplo rapido:

tblMiTabla
- Status int
ó
- Status Booleano

Tu mandas siempre un dato entero para Status, pero en la base de datos un dato entero ocupa 4 Bytes y in Booleno sono 1, eso es una diferencia que si no usas la sintaxis correcta podrias cometer errores, o bien, no identificar facil y rapidamente la diferencia.

Y recuerda que si estas creando algo para que crezca, debes pensar que despues otras personas lo leeran, o tu mismo despues cuando lo necesites, y en el caso particular de "cokete", despues cuando lea el codigo sabra sin tener que abrir la base de datos que tipo de datos exactamente esta utilizando.

[Neuron_376]

cokete... mire esto en tu codigo...

Mira, si el interprete lee esto bien:

Enviada = 'False' >>> si eso es correcto, entonces el unico cambio seria:

strEnviada="False"
SQL="UPDATE Noticias SET Fecha=#" & Day(strFecha) &"/" & Month(strFecha) &"/" & Year(strFecha) &" " & FormatDateTime(strFecha,vbShortTime) &"#, Titular='" & strTitular &"', Cuerpo='" & strCuerpo &"', PieNoticia='" & strPieFoto &"', Enviada='" & strEnviada & "'"

SQL=SQL & " WHERE CodNoticia=" & Request.Form("codnoticia") & ";"
Conn.Execute SQL


Si el interprete lee esto bien:

Enviada = False >>> si eso es correcto, entonces el unico cambio seria:

strEnviada="False"
SQL="UPDATE Noticias SET Fecha=#" & Day(strFecha) &"/" & Month(strFecha) &"/" & Year(strFecha) &" " & FormatDateTime(strFecha,vbShortTime) &"#, Titular='" & strTitular &"', Cuerpo='" & strCuerpo &"', PieNoticia='" & strPieFoto &"', Enviada=" & strEnviada

SQL=SQL & " WHERE CodNoticia=" & Request.Form("codnoticia") & ";"
Conn.Execute SQL

Si te fijas, todo es basado en el interprete, de como funciona el, entonces tu debes crear la cadena exactamente como el interprete la entiendo correctamente.

Suerte.

[u_goldman]

Sin afan de ofender, ni contradecirte solamente porque si, pero no me refiero a utilizar campos enteros en tu tabla que hagan la funcion de booleanos, me refiero a utilizar el valor primitivo para este tipo de dato que es si o si un entero 1/0, esta claro que en el momento de codificar tienes que utilizar convenciones para hacer tu codigo mas amigable, sucede sobre todo con las variables de tipo booleanas, que crean confusion, por eso la recomendacion muchas veces es no solamente utilizar el prefijo bln o bool, sino utilizar algun nombre que sea de facil comprension:

blnSe_Caso_Y_se_Divorcio

es mas facil de entender que:

blnDivorcio

Es por eso que en realidad se utiliza un true/false para distinguir estas variables, pero...pero, haz pruebas, cambia el LCID de alguna de tus aplicaciones a un LCID que utilice espanol, ahora trata de insertar un valor true/false, y veras lo que te pasa...intenta insertar un verdadero/falso, cosa que no reconoce tu manejador de base de datos y te va a decir "Momento muchacho, yo no entiendo tu lenguaje", por eso, no solo es mas seguro utilizar un 1/0, sino tambien mas escalable.

Mis $0.02

[Neuron_376]

Todos los puntos son muy buenos...

Piensa esto muiy rapido... tu manejas tu servidor, no otra persona, estamos hablando de bases de datos, no de ASP, porque dentro del ASP, siempre hacemos cosas como:

if (intCont) then .... asumiendo el 1 y 0 como true y false, y eso es valido

if (blnDivorcio) then .. asumiendo el 1 y 0 como true y false, y eso es valido

Ahora bien... imagina el caso que tu mismo acabase de mencionar, si no entiende booleanos, entonces tendras que usar un dato tnyint para representar un booleano, y en ese caso, pues bien, la recomendacion correcta seria, NO USES DATOS BOOLEANOS, usa datos ENTEROS, pero ese es un caso que no va a pasar.

Ahora bien digamos que si pasa (TODO ES POSIBLE)... pero al reves... imagina que a tu administrador de bases de datos lo restringes a no aceptar 1 y 0 para datos booleanos... y no puedes cambiarlo ????

Como le haces facilmente para cambiar todas tus paginas de ASP para que en lugar de 1 y 0 tengan True y False, o simplemente el caso que menciono "javopereira" donde los valores para True y False no son los comunes... bien, tu tendrias que ir casi casi pagina por pagina cambiando todo el codigo...

Para mi en mi codigo, para corregir el caso que tu mencionas, basta con entrar a DreamWeaver y hacer dos BUSCAR-REPLATE donde digo:

1. Remplaza en todo el sitio "True" por "1"
2. Remplaza en todo el sitio "False" por "0"

Claro, solamente en mi codigo que tengo listo para subir al servidor, es decir mi carpeta de desarrollo, y tu tendrias que buscar absolumante todas tus variables tipo booleano para decir True y False

Esa es una gran diferencia verdad?, tu codigo debe estar preparado para que cualquier cambio inesperado como esta hipotesis que estamos planteando pueda ser manejada en pocos minutos sin afectar absolumante nada la funcionalidad...

Creeme, siempre hay muchas formas de hacer las cosas, pero siempre hay una forma correcta.

---- AGRGANDO ----
El caso que mencionas de compilador en español, esta bien, ese caso lo arreglo con dos Replaces tambien:

1. Remplaza en todo el sitio "True" por "Verdadero"
2. Remplaza en todo el sitio "False" por "False"

Repito, solo en mi carpeta de desrrollo, donde tengo todo lo que voy a subir, no en todo mi sitio local.

[u_goldman]

o simplemente el caso que menciono "javopereira" donde los valores para True y False no son los comunes...

Claro que son los comunes, trata de insertar un -1 para un campo booleano en Access y veras lo que pasa...

Trata de insertar en MS SQL un valor TRUE a un campo de tipo bit y veras lo que pasa



Supongo que ellos tambien estan en un error, y no pensaron en que en un servidor de produccion restringirian la posibilidad de utilizar enteros?

Recuerda que solo estoy hablando del manejo de variables booleanas para su almacenamiento en bases de datos, y la complicacion que existe con las distintas plataformas y que como mencione, es mucho mas sencillo y escalable, y menos suceptible de cambio.


Salu!

[Neuron_376]

En Accces no se, la verdad nunca lo he usado como mi administrador de bases de datos, y es bueno saber que si son los comunes.

Bueno, todo es valido, si estas mas agusto con 1 y 0, esta bien, pero para mi como te dije antes, para adaptar el codigo a cualquier plataforma me bastan 2 replaces genenales y listo... Si estuviera programando con 1 y 0, esto seria casi imposible.

Ademas decir que 0.2 = True ó igual a Falso, sigue siendo para mi algo malo, ademas un grave error manejar ese caso, un muy grave error en el codigo, y mas grave pasarle a la base de datos un True o un False basado en decimales.

Pero esta bien, eso en lo unico que tengo que opinar de este tema.

Suerte!!

[cokete]

Muchas Gracias tios, no hacia falta hacer un debate pero bueno..jejejeje os lo agradezco muchisimo, con el 1 y el 0 se solucionó todo.... la de vueltas que le he dado......puffff
Gracias.