Jusqu'où avec Access ?

[Vance]

Je dois faire la conception d'une application qui intègre les règlements des clients et la gestion de ce fichier avec des alertes lorsqu'on dépasse les dates d'échéances; est-ce que avec Access il est possible de réaliser cela?

[lvr]

Tu peux faire énormément avec Access.
Pour moi les avantages sont:
- développements de belles interfaces, faciles à utiliser et à intégrer avec windows
- rapidité à mettre "quelque chose" en place,
- facilité à gérer
- VBA te permet de customiser de manière très fine.

Les inconvénients sont:
- performances: si ta db est grosse alors Access n'est pas top
- stabilité: pas toujours hyper-stable: si ta db est critique, alors Access n'est pas top
- pas vraiement prévue pour le multi-user. Une db Access, c'est un fichier à ouvrir (d'autres, plus callés, te diront peut-être le contraire, ce n'est que mon opinion)
- VBA reste VBA: si t'es pas vigilent: tu veux vraiment écrire des crasses avec ce langage, plus qu'avec d'autres.

J'ai souvent mis Access en oeuvre comme interface vers une autre db: Oracle, MySql: cela permet d'avoir une interface jolie, pratique et facile à utiliser, tout en ayant un db plus solide pour du travail de fond (batch, site web, ...)

[Maxence HUBICHE]

Tu peux faire tout ce que tu veux avec Access.
Tu ne seras limité que par ton imagination (Arkham a même réussi à refaire le PacMan, c'est tout dire !).

Les points forts/faibless énoncés par Ivr sont globalement vrais, et il faut en tenir compte.

Je ne me permet donc d'intervenir ici que pour la partie finale :
Si tu dois faire non pas une base "fichier" comme le moteur JET d'access (moteur natif) le fait, mais une base "Client/Serveur", beaucoup plus économe en terme de ressources réseau, je ne peux que te conseiller de faire un "PROJET" et non une "BASE DE DONNÉES" (Fichier/Nouveau)
Dans ce cas, il te demandera de te connecter NATIVEMENT à un serveur SQLServer.
Soit tu as déjà SQLServer (Cooooool !)
Soit tu ne l'as pas, et ne souhaites pas l'acheter (cher !). Alors fais une recherche sur MSDE. C'est le moteur SQLServer, mais... gratuit !

[mayloshi]

Je ne sais pas si ce sont des inconvenients corrects que je vai donner, mais pour les etats imprimés, tu es obligé de passer par une table ou une requete pour recupérer toutes les valeurs que tu veux afficher. En plus son SQL est un peu pauvre (Pas moyen d'imbriquer des jointures avec deux tables charnières) et depourvue de beaucoup de fonctions.

[Philippe JOCHMANS]

Bonjour

Envoyé par mayloshi

Je ne sais pas si ce sont des inconvenients corrects que je vai donner, mais pour les etats imprimés, tu es obligé de passer par une table ou une requete pour recupérer toutes les valeurs que tu veux afficher.

Et alors, Crystal Report aussi, Report sous Base Oracle aussi, et ce sont des gros gestionnaires d'Etas, c'est l'idéal des requêtes car dynamiquement tu peux filtrer.

En plus son SQL est un peu pauvre (Pas moyen d'imbriquer des jointures avec deux tables charnières) et depourvue de beaucoup de fonctions.

Pas d'accord, je suis ne train de faire du SQL Oracle, et je ne vois pas beaucoup de différences en nombre de fonctions, et en plus tu peux créer tes fonctions en VBA que tu incorpores dans tes requêtes, ce qui t'apporte d'énormes possibilités.

Starec

[lvr]

En plus son SQL est un peu pauvre (Pas moyen d'imbriquer des jointures avec deux tables charnières) et depourvue de beaucoup de fonctions.

Le SQL d'access n'est limité que si tu te bornes à utiliser l'éditeur graphique.
Par contre, si tu le saisis à la main, je n'ai jamais vu beaucoup de différence par rapport au SQL d'Oracle (je parle en termes de capacité).

Le gros avantages du SQL sous Access est que tu peux y incorporer des petites fonctions que tu auras écrites en VBA si tu veux faire de plus gros travaux. Et ça sous oracle, c'est une épine dans le pied si tu ne maîtrise pas PL/SQL et consort...