VB.NET/Access: problème d'enregistrement de données

Bonjour,

Je suis actuellement en train de travailler sur un projet de Répertoire en VB.NET.
Au départ, la base de données était en SQL Server mais à cause de la politique de l'entreprise, j'ai été forcé d'utiliser une base de données Access.
Afin d'avoir une application "propre", je l'ai entièrement recréé en utilisant la BDD Access (et en reprennant les différentes fonctions de la version sous SQL Server de mon app bien sûr).

Mais maintenant, lorsque je test l'application, celle ci fonctionne parfaitement sauf en ce qui concerne l'ajout/modification/suppression d'enregistrements.
Par exemple, lorsque j'essaye d'ajouter un fournisseur depuis la fenêtre dédié à l'ajout de fournisseurs, celui-ci est bien présent dans la fenêtre de consultation des fournisseurs mais quand je redémarre l'application, il n'y est plus (et il n'est pas non plus ajouté à la base de données).

Pour la création de la fenêtre d'ajout/modification/suppresion, j'ai tout simplement fait glisser la table Fournisseur (depuis la fenêtre "source de données") vers la fenêtre, créant ainsi un DataGridView contenant les fournisseurs ainsi qu'un "Binding Navigator" permettant de naviguer entre les enregistrements mais aussi de sauvegarder les modifications apportées dans le DGV (avec le bouton en forme de disquette), cependant ce bouton n'a pas l'air d'actualiser la BDD.
Tout cela fonctionnait parfaitement lorsque j'utilisais SQL Server.


Je précise que les tables de la BDD Access ont été créées en important les tables de SQL Server car celles-ci contenaient pas mal de données.

Ainsi, les ID de chaque table dans Access sont au format "Number" et non "AutoNumber" (donc pas d'incrémentation automatique, l'utilisateur doit lui-même taper un ID dans le DGV lorsqu'il veut ajouter un fournisseur).
En effet, il est impossible de modifier le type d'une colonne lorsque celle-ci contient des données. Je pourrais créer une nouvelle colonne ID en AutoNumber mais, dans la colonne ID actuel, il y a certains "écarts" (on passe, par exemple, d'un fournisseur ayant 120 pour ID à un fournisseur ayant 122) dû à des enregistrements qui ont été supprimés. Et les fournisseurs étant liés, par leur ID, à certains produits, je serait obligé de reprendre chacune des liaisons...

Peut-être qu'il est possible de modifier manuellement la valeur de l'ID en AutoNumber afin de recréer ces "écarts" ?

J'espère avoir été clair.

En espérant que vous puissiez m'aider.
Merci d'avance

Cordialement.

Je suis pas un champion du designer et de sa génération de code automatique.

Néanmoins tes données sont stockée localement dans ton application à l'aide d'un Dataset (supposant que c'est du bon vieux ADO.NET basique). La liaison avec la base de données s'effectue à l'aide de plusieurs TableAdapter (1 pour chaque table dans la base de donnée) qui s'occupe en premier lieu de remplir le dataset (à l'aide d'une instruction .Fill) et en seconde partie à sauvegarder les modifications (si nécessaire) à l'aide d'une instruction .Update. Parfois on retrouve un TableAdapterManager qui permet de contrôler plusieurs TableAdapter, plus particulièrement pour la sauvegarde.

Normalement ces différents éléments ont du être ajouté par le designer dans les composants (la barre grise sous le formulaire) lors du glissage.

De mes souvenirs la création de code automatique ajoute les instructions .Fill dans la procédure évènementiel de chargement du formulaire mais ne crée pas l'instruction Save (avec Access tout du moins car avec SQL Server je n'ai jamais utiliser la création automatique). Il faut donc ajouter l'instruction Update des TableAdapter (ou UpdateAll du TableAdapterManager) à la main quelque part (Fermeture du formulaire, un clic de bouton, etc.).

Concernant l'incrémentation automatique avec Access, ça fonctionne moyennement bien parce que la valeur générée n'est pas retournée dans ton dataset pour les nouveaux enregistrement et par conséquent les modifications ultérieur planteront si l'application n'a pas été fermée entre temps. Il existe des techniques pour remédier à ce problème mais je vais pas m'étendre sur ce sujet vu que tu n'utilises pas l'incrément automatique.

Je ne peux que te conseiller de te documenter sur le fonctionnement des datasets et des tableadapters (ADO.NET) et de ne pas faire confiance au code généré automatiquement.

Bonjour,

Merci de ta réponse !

Je me suis déjà un peu renseigné sur tout ça, et justement, quand ma BDD était en SQL Server, tout fonctionnait à la perfection, et depuis que je suis passé à Access, la sauvegarde ne fonctionne plus...

Quant au type "AutoNumber", le fait que je ne l'utilise pas ne pose pas de problèmes alors ?

Cordialement.

Citation:

---

Quant au type "AutoNumber", le fait que je ne l'utilise pas ne pose pas de problèmes alors ?

---

Ce sera difficile à gérer si on fait un update global qui valide plusieurs ajouts, suppressions et modifications de la DataTable.

Toutefois, si on fait un update() par enregistrement, il n'y aura pas de problème théorique, mais on devra gérer les éventuels conflits qui pourraient se produire sur une commande INSERT :
Si la commande échoue à cause d'une erreur de type Duplicate Key, il faut trouver une nouvelle valeur de clé primaire, modifier le paramètre coorrespondant à la clé dans la commande INSERT et relancer l'update().

Bonjour,
Lors de la création du programme, a-t-on intégré une base Access en local ou non ?

