[WD17] Impossible de savoir si la valeur par défaut d'une rubrique est Null

[Arnaud B.]

Bonjour,

Il est possible de connaitre la valeur par défaut d'une rubrique avec la propriété ..ValeurDéfaut.

Mais cette propriété semble toujours renvoyer une chaine vide dans le cas où la valeur par défaut est définie à Null !

Et ce même si on récupère cette valeur dans une variable de type Variant, qui gère le Null.

Si on met le curseur sur cette variable dans le code, en exécution, on voit qu'elle affiche "" et non pas <Null>.

Donc à priori impossible de différencier une rubrique Texte qui a une valeur par défaut "" (chaine vide) et une rubrique Texte qui a une valeur par défaut à Null (bien sûr, la rubrique a "Null autorisé" coché).

Constatez vous la même chose ?

D'avance merci, cdlt, Arnaud.

[madsland]

Bonjour,

Pour savoir si la rubrique est à Null, il faut tester la propriété ..Null de la rubrique. (FICHIER.RUB..Null)


Cordialement

Madsl@nD

[wimbish]

Bonjour,

Si ton problème est de "ramener" des enregistrements avec la valeur vide mais pas avec la valeur NULL, tu peus utiliser le requêtage SQL pour les différentier ou la propriété ..NULL de la rubrique.

Sinon, que te renvoi le test MonFic.MaRub....ValeurDéfaut = NULL ?

[R&B]

Dans la doc, les fonctions SQL NVL, IF_NULL ou IS_NULL sont désormais reconnues :
http://doc.pcsoft.fr/fr-FR/?2034005#NOTE2_43

[tatayo]

Tout celà ne répond pas à la question de base d'Arnaud B: il ne veut pas savoir si la rubrique est à null, mais si la valeur par défaut de la rubrique est null.
Il faudrait quelquechose du genre ..valeurDéfaut..null = vrai, mais je ne sais pas si c'est faisable (je n'utilise pas HF).

Tatayo.

[Hemgé]

Bonjour,

Ceci devrait pouvoir le faire, mais je n'ai pas testé :

La propriété ValeurParDéfaut permet de :
Connaître la valeur par défaut d'une rubrique. Cette rubrique a été définie sous l'éditeur d'analyses ou définie par programmation.
Définir la valeur par défaut d'une rubrique (lors de la description de la rubrique par programmation uniquement).

Je fais un second Post à propos de NULL car je terminais juste un mémo pour PC Soft, suite à un problème rencontré sur les Dates et la valeur NULL.

Hemgé

[madsland]

Je persiste à dire que la propriété ..Null permet de le faire.
Il suffit de faire un HRAZ(FICHIER,RUBRIQUE) pour mettre la rubrique à sa valeur par défaut puis de faire un FICHIER.RUBRIQUE..Null pour savoir si la valeur par défaut est à Null.
Je tiens à préciser que je n'ai pas testé

[gardangel]

Tu n'es pas fou Arnaud, c'est effectivement le cas.

Dans leur code C, "il" ne retourne pas le NULL mais bien une valeur de type "". Après tout, une table HS est un fichier. Dans un fichier, l'absence de caractère est une interprétation à "". Peut-être que cela a un lien avec la séquence interne des fichiers HF ?

Le "NULL" à cocher n'est pas à proprement parlé un vrai NULL dans windev mais plutôt l'absence de caractère "".

Tu devras te résigner à considérer cette particularité. Que la différence entre un NULL et un "" est la même, avec HF...

J'anticipe un inconvénient vraiment mineur. Que ValeurDéfaut ramène "" ou NULL change quoi ? Tu voudrais vérifier si la rubrique est vierge ? Crée une rubrique "booléen" du genre "bEst_Premiere_Saisie" pour faire cette validation. Ou encore, utilise une situation réelle pour mesure cet aspect (exemple : un timestamp date + heure).

[tatayo]

Envoyé par gardangel

J'anticipe un inconvénient vraiment mineur. Que ValeurDéfaut ramène "" ou NULL change quoi ? .

