none
Problème de contraintes...

    Discussion générale

  • Bonjour,

    Je rencontre un problème avec mon DataSet sous VS. J'ai un projet ASP.Net avec un DataSet fortement typé, qui contient un TableAdapter.

    Lorsque j'effectue une requête SELECT, sans aucune raison VS me lève une exception

    "Impossible d'activer les contraintes. Une ou plusieurs lignes contiennent des valeurs qui violent les contraintes de type non null, unique ou de clé externe."

    Or, ma table ne possède aucune contrainte hormis la clé primaire et des champs non nuls. J'ai alors utilisé la technique du "Fill" avec un Try pour sérier l'erreur et j'obtient un message me disant que la colonne "ID" ne peut être nulle.

    Ce qui est complètement débile, car étant une clé primaire, aucun code n'aurait permis l'insertion d'une ligne sans clé primaire. De plus, le champ est de type UNIQUEIDENTIFIER avec un DefaultValue "newid()", ce qui fait que même si je m'était planté dans mon code et que j'avais réellement inséré une valeur nulle, SQL Server aurait automatiquement générer un ID pour la ligne.

    D'autre part en regardant sous SSMS, je ne vois aucun ligne dans la table qui à une valeur nulle pour l'ID...

    J'ai également désactivé les contraintes dans le DataSet (EnforceConstraints= False) mais bien sûr, ça fait kedal ! Je serais DRH chez MS j'en foutrait des développeurs dehors moi, je te le dis ! C'est pas croyable de voir des logiciels autant bourré de bug débiles et si peu fiable, quelle connerie ! 

    jeudi 11 juillet 2013 13:47

