Discussion :

[AMP29]

Bonjour,

Presque tout est dans le titre.

Ma méthode Update met à jour le dataset mais n'écrit pas la modif dans la base.

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
 
        private void btnEnregistrer_Click(object sender, EventArgs e)
        {
            if (connexion == null) return;
 
            //------ Récup & Mise en forme pour enregistrement --------
            Int32 Key = Int32.Parse(ListExtraire.SelectedIndex.ToString()) + 1;
            int CleRef = Key;
            int CleGis = Lire_Cle_Primaire_Table("Gisement", GisementTxt.Text); // case = 0 >> Création de catégorie ? 
            //----------------------------------------------------------
 
 
            SqlCommand commandUpdate = new SqlCommand("UPDATE Items SET Gisement = @Gisement WHERE REF = @REF", connexion);
 
            commandUpdate.Parameters.Add("@REF", SqlDbType.Int);
            commandUpdate.Parameters["@REF"].Value = CleRef;
            commandUpdate.Parameters.Add("@Gisement", SqlDbType.Int);
            commandUpdate.Parameters["@Gisement"].Value = CleGis;
 
            builderItems = new SqlCommandBuilder(itemsTableAdapter);
 
            builderItems.DataAdapter = itemsTableAdapter;
            itemsTableAdapter.UpdateCommand = commandUpdate; 
 
            try
              {
                    this.Validate();
                    commandUpdate.ExecuteNonQuery();
                    MessageBox.Show("Update successful");
              }
                catch (System.Exception ex)
              {
                    MessageBox.Show("Update failed");
              }
        }

Aucune erreur à l'exécution.
J'ai dû essayer 20 trucs différents.
Pour info

Code :

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

itemsTableAdapter.Update(artcollectionDataSet.Tables["Items"]);

à la place du ExecuteNonQuery() ne fonctionnait alors pas du tout.

Merci

[AMP29]

Quel plaisir de passer ses journées à écumer le net Anglais-Français pour trouver une lueur d'explication !

Voici ce que j'ai trouvé sur https://social.msdn.microsoft.com/Fo...csharplanguage
Traduction de l'Anglais :

Le problème était que lorsque j'ai importé le fichier TestDB.MDF dans mon projet Visual 2010, une copie de celui-ci a été effectuée dans le dossier du projet.
Lorsque vous exécutez / déboguez le programme, une autre copie de ce fichier est créée et placée dans le dossier \ bin \ Debug \.
Dans la chaîne de connexion que j'utilisais, j'avais mentionné: AttachDbFilename = | DataDirectory | \ TestBuildDB.mdf .. Cela signifiait que toutes les lectures / écritures étaient effectuées sur la copie dans le dossier bin \ Debug.
Cependant, le fichier TestDB.MDF que je cherchais pour vérifier si des enregistrements ont été insérés ou non, était dans le dossier du projet! Donc, fondamentalement, il y avait deux fichiers MDF, et j'écrivais les enregistrements dans un fichier, mais j'essayais de les trouver dans l'autre

Lorsque vous ajoutez un fichier MDF dans votre projet VS2010, VS2010 établit par défaut une connexion à ce MDF , d'où vous pouvez parcourir les éléments de ce fichier MDF.
Le fichier MDF utilisé à cet effet était celui placé dans le dossier du projet, PAS celui du dossier bin \ Debug \.
Et comme je l'ai dit plus tôt, mon code a utilisé celui du dossier bin \ Debug

Donc, ce que j'ai fait maintenant, c'est que j'ai supprimé la référence du fichier Test.MDF de mon projet, ce qui supprime la copie présente dans le projet. dossier. Cependant, j'ai une copie du fichier TestDB.MDF dans le dossier bin \ Debug \, auquel je me connecte depuis mon application.
Et si je veux parcourir le fichier MDf en dehors de mon projet, j'utilise SQL Management Studio. Le seul problème ici est qu'un fichier MDF ne peut être utilisé que par un programme à un moment donné. Donc, si je dois l'utiliser avec mon application, je dois la mettre hors ligne depuis SQL Management Studio, et vice versa!

