Buenas!.

Me gustaría preguntaros vuestra opinión sobre esto.

Imaginar que conocéis el nombre de la región mundial pero no conocéis la población.
¿ Usarías null ?.

Distinto es el nombre de la región.



¿ Usarías mejor un valor como cero, una cadena vacía o el valor Falso ?.

Los expertos no recomiendan el uso de Null.

En el caso de que se quiera recordar que poblaciones tienen un valor nulo para cambiarlas,
podríamos hacer:



Los problemas vienen si usamos  NULL y hacemos operaciones lógicas.

...Es que en SQL no existe el blanco y negro, o verdadero y falso..null..es desconocido, el tercer valor lógico.
Claro que usar NULL, depende también del gestor de base de datos.

Se debería usar con precaución.

Saludos

===================
Gambas Básico
"No es un bug, es una característica no documentada"

Me encontré un pequeño problema. Ahora quiero cambiar a un valor el registro cuyo campo poblacion es null.

Puedo hacer esto:



Pero no puedo hacer esto:



 

===================
Gambas Básico
"No es un bug, es una característica no documentada"

Debieras eludir siempre el null. No tiene ningún sentido. Si tienes que trabajar con el contenido de los campos es muuuucho mejor saber de antemano con qué te vas a enfrentar. Un campo vacío sigue teniendo un valor cadena vacía, 0, lo que sea, pero un valor que puedes evaluar. Null es la ausencia de valor y la posibilidad de que eso ocurra te complicará la lógica de toda operación que quieras evaluar sobre ese campo:
Ahora tendrás siempre y en cada una de las operaciones que comprobar si es null o no y si no lo es entonces evaluar el contenido.

Recuerda también que gambas no implementa por defecto los atajos lógicos en la evaluación de las expresiones, es decir:

Si el campo A puede tener un valor null cuando debería ser numérico, no te vale esto:



gambas, antes de decidir si la expresión es cierta o falsa evalúa cada uno de sus elementos, el isnull y el > 0, y éste último generará un error de comparación. Tendrás que codificar siempre:



Dice el Benoit que si codificas


Entonces la evaluación se detiene en la primera expresión y no se genera error.
No lo he probado, pero ¿qué necesidad hay de todo esto?, que cada campo contenga un valor de su tipo (con Mysql es automático, con SQLite tienes que añadir la restricción default en la definición de la columna) y no tendrás ningún problema ni complicación.

Saludos

===================
No podemos regresar

Shordi:

Vale, entonces null desechado para esto.

shordi escribió: [Ver mensaje]

Dice el Benoit que si codificas

Código: [Descargar] [Ocultar] [Seleccionar]

Código: [Descargar] [Mostrar]

if not isnull(miresult!a) and if miresult!A > 0

Entonces la evaluación se detiene en la primera expresión y no se genera error.
No lo he probado, pero ¿qué necesidad hay de todo esto?, que cada campo contenga un valor de su tipo (con Mysql es automático, con SQLite tienes que añadir la restricción default en la definición de la columna) y no tendrás ningún problema ni complicación.

Puede que para base de datos no sea necesario usar este tipo de expresión.
Pero se usa para otras cosa, son los llamado cortacircuitos. Y funcionan.

Saludos

===================
Gambas Básico
"No es un bug, es una característica no documentada"