Utilisation simultané de Access avec Dataverse

Bonsoir à l'équipe.

J'ai un sérieux soucis pour l'utilisation de Access de façon simultanée. En effet le principe de lecteur partagé (en mettant la base dorsale sur le serveur et le frontal chez les utilisateurs ) ne réponds pas à nos attentes. Parmi les difficultés on note l'impossibilité d'utiliser la base de donné hors du réseau local.


En fouillant j'ai trouvé une nouveauté que Microsoft à mis en place qui semble pallié à cette difficulté : il s'agit de Dataverse. Je ne m'y connais pas trop mais il semble que les tables peuvent être exportées vers Dataverse comme backend . Je ne sait pas si quelqu'un connait bien le fonctionnement de Dataverse pour vraiment m'appuyer.


J'ai essayer d'exporter mon projet vers Dataverse mais il m'affiche des erreurs. En recherchant j'ai vue que y'a certains champs pris en charge dans Access et qui ne passe pas dans Dataverse. C'est le cas des champs multivalués. J'ai deux champs multivalué et si Dataverse ne le prend pas en charge cela va porter un coup à mon projet. Je me dit qu'il doit y avoir un système de contournement.

J'ai donc besoin de votre experience . Es ce que Dataverse sera la solution pour une utilisation simultanée (à entré sortie rapide) de Access et aussi comment gérer les champs multivalués de Access dans Dataverse.

Merci pour votre appuis.

Bonjour,

Les champs multivalués : l'une des pertes de temps et d'argent la plus flagrante des équipes de dev de Microsoft Access. Une vrai fausse bonne idée pour palier aux carences des utilisateurs de MS ACCESS sur la question des bases de données.

Un champs multivalués est simplement la méthode la moins élégante imaginée pour éviter de construire une simple relation plusieurs à plusieurs.

Remplacer des champs multivalués par un vrai structure conforme au règles du SGBDR et sans doute la meilleure et plus pérenne des solutions.

Cordialement,

bonjour,

Citation:

---

Envoyé par loufab

Les champs multivalués : l'une des pertes de temps et d'argent la plus flagrante des équipes de dev de Microsoft Access. Une vrai fausse bonne idée pour palier aux carences des utilisateurs de MS ACCESS sur la question des bases de données.

---

absolument bien dit ... et le fait que d'autres applications (exemple : SharePoint) ne les prend pas en charge constitue bien la preuve que ce "machin" est un non-sens, une aberration. La preuve aussi est le nombre de posts de demande d'aide suite à son utilisation

Bonjour à tous,

Petite question soulevée par ce post: cela veut il dire que si on n'a pas de champs multivalués dans une application Access, on peut la porter sur Dataverse pour profiter d'une utilisation hors du réseau local ?

Merci pour vos avis éclairés :idea:

bonsoir,
oui, mais seulement les tables d'après ce lien ou celui-ci et elles sont accessibles avec Power Apps, Power BI, Azure ... et aussi Power Query (?) mais pas Access, peut-être par le biais d'une des API citées ?
Il me semble que si c'était le cas, Microsoft en aurait fait clairement mention.

Cela dit, j'ai lu les 2 documents mis en lien en diagonale juste avant de poster et dans chaque il y a énormément de liens qui mènent vers d'autres docs.

Merci bien tee_grandbois pour ces infos. Effectivement, il y a pleins de liens ..

Apparemment oui, on peut migrer les tables et les garder liées automatiquement lors de la migration à Access. Du coup, on peut modifier les données:
- par Access
- par une appli mobile que l'on fabrique dans Databerse
- sous teams, on peut aussi faire une appli qui met à jour les tables migrées.

ça semble super pour partager les données access.
J'ai vu qu'il y avait qq restrictions au niveau des tables, et qu'il faut être sous access 365.

Voici les articles que j'ai vu:
https://learn.microsoft.com/fr-fr/po...s-to-dataverse

Et, en anglais, une explication et démo d'une migration des tables d'une appli Access vers Dataverse (pour faire une petite appli mobile) et vers teams.
Ainsi, on peut mettre à jour les données de n'importe quelle appli :)
https://www.youtube.com/watch?v=IeQfFGmy5cY&t=1935s

Si certains d'entre vous on déjà essayé, merci de laisser vos remarques et / ou conseils sur cette nouvelle fonctionnalité.
Et aussi sur les temps d'accès à distance.