Mais mais mais... c'est pas possible ça !

J'ai vérifié pour mon cas avec SQL Management et c'est vrai.
Mes données sont enregistrées dans la copie bin/degug de mon projet : copie 2.
Alors que je mets à jour les données de mon appli à partir du fichier mdf dans le dossier du projet : copie 1.
Je ne lit donc pas le fichier mdf modifié. Sauf durant le temps où l'appli est démarrée.
Quand je relance l'appli je retrouve le fichier 1 intact.

Il y a un fichier pour lire (à la connexion) et un pour écrire. C'est fou quand même, non ?

J'ai supprimé la référence à la copie 1 et tenté d'en créer une autre vers la copie 2 sous bin/debug.
Ça ne marche pas. L'appli lit toujours les données de la copie 1 dans le dossier du projet.

J'ai supprimé la copie 1. VS ne fonctionne pas sans la copie 1.
J'ai copié 2 à la place de 1 (je ne sais pas pourquoi ), VS crée une nouvelle copie 2 (donc 3) sous bin/debug. Je m'y attendais !

Je ne peux pas travailler sans savoir ce que je fais.
Je suis quand même épaté que VS fonctionne de cette manière.

Il y a t-il une solution pour travailler avec des données qu'on manipule ou pas ?
Il doit s'agir d'une protection. On doit pouvoir la contourner.

Merci

[AMP29]

En espérant que cette réponse serve à quelqu'un car ce problème avec Visual Studio n'est pas assez documenté.
https://social.technet.microsoft.com...se-folder.aspx

Database default

Adding a database to a project from Visual Studio’s Solution Explorer Copy to Output Directory will be set to [Copy always]. This has caused great confusion when new developers build/run a project, alter data in their database then on the next run their changes are gone.
Options

Copy always: This option works best when a developer intent is to have a clean slate to ensure their code functions correctly rather than having to clean up data on each build.

Copy if Newer: Use this option when the intent is to ensure changes to a database or a file persist between builds. Unlike [Copy always], [Copy if Newer] will leave files untouched unless there is a change to the file. For example, adding a new field or changing the field type in a database table will trigger a onetime copy, the same for working with any file, make a change and there will be a onetime copy.

This also means any data in a file within the build folder will be overwritten.

Do not Copy: As the option indicates, the file will not be copied. Note that changing from one of the other options will cause the file to be removed from the build folder. If the file in the build folder is needed then first, create a copy of the file before changing Copy to Output Directory to [Do not Copy].

et d'autres infos ici :
http://www.vbforums.com/showthread.p...quot-confusion

Donc voilà. Tout cela à cause d'une malheureuse option quasi cachée dont on peut interroger la pertinence.
>Explorateur de solution>mabasededonnees.mdf>Propriétés

Pour ma part "Do not copy" ne fonctionne pas. VS cherche quand même à copier la base de données dans le répertoire du projet. Forcément, il n'y arrive pas puisque qu'il l'utilise. Bref...

J'ai sélectionné "Copy if Newer".
VS lit et enregistre le fichier copie 2 présent dans /bin/debug et on retrouve ses modifications à chaque lancement de l'appli. Ouf !
Le fichier de BdD dans le répertoire du projet, la copie 1, n'est pas altéré.
Ce n'est que lorsqu'on change qq chose dans ce fichier copie 1 qu'il écrasera la copie 2 de travail dans /bin/debug.

Ce qui n'est toujours pas formidablement pratique si comme moi on se fiche de conserver une base de donnée vierge.
Je travaille avec une base de donnée de test spécialement créée pour l'occasion.
Je construit de front Appli ET BdD.
Je tiens à conserver ses éventuels changements de structure inspirés par l'écriture et le debug de l'appli.
La précaution sera de sauvegarder régulièrement la copie 2 afin qu'elle ne se fasse pas écraser par la copie 1 si par hasard et inadvertance une modification intervient dans cette dernière.
Et de copier la copie 2 à la place de la copie 1 si cela arrive.

Purée c'est lourd pour un truc qui aurait dû fonctionner bêtement normalement !
Je suppose que personne ne travaille, construit et debug son appli avec le seul, l'unique exemplaire d'une éventuelle base de donnée précieuse au risque de la corrompre.
Je trouve cette option parfaitement débile.

