Discussion :

[star]

VS2015 - WPF - ADO.NET - ACCESS

Je fais face à un comportement anormal lorsque j'enregistre des commandes d'un client dans une relation Maître/Détail au travers de deux DataGrid.

Lorsque je saisis un client sur la dernière ligne vide du contrôle DataGrid Maître, ensuite je saisis une commande de ce client dans le DataGrid Détail sur la dernière ligne de ce contrôle, et que je clique sur le bouton d'enregistrement, pendant la phase de consolidation dans la source de données, l'application efface le contenu du contrôle détail alors que la vue de la table des commandes a bien pris en compte la commande que je viens d'enregistrer.
Si je relance l'application et que je me positionne sur le client que je viens de rentrer, la commande apparaît bien dans le DataGrid des commandes.

J'ai tracé le parcours en phase de consolidation et m'aperçois que l'anomalie est liée à la fonctionnalité de mise à jour des clés étrangères des enregistrements du DataTable Commandes lorsque la numérotation automatique du client est effectuée dans l'évènement RowUpdated du Datable Clients. La propriété de la relation est Update Cascade.

Avant lancement de la consolidation


Pendant


Après consolidation


Je ne sais vraiment pas comment régler ce problème et cela fait quelques jours que je cherche désespérément. Je suis tombé sur des liens sur internet qui en parlent mais sans solution :
https://stackoverflow.com/questions/...-from-datagrid
https://connect.microsoft.com/Visual...-binding-issue

Chose encore plus bizarre, lorsque je saisis un nouveau client et que je l'enregistre d'abord dans un premier temps, puis ensuite je saisis une commande, la colonne de clé étrangère de l'enregistrement Commande est initialisée de manière erronée avec une numérotation auto incrémentée, alors qu'elle devrait reprendre la valeur de la clé primaire de l'enregistrement Client. Mais bon, cela est un autre problème mais qui pourrait être cependant lié au premier.

Aussi, je me permets de vous indiquer un lien de téléchargement de mon projet WPF pour éventuellement que vous puissiez reproduire le comportement et éventuellement m'aidez à résoudre ce problème qui est très bloquant pour moi et le projet sur lequel je travaille.

https://drive.google.com/file/d/0B64...ew?usp=sharing

Merci d'avance de votre aide
.

[star]

Bonjour,
Je souhaiterais corriger un point de mon post concernant la numérotation automatique du client qui est plutôt effectuée dans l'évènement RowUpdated du TableAdapter du DataTable Clients. La relation entre deux tables Clients et Commandes inclue la contrainte de clé étrangère et prévoie les règles Update Cascade, Delete Cascade et Accept/Reject None.

