Problème
1. Il existe un DataGridView, une des colonnes est DataGridViewComboBoxColumn;
2. Les données sont jetées dans la grille via le DataSource, comme un DataTable (pas ligne par ligne, c'est important);
3. Les données dans le ComboBoxColumn sont également liées, la source de données a un DataMember rempli, ligne par ligne ou pas - peu importe, la structure de données spécifique n'est pas non plus importante, le ValueMember qu'il contient est Integer, Long ou même String.
Lors de la sélection de quelque chose dans la liste déroulante, dgv_DataError détecte une erreur: "Valeur DataGridViewComboBoxCell non valide". Et en la remplissant - elle.
Chercher
Google n'a publié que deux pages et demie de forums. Cela signifie que le problème est répandu, mais qu'il ne peut être résolu au niveau intermédiaire. Mauvaises directions de développement de la pensée:
a) Après avoir lié les données, parcourez chaque ligne et utilisez les poignées pour réaffecter la valeur dans la cellule, en la trouvant dans la liste.
b) Raccrochez la gestion dgv_DataError.
En même temps, lorsque vous remplissez manuellement les lignes du tableau via Rows.Add (), tout va bien.
Mes collègues ont malheureusement essayé de comprendre ce qui n'allait pas avec la liste, mais le problème n'était pas avec elle, mais avec le type de non-concordance.
Historiquement, MS SQL utilise la décimale pour une colonne avec l'identité activée. Oui, il est décimal (18,0), mais il reste toujours un type de données fractionnaire. Je suis d'accord, il est toujours pratique de voir la décimale de l'index. Si j'attends jusqu'à un million d'enregistrements par an, alors décimal (7,0) suffit pour 10 ans et décimal (10,0) pour 10000. Disons que le Soleil explose dans 5 milliards d'années - comptons les chiffres: 6 + 9, c'est-à-dire decimal (15,0) suffit, et la valeur par défaut 18 - avec une marge.
Et dans la liste, nous avons Integer, Long ou même String!
Nous remplissons les lignes avec des stylos, le blockhead de fer transforme implicitement tout ce qui est fractionnaire et non fractionnaire pour nous. Lent et fiable. Et nous voulons que cela soit rapide, mais les économies sont réalisées, notamment l'absence de vérifications de type et de conversions inutiles.
En conséquence, nous rencontrons deux problèmes:
1. Lors du chargement des données dans une table, au lieu des noms d'en-tête de la liste, les ID de la base de données sont affichés dans la colonne.
2. Lorsque vous sélectionnez un nom d'en-tête dans la liste déroulante, la valeur de la cellule n'est pas mise à jour.
Décision
Si la base de données est très, très volumineuse, ancienne ou indisponible pour le développeur d'interface, utilisez des index décimaux dans la zone de liste déroulante.
S'il est plus facile de changer la structure des tables dans la base de données, alors utiliser bigint pour les clés étrangères est bon, il est plus grand que décimal (18,0) de presque un bit entier et plus rapide.