Dans le cas d'une clé étrangère, null signifie qu'elle ne "pointe" vers aucun enregistrement, et "" vers un enregistrement dont la clé est "". Ce n'est pas du tout la même chose !

Tatayo.

[Hemgé]

Bonjour,

J'ai testé ValeurParDéfaut et la réponse est effectivement "" pour une rubrqiue dont la valeur par défaut est NULL et qui apparaît bien comme NULL avec WDMap.

Par contre, Gargandel, reste alors à étudier complètement comment se comporte les différents tests de NULL et "" tant en Windev qu'en SQL.

C'est ce qui a motivé mon post sur Null et les dates : dans une requête SQL, les rubriques NULL étaient détectées par IS NULL tandis que les rubriques vides ne l'étaient pas.
Et vice-versa.

Bonne journée
Hemgé

[Arnaud B.]

Bonjour,

Merci à tous pour vos retours, je me sens moins seul maintenant !

Comme l'a indiqué Tatayo, mon but n'est pas de savoir si la valeur d'une rubrique est Null, mais si la valeur par défaut de la rubrique dans l'analyse est Null.

Or ..ValeurDéfaut renvoie une chaine vide dans tous les cas, que la valeur par défaut soit effectivement une chaine vide "" ou Null.

Le test ..ValeurDéfaut = Null échoue également.

Pourquoi est ce important de faire la différence ? Là encore, comme l'a indiqué Tatayo, autant Null ne viole pas une contrainte de clé étrangère 0,1 autant la chaine vide "" la viole.

Vous me direz sûrement et vous aurez raison : ce n'est pas le cas dans Hyperfile.
En effet, Hyperfile ne fait pas de différence entre Null et une chaine vide (pour une rubrique texte), en ce qui concerne le respect d'une contrainte de clé étrangère.
De même, pour une rubrique numérique, Windev ne fait pas de différence entre 0 et Null.
C'est que l'on peut insérer dans la base de données"" (pour une chaine) ou 0 (pour une rubrique numérique) dans une rubrique FK_ID avec une contrainte de clé étrangère 0, 1 : aucune erreur ne sera déclenchée.

Tout ceci est vrai... mais seulement dans Hyperfile !

Ce n'est plus du tout vrai dans d'autres SGBD comme Postgres avec lequel nous travaillons.

Si vous insérez "" ou 0 dans une rubrique sur laquelle est posée une contrainte de clé étrangère 0,1, il va vous hurlez à la face et il aura raison ! Car "" ou 0 n'existe pas dans la table étrangère.

Seule la valeur Null indique que la valeur n'est pas renseignée et ne participe pas à la relation.

Si vous migrez une base Hyperfile existante vers un autre SGBD, vous avez intérêt à anticiper ce genre de problèmes !

Pourquoi avons nous besoin d'avoir cette information ? Parce que nous développons un équivalent de WDModif pour synchroniser automatiquement un schéma postgres avec l'analyse.

Donc si la valeur par défaut est Null, l'ordre de création sera "ADD COLUMN DEFAULT Null" et non pas "ADD COLUMN Default '' ".

D'après vos retours, je vois 2 pistes :
- tester ..ValeurDéfaut..Null = vrai (mais j'ai peu d'espoir que cette syntaxe soit autorisée) (merci Tatayo)
- faire HRaz(fichier, rubrique) et tester rubrique..nul (merci madsland)

Je vous tiens au courant.

Cdlt, Arnaud.

[Hemgé]

Comme écrit plus haut, sur une rubrique dont la valeur par défaut est NULL,
..ValeurParDéfaut renvoie une chaîne vide ('') et non le Null attendu/espéré.

Par contre, Windev gère vraisemblablement cette valeur de manière spécifique puisque l'affectation Rubrique = Null ne fonctionne pas et qu'il faut passer par la propriété Rubrique..Null = Vrai pour affecter NULL à une rubrique Hyperfile.

Et s'il y a gestion spécifique, tous les espoirs sont permis.
(Mais pour quelle version ? )

