Discussion :

[apprenti46]

Bonjour à tous,

Nous travaillons actuellement avec un projet Access2007 (adp avec beaucoup de form et reports) lié un SQL Server 2005 ou 2008 (je ne sais plus).

Les nouvelles versions d'Access ne supportant plus les ADP, nous cherchons une solution pour remplacer ce projet.

Une des solutions (facile) serait de refaire la même chose que le projet existant mais en Access2013 toujours lié à SQL.
Nous sommes une 20aine de personnes à travailler dessus et certaines tables frôlent les millions de lignes.

Qu'en pensez-vous?
Quels sont les avantages et inconvénients ?

D'avance merci pour votre aide et bon week-end,

Fred.

[User]

Bonsoir,

J'espère ne pas enfoncer une porte ouverte, mais je dirai à première vue, que si vous passez le projet sous Access 2013, vous bénéficierez de la facilité de développement et de maintenance propre à Access. Par contre vous risquez de perdre en performance. Hormis le nombre d'utilisateurs, cela va en fait dépendre principalement de la structure de la base et plus particulièrement des requêtes et du code.

Cordialement,

[apprenti46]

Bonjour à tous,

Le temps passe vite et la situation n'a pas évolué: nous utilisons toujours notre "gros" adp.

Nous tentons d'utiliser notre serveur Office2007 en tant qu'app dans un serveur plus récent mais les interactions (output automatisé Word/Excel et autres) entre notre adp (2007) et notre environnement plus récent n'est pas top.

Est-ce que de nouvelles solutions sont apparues depuis 2016?
Est-ce que Delphi serait une solution alternative?

Qu'en pensez-vous?

Merci d'avance.

Fred.

[argyronet]

Bonjour,

Humm il y a pas mal de discussions là dessus et il en ressort que majoritairement avec les dernières versions d'Access, un ADP soit un moins bon choix que les tables liées dans une configuration Frontale/Dorsale car elle offre une meilleure flexibilité et permet en plus d'autoriser les tables locales.

Premièrement, il y a la solution alternative de basculer sur une configuration d'Access 2013 sur le Web ; celle-ci utilise nativement des tables de serveur SQL ce qui laisse supposer que l'on pourra utiliser des triggers ou des procédures stockées.
En revanche, ce choix ne permet pas de proposer une interface utilisateur riche pour le frontal du fait justement des limitations du Web vu par Access. Par ailleurs, il n'existe pas d'interfaces adaptées pour appeler et transmettre des informations de façon bilatérale aux procstock avec lesquelles on peut théoriquement écrire avec SQL Azure. De ce fait, cette solution est un choix délicat et il n'est pas recommandé dans le cas où vos écrans exigent un look personnalisé particulier.

Deuxièmement, vous avez aussi la possibilité de basculer sur SharePoint comme serveur principal avec votre application Access frontale telle que, avec des tables liées et exploiter le code VBA classique. De ce choix dépendent majoritairement le volume de données et la façon dont il est traité dans votre projet...
L'avantage de ce choix est qu'il permet une utilisation "hors ligne", et votre application peut tourner sans connexion au serveur jusqu'à ce que l’utilisateur se connecte de nouveau au réseau et synchronise ses données.
Si l'option hors ligne est intéressante pour vous, il est conseillé de privilégier vos appels SQL via DAO plutôt qu'ADO, car ce dernier n'est en toute apparence pas ou mal adapté pour une plateforme Sharepoint.

Et pour terminer, la troisième solution qui reste à,la fois reconnue, stable et efficace avec de bonnes performances consiste à simplement lier vos des tables SQL Server à votre application frontale.
Cela vous permet de continuer à utiliser, appeler ou passer des paramètres à vos procédures SQL directement sur le serveur SQL via du code approprié avec des Command.
Vous conservez bien évidemment dans ce cas votre code VBA avec la technologie ADO.
Il vous faudra alors substituer votre projet ADP au profil d’une classique base de données Access sur laquelle vous attachez vos tables SQL Server avec le pilote idoine. De plus, ce choix vous permettra en parallèle de lier des tables d’une base dorsale Access qui pourra traiter des données issues des tables SQL Server à travers des requêtes action locales.
Le choix de cette alternative vous demandera de modifier quelques-unes de vos habitudes de développeur.
À titre d’exemple, le fait d’attacher une « Vue » SQL Server mais de ne pas pouvoir la manipuler avec des critères pourra vous permettre à passer une condition Where ou un Filtre (passé à l’argument d’un OpenForm ou OpenReport) et ce sans modifier l’objet source. De plus, cela sera traité avec de relatives bonnes performances.
Quant à la modification, maintenance ou création des vues et des procédures stockées, vous devrez faire appel à des outils propre à SQL Server, par exemple SQL Management Studio (SSMS) bien que cela prenne peut-être un peu plus de temps à élaborer et/ou concevoir qu’avec Access lui-même qui permet lui d’élaborer des requêtes-minute.
Cette dernière alternative reste de loin la moins coûteuse et la plus facile à mettre en œuvre pour vous d’un point de vue temps de refonte du projet, car vous conservez quasiment tout votre code existant et si vous maîtrisez Access, le temps de familiarisation sera minimisé.

Bonne décision...

Argy

[apprenti46]

Merci Argy pour cette réponse !!
Je vais donc me renseigner sur Access et les tables liées.

[apprenti46]

Bonjour à tous,

Le temps passe et nous sommes toujours en .adp mais plus pour longtemps...

Je souhaiterais donc convertir mon projet adp en mdb ou accdb mais je n'y arrive pas :-((
Comment faire?

Mon adp tourne sur un AC2007.


Merci d'avance,

Fred.

[micniv]

Cette lecture peut peut-être aider
https://accessdevtools.com/blog/find...cdb-migration/

Le plus intéressant serait sans doute de viser à convertir le projet ADP en base SQL SERVER + Access-VBA en front.

[apprenti46]

Bonjour,

Merci pour ce lien.

Mais mon premier problème est vraiment de "copier" mes états et rapports dans de mon .adp vers un .accdb ou .mdb.

Faut-il un ACCESS 2010 pour le faire car dans 2007, je ne vois pas comment.

Merci d'avance.

Fred.