Voir ci-dessous documentation trouvée à ce sujet ( et qui n'est pas de moi) :
La base Access ou SQL Server doit-elle être :
- Copier le fichier dans le projet ?
- Ou bien pointer à son emplacement d'origine ?
ATTENTION A L’EXECUTION EN MODE DEBUG !!

Si vous affichez les propriétés du fichier « DBContacts.mdf », vous remarquerez par défaut que la propriété « Copy To Output Directory » vaut « Copy always ». Que signifie cette valeur ?

Cela indique que lorsque vous régénèrerez votre projet une copie de votre fichier « DBContacts.mdf » placé à la racine de notre projet sera toujours copier dans le répertoire « Debug ». Donc si vous lancez plusieurs fois votre projet en mode « Debug », ne soyez pas surpris de perdre les données sauvegardées puisque VS2005 écrasera à chaque fois le « Debug\DBContacts.mdf » par « .\ DBContacts.mdf ».

Pour nos tests avec la sauvegarde en base, je vous conseille, une fois le projet compilé, de lancer le fichier « Gestion.Contact.exe » contenu dans le répertoire « Debug ». Et attention, n’oubliez pas qu’à chaque recompilation du projet ou exécution en mode « Debug », vous perdrez les données déjà saisie dans la base.

Autrement dit, l'utilisation d'un fichier en local ne permet pas de savoir si les mises à jour sont faites, ce qui n'est pas le cas si le fichier .mdf n'est pas intégré au projet.

Bonjour,

Merci beaucoup pour votre réponse.

Alors, en effet, lorsque j'ai ajouté le fichier Access en source de données, VS m'a proposé de copier la base dans le dossier, ce que j'ai fait car j'aimerais mettre l'application dans le dossier commun d'une entreprise et ca serait plus pratique au niveau de la chaîne de connexion.

Donc j'ai lancé l'(application en mode Debug, j'ai ajouter un exemple de fournisseur puis quitté l'application. Je l'ai ensuite relancé directement depuis le fichier .exe du dossier Debug, comme indiqué dans le cours (un grand merci pour ce cours d'ailleurs) et en effet, le fournisseur créé est bien là.

Est-ce que cela signifie que lorsque les employés lanceront l'application depuis le fichier .exe ils ne rencontreront pas ce problème ?
Y a-t-il un moyen de remédier à ça ?

Merci infiniment.

Cordialement.

Bonjour,
En effet, en travaillant avec le fichier EXE, les modifications de la base seront conservées.

Bonjour,

Donc si j'ai bien compris, ce problème n'en est pas vraiment un et les employés pourront travailler avec l'application sans perdre de données tant que personne ne debug le projet ?

Cordialement.

Ca veut surtout dire que chaque installation utilisera sa propre base de donnée et que votre application sera mono-poste (chaque utilisateur travaille dans son coin).

Dans le cadre d'une application multi-poste, on inclus pas la base de données avec l'installeur des clients. Cette dernière est déployée séparément par un autre processus. De plus il faut aussi prévoir une fonctionnalité permettant de lier l'application à la bonne base de donnée (formulaire qui permet d'enregistrer la configuration de la chaîne d'accès à la base de donnée par exemple).

Ah..

La politique de l'entreprise étant très restrictive à propos des installations, serait-il possible de faire en sorte que les fichiers de l'application soit dans le dossier commun afin que les utilisateurs la lance à partir de là ?

Ou alors, pourrais-je mettre les fichiers de l'application (donc le .exe) sur les postes, et la base de données sur le dossier commun puis de faire en sorte que la chaine de connexion pointe vers l'emplacement de la BDD (dans le dossier commun) ?

Désolé pour les questions, mais je n'y connais vraiment rien dans ce domaine.

Citation:

---

Ou alors, pourrais-je mettre les fichiers de l'application (donc le .exe) sur les postes, et la base de données sur le dossier commun puis de faire en sorte que la chaine de connexion pointe vers l'emplacement de la BDD (dans le dossier commun) ?

---

De préférence, on mettra l'exe et la BDD dans le dossier commun sur le réseau, ce qui ne nécessite aucune installation sur les postes (pourvu qu'ils disposent du framework .net).
La base étant commune, il faut que les conflits multi-utilisateurs ait été gérés si plusieurs utilisateurs peuvent accèder/modifier simultanément la BDD.

Bonsoir,

Citation:

---

De préférence, on mettra l'exe et la BDD dans le dossier commun sur le réseau, ce qui ne nécessite aucune installation sur les postes (pourvu qu'ils disposent du framework .net).

---

Encore mieux, c'est EXACTEMENT ce que je cherche à faire. VOus me confirmez donc que c'est possible ? (je suis justement en train de négocier, depuis hier, avec le service info pour qu'ils installent le Framework sur les postes)

Et justement, concernant votre dernière phrase, est-il possible pour plusieurs personnes d'accéder à l'application s'ils peuvent juste CONSULTER les données ?

Cordialement.

Citation:

---

c'est EXACTEMENT ce que je cherche à faire. VOus me confirmez donc que c'est possible ?

---

Oui.
Problèmes possibles sur les postes sont en 64 bits avec une version 32 bits d'office (solution éventuelle en compilant avec target X86 au lieu de any cpu).

Citation:

---

est-il possible pour plusieurs personnes d'accéder à l'application s'ils peuvent juste CONSULTER les données ?

---

Plusieurs utilisateurs peuvent se connecter simultanément.
Si un seul utilisateur d'entre eux est autorisé à opérer des modifications, pas de conflits en écriture à gérer.

Bonjour,

Je vous remercie beaucoup pour votre aide qui m'aura été précieuse.

Cordialement