Vues avec SQL SERVER

Bonjour
J'ai développé il y a quelques temps un projet ADP avec access 2007 connecté à un serveur SQL 2008...
Depuis le passage à office 365 ce n'est plus possible de l'utiliser donc on a publié access 2007 sur un serveur TSE.

Je regarde pour redévelopper l'appli sur Access 2016 donc j'ai commencé par vouloir lier mes tables et vues etc.
Le soucis c'est que pour les tables pas de soucis, par contre les vues pas possible, mes vues n'ont pas de clef primaire donc il ne veut pas ouvrir ma vue (il reconnait la vue comme un table)
Vais-je devoir recréer mes vues dans l'appli (pas génant en soit mais les vues sur le serveur ça avait le mérite de diminuer la taille des transfert d'info, les utilisateurs passent par un vpn parfois donc il me faut limiter les échanges volumineux)

Je me pose aussi la question pour mes procédures stockées, vais-je pouvoir les appeler depuis access 2016 sans soucis ?

Si quelqu'un a une expérience de transfert d'un ADP vers une appli access 2016 (2013 aussi c'est pas différent)

Bonjour,

Désolé je ne vais pas répondre directement à la question :aie:

J'ai une appli qui fonctionne bien entre 2007 accdb et MSQL express 2012
Les tables sont liées mais je fais tout ce que je peux en ADO sinon les temps de réponse peuvent être désastreux. ADO oblige à utiliser le SQL de MSQL, relativement différent de celui d'access, par contre cela donne accès aux vues, procédures...
Les tables liées ne servent finalement qu'à remplir les écrans au standard access et je fais en sorte que la vue sous-jacente (décrite coté access) ne soit pas trop chargée !

Citation:

---

Envoyé par Piou2fois

les utilisateurs passent par un vpn parfois donc il me faut limiter les échanges volumineux)

---

En l'occurence il me semble que le vpn est plus favorable que le fonctionnement standard d'access en terme de flux réseau car "presque" tout se passe entre le serveur de données et le serveur vpn - qui peut être le même :)

A terme l'ergonomie standard d'access, très facile à programmer, se trouve quand même de moins en moins utilisable et du coup risque d'apparaitre le besoin de migrer l'appli vers un langage plus "pro" type .net ou autre si le nombre d'utilisateurs et/ou le volume de données dépasse les capacités d'access 8O

J'aimerai profiter des facilités de développement offertes par Access, même si pour certaines choses je vais passer par ADO (justement pour les procédures stockées, c'est déjà le cas en ADP de toute façon)
Ce que je veux éviter c'est de faire des UPDATE via VBA, je veux utiliser les feuilles de données ou formulaires etc.
Pour les vues, je vais passer par ADO, c'est de toute façon de l'affichage sans possibilité de modifier, donc je peux forcer le rowsource facilement.
Merci