Hemgé

[gardangel]

Hemgé a écrit :

"Par contre, Gargandel, reste alors à étudier complètement comment se comporte les différents tests de NULL et "" tant en Windev qu'en SQL." Précises cette phrase stp.

Tayato, tu dis qu'il y a différence entre une clef à valeur NULL ("indication" d'un sans lien) et une clef à valeur "". Je suis curieux : dans quelle circonstance utilisée une clef avec "" sur un lien intertable ? Si cette clef fait référence à une autre table, cela signifie que la clef "unique" de cette table liée peut contenir une seule valeur "". Généralement, une clef possède un incrément logique (un id += 1) ou une chaîne ayant un incrément (un no social, une raison sociale, etc). La valeur "", pour sa représentation est en soi un NULL "logique". Dans son utilisation sans lien intertable, le NULL pourrait être un indicateur d'une valeur à vierge ou l'absence d'un "quelque chose". Mais ça reste un indicateur "X".

La valeur NULL aurait pu être un Faux de type booléen ou le chiffre 0 ou tout autre indicateur spécifiant une absence de saisie ou activité. Je ne comprends pas.

[tatayo]

Techniquement, une clé primaire peut être de n'importe quel type, et ne représente pas forcément un compteur (au sens large).
Je peux te donner un exemple: dans l'ERP que nous utilisons, la clé primaire des fiches articles est la référence de l'article, référence qui est une chaine saisie par l'utilisateur. Et ceci est vrai pour pas mal d'entités dans l'ERP (code client, code fournisseur, devise, tarif, catégories...).

Attention, je ne dis pas que c'est intelligent de créer un enregistrement dont la clé vaut "", je dis juste que techniquement rien ne l'empêche. Je voulais juste faire remarquer que "" et nul sont deux valeurs différentes.
"" est une chaine vide, null signifie que la rubrique n'est pas renseignée. Dans certains cas c'est utile de faire la différence. D'ailleurs Null ne vérifie aucune comparaison dans les requêtes...

De même pour les booléen. Null ne signifie pas faux, mais non renseigné.
Dans le cas d'un fichier personne, imaginons que le genre soit un booléen: vrai pour féminin, faux pour masculin (pour changer). Quand le genre est inconnu ou inapplicable (personne morale), je préfère mettre Null qu'une valeur arbritraire.

Donc pour résumer,ma remarque n'avait pas d'autre but que de rappeler que Null et "" sont deux valeurs différentes.
Tatayo.

[Nicolas_Jeanneau]

Bonjour,

j'abonde dans le sens de tatayo sur la différence. C'est aussi le cas pour les numériques et leur somme dans une requête : null pas de contenu à sommer, 0 la somme fait 0 !

Dans un système décisionnel, c'est vraiment important de faire la différence par exemple. Tout les null permettent de mettre en évidence les champs non remplis et pouvant dégrader la qualité des données dans la base.

Enfin pour revenir au sujet, la valeur par défaut d'un champ devrait pouvoir être trouvée même si la base n'est pas alimentée donc en soit il devrait retrouver à partir de l'analyse la valeur par défaut. C'est relativement grave comme problème en fait !

[Hemgé]

NULL, c'est pas si nul que ça et ce n'est même pas du tout nul !
C'est une institution, me semble-t-il.
Et son utilisation est relativement convenue, consensuelle.

La possibilité de rencontrer NULL dans une variable ou une rubrique, c'est comme une logique à 3 états, avec ce troisième état qui signifie que la variable ou rubrique soit n'a encore jamais été affectée soit ne l'est plus.

