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.

[apprenti46]

Bonjour à tous,

Le temps passe vite...quand on court tous les jours et pas le temps de développer pour le futur....

Je reviens enfin vers vous car j'ai commencé la migration adp vers accdb.

J'étais content, j'avançais bien....mais mon rêve s'arrête net ;-)...car je viens de me rendre compte que, dans certaines tables je sais créer des lignes mais impossible de faire une modification après, que ce soit dans une ligne déjà existante ou dans une ligne que je viens de créer en Access.

Avez-vous une idée où chercher?
Je connais bien Access et vba mais pas SQL SERVER.

Merci d'avance pour votre aide.

Fred.

[Robert1957]

Bonjour Fred,

Une première chose à vérifier dans la table concernée est la présence d'un champ de type "bit". Ce champ doit avoir une valeur par défaut pour que les données soient éditables.

La table doit aussi avoir une clé primaire identifiée par Access.

Bonne journée

[Mat.M]

Je connais bien Access et vba mais pas SQL SERVER.

je n'arrive pas à comprendre pourquoi utiliser Access avec des tables liées sur une base SQL-Server.
C'est pas possible de développer un front-end avec VB.NET qui présente énormément de fonctionnalités ?
Si vous voulez je vous refais tout le projet avec des formulaires en VB.NET ou mieux C# je prends pas cher comme freelance

[apprenti46]

Bonjour Fred,

Une première chose à vérifier dans la table concernée est la présence d'un champ de type "bit". Ce champ doit avoir une valeur par défaut pour que les données soient éditables.

La table doit aussi avoir une clé primaire identifiée par Access.

Bonne journée

Bonjour Robert,

Je continue à tester mais je ne trouve toujours pas la raison du problème sur certaines tables.
A un moment, je pensais à un nombre de lignes mais ce n'est pas cela car...

Voici un exemple de table de plus de 100.000 lignes et les modifs "passent':




Maintenant, j'ai l'impression que ce sont les tables avec beaucoup de champs qui posent problème???
Ou alors un certain type de champs ??

Voici le message qui apparaît:



Une idée?

[apprenti46]

je n'arrive pas à comprendre pourquoi utiliser Access avec des tables liées sur une base SQL-Server.
C'est pas possible de développer un front-end avec VB.NET qui présente énormément de fonctionnalités ?
Si vous voulez je vous refais tout le projet avec des formulaires en VB.NET ou mieux C# je prends pas cher comme freelance

Simplement pour la rapidité: c'est une grosse app avec bcp de forms et reports et il n'y a pas énormément de travail pour que cela fonctionne.

[apprenti46]

Pour mon problème de modification de données impossible dans certaines tables, j'ai trouvé la solution pour une des tables: les champs BIT en SQL SERVER doivent être en NULL NON AUTORISE.