Merci pour votre réponse. Je doit comprendre que je doit casser les champs multi-valué et en faire des tables liées.

Mais je pensais a créer une copie de ma table tous en remplaçant le champs multivalué par un type texte. Cette table copie sera donc indexée dans

Dataverse et j'écrit un script qui met a jour les deux tables en fonctions des modifications et des insertions suivant les contraintes du champs multivalué

de la table en question.

En fait l'avantage des champs multivalués et qu'ils facilitent l'insertion des données a travers un seul formulaire. Du coup si je la supprime il me faut

revoir les formulaire , les requêtes etc.

Citation:

---

Envoyé par loufab

Bonjour,

Les champs multivalués : l'une des pertes de temps et d'argent la plus flagrante des équipes de dev de Microsoft Access. Une vrai fausse bonne idée pour palier aux carences des utilisateurs de MS ACCESS sur la question des bases de données.

Un champs multivalués est simplement la méthode la moins élégante imaginée pour éviter de construire une simple relation plusieurs à plusieurs.

Remplacer des champs multivalués par un vrai structure conforme au règles du SGBDR et sans doute la meilleure et plus pérenne des solutions.

Cordialement,

---

Merci bien pour ces lien et cette confirmation pour motiver l'utilisation de Dataverse.

A mon niveau je tante de faire migrer les tables respectant les contrainte de migration vers Dataverse mais cela echoue.


J'ai ce message d'erreur : Mise à jour impossible. La base de données ou l'objet est en lecture seule.

Puis quand je clic sur ok il me dit : Le champ « idObjet » n'est pas un champ pouvant être mis à jour.

« idObjet » est une clé primaire de ma table de type texte.

Pièce jointe 642271
Pièce jointe 642272

Citation:

---

Envoyé par LeMin

Merci bien tee_grandbois pour ces infos. Effectivement, il y a pleins de liens ..

Apparemment oui, on peut migrer les tables et les garder liées automatiquement lors de la migration à Access. Du coup, on peut modifier les données:
- par Access
- par une appli mobile que l'on fabrique dans Databerse
- sous teams, on peut aussi faire une appli qui met à jour les tables migrées.

ça semble super pour partager les données access.
J'ai vu qu'il y avait qq restrictions au niveau des tables, et qu'il faut être sous access 365.

Voici les articles que j'ai vu:
https://learn.microsoft.com/fr-fr/po...s-to-dataverse

Et, en anglais, une explication et démo d'une migration des tables d'une appli Access vers Dataverse (pour faire une petite appli mobile) et vers teams.
Ainsi, on peut mettre à jour les données de n'importe quelle appli :)
https://www.youtube.com/watch?v=IeQfFGmy5cY&t=1935s

Si certains d'entre vous on déjà essayé, merci de laisser vos remarques et / ou conseils sur cette nouvelle fonctionnalité.
Et aussi sur les temps d'accès à distance.

---

S'il vous plait savez vous lequel est plus optimale entre Dataverse et Sharepoint s'il faut migrer des tables Access comme backend .

Merci.

Citation:

---

Envoyé par tee_grandbois

bonjour,

absolument bien dit ... et le fait que d'autres applications (exemple : SharePoint) ne les prend pas en charge constitue bien la preuve que ce "machin" est un non-sens, une aberration. La preuve aussi est le nombre de posts de demande d'aide suite à son utilisation

---

je ne connais pas Dataverse et je n'ai jamais utilisé SharePoint, difficile de répondre à la question

Bonjour,

un peu de retard pour répondre, mais quelques éléments à prendre en considération pour savoir quoi choisir entre des listes Sharepoint ou des entités Dataverse.

As-tu un besoin de performance ?
As-tu plusieurs milliers d'enregistrements qui seront à gérer sur une période de 6 mois ?
As-tu besoin de gérer des accès aux données personnalisés ?
Les données que tu stockes sont critiques ?


Si a l'une de ces questions tu as répondu oui, je te recommande Dataverse :)

Merci beaucoup pour votre réponse. En fait mon problème à été résolu . Il se trouve que SharePoint n'accepte pas les clés primaires de type String dans une liste.
J'ai donc contourné cela en créant un clé primaire de type numérique pour le champs "idObjet" au niveau de ma base de données Accès avant le migration.

Merci bien.