le code de la méthode RowUpdated est :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
 
        private void dataadapterClients_RowUpdated(object sender, OdbcRowUpdatedEventArgs args)
        {
            if (args.RecordsAffected > 0)
            {
                if (args.StatementType == StatementType.Insert)
                {
                    Console.WriteLine("[DBWpf, ClientsTableAdapter] dataadapterClients_RowUpdated, Attibue un numero d'ordre au client nouvellement cree");
 
                    OdbcCommand cmdIdentity = new OdbcCommand("SELECT @@IDENTITY", args.Command.Connection);
                    cmdIdentity.Transaction = Transaction;
                    Console.WriteLine("[DBWpf, ClientsTableAdapter] dataadapterClients_RowUpdated, Avant numerotation automatique du client");
                    int id = (int)(cmdIdentity.ExecuteScalar());
                    Console.WriteLine("[DBWpf, ClientsTableAdapter] dataadapterClients_RowUpdated, Client_ID : " + id);
                    args.Row.Table.Columns["Client_ID"].ReadOnly = false;
                    args.Row.Table.DataSet.Tables["Commandes"].Columns["Client_ID"].ReadOnly = false;
                    MessageBox.Show("Stop ??????????????????");
                    args.Row["Client_ID"] = id;
                    args.Row.Table.Columns["Client_ID"].ReadOnly = true;
                    args.Row.Table.DataSet.Tables["Commandes"].Columns["Client_ID"].ReadOnly = true;
                    Console.WriteLine("[DBWpf, ClientsTableAdapter] dataadapterClients_RowUpdated, Apres numerotation automatique du client");
                }
                if (args.StatementType == StatementType.Insert || args.StatementType == StatementType.Update)
                {
                    Console.WriteLine("[DBWpf, ClientsTableAdapter] dataadapterClients_RowUpdated, Recuperation de l'horodatage de la ligne client. Type d'ordre : " + args.StatementType);
 
                    int intCriteria = 0;
                    if (args.StatementType == StatementType.Insert)
                        intCriteria = (int)args.Row["Client_ID"];
                    else
                        intCriteria = (int)args.Row["Client_ID", DataRowVersion.Original];
                    OdbcCommand cmdStamp = new OdbcCommand("SELECT Stamp FROM Clients WHERE Client_ID = " + intCriteria, args.Command.Connection);
                    cmdStamp.Transaction = Transaction;
                    Console.WriteLine("[DBWpf, ClientsTableAdapter] dataadapterClients_RowUpdated, Avant ExecuteScalar");
                    DateTime dteStamp = (DateTime)(cmdStamp.ExecuteScalar()); // DateTime.Now
                    Console.WriteLine("[DBWpf, ClientsTableAdapter] dataadapterClients_RowUpdated, Horodatage : " + dteStamp);
                    args.Row.Table.Columns["Stamp"].ReadOnly = false;
                    args.Row["Stamp"] = dteStamp;
                    args.Row.Table.Columns["Stamp"].ReadOnly = true; // true
                }
            }
            else
            {
                // args.Row.RowError = "Conflit d'acces concurrentiel optimiste rencontre"; // Concurrency Violation Encountered
                // args.Status = UpdateStatus.SkipCurrentRow;
            }
        }