[MABROUKI]

Bonjour
Tes connaissances sur VS et les BD ont besoin de lifting.
Il n' y a de Systeme VS & System.Data .Il y a un seul systeme : System.Data meme si tu as l'illusion d'optique que VS utilise autre chose.

Il ne faut pas confondre les fonctions de Adapter.Update et Builder.
Adapter.Update sert aux m.a.j. Il nécessite un Command.
Builder est un class utilitaire qui évite d’écrire à la "mano" des requêtes : Update,Insert,Delete( Builder.GetRequeteX())
Builder génère automatiquement ces 3 requêtes à partir de la Requête de lecture Select de la table BD en cause que tu fournis à Adapter.
L'appel Adapter(ds,table) utilise à bon escient (intelligement) les 3 requêtes auto-générées par Mister Builder.

Fichier BD du projet :
l'ajout dans le concepteur du Fichier BD offre l'option d'utiliser le fichier soit à son emplacement d'origine ,soit de faire une copie dans le dossier \bin\debug
Les modifs apportées sont à rechercher suivant ce choix.
Evidemment si tu tapes n'importe rageusement en réponse aux questions du concepteur ce sera la "nuit totale" pour toi.

[AMP29]

Bonjour,
Mes connaissances sur VS et BD n'ont pas besoin de lifting, je n'en ai simplement pas beaucoup.
Je débute.
Merci donc pour tes précisions.

Ce problème avec l'option "copy" m'a un peu exaspéré, je l'avoue.
Mais il ne faut pas me croire pour plus "rageur" que je le suis.
Le ton et les imprécisions de mes posts peuvent le laisser croire, je le reconnais.
J'apporte ici simplement quelque chose qui pourra servir à l'avenir à d'autres débutants comme moi.

Comme écrit dans la page de microsoft

This has caused great confusion when new developers build/run a project, alter data in their database then on the next run their changes are gone.

Ce que j'ai écrit, j'aurais aimé le trouver rapidement (et en Français) quand j'ai commencé à chercher la réponse à ce problème.
Ça m'a quand même pris plus d'une journée. J'ai donc souhaité documenter cette question.
Il faut aussi que les débutants parlent aux débutants, non ?

J'imaginais bien que VS et Builder étaient deux façons différentes d'utiliser la même chose.
Je les ai mélangées dans mon code et je me demande maintenant si je ne ferais pas mieux de choisir l'une ou l'autre.
J'ai tiré des "fils" que VS me proposait, créé des BindingSources pour remplir facilement des contrôles et rempli des TableAdapter avec les outils graphiques disponibles.
Le builder me parait à présent plus précis et plus explicite (on voit les requêtes dans le code, par exemple).

Penses-tu que je devrais reprendre mon code pour n'utiliser que le Builder ?

Merci

[MABROUKI]

bonjour
L'utilisation de Builder peut degrader les performances selon MSDN Help FR:

Vous devez au minimum définir la propriété SelectCommand afin que la génération de automatique de commandes fonctionne. Le schéma de table extrait par la propriété SelectCommand détermine la syntaxe des instructions INSERT, UPDATE et DELETE générées automatiquement.

Ceci :
SelectCommand doit aussi retourner au moins une clé primaire ou une colonne unique. Si aucune n'est présente, une exception InvalidOperation est levée et les commandes ne sont pas générées.

et ceci pour conclure :
L'objet DbCommandBuilder doit exécuter SelectCommand afin de retourner les métadonnées nécessaires à la construction des commandes INSERT, UPDATE, et DELETE SQL. En conséquence, un trajet supplémentaire vers la source de données est nécessaire et peut gêner les performances. Pour parvenir à une performance optimale, spécifiez vos commandes explicitement plutôt que d'utiliser l'objet DbCommandBuilder.

Donc en production ,il faut coder ses requêtes explicitement ou utiliser des procédures stockées en BD (écrite en langage SQL).
Et bien sur l'indispensable System.Data pour l'affichage sur l'UI.