Toutes les réponses

  • Bonjour

    N'est pas la première fois, veuillea essayer de respecter l’Etiquette sur les forums Microsoft MSDN.
    Et pour résoudre votre problème, pouvez –vous vérifier la commande SQL de sélection du DataAdapter ?

    Merci

    Aurel


    Aurel BERA, Microsoft
    Microsoft propose ce service gratuitement, dans le but d'aider les utilisateurs et d'élargir les connaissances générales liées aux produits et technologies Microsoft. Ce contenu est fourni "tel quel" et il n'implique aucune responsabilité de la part de Microsoft.

    jeudi 11 juillet 2013 14:31
    Propriétaire
  • Bonjour,

    J'essayer de respecter, j'essaye...

    Mais lorsqu'on voit le peu de considération que porte Microsoft à ses clients, et bien on a pas envie de les respecter. Je me suis juste emporté car je travaille actuellement sur un projet important et lorsque je vois de tels défauts dans Visual Studio je ne peux que crier ma haine envers des gens trop bien payés pour la qualité médiocre du travail qu'ils fournissent ! En utilisant la technologie Microsoft, on prend le risque de voir son business paralysé à tout moment à cause de problèmes idiots, pensé par des gens qui apparemment n'ont pas toute leur tête.

    Pour la requête SELECT du TableAdapter, un simple SELECT champ1, champ2, champ3 WHERE id=@id comme il y en a des dizaines d'autres dans mon DataSet qui fonctionnent parfaitement.

    Après j'ai juste exprimé ma colère envers l'équipe qui développe Visual Studio chez MS, je n'ai rien contre les gens de ce forum qui prennent de leurs temps pour aider les autres, bien au contraire il ont tout mon respect. 

    De toute façon, je ne pense pas que je trouverais de réponse, il s'agit d'un simple bug, d'un défaut de conception à ajouter à la très longue liste des bugs de VS. Il va falloir que je "contourne". Toujours le même problème, on perd en recherche de bug idiots ce qu'on gagne en productivité...

    jeudi 11 juillet 2013 16:28
  • Merci de votre inquiétude. 

    Mais il s'agit bien d'un bug. J'ai pu trouvé la cause, en réalité dans ma table j'ai un champ qui accepte les valeurs nulles. Un champ de type Int. Au moment de la création du TableAdapter, celui-ci pour une raison inconnue a défini la propriété AllowDBNull à False. Cela fait partit des nombreux bugs aléatoires de VS, un de plus...

    J'ai donc modifié cette propriété et tout est rentré dans l'ordre. Mais cela ne me fera pas pour autant changer d'avis sur Visual Studio.

    Hier par exemple, alors que je travaillais en local sur un projet, j'ai téléchargé le DataSet du site de production vers mon site local via mon client FTP (Filezilla). Le projet était ouvert et m'a affiché un message m'indiquant que la source avait changé. J'ai cliqué sur "Recharger" et Visual Studio était sensé prendre en compte le nouveau fichier. J'ai alors effectué une modification sur le DataSet et je l'ai republié. Sauf qu'en réalité VS ne m'avait pas chargé le fichier et avait laissé l'ancien. Heureusement que j'avais des sauvegardes. Car le fichier datait de 15 jours. C'est inadmissible de voir autant de bugs au sein d'un seul et même logiciel sensé être conçu justement par des développeurs et pour des développeurs ! Qui plus est d'après mon expérience, Visual Studio est sans nul doute le logiciel professionnel qui comporte le plus de bug au monde et cela depuis des années. Quelle honte. Mais ce qui écoeur par dessus tout c'est de voir que vous effacez mes messages alors que je dis simplement la vérité. Vous n'avez même pas le courage d'assumer votre incompétence. 

    jeudi 18 juillet 2013 12:10
  • Bonjour

    Mais il s'agit bien d'un bug. J'ai pu trouvé la cause, en réalité dans ma table j'ai un champ qui accepte les valeurs nulles. Un champ de type Int. Au moment de la création du TableAdapter, celui-ci pour une raison inconnue a défini la propriété AllowDBNull à False. Cela fait partit des nombreux bugs aléatoires de VS, un de plus...

    Evidement un bug. Aucune chance que quelqu’un a changé la BD après la génération du dataset? Ou modifier la propriété après sa génération ?

    Sur l'autre bug je peux vous dire, qu’après plus de 10 ans d'utilisation de VS je n'ai pas vu ça. Si vous pouvez nous indiquer exactement les pas à suivre pour le reproduire, peut-être il sera résolu dans la prochaine version.

    Je dois vous rappeler de respecter Etiquette sur les forums Microsoft MSDN.

    N'est pas optionnel!

     


    Aurel BERA, Microsoft
    Microsoft propose ce service gratuitement, dans le but d'aider les utilisateurs et d'élargir les connaissances générales liées aux produits et technologies Microsoft. Ce contenu est fourni "tel quel" et il n'implique aucune responsabilité de la part de Microsoft.

    jeudi 18 juillet 2013 12:26
    Propriétaire
  • Pour la table non, elle n'a pas été modifiée. Ce qui est étonnant c'est que ce bug est survenue plus tard. Au moment des tests cela fonctionnait.

    "Sur l'autre bug je peux vous dire, qu’après plus de 10 ans d'utilisation de VS je n'ai pas vu ça." 

    Bien entendu les bugs de Visual Studio ne sont fréquents que sur les projet ASP.Net. Tout autre projet (WPF, Silverlight, Winform, Console...) fonctionnent à merveille. Les bugs y sont très rares.

    C'est vraiment ce que je trouve étonnant. Suis-je le seul à rencontrer autant de bugs depuis des années sur le développement ASP.Net ? J'ai pourtant testé VS sur XP, Vista, Windows 7 et j'ai eu l'occasion de travailler un petit peu sous Windows 8 que se soit des systèmes 64 ou 32 bits et avec VS2008 à 2012. 

    Beaucoup de bugs n'ont pas été corrigés. Comme ce bug ou le fichier CSS est tronqué on ne sait pour quelle raison. La prochaine fois que cela m'arrive, je viendrais ici vous déposer ma capture. Par contre ne me demandez pas comment reproduire le bug car il survient de façon aléatoire. Je sais bien qu'il y a forcément un élément déclencheur, mais il ne dépends apparemment pas d'une action utilisateur particulière. Si c'était le cas, j'aurais déjà tout fait pour l'éviter.

    C'est le cas pour le designer qui se mélange complètement les pinceaux dès que le formulaire devient trop complexe à gérer. Il n'est pas normal que VS prennent 70% des ressources processeur pour déplacer un élément sur le formulaire en mode design. Et ça, ça n'a jamais été corrigé ! Idem pour la sélection des balises qui ne fonctionnent pas, ou de façon aléatoire. Les templates des contrôles serveurs qui dès la mise à jour se referment, les tableaux qui lors des copier/coller mélangent les cellules....

    Vous n'allez pas me faire croire qu'après 10 ans d'utilisation de VS, vous n'avez jamais rencontré un de ces bug ?

    lundi 22 juillet 2013 12:45
  • En ce qui concerne l’AllowDBNull  je sus presque sûr que n'est pas un bug.

    Même des autres modifications dans la BD (éliminer une valeur default pour une colonne) peut « faire apparaitre » ce type de bug. On peut imaginer une dizaine de modifications qui font apparaitre ce bogue avant de dire que c’est une modification erratique d’un DataSet faite par VS.

    J’ai dit que je n’ai pas vu le deuxième bug dans ce thread : sélectionner l’option d’actualiser la source et le système ne fait pas ça.

    Pour les autres – j’ai rencontré un ou autre, mais je les ai éliminée en ne plus utilisant le mode designer. Le plus évident c’est qu’il consomme des ressources. Copier-Coller – en mode texte pas de mélange. CSS- éditer en mode texte- pas troncature. Sélection  - en mode texte ou le boite a sélection.

    Vous me dites que vous avez dizaines de contrôles dans un WebControl ou WebPage  mais, au moins de point de vue utilisateur ça c’est une mauvaise conception (c’est vrai, parfois on n’a pas une autre solution) mais personne n’aime pas à avoir des dizaines de contrôles a remplir.

    Aussi, j’ai vu que vous utilisez un serveur FTP comme solution de contrôle des sources. Pourquoi ne pas utiliser le vieux VSS ou TFS, ou un autre ?

    Comme ça vous avez la trace et vous savez exactement qui et comment a modifié le code.

    Cordialement,


    Aurel BERA, Microsoft
    Microsoft propose ce service gratuitement, dans le but d'aider les utilisateurs et d'élargir les connaissances générales liées aux produits et technologies Microsoft. Ce contenu est fourni "tel quel" et il n'implique aucune responsabilité de la part de Microsoft.

    lundi 22 juillet 2013 13:28
    Propriétaire
  • Donc la solution est d’utiliser le mode code ? En gros si on doit payer 1000€ Visual Studio pour s'en servir comme Notepad simplement parce que les développeurs Microsoft refusent de corriger les bugs depuis 5 ans ?

    Et donc si je comprends bien tout le monde fait pareil et n'utilisent le designer que pour des modifications minimes !

    Et tout le monde trouve cela normal, un logiciel à 1000€ dont la partie design n'est pas utilisée car bourrée de bug cela ne choque pas ? Ni les clients, ni Microsoft ? 

    Alors je dois être fou, ou le seul être humain sur terre à qui il reste un minimum de logique !

    Quand à dire que mes produits sont mal conçus car ils ont des dizaines de contrôles, on se demande à quoi servent donc les Datgrid, les FormView, les GridView, les DataList et leurs templates puisse qu'à vous entendre 10 contrôles c'est déjà trop pour un formulaire ASP.Net.

    Et en parlant de bugs vous feriez bien aussi de revoir ce forum car au simple appuis sur la touche DEL, la police réduit de taille...

    Bref, encore une question d'habitude.


    • Modifié Mayzz lundi 22 juillet 2013 13:50 Orthographe
    lundi 22 juillet 2013 13:48
  • C'est simple : j'utilise les fonctions VS qui me convient  (auto complète, debug, compilation pour nommer seulement le plus évidentes) et je ne les utilise pas ceux qui ne me convient.

    C'est simple : j'utilise les fonctions VS qui me convient  (autocomplete, debug, compilation, editeur DataSet/ editeur modele EF  pour nommer seulement le plus evidentes) et je ne les utilize pas ceux qui ne me convient. 

    Pour ce qui concerne la touché DEL - quel explorateur utilisez-vous?

    J'ai testé avec 3 et je ne peux pas la reproduire.


    Aurel BERA, Microsoft
    Microsoft propose ce service gratuitement, dans le but d'aider les utilisateurs et d'élargir les connaissances générales liées aux produits et technologies Microsoft. Ce contenu est fourni "tel quel" et il n'implique aucune responsabilité de la part de Microsoft.

    mardi 23 juillet 2013 08:00
    Propriétaire
  • J'utilise Google Chrome, le bug se produit lors ce que je saisi un texte et que je presse la touche DEL entre deux phrases pour supprimer par exemple les sauts de ligne en trop.

    Voici un exemple:

    Je saisi une phrase ici.

    Cette phrase est en taille réduite car j'ai supprimé le saut de ligne en trop entre la phrase du dessus et celle-ci.

    Voilà comment reproduire le bug de façon simple.

    Pour Visual Studio, il n'est pas question de convenance. Si il possédait un vrai éditeur visuel qui fonctionne et non un pauvre "programme tout buggué" nous l'utiliserions tous plutôt que de saisir du texte, car nous savons que c'est beaucoup plus pratique. Pourquoi Microsoft utilise toujours un WebBrowser pour l'aperçu ? Pourquoi en 5 ans un contrôle personnalisé pour le designer de VS n'a pas été développé ? 

    Imaginez si l’éditeur visuel XAML était identique ? Vous vous voyez créer des templates WPF ou XAML juste en tapant du code ? Non bien entendu. Ce n'est pas une question de choix, nous sommes obligé car Microsoft ne fait pas correctement son travail depuis 5 ans. C'est une honte pour des programmeurs de vendre un produit d'aussi mauvaise qualité. Même un débutant arriverait à faire mieux en une période si longue. On se demande vraiment pourquoi personne ne fait rien chez Microsoft. Si j'avais le temps je ferais un procès à Microsoft pour escroquerie. Car un bug peut arriver, mais vendre un produit qui ne fonctionne pas pendant 5 années consécutives ne porte pas d'autre nom que "arnaque".

    Mais j'ai trouvé une solution plus simple et j'ai commencé hier. Je prends maintenant des vidéos de ces bugs, lorsqu'ils se produisent et je les publierais sur Youtube. Peut être que quand Microsoft en aura marre de voir son produit dénigré ils feront le nécessaire.

    mardi 23 juillet 2013 10:35
  • Voilà, en 10 minutes deux autres bogues. 

    Un tableau tronqué durant l'édition d'un modèle de FormView.

    J'ai simplement voulu déplacer un contrôle HiddenField d'une cellule vers une autre du tableau en mode design et voilà le travail. Bien entendu je sais qu'il faut le faire en mode code, c'est plus simple. Mais pourquoi un truc aussi basique qu'un drag and drop ne fonctionne pas sous VS ?

    J'ai donc fermé la fenêtre en refusant l'enregistrement de la page, et Visual Studio m'affiche un message d'erreur inconnu en me parlant d'extension de fichier.

    Alors oui en effet il faut utiliser le mode code, seulement la sélection de celui-ci est totalement déroutée. Visuellement pour atteindre le "EditTemplate" d'un FormView, il faut cliquer sur le SmartTag, modifier les modèles et sélectionner "EditTemplate". En suite en mode "Fractionner" dans l'éditeur visuel, il suffirait de cliquer sur le contrôle HiddenField pour sélectionner la partie code (html/aspx) de celui-ci. Seulement un autre bug survient c'est que Visual Studio sélectionne tout le code du FormView, cela ne sert donc à rien. Alors on scroll le code pour trouver le contrôle et une fois qu'on l'a trouvé on clic sur le code du contrôle mais Visual Studio nous repositionne au début du FormView.

    Comment de tel bugs peuvent passer les tests chez Microsoft ???? Impossible que Visual Studio ait passé les tests, tellement de bugs ! Ne pas tomber sur un bug relève du miracle !

    C'est vraiment ridicule, quand allons-nous avoir un vrai éditeur qui fonctionne ? Pourquoi tant de bugs ? Ce n'est vraiment pas possible qu'une équipe de développeurs soit à ce point incompétente...

    Malheureusement on ne peut pas directement dialoguer avec ces gens la pour leur faire comprendre notre façon de penser !


    • Modifié Mayzz mardi 23 juillet 2013 17:48 othographe
    mardi 23 juillet 2013 11:37