Discussion :

[noftal]

Bonjour,
Mon appli gère une base de données.
Grâce à des BindingSource, je mets à jour des champs fils en fonction de la valeur de champs père.
Sur une base de données constituée, j'ai modifié la structure du fichier de la base de données pour ajouter un champ à l'une des tables.
Quand, dans l'appli, j'enregistre une modification de l'un des champs de cette table, le binding source correspondant ne se met pas à jour correctement depuis que j'ai créé ce nouveau champ.
En creusant, je me suis rendu compte que c'est lié à la valeur "null" de ce champ (valeur normale car je viens de le créer).
En effet, si je modifie la structure de la bdd pour que la valeur par défaut de ce nouveau champ soit 0, le binding source marche correctement.
Dans mon cas présent, ça ne me dérange pas de forcer la valeur par défaut du champ à 0 parce que le sens précis de ce champ, qui est de type integer, s'y prête bien.
Je voulais savoir si vous avez déjà rencontré ce genre de pb, ou si vous avez une explication. Je ne pourrai pas toujours forcer la valeur du nouveau champ à 0 à chaque fois que je déciderai d'en créer un.

En mode debug pas à pas, c'est à partir de cette instruction, semble-t-il que ça commencer à partir en sucette :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 bs_MaTable.Filter = "Numero = " & CurrentKey

Si je mets un espion sur l'une des valeurs de l'enregistrement courant,
- avant création du champ, après l'exécution l'instruction ci-dessus, l'espion renvoie bien une valeur
- après la création du champ, après l'exécution de l'instruction ci-dessus, l'espion renvoie une valeur empty

Comme, pour l'instant, j'ai contourné le pb, ne me répondez que si ce pb vous rappelle quelques chose. Ce n'est pas la peine de passer trop de temps dessus

[strikel]

pourquoi ne pas tester sur la valeur null

Pour les champs numériques :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
bs_MaTable.Filter = "Numero = " & CurrentKey & " or numero is null"

Pour de l'alpha attention :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
bs_MaTable.Filter = "Numero = '" & CurrentKey & "' or numero is null"

[noftal]

Non, tu m'as mal compris.
CurrentKey n'a rien à voir avec le nouveau champ.
Je reprends.
Si j'ai un champ texte qui affiche le champ0 de ma table.
Je mets un espion sur "TXT_Champ.text" de façon à voir si bs_matable réagit bien.

L'espion affiche la bonne valeur jusqu'au moment où s'effectue dans mon code l'instruction que je citais.
le bs_matable.Filter (quel que soit ce qui se trouve derrière) modifie le bindingsource. Il est donc normal que TXT_Champ.text change de valeur.
Au passage de l'instruction bs.Filter...,
- avant ajout de mon nouveau champ, TXT_Champ.text affiche la bonne valeur
- après ajout de mon nouveau champ, TXT_Champ.text affiche la valeur empty.
Alors que, a priori, le nouveau champ n'interfère pas dans le résultat de bs.filter.

[strikel]

ok c'est plus clair.
As tu vérifier que le datasource de bs_MaTable est toujours valide ?
il faudrait voir le code que tu utilises pour ajouter ton champ

[noftal]

En fait, je l'ai dit mais ce n'était pas très clair : j'ajoute mon nouveau champ directement dans le fichier de base de données, sans passer par le code.
J'utilise un SQL designer qui me permet de manipuler mes tables comme dans Access.
Donc le bs n'est pas modifié. Il représente la liaison à la datatable qui elle même représente la table de la BDD dans laquelle j'ai ajouté un champ.
Bien sûr j'ai mis à jour mes datatables dans le XSD pour qu'elles englobent bien le nouveau champ.

[Kropernic]

Je n'ai pas encore creusé pour savoir pourquoi mais VB.NET n'aime pas les marqueurs NULL (je rappelle que ce n'est pas une valeur) en général.

Si par exemple on rempli un SqlDataReader à l'aide d'une requête pouvant renvoyer des marqueurs NULL pour certaines colonnes, si on tente d'accéder à un item du SqlDataReader contenant un marqueur NULL, une exception est levée. C'est pourquoi, avec ce genre de requête, il faut obligatoirement tester chaque élément (étant dans une colonne pouvant contenir des marqueurs NULL) à l'aide de IsDBNull.

Je ne serais qu'à moitié étonné que ton problème ait la même origine.

Mais quoi qu'il en soit, du point de vue de la normalisation le bonhomme NULL (©fsmrel ?) est à proscrire. Son apparition est le signe d'une erreur de modélisation de la base de données d'une base de données pas assez normalisée.