(Au passage : le champ interrupteur à 3 états devrait d'ailleurs renvoyer NULL et non -1, lorsqu'il est à l'état indéterminé).

On peut, comme suggéré, recourir à un booléen associé ou à une autre information logique, mais à titre de contournement pas "par essence".

" ... comment se comporte les différents tests de NULL et "" tant en Windev qu'en SQL."

A partir du moment où on sait qu'il existe des problèmes avec le NULL et qu'il n'est pas toujours détectable / comparable, soit on y renonce et cela ne me convient pas trop, soit on doit commencer à systématiser les situations où on veut l'utiliser et s'assurer qu'on peut le traiter, tout en restant à la merci d'une erreur non détectée ou d'une exception que l'on a pas mise en évidence.
Comme toujours dans ce genre de situation, la paranoïa rode.

Bonne soirée
Hemgé

[GCASPIC10]

Merci Hemgé,

L'utilisation d'interrupteur 3 états m'a permis de me dépoiler un peu...

Je ne comprenais pas pourquoi tout fonctionnait (enregistrement dans fichier, affichage dans fiche) à l'exception de la case à cocher grisée (3ème état) qui ne s'affichait pas !

Je me suis reposé la question à la lecture de ce message

ATTENTION : Pour rappel en effet, la valeur à exploiter est soit :

Code :

1
2
3
4
5
6
7
8
9
10
11
12
//Remarque : Si l'option gère les trois états, elle peut prendre pour valeur :
// 0 : option décochée
// 1 : option cochée
//-1 : option indéterminée (grisée)
SELON INT_Impression[1]..Valeur
	CAS 0 
		INT_Impression[1]..Libellé = "Imprimante"
	CAS 1
		INT_Impression[1]..Libellé = "Email"
	AUTRE CAS // idem CAS -1
		INT_Impression[1]..Libellé = "Imprimante + Mail"
FIN

La valeur -1 correspondant à la valeur null bien sur

A+

[laurent30s]

Dans l'analyse on peut générer le script SQL correspondant à une analyse (ou un fichier)

Dans le menu "Structure de fichiers .. Générer le script SQL". Puis l'assistant se lance.

J'ai fait un test vers Postgres mais le script généré ne reporte le fait que des rubriques sont à NULL.

Par contre vers PostgreSQL c'est bon... on a l'indication des rubriques par défaut à NULL... mais lui n'a pas les clés étrangères... et certains types sont différents bien sur...

Pas très cohérent tout ça...

[alexeyk]

Envoyé par laurent30s

Dans l'analyse on peut générer le script SQL correspondant à une analyse (ou un fichier)

Dans le menu "Structure de fichiers .. Générer le script SQL". Puis l'assistant se lance.

J'ai fait un test vers Postgres mais le script généré ne reporte le fait que des rubriques sont à NULL.

Par contre vers PostgreSQL c'est bon... on a l'indication des rubriques par défaut à NULL... mais lui n'a pas les clés étrangères... et certains types sont différents bien sur...

Pas très cohérent tout ça...

Et tu peux aussi essayer de faire des identifiants composés de plusieurs clés, puis faire un delete ou update sur l'une des clefs. Les mises à jour des clés ne sont pas répercutées, le delete cascade ne suit pas. Vive les integrités référentielles sur HF, pas très cohérent non plus.

Alex.

[Arnaud B.]

La génération de scripts SQL est complètement bugguée, en tout cas pour Postgres (mais je suppute que c'est le cas pour d'autres SGBD).

Effectivement, les types sont incohérents, les FK sont perdues, des index aussi...

Il y a plein de positions qui sont prises arbitrairement par Windev qui sont tout sauf des détails : les clés composées sont créés en tant que rubriques, alors que ce pourrait être sous forme d'index multi-colonnes... etc etc...

Bref, c'est un gadget inutilisable.

Cdlt, Arnaud.

Envoyé par laurent30s

Dans l'analyse on peut générer le script SQL correspondant à une analyse (ou un fichier)

Dans le menu "Structure de fichiers .. Générer le script SQL". Puis l'assistant se lance.

J'ai fait un test vers Postgres mais le script généré ne reporte le fait que des rubriques sont à NULL.

Par contre vers PostgreSQL c'est bon... on a l'indication des rubriques par défaut à NULL... mais lui n'a pas les clés étrangères... et certains types sont différents bien sur...

Pas très cohérent tout ça...