J'ai donc une forte présomption que l'anomalie proviendrait de l'instruction située juste après le MessageBox.Show() qui initialise l'ID du client et propage la mise à jour (Update Rule Cascade) aux enregistrements enfants correspondant aux commandes du client (une seule commande dans le cas de l'exemple de mon post) :

Code :

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

1
2
3
 
MessageBox.Show("Stop ??????????????????");
args.Row["Client_ID"] = id;

Le mécanisme de liaison "TwoWay Binding" de WPF devrait assurer la mise à jour de l'UI, mais dans le cas présent, je fais face à un effacement du DataGrid des commandes bien de la ligne de la commande ait été ajoutée à la table Commandes du Dataset ????



Est-ce que quelqu'un pourrait m'expliquer ce que j'aurais oublié de faire pour que cela fonctionne correctement ?

Merci d'avance
.

[star]

Je n'ai toujours pas réussi à trouver une solution mon problème de non affichage des enregistrements à l'issue d'une saisie sur la dernière ligne vide du DataGrid Détail.
Je désespère...
Merci à toute âme charitable qui pourrait m'aider à le résoudre
.

[star]

Pourriez-vous me confirmer qu'il est effectivement possible de "binder" des contrôles WPF (DataGrids) à des sources de données ADO.NET (DataViews et Datatables) ?
Merci
.

[Noxen]

Pour DataView je pense que oui, ça implémente IList, ICollection... Pour DataTable c'est moins sûr. Mais ça ne me parait de toute façon pas une très bonne idée. Pourquoi tu ne veux pas passer par un pattern MVVM ? Ça te permettrait de repartir les difficultés sur plusieurs couches.

[star]

Ce n'est pas trop pour moi la question d'utiliser un pattern plutôt qu'un autre.
Je cherche à faire tourner mon appli avec certaines technos : VS2015 - WPF - ADO.NET - ACCESS, sans recours à un pattern particulier.
A vrai dire, je voudrais reproduire d'une certaine manière en WPF quelque chose qui fonctionne parfaitement en WinForms... (;
Jusque-là, je n'ai rencontré aucun souci, sauf le cas de figure discuté ici.
https://connect.microsoft.com/Visual...wupdated-event
.

[star]

J'ai beau cherché par tous les moyens, mais je n'ai jusque-là trouvé aucune solution à mon problème
J'aurais vraiment besoin que quelqu'un m'aide à le régler
Merci à vous
.

[star]

Bonjour la communauté,
Ce lien concernant les derniers développements relatifs à l'objet de mon feedback au Support Microsoft : https://connect.microsoft.com/Visual...wupdated-event

De l'aveu même des ingénieurs du support technique, il s'agit belle et bien d'un bug WPF - ADO.NET datant d'il y a au moins 7 ans, qui a été partiellement corrigé au niveau des API ADO.NET en 2011 dans la version 4.5 du .NET Framework, mais pas du tout du côté des API WPF car non visé dans le workflow de validation des corrections de bugs. De plus, ils vont devoir reprendre les investigations depuis le début en raison de la perte des tests unitaires entrepris entre temps.

Mais bon, cela ne règle en rien mon problème immédiat. j'attends encore qu'ils me proposent une solution de contournement réalisable sans trop de pirouettes abracadabrantes.

Que va donc être l'issue de ce bug ?
Est-ce que les ingénieurs de Microsoft comptent le fixer dans les prochaines mises à jour du Framework. Pour la 4.7, c'est acquis il est déjà trop tard.
Pour ma part, je pense que Microsoft devrait absolument régler ce bug dans une certaine mesure, parce qu'il en va de la crédibilité de tout le Framework d'accès aux données ADO.NET et de toute la mécanique de liaison du WPF. Sans une correction adéquate, l'ensemble de l'API est sans aucun intérêt, on peut le prendre et le jeter à la corbeille (Il faudra qu'elle soit bien grande). Et je ne parle même pas de l'expérience utilisateur pour être dans le vent.
Quelle va être la deadline pour une résolution ?

Pour seule indication encourageante, ils rajoutent à la fin de leur réponse : "You may receive a general 'Feedback Item Updated' notification as well, if any other changes were made by Microsoft".
J'aime beaucoup la petite nuance conditionnelle du "if".

Après 7 longues bonnes années d'attente, Il est urgent d'attendre encore
La suite des évènements au prochain épisode
.

GMT-10, Jeudi 13/07/2017
Réponse du Support Microsoft : The WPF team will look at fixing this in a future release. When it's fixed, we'll reply to this thread. Given the current backlog and release schedules, the best estimate would be roughly a year from now.
Commentaire : Minimum 1 an d'attente pour la correction du bug WPF. Fidèle au précepte d'Auguste, on inscrira la devise ci-après au nom de Microsoft : "Hâte-toi lentement"

Ma réponse au support :
Thank you for having planned a fix to this bug problem, despite the estimated calendar of a year which is quite long I find. Would it not be possible to settle it more quickly?
The prerequisites for my IT development projects depend on it. Because of this bug, I am unable to deliver them on time and see myself probably having to pay penalties.

What could be the workaround to the specific case of the bug so that I can continue my projects, deliver them on time and avoid loosing money?

I would greatly appreciate your assistance in setting up a temporary workaround base on my test project downloadable at this web address: https://drive.google.com/file/d/0B64...ew?usp=sharing
Thank you very much for your help
.

[star]

GM-10, vendredi 14/07/2017

Réponse du Support Microsoft :

If you have a Premier support contract, you can request a hotfix via your CSS representative. To set expectations, your request would likely be refused on the grounds that the bug has existed for 10 years with only two complaints, and the first complainant (from 2010) went silent and got no up-votes. (Hotfixes normally fix regressions, or core scenarios that block lots of people.) You'd have to supply a very strong business case.

I don't see any simple workarounds. The bug is a result of miscommunication between ADO and WPF, which you can't affect from the app. The best I can suggest is to try implementing a "wrapper" data model using types that raise the kind of events WPF needs to hear - ObservableCollection<T>, items exposing INotifyPropertyChanged, etc. This is a huge amount of work, as you'll have to translate between ADO's model and the wrapper model, solving the very same communication problems that led to the bug (with no guarantee you can do so). I don't imagine you'd have the time or resources to do it.

Alternatively, perhaps you could restructure your data to avoid using the "data relations" features of ADO. Again, I don't imagine that's a real option.

We apologize for the inconvenience caused by this bug, and thank you for reporting it so that we can fix it in the future. I know that doesn't help you today, but given our backlog, priorities, and schedule, it's the best we can do.

Ma demande au support :

A simple workaround could be a relinkage among the DataGrid objects, CollectionViewSource objects, and DataViews of the DataTable objects after the commit phase, by reestablishing the binding between them.
This is the solution I'm trying to pace in the code behind, except that I can not figure out how to get it right in code.
Unfortunately, I do not have enough knowledge of WPF API to write it by my own.
This is why I kindly ask for your support. Could you at least bring your technical assistance in carrying it out?

I feel that you have absolutely no awareness of the importance of this bug and its impact on the framework implementing ADO.NET coupled with WPF.
For developers coming from the WinForms platform, willing to migrate their applications to WPF, this feature is most crucial for a smooth transition.
Without a bug fix, the entire binding interface API between ADO.NET and WPF would no longer have any interest. You can throw it into the trash can.
I suggest you think carefully on it and measure the decisions you will make.
It's not because this bug was only raised by two people in the entire universe that it takes away any credibility to the thing.
What is the most valuable foundation of developers today? WinForms or WPF? What is Microsoft's intention for WPF? Is it not WinForms base smooth migration to WPF?
Otherwise, it would has meant that I did not catch a thing of the whole story.
If it is so, then forget about it!
Sincerely
.

[François DORIN]

Bonjour,

J'ai regardé un peu et j'en est aussi conclu au bug.

Je ne suis pas spécialiste WPF, mais j'ai essayé pas mal de chose, et rien n'y à fait (forcer un reload(), modifier la source, modifier le binding, etc...) et à chaque fois, j'ai le même résultat. J'ai l'impression qu'il faudrait changer le CollectionViewSource au niveau du maître pour réussir à faire quelque chose. Mais dans ce cas, on perdrait la sélection, qu'il faudrait alors refaire via du code. L'intérêt d'utiliser une CollectionViewSource perdrait alors entièrement son intérêt.

Que va donc être l'issue de ce bug ?
Est-ce que les ingénieurs de Microsoft comptent le fixer dans les prochaines mises à jour du Framework. Pour la 4.7, c'est acquis il est déjà trop tard.
Pour ma part, je pense que Microsoft devrait absolument régler ce bug dans une certaine mesure, parce qu'il en va de la crédibilité de tout le Framework d'accès aux données ADO.NET et de toute la mécanique de liaison du WPF. Sans une correction adéquate, l'ensemble de l'API est sans aucun intérêt, on peut le prendre et le jeter à la corbeille (Il faudra qu'elle soit bien grande). Et je ne parle même pas de l'expérience utilisateur pour être dans le vent.
Quelle va être la deadline pour une résolution ?

Il faut bien comprendre que ce n'est pas simple de modifier un bug dans le framework .Net, et pour plusieurs raisons.

Tout d'abord, Microsoft propose une API très stable depuis toujours. Il est très rare qu'une API publique change de comportement. Et lorsque c'est le cas, c'est toujours motivé par une raison valable (par exemple, la sécurité).

Ensuite, corriger techniquement un bug "est facile". S'assurer que cela ne produit pas d'effet de bord en est une autre, qui peuvent être très subtile et venir impacter des applications qui fonctionnent très bien en est une autre. J'ai déjà eu à subir cela dans le cadre d'un projet, et j'avais que c'est très désagréable. Mise à jour via Windows Update, et c'est l'application qui devient inutilisable (le composant CristalReports pour générer des rapports au format PDF s'est soudainement mis à prendre 100% d'un processeur pendant 10min pour générer un pdf au lieu de le faire de manière quasi-instantanée. Cela sur un serveur web, avec 2 rapports lancé en même temps, l'application était en carafe).

Enfin, corriger le bug en lui-même peut éventuellement demander une refonte importante de l'implémentation actuelle, avec tous les risques que cela encourt et que je viens de mentionner au paragraphe précédent. Devant le peu d'utilisateurs impactés jusqu'à présent en 7 ans, je ne suis guère étonné qu'il n'y est pas eu plus d'investissement.

Maintenant, quand je lis que "que l'API est bonne à jeter", je n'interpète cela que comme l'expression d'une frustration. Car l'API est bel et bien utilisé, par de nombreux utilisateurs et qui ne partagent pas le même point de vue ! Il y a un bug, c'est malencontreux, mais c'est inévitable. Si je suivais ton raisonnement, alors je dirais que SQL Server est bon à jeter car j'y ai découvert un bug. Mineur (une fonction qui devrait être déterministe qui ne l'est pas), mais qui a des conséquences et provoque des limitations (notamment dans la gestion des vues indexés / colonnes calculés). Ben j'ai revu ma conception et j'ai fais autrement. C'est chiant, mais c'est ainsi.

Après, Microsoft a proposé aussi un hotfix. La seule chose, c'est qu'il faut avoir un compte premium.

[star]

Merci François pour ta contribution.

j'ai essayé pas mal de chose, et rien n'y à fait (forcer un reload(), modifier la source, modifier le binding, etc...) et à chaque fois, j'ai le même résultat.

Tes tentatives m'intéressent beaucoup. Pourrais-tu partager tes codes ici afin que je puisse les comparer aux miens ?

Merci
.

[François DORIN]

Je n'ai que ma dernière tentative à disposition. Je n'ai pas sauvegardé l'historique.

Code :

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

1
2
3
4
5
6
7
8
private void Check_Click(object sender, RoutedEventArgs e)
{
    System.Windows.Data.CollectionViewSource detailsViewSource = ((System.Windows.Data.CollectionViewSource)(this.FindResource("detailsViewSource")));
    Binding binding = new Binding();
    binding.Source = detailsViewSource;
 
    detailsDataGrid.SetBinding(DataGrid.ItemsSourceProperty, binding);
}

Il s'agit d'un code que je lance manuellement (j'ai rajouté un menu pour cela). Ici, j'ai essayé de recréer le binding au niveau de detailsViewSource, mais sans succès...

[star]

En effet, ce bug est très frustrant dans le cas où l'on cherche à élaborer une interface graphique Maître/Détails, pourtant classique dans les applications de gestion, mettant en oeuvre deux contrôles de type grille.
Lorsque je dis qu'en raison de ce bug, l'API de liaison WPF avec une source de données ADO.NET est bon à être jeté à la poubelle, c'est parce qu'il devient totalement inutilisable dans ce cas.
Quel est l'intérêt si l'utilisateur ne peut même pas saisir l'information et assurer sa persistance au travers de cette interface.
C'est pourquoi, je considère personnellement qu'il s'agit ici plutôt d'un bug majeur.
On peut toujours contourner les obstacles et faire autrement, mais en terme d'expérience utilisateur, on ne restitue pas forcément la même chose.
Je m'étonne seulement qu'il n'y ait pas plus de réaction sur ce forum et qu'il n'y ait pas plus de développeurs à demander la correction de ce bug. C'est à croire que très peu gèrent l'interface utilisateur de leurs applications suivant cette méthode.
.

[François DORIN]

Il faut bien comprendre qu'il y a une multitude de manières d'arriver à un résultat, chacune étant plus ou moins différentes en fonction des technologies employées, de l'expérience de l'utilisateur, etc...

Je pense que peux de gens sont impactés par ce bug à l'heure actuelle car peu de monde lient WPF, DataSet, structure Maitre/Détails, Binding et données modifiables (car c'est cette configuration particulière qui pose problème). Autant cette liaison est courante (car historique !) avec Winform, autant avec WPF, une technologie plus récente, les gens ont certainement tendance à utiliser des méthodes d'accès aux données plus récentes comme Entity Framework.

Lorsque je dis qu'en raison de ce bug, l'API de liaison WPF avec une source de données ADO.NET est bon à être jeté à la poubelle, c'est parce qu'il devient totalement inutilisable dans ce cas.
Quel est l'intérêt si l'utilisateur ne peut même pas saisir l'information et assurer sa persistance au travers de cette interface.
C'est pourquoi, je considère personnellement qu'il s'agit ici plutôt d'un bug majeur.

Même si c'est bloquant pour toi avec ton implémentation actuelle, cela ne fait pas de ce bug un bug majeur pour autant. Comprends bien :

• Le framework .Net est utilisé par des millions de développeurs
• Il faut une configuration bien particulière (WPF + DataSet + Binding + Maitre/Details + Modification)
• En 7 ans, seules deux personnes ont soulevé un problème dans cette configuration bien particulière
• Aucune atteinte à la sécurité (pas d'introduction de faille a priori)
• Possibilité de faire autrement (mais il faut revoir la structure de l'application)

[star]

Bonjour François,

Je suis content de m'apercevoir d'être bien compris dans mes explications, et ton dernier post l'atteste.

J'estime juste, qu'après tant d'effort de la part de Microsoft dans la création de toute une infrastructure de conception (Designer de Datasets sources de données, Glisser/Déposer dans le Designer d'interface utilisateur, Liaison de données et Classes d'accès aux données externes), on en arrive à un produit à trois quarts finalisé.

Nous devrions tous voter pour cette demande de correction de bug, et nous obtiendrions alors un outils quasi parfait. Pour voter : https://connect.microsoft.com/Visual...wupdated-event

Merci
.

[star]

Pour ceux que cela intéresse, Microsoft incorpore dans la prochaine version du Framework .Net 7.4.2 la correction du bug :

In a master/detail scenario using ADO data, changing the primary key of a master item cleared the display of the corresponding details, with no way to display them thereafter. This is fixed by default for apps targeting .NET Framework 4.7.2, and for all apps that set the app-context switch Switch.System.Windows.Data.DoNotUseFollowParentWhenBindingToADODataRelation to false. [457740, PresentationFramework.dll, Bug]

https://github.com/Microsoft/dotnet-...052-changes.md

.

[star]

ISSUE intégrée par Microsoft dans la dernière version .NET 4.7.2 : "In a master/detail scenario using ADO data, changing the primary key of a master item cleared the display of the corresponding details, with no way to display them thereafter. This is fixed by default for apps targeting .NET Framework 4.7.2, and for all apps that set the app-context switch Switch.System.Windows.Data.DoNotUseFollowParentWhenBindingToADODataRelation to false. [457740, PresentationFramework.dll, Bug]"

Lorsque je compile, établis l'édition de lien et exécute directement sous VS2015, le bug persiste, les détails correspondants sont supprimés et ne sont donc pas réaffichés proprement.

Par contre, si j'exécute l'application ciblant .NET Framework 4.7.2 directement à partir du système d'exploitation Windows, le bogue ne se produit pas et l'affichage des détails correspondants est mis à jour correctement.

Serait-il possible de résoudre ce problème lors de l'exécution au travers de Visual Studio 2015 ?

Merci pour vos réponses

.