Discussion :

[Mouse]

Bonjour,

je dois developpez une base de donnee relativement importante qui doit gerer tout le process d'une entreprise.

Actuelement cette entreprise utilise Access pour stocker toutes ses donnees, ils ont donc une bonne dizaine de bases de plus de 50 Mo.

Vu qu 'une cinquantaine de personnes utilisent en permanence ces bases, elles tombent TRES souvent en panne, c'est a dire qu'elles doivent etre reparees (c'est une fonction propre a Access) au moins 3 fois par jour, ce qui implique que tout le monde doit quitter le programme.

Je suis dans cette entreprise pour 16 mois, et je suis la pour refaire tous leur systeme. Je viens d'etre diplome, mais un diplome d'ingenieur en mecanique, je n'ai donc pas de formation propre en informatique, et ce que je connais se resume a VBA, Access, MySQl et un peu de PHP. En lisant vos messages sur ce forum, je me rends compte que mes connaissances sont plutot legeres...

Cette entreprise m'a embauche car je connais parfaitement Access et qu'elle souhaite redevelopper leur base avec. Mais je ne pense pas que c'est la bonne solution. Etant donnee qu'ils souhaitent rester avec Microsoft, je leur ai parle de SQL Server, qui je pense est plus adapte. Ils sont d'accord pour l'utiliser.

Le probleme maintenant, c'est qu'il me faut developper la partie cliente. Je pensais la developper sous Access, et faire un lien ODBC, car je connais vraiment tres bien Access, et le personnel est tres familier avec.

Je voudrais juste avoir votre avis la dessus, Access est-il adapte pour cela, faut-il que je developpe quelque chose sous Delphie, Java...

Merci pour votre aide
Mouse

[neo.51]

Ce qui est sur c'est qu'il ne faut pas développer en access! Si tu prend SQLserveur et que tu veux rester sur du microsoft, tu peux développer en .NET(ASP.NET ou VBnET ou C#). Sinon, il y a effectivement delphi, ou java. Si tu n'as pas beaucoup de conaissances en informatique je de conseillerais plutot d'utiliser Delphi si tu veux faire du client/serveur et plutot de l'ASP.NET si tu t'oriente vers des pages web : ASP.NET offre le meilleur rendement possible au niveau des connections à une base de donnés SQL serveur(5 fois plus rapide qu'asp4).

[Epictète]

Le fait que tu remplace les fichiers access par un véritable serveur de base de données SQL : SQL-SERVER pour passer en architecture Client/Serveur cela me parais déjà une étape indispensable pour régler les différents problemes.

Cependant avec ce seul changement, tu va déjà rencontrer un premier probleme, SQL-SERVER nécessite la compétence "Administrateur base de données" avec SQL-Server, en général au moins une semaine de formation spécialisée sur SQL-SERVER (en plus de ta formation générale SGBD et SQL).

L'exploitation d'une base de données SQL-SERVER n'à rien à voir avec celle des fichiers access.

Pour ce qui est du développement "client/station", c'est certains que Delphi peut aussi t'apporter beaucoup de chose, cependant de meme Delphi est un outil destiné en principe aux développeurs professionnels, (ou développeurs passionnés).

Tu ne pourra pas envisager le développement d'applications avec Delphi sans passer par une notable période de formation, en plus de ta formation SQL-SERVER.

[Mouse]

Ce qui est sur c'est qu'il ne faut pas développer en access!

Est-ce que mon choix ne doit pas tenir compte des connaissances qu'a l'entreprise ?
Je veux dire par la qu'elle a depense plein d'argent pour faire des formations Access.
Il m'est difficile de venir et de leur dire, OK, Access c'est nul, on change tout.

[neo.51]

Ce qui est sur c'est qu'il ne faut pas développer en access!

Est-ce que mon choix ne doit pas tenir compte des connaissances qu'a l'entreprise ?

biensur

Je veux dire par la qu'elle a depense plein d'argent pour faire des formations Access.
Il m'est difficile de venir et de leur dire, OK, Access c'est nul, on change tout.

Formation de programmeurs ?

D'aprés ce que tu nous dis il n'est pas possible de rester sur access : si ta boite parle de sql server c'est qu'elle se rend compte des limites d'access. Access n'est pas vraiment le langage le plus adapté pour un grand système d'information. Donc aprés c'est à toi de voir jusqu'on ton entreprise est prète à aller pour améliorer son système d'information. Et ça a un cout, à toi de voir avec ton entreprise quelle somme elle veut investir dans cette "mise à niveau".

[Mouse]

Les formations sont surtout pour permettre aux utilisateurs de savoir faire des requetes, importer des tables, c'est des formations pour debutant, mais qui ont ete faites car Access est tres utilisee ici...

je vais passer 16 mois sur ce projet, ce qui me laisse le temps de tester toutes les possibilites avant de me lancer vraiment.

Je vais telecharger Delphi, pour avoir une idee sur son fonctionnement.

Une derniere petite question, le developpement avec PHP ou ASP.NET est beaucoup plus long que le developpement sous Delphi ou Access ? Est-ce judicieux de faire ce choix sachant que les bases sont utilisees uniquement dans l'entreprises (aucun lien avec internet) ?

Dans tous les cas merci beaucoup pour vos conseils
Mouse

[neo.51]

Je te conseille fortement ASP.NET plutot que php pour un développement web : ASP.NET est optimisé pour MS SQL serveur, et il existe des outils permettant un développement rapide et intuitif pour faire de l'ASP.NET.

Pour ce qui est du choix de Delphi ou ASP.NET : ce qui me parait les deux meilleures alternatives, chacun a ses avantages et ses inconvenient.

Si tu fais du client/serveur avec delphi, tu devras installer un client sur chaque poste de ta boite. L'avantage, c'est que le serveur sera moins solicité que si tu fais de l'asp.net.

Si tu fais un developpement web, le serveur sera certe plus solicité, mais tu n'aura aucun problème d'installation sur les poste clients.

Ne connaissant pas bien Delphi, je vous invite à donner votre point de vue sur l'avantage de l'utilisation de delphi dans un tel contexte.

[al1_24]

Quant à la formation Access des utilisateurs, elle n'est peut être pas complètement perdue.
S'il s'agit pour eux d'interroger la BD (Requêtes et Etats, voire Formulaires en consultation) il est toujours possible dans Access de créer des tables liées à SQL-Server (ou toute autre serveur de BD d'ailleurs).
Et puis, si ta base est bien construite (contrôles, intégrité référentielle) ils peuvent même aller jusqu'à la saisie.
C'est vrai que lorsqu'on a l'habitude d'utiliser Access pour consulter des données, c'est agréable de pouvoir continuer à le faire avec une BD puissante derrière.
Même si ça reste avant tout un outil pour la création d'application TRES limitées.

[Mouse]

Vu que la base de donnees est exclusivement utilise dans l'intranet de l'entreprise, je pense que je vais mettre l'option ASP.NET de cote.

Il ne me reste donc que Delphi et Access. Ce qui me permet deja de voir plus clair sur les possibilite que j'ai de chercher des infos dans une base de donnees SQL Server.

Je vais telecharger Delphi, pour avoir une idee, et ensuite en parler avec ceux de ma boite. Mais sa politique est d'acheter une licence Access pour chaque poste, donc je sais pas s'ils voudront acheter une licence Delphi, sachant qu'apres mon depart, ils vont devoir embaucher une personne seulement pour cela, alors que la, y'a du monde qui connait Access au niveau developpement.

Bon peut etre que j'essaie de trouver tout les arguments pour Access, car moi meme je ne connais pas delphi, et je voudrais pas me planter, mais je vais regarder delphi, et faire mon choix apres.

Merci

[neo.51]

ok, ben bon courrage

et tiens noua au courrant

[manuel76]

Contrairement à sqlserveur, access ce n'est pas du client serveur c'est du fichier partagé.

Lorsque tu met un fichier MDB dans un répertoire du serveur. La personne qui se connecte dessus vas rappatrier la totalité de la base sur son poste client (bonjour le réseau) même si elle a juste besoin de connaitre le dernier enregistrement. Peut importe la puissance du serveur tu utilise le réseau que tu bouche et les pc clients.Si word plante sur son poste elle peut endommager la base d'ou le bouton "réparer".

Avec SQL Serveur il y a une application qui fonctionne sur le serveur si tu veux interroger la base pour avoir par exemple le dernier enregistrement c'est la machine serveur qui va utiliser sa puissance le réseau ne rappatriera dans ce cas qu'un seul enregistrement (ouf). Si le pc plante pour une raison x ou y ta base de donnée ne craint rien.


Autre chose importante : le ploblème du lock si tu un utilisateur fais une modif sur un enregistrement ACCESS il bloque son enreg pour sa propre modif or access bloque que des pavés de 2 ko minimum si ma mémoire est bonne. Il y aura donc non seulement 1 ligne de bloquée mais plusieurs pour atteindre 2 ko (un truc peu être de faire des lignes de 2k o mais bon....). Ce problème va te tomber dessus au moment des tests multi-utilisateurs. Il est possible que tu soit obligé de gérer par pgm des problème de blocages infinies (verous mortel). Avec sql serveur ces problèmes sont infiniment moindre

Tout ca pour te dire que si tu garde ACCESS pur ton client et toi allez vers des tas de problèmes de perf , de fiablité ...Et de test qui n'en finissent pas. Un conseil donc TU DOIS AVOIR A TOUT PRIX UN SERVEUR DE BASE DE DONNEE

C'est plus cher mais ton boulot ne passera pas à la poubelle. Pour ACCESS via ODBC s'est aussi du client serveur sauf si tu met du fichier mdb au bout evidemment (pire encore)

A+ et bonne chance

[SQLpro]

Est-ce que mon choix ne doit pas tenir compte des connaissances qu'a l'entreprise ?
Je veux dire par la qu'elle a depense plein d'argent pour faire des formations Access.
Il m'est difficile de venir et de leur dire, OK, Access c'est nul, on change tout.

Mais non seulement ton entreprise en a vu les limites mais Microsoft aussi puisque Access et le langage VB sont tous les deux abandonnés pas Micosoft au profit de SQL Server (version MSDE) et C#... !

Autrement dit ton entrprise a misé sur des "trash" technologies... C'est d'ailleurs une habitude chez Microsoft que de proposer un outil bâclé puis de l'abandonner quelques années après en ayant fait croire à la pérénitée de l'investissement.

En revanche SQL Server existe depuis... bien avant Microsoft puisqu'il s'agit à l'origine du SGBDR SQL Server de Sybase !

En ce qui concerne C# il ne s'agit que d'un ersatz de Java et sa pérénité est tout aussi suspecte...

Donc le résumé est de dire : OK sur SQL Server, mais avec un outil de développement tiers plus implanté.
Le choix de Delphi est un excellent choix pour débuter car Delphi repose sur un langage normatif qu'est le Pascal et la palette des composants disponible pour développer est l'une des plus considérable.

Bien qu'il faille prendre en compte l'aspect formation à un SGBDR comme SQL Server et à Delphi, rien ne t'empêche de commencer par te faire la main sur une mini appli, puis de demander de l'assistance sur quelques journées afin de repartir du bon pied et fabriquer une application robuste.

En ce qui concerne la partie SQL de SQL server tu trouvera des tutoriaux sur SQLpro et sur developpez en général, tout comme pour la partie Delphi.
N'hésite pas à poser des questions dans les forums.

A +
[/quote]

[Typhoon]

Ptet bien que tu n'as besoin de Langage du tout...
Dans un premier temps tout depend du besoin que les gens ont de la base...
Si ces requetes sont simples tu peux les faire sous forme de procedures stockees et de vues directement sous SQL.
Ensuite tu donnes les droits d'acces a chacun suivant les vues qu'ils ont droit d'executer.
Exemple : j'ai besoin de savoir le status d'un produit en stock, tu cliques sur Quel_est_le_status_de tu remplis 'Patate' et ca te sort 'Y EN A PLUS'

Dans un deuxieme temps tu pourras t'atteler a faire une interface un peu plus design dans un langage ou tu te sens a l'aise, n'importe quel langage du comerce a des OCX ou des plugins pour te permettre d'acceder aux bases sans trop t'embetter.

Mais si c'est toi qui doit t'occuper de la base sur SQL, commence par bien apprendre SQL (le transac, les jobs... les backups, la recup,...)

En access on pouvait aussi faire ce genre d'appli.


Rudolf
Architecte et programmeur de talent,

[seb98]

C'est vrai que les outils de dev comme asp, delphi etc..
sont trés puissant.
mais on peut faire pas mal de chose avec access 2000 + SQL server.

Cela fait 2 ans que je developpe des logiciel de gestion avec access (pour la partie formulaire et code) et SQL Server (pour les données).
et je n'ai encore pas eu de problème majeur.

Donc au lieu de vouloir essayer des progs trop "professionnel", essaye un peu cette méthode.

Tu lances Access, tu créé un projet access (adp), tu te connecte à SQL Server et du code des formulaires comme si tu était en pure access.

L'interet, c'est que tu sera sûr de pouvoir finir ton developpement sans devoir demander plusieurs formations (fin chère) sur les logiciels de prog. derniers cris (faut arreter de faire des reves d'ingénieur informatique).

Pour le déploiement, il existe des run-time. Donc pas besoin de licence particulière pour les utilisateurs.

voilà c'était ma petite contribution à ce forum.

[Maxence HUBICHE]

Aaaah Voilà une réponse qu'elle est bonne !

Pourquoi crier haro sur Access ?
Il implémente des frontaux sur SQL Serveur en natif sans passer par les connexions ODBC standard.
Alors, effectivement, en faisant un ADP au lieu d'un MDB tu auras tout l'avantage de SQL Serveur pour ce qui est du C/S, et tout l'avantage du RAD et de l'interface Access satandard, et tu verras une claire différence au niveau de la rapidité.

Maintenant, il est vrai que tu auras toute la lourdeur de l'interface Access elle-même, et donc, les performances seront moindre que dans le cas d'un développement de logiciel standard.

Si ce que tu veux c'est mettre à fond dans les performances, alors là ... Delphi, C++, ... et comme le disait Neo, si tu veux l'orienter Web ASP.NET ...


En fait, il faut savoir où te positionner.
Quels coûts cela fera supporter à l'entreprise ?
Auras-tu le temps de tout faire ?
- Formation SQL Serveur (Coût / Temps)
- Installation SQL Serveur (licences / Temps)
- Implémentation des bases SQL Serveur (Temps)
- Développement (Coût achat licences / Temps)


NB : un adp implique un déploiement sur chaque poste utilisateur, mais pas un surcoût en licences ...

[Etienne Bar]

+1 pour la réponse de ZeMenace et seb98 !

D'autant plus que tes utilisateurs, s'ils ont accès à la base pour effectuer des requêtes, risquent de réagir très négativement à un logiciel "fermé".

Pour l'avoir fait, passer d'Access à Delphi n'est pas facile et implique du temps et des prises de tête !

[bifidus]

Salut,
J'ai été confronté au meme problème dans ma boite...
ACCESS plantait la base 2 à 3 fois par jour et parfois n'arrivait pas à la réparer.
Je me suis benoitement dit qu'il suffisait de lier des tables SQL Server sous ACCESS et le résultat fut catastrophique: délais de réponse rédhibitoire, vérouillage intempestifs de pages entières...
J'ai fini par me décider à attaquer SQL server directement en VB, puis maintenant en VB .NET.
Je n'avais pas la moindre idée de ce qu'était un Server de donnée et je ne faisais que du Basic-pour-Access.
Ca m'a pris un mois pour avoir un truc utilisable, mais depuis c'est le pied ! Plus aucun plantage et la base est désormais ouverte sur le net en lecture et ecriture en ASP !
On peut utiliser SQL Server de facon trés simple et je pense qu'une semaine suffit pour faire une base qui tient la route et la sauvegarder.
Pour le Server un bon gros 400 MHz avec 256 Mo suffit sous SQL 7.
- De toute façon les trucs plus compliqués (trigger, TSQL) n'existent pas sous ACCESS et on n'en ressent pas tout de suite le besoin.
- Il reste la possibilité de laisser ACCESS avec des tables liées aux utilisateurs expérimentés, mais juste pour rappatrier des données, NE JAMAIS ECRIRE VIA ACCESS, les résultats sont catastrophiques.
Bon courage

[TheFreeman]

Cela fait 2 ans que je developpe des logiciel de gestion avec access (pour la partie formulaire et code) et SQL Server (pour les données).

Bonjour,

J'ai une appli Access et je voudrai changer la BD partagée par un vrai C/S en concervant si possible le Front en Access.
SQLServer est tout désigné, mais as-tu eu le choix avec d'autres SGBD comme PostgeSQL ou InterBase ? Si oui, que justifie ton choix ?

Merci,

[TheFreeman]

Je me suis benoitement dit qu'il suffisait de lier des tables SQL Server sous ACCESS et le résultat fut catastrophique: délais de réponse rédhibitoire, vérouillage intempestifs de pages entières...
...
- Il reste la possibilité de laisser ACCESS avec des tables liées aux utilisateurs expérimentés, mais juste pour rappatrier des données, NE JAMAIS ECRIRE VIA ACCESS, les résultats sont catastrophiques.
Bon courage

C'était justement une de mes intentions, garder mon Front en Access et le lier à une SQBD C/S comme SQL Server ou un autre ; car j'ai des temps de réponse lamentable actuellement.
Tu me confirme ne pas avoir eu de gain de temps de réponse avec SQL Server ?

Merci,

[bifidus]

Salut,
Access n'est a mon avis utilisable qu'en monoposte.
En réseau c'est une véritable catastrophe (meme en temps que simple client) au niveau des traffic de données, des verrouillages etc... Tout ce que je peux lire sur le sujet me conforte dans ma propre expérience.
SQL Server est un excellent gestionnaire de base de donnée pour des bases moyennes, mais si on rajoute la couche ACCESS au milieu les performances chutent dramatiquement.
A mon avis au plus tot on se libère d'ACCESS au mieu c'est... d'autant plus que l'architecture donnet propose des outils trés performants pour accéder aux serveurs sql...
Pour les perfs pures tout dépend de tes besoins: la différence entre un vrai serveur comme Oracle ou Sql serveur se fait sentir lors de la montée en charge. avec deux connectés Access est surement plus rapide que sql serveur car il n'a pas les memes mécanismes de triggers, de journal de transaction etc... Il est par contre complètement instable....
Si tu trouves ACCESS seul trop lent avec peu de connectés c'est qu'il doit y avoir un problème dans ton architecture, le passage à ACCESS sur SQL server ne résoudra rien, au contraire ca ne t'apportera que des ennuis.