Discussion :

[mat.M]

Gerer, fililale caisse d'pargne, systeme propriétaire de tenu de compte unitaire d'epargne salariale

Tiens ? j'ai travaillé sur un projet pour la Caisse d'Epargne et la base de données c'était ...SQL-Server

JE résume un développement ponctuel quelque soit l'environnement, Access, vois meme Excel plus VBA, c 1 personne, plus la recette des utilisateurs.
1 data server, une machine cliente, une interface utilisateur, un moteur transactionnel, les routines de report, les support utilisateur.....C une SSII complête...
Parles t'on réellement de la même chose ?

Tout à fait d'accord mais quand on se lance dans un projet informatique , il faut y réfléchir à plusieurs fois ! Il faut déterminer

*le but recherché du logiciel
*est-ce que le logiciel une fois développé et testé présentera un intérêt pertinent ? Et que les tâches accomplies par ce progiciel , on ne puisse pas simplement les réaliser avec...Excel ou Word ?

[Maxence HUBICHE]

*le but recherché du logiciel ?

Ben ça, on l'a dit et redit...
Ca vaut le coup de revenir dessus ?
'petits' projets avec peu d'utilisateurs simultanés

*est-ce que le logiciel une fois développé et testé présentera un intérêt pertinent ? Et que les tâches accomplies par ce progiciel , on ne puisse pas simplement les réaliser avec...Excel ou Word ?

Et après tu dis qu'on ne peut pas faire grand chose avec Access ?????
Ben essaie de faire la moitié de ce qu'on peut faire avec Access avec Excel !
Ce sont 2 logiciels différents !
Faire des 'bases de données' sur Excel ... oui, on peut ! Mais faire du dessin sur Word aussi. Et tu vas te galérer à reproduire des fonctionnalités natives dans Access. pour word ... n'en parlons pas !


Quand au VBA, s'il n'y a que la gestion d'erreur qui te chagrine ...
Tu sais qu'une erreur est un objet ? Que tu peux l'intercepter ? lui définir des propriétés, lui appliquer des méthodes ?
Alors tu sais que dans ton gestionnaire d'erreur, tu peux très bien savoir, sans que ce soit du bricolage du tout si c'est une erreur de DIV/0 ou de EOF atteint !
Qu'avec les instructions RESUME tu peux te ballader où tu veux dans ton code.
J'avoue que là, je n'ai pas tout bien compris à tes remarques à ce niveau.
Je ne dis pas que tu n'es qu'une brèle en VBA, je dis que je ne comprends pas ... l'intérêt de ces assertions.

[mat.M]

Ben ça, on l'a dit et redit...
Ca vaut le coup de revenir dessus ?
'petits' projets avec peu d'utilisateurs simultanés

J'ai pas pensé à revenir en arrière et corriger mon texte : je voulais écrirer le progiciel et non le logiciel.
Et je voulais parler d'un logiciel en général donc un progiciel donc un projet informatique développé par une SSII ( ou autre ) , dojnc de manière générale et non d'une application développée avec Access

[bidou]

J'avoue que là, je n'ai pas tout bien compris à tes remarques à ce niveau.
Je ne dis pas que tu n'es qu'une brèle en VBA, je dis que je ne comprends pas ... l'intérêt de ces assertions.

moi je ne prendrais pas ces précautions, c'est une brèle en VBA.
Dans ton cas, On error Goto 0 te fais ressortir de ton gestionnaire d'erreur tout comme try catch. Sinon comme le dis Zemenace, tu peux tester l'objet Err.
Dans ta ligne de dimensionnement ou est le problème. La faute que tu soulignes est une erreur de débutant.

VBA n'est pas un véritable language de programmation comme Java , C++ voire Delphi ou autres.

Qu'en sais tu puisque tu ne sais pas t'en servir.

[mat.M]

moi je ne prendrais pas ces précautions, c'est une brèle en VBA.

C'est gentil de m'insulter , merci .

La "brêle en VBA" a comme même dispensé une formation sur...VBA Access dans une SSII pour notamment des personnes qui devaient être placées chez des clients finaux.
Et d'après les retours que j'ai eu , les dites personnes semblaient satisfaites des quelques conseils que j'ai avec modestie donnés

Dans ta ligne de dimensionnement ou est le problème. La faute que tu soulignes est une erreur de débutant.

C'est une erreur de débutant pour toi certes, mais qui passe inaperçue pour bcp de monde.
Et le problème c'est quand on doit travailler sur tout un projet professionnel truffé d'incohérences et qu'il faut éliminer ces incohérences pour une date donnée

[bidou]

C'est gentil de m'insulter , merci .

Ce n'était pas le but, mais pour argumenter ton propos tu nous sort une faute de débutant et une méconnaissance profonde de la gestion d'erreur en vba. Je te rappelles que tu viens allègrement troller sur le VBA, tu devrais au minimum avoir une argumentation solide.

La "brêle en VBA" a comme même dispensé une formation sur...VBA Access dans une SSII pour notamment des personnes qui devaient être placées chez des clients finaux.
Et d'après les retours que j'ai eu , les dites personnes semblaient satisfaites des quelques conseils que j'ai avec modestie donnés

Et tu ne sais pas utiliser la gestion d'erreur, elle devait être top la formation.

C'est une erreur de débutant pour toi certes, mais qui passe inaperçue pour bcp de monde.
Et le problème c'est quand on doit travailler sur tout un projet professionnel truffé d'incohérences et qu'il faut éliminer ces incohérences pour une date donnée

Mais la le problème n'a plus lieu d'être. Un programme mal écrit, quel que soit le langage reste une horreur à corriger. J'ai lu des programmes C qui te ferait envisager le suicide, tellement leur programmation était incohérente.

Si ma réaction t'as vexé j'en suis sinbcèrement désolé, mais a certains moment c'est fatiguant de lire toujours les même bétises sur le VBA.
Ce n'est pas un langage purement objet, c'est entendu.
Il a la lenteur des langages interprété, soit.
Mais il permet une vitesse de developpement tout à fait respectable, et d'écrire un code robuste pour peu qu'on sache le manipuler. De plus il est relativement facile à apprendre. En tous cas, je ne vois pas en quoi ce ne serais pas un langage de programmation.

[mat.M]

Ok c'est promis je ne "trollerai" plus cette discussion.

Juste un petit droit de réponse :

J'ai lu des programmes C qui te ferait envisager le suicide, tellement leur programmation était incohérente.

C'est indéniable . Le code source développé dans n'importe quel language informatique peut devenir rapidement "un torchon" si on ne fait pas preuve d'un minimum de rigueur.


cet exemple provient du MSDN (ce qui est la référence de l'éditeur )

Pour n'importe quel débutant ou n'importe quelle autre personne la démarche logique du traitement du code suivant est littéralement incompréhensible et tordue :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
 
Sub OnErrorStatementDemo()
   On Error GoTo ErrorHandler   ' Enable error-handling routine.
   Open "TESTFILE" For Output As #1   ' Open file for output.
   Kill "TESTFILE"   ' Attempt to delete open 
            ' file.
   On Error Goto 0   ' Turn off error trapping.
   On Error Resume Next   ' Defer error trapping.
   ObjectRef = GetObject("MyWord.Basic")   ' Try to start nonexistent
            ' object, then test for 
'Check for likely Automation errors.
   If Err.Number = 440 Or Err.Number = 432 Then
      ' Tell user what happened. Then clear the Err object.
      Msg = "There was an error attempting to open the Automation object!"
      MsgBox Msg, , "Deferred Error Test"
      Err.Clear   ' Clear Err object fields 
   End If   
Exit Sub      ' Exit to avoid handler.
ErrorHandler:   ' Error-handling routine.
   Select Case Err.Number   ' Evaluate error number.
      Case 55   ' "File already open" error.
         Close #1   ' Close open file.
      Case Else
         ' Handle other situations here... 
   End Select
   Resume   ' Resume execution at same line
            ' that caused the error.
End Sub

Pour gérer les erreurs "mentalement" , avec son esprit , on s'y perd totalement.
Si on essayait de représenter la gestion des erreurs sur un organigramme , la tâche s' avérrait absolument ardue tant les sauts à des références , étiquettes et lignes de code sont nombreux.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
 
On Error GoTo ErrorHandler   ' Enable error-handling routine.
   Open "TESTFILE" For Output As #1   ' Open file for output.
   Kill "TESTFILE"   ' Attempt to delete open 
            ' file.
   On Error Goto 0   ' Turn off error trapping.
   On Error Resume Next   ' Defer error trapping

Le programme tente d'ouvrir le fichier "TESTFILE" , quel "On Error" supporte l'échec d'ouverture du fichier ??
Confusion totale .

Donc je suis têtu mais tout un projet avec des blocs de codes comme celui indiqué précédemment c'est des heures et des heures à décortiquer ce projet et des heures et des heures à diagnostiquer les bugs.

En Java , ou C# ou C++ la même chose s'écrirait à peu près ainsi :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
 
try {
 
fichier.Ouvrir ("TESTFILE");
 
}
catch(...) { Message "erreur";}
 
try{
 
CreeObjet ("MyWord.Basic");
}
 
catch(...) {  Message "erreur"; }
 
//etc...

C'est tout de même plus clair non ?

[bidou]

tu es tétu ce qui n'est pas grave, mais tu dis n'importe quoi, ce qui l'est plus.
Tu es allé nous chercher un exemple du fin fond du msdn (office95), qui utilise deux mode de gestion d'erreurs dans la même fonction, ce que personne ne fait. De plus tu as enlevé le texte explicatif qui dit que justement le but est de montrer deux techniques de gestion d'erreurs.

Si on essayait de représenter la gestion des erreurs sur un organigramme , la tâche s' avérrait absolument ardue tant les sauts à des références , étiquettes et lignes de code sont nombreux.

ce serait d'une simplicité biblique. Il n'y a qu'une étiquette et un saut. En plus ce n'est pas un programmeur C++ qui va nous parler de nombre de lignes de code, parce que je pourrais donner des exemples édifiant de la différences de codage pour obtenir la même chose. Ce n'est surement pas VBA qui utilise le plus de lignes de codes.

enfin pour montrer que ton exemple est juste un tour de passe passe je te réécris la même fonction

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Sub OnErrorStatementDemo()
 
    On Error GoTo ErrorHandler
        Open "TESTFILE" For Output As #1
    On Error GoTo 0
 
    On Error Resume Next
    ObjectRef = GetObject("MyWord.Basic")
    If Err.Number = 440 Or Err.Number = 432 Then
        MsgBox "Erreur Automation", , "Error Test"
        Err.Clear
    End If
    Exit Sub
 
ErrorHandler:
    If Err.Number = 55 Then
        Close #1: Resume
    End If
 
End Sub

c'est tout de même pas compliqué, non ?

[Maxence HUBICHE]

Moi, j'aurai fait ....

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
Sub OnErrorStatementDemo() 
    On Error GoTo ErrorHandler 
        Open "TESTFILE" For Output As #1 
        Kill "TESTFILE"
        ObjectRef = GetObject("MyWord.Basic") 
 
FinProg:
    On error resume next
    Close #1
    Exit Sub 
 
ErrorHandler: 
    Select case Err.Number 
        Case 55 
             Err.clear
        Case 440, 442
            MsgBox "Erreur Automation", , "Error Test" 
            Err.Clear 
        Case Else
            Msgbox "Erreur n°" & err.number & "(" & err.description & ") non attendue)",vbCritical
   End Select
   Resume Finprog 
End Sub

[Zeo_BO]

En outre, sous java (je suis pas certain), il est difficile d'avoir une procédure spécifique de gestion d'erreur.
Sous VBA, les procédures ecrites par bidou ou Zemenace, pour peu que le code soit pensé, peuvent être entiérement stockées dans une fonction sub() avec en réception d'argument l'err.number et eventuellement une variable qui recoit un donnée précisant la procédure qui génére l'erreur

Ca évite un try{} catch {} dans chaque procédure.
Et malgré tout les approches ne sont pas si éloignées.
Le "on error resume next" fait "le throws exception"
Le "on error goto" fait le try{} catch {}

C'est en plus propre, puisqu'il n'y a qu'une procédure.

[azu1]

alalalala le probleme c'est que vous vous cantonnez tous derriere vos positions
vous essayez tous de convaincre l'autre sans l'ecouter.....

BREF pour resumer ACCESS est un vrai SGBD et VBA est réellement puissant pour peu quon sache l'utiliser.
et je veux pas etre mechant mais c'est franchement plus simple que le C C++ ou java.....

Mais je serais idiot de dire VBA c'est top et JAVA c'est de la merde....
c'est faux cela depend juste des besoins.
on va pas utiliser une usine a gaz nécesitant des jours de developpement quand cela n'est pas nécessaire.
Par contre juste en passant, dans les salles de marches de BNP et de la Societe generale (pour ne cité que ca) on utilise tous les jours access VBA et meme Excel...
a bon entendeur...

PS: Au fait arreter de vous entretué je pense qu'on a plus 10 ans et que le but est d'avoir une vision objective de la question de départ
en tout cas ce qui me fait sourire c'est que le petit malin qui a poster cette question n'a pas donné de nouvelles.... ni n' a posé d'autre questions

[Maxence HUBICHE]

ce n'est qu'une redite azu1 !
Tout cela a déjà été rabaché par leVieux et moi-même (entre Autres ...)

[Beuss]

Je suis d'accord avec azu1 pour le post initial, de plus pourquoi chercher des arguments pour convaincre quelqu'un d'abandonner access si on ne connait (apparemment) pas le logiciel?

[Promesses]

Bonjour, je suis nouveau, et j'aime bien ce debat et les differents points de vues car je travaille dans une petite SSII dans laquelle je dev la majorité des applis en VBA/ access... et ca marche dans les entreprises (biensur en fonction des besoins)
Toutefois il est vrai que, quand le projet va prendre de l'ampleur, on passe a une intranetisation passant pas l'ASP 'fin bref...

On Error Goto mon_gestionnaire_erreur

C'est désespérant pour mettre au point un module de code !

En VBA (et aussi en VB ancienne mouture ) , on ne peut pas délimiter avec précision le bloc de code susceptible d'engendrer des erreurs .

Par exemple ,quelconque

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
On Error Goto mon_gestionnaire_erreur
Dim quotient as Integer
Dim resultat as Integer
Dim nombre as Integer
Dim rs as Recordset
nombre =10000
quotient=0
resultat=nombre/quotient ' erreur 1 div par zero
 
Set rs=CurrentDB.OpenRecordset("table_clients")
rs.MoveFirst ' erreur 2 : table_clients contient enregistrements ?

Comment délimiter :
* ce qui est susceptible de provoquer une division par zero
*un recordset mal initialisé

Je sais vous allez me donner 1000 réponses m'affirmant que c'est possible, que je suis un incompétent .
Mais il faut avouer que c'est au prix d'un certain "bricolage" !

C'est pourtant si simple de faire de simple tests

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
 
Dim quotient as Integer
Dim resultat as Integer
Dim nombre as Integer
Dim rs as Recordset
nombre =10000
quotient=0
 
if quotient <> 0 then
	resultat=nombre/quotient ' erreur 1 div par zero
else
	resultat = 0
end if
 
Set rs=CurrentDB.OpenRecordset("table_clients")
if rs.recordcount <> 0 then
	rs.MoveFirst ' erreur 2 : table_clients contient enregistrements ?
end if

c'est pas du bricolage, c'est de la propreté de code, parce que je pense que la gestion d'erreur doit se faire quand des tests ne peuvent plus etre faits...

Tiens ! Une autre erreur qu'on commet facilement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
Dim d1, d2 As Double

Ou est l'erreur ? d1 est un variant , d2 est effectivement un "double"

Bah c'est pas propre en VBA
suffit juste de faire

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
Dim d1 as double, d2 As Double

C'est pas si compliqué, fin c'que j'en dis moi....
En tout cas, je développe beaucoup en VBA/Access et je peux dire que ca marche bien dans les entreprises

[hkhan13]

hum pas mal qd meme les arguments des uns et des autres

dire qu'Access est utilisable que dans le milieu des "PME", j'ai du mal a le concevoir ca... en effet Access est present dans de nombreux milieux (SNCF, banque marché financier (back office qd meme :p), etc... etc...) c'est pas une histoire de taille d'entreprise mais de taille de projets....

(ps : financierement une PME est capable de mettre en place un projet sur n'importe quelle plate forme)


le langage de programmation, bin que tu utilises VBA, c ou Java, si tu ecris mal ton code le resultat sera le meme....
j'ai recupere plusieurs applications sous Access, certaines mal concues et d'autres (une en particularite) tres tres bien faites... c pas le langage qui fait la difference dans un programme mais le developpeur...


la gestion des erreurs : je la trouve pas mal au niveau d'access, perso je capte mes erreurs a travers un "on error goto erreur" et Erreur me renvoie a une fonction qui globalise toutes les erreurs et affiche soit un message perso soit un message Access


le gros avantage d'access est sa rapidite de developpement, ses multiples possibilites et le cout
ses defauts : bin que pour les petits projets dans lesquels la securite est pas primordiale (la securite Access existe mais ca vaut pas un vrai SGBD), pas de triggers (et ca ca m'embete)....

enfin bref, je suis pas fana d'access a 100%, mais je decouvre a travers mes differents projets dessus des choses interessante et sympa a mettre en place

[azu1]

hkhan13 j'aime bien ta façon de penser....
et je suis tout a fait d'accord avec toi.

[BisonDiligent]

Comme beaucoup d'amateurs ayant un bagage disons "semi professionnel" en informatique, j'utilise Access sporadiquement depuis des années.

J'ai réalisé quelques applications bien crasses, à usage professionnel, qui ont un premier mérite, celui de fonctionner.

Ces applications ont un second mérite : elles définissent très clairement mes besoins et ceux de mes collègues.

Si l'implémentation est loin d'être parfaite, l'analyse elle, est bel et bien terminée, et elle a été réalisée par l'utilisateur. (Recueil des besoins, analyse de l'information à traiter, conception et implémentation des fonctionnalités, critique même des défauts d'implémentation...)

Je comprends que celà horripille les "vrais professionnels", qui sont mis hors coup, et qui se prennent pour des martyrs lorsque l'on fait appel à eux pour mettre de l'ordre dans une bdd bidouillée et passer éventuellement en système client-serveur.

Je ne crois pas, pour ma part qu' Access aboutisse à une impasse.
D'abord, les données restent les données, les relations idem, et tout celà se transfère aisément, en cas de besoin, vers des systèmes plus sophistiqués si le besoin s'en fait réellement sentir. Un projet Access 2000 est conçu pour passer facilement en SQL Server.

En fait, le boulot d'un vrai professionnel n'est pas de se donner d'emblée le confort d'une solution sophistiquée, chère, et dont la maîtrise est réservée à des spécialistes (ce qui leur confère prestige, pouvoir et rénumération), mais bien de trouver la solution la mieux adaptée aux besoins et aux désidérata des commanditaires.

Je sors d'une formation ASP (pas encore .net) et je me suis posé la question suivante :

Quand Access, utilisé en réseau, commence à engorger celui-ci, pourquoi ne pas faire un grand pas en avant, et passer à un intranet? Si on place IIS et Access sur la même machine avec beaucoup de ram, ne peut-on pas de cette manière faire travailler asp + ADO + Access strictement en local? Le réseau ne véhiculerait plus alors que des pages HTML, les recordset, à peine ouverts seraient déjà refermés, limitant ainsi grandement le temps de verrouillage des enregistrements.

Ceci n'est évidemment qu'une idée, que je vais creuser dans les mois qui viennent. A vue de nez, c'est une solution qui devrait convenir pour au moins certaines applications. Elle n'est même pas incompatible avec l'usage d'access, en réseau, directement. (Comme celà, le patron, ou sa secrétaire peut toujours créer une requête d'analyse croisée et la mettre en oeuvre à la va vite, si le besoin s'en fait sentir...)

Si, dans certains cas de figure, cette solution intermédiaire pouvait réduire de moitié le traffic réseau et le temps de verrouillage des enregistrements, ce serait une solution élégante, offrant par ailleurs les avantages du système trois tiers.

Mais je pense qu'il existe aussi d'autres possibilités pour augmenter les possibilités d'utilisation d'Access en réseau, à tester au cas par cas.

- utilisation de formulaires de saisie indépendants, pour limiter le temps de verrouillage des enregistrement . Bien sur, il faut mettre du VBA derrière (et pas toujours élémentaire) simplement pour enregistrer un formulaire, ce qui n'est pas nécessaire en utilisation "classique" d'access - mais, en utilisation classique, on est en fait en transaction verrouillée pour les données du formulaire, et ce depuis l'instant où l'on a commencé à remplir un formulaire, même si on est interrompu par le téléphone (en monoposte, celà n'a aucune conséquence ...)

- windows terminal server? Avec des interfaces déportées sur le serveur (pourquoi pas une interface par utilisateur?)

- une combinaison des solutions précédentes?

J'aimerais que des professionnels me disent : j'y ai pensé, j'ai testé, celà donne tel ou tel résultat, avec telle ou telle contrainte (des contraintes, j'en voit déjà quelques-unes ...)

Comme je suis une vieille caboche, je vérifierai de toute façon par moi-même.

Merci à tous ceux qui animent le débat!

[ericdes]

J'ai realise 2 projets avec MS-Access, certains se sont passes mieux que d'autres :

(1) Projet 1 - VB5 / Access 2000 / DAO, le .mdb est sur le server et l'application est sur plusieurs ordinateurs, mais principalement utilisee par un seul utilisateur. Depuis 4 ans que l'application tourne, je n'ai rencontre aucun problemes. Taille du .mdb : 15 Mo.

(2) Projet 2 - Delphi 6 / Access 2000 / ADO. L'application est maitenant utilisee par une dizaine d'utilisateurs. Je ne cesse d'avoir des problemes, en particuliers lors des 'post', j'ai des erreurs qui ne raise rien sous Delphi, j'en suis arrive a suppose qu'elles viennent d'Access. En particulier, des enregistrements ne se font pas, des enregistrements avec une cle vide (non authorisee) apparaissent. Cela apparait pratiquement 2 fois par semaine et nous devons 'reparer' la base de donnes (heureusement, c'est automatique et il n'y a pas de donnees perdues). Taille du .mdb : 30 Mo.

(3) Nouveau projet, avec Delphi 7 et quelle base de donnees? En fait je voudrais creer un logiciel de type Ciel, et je viens de lire dans cette discussion qu'il utilise Access pour stocker les donnees. J'ai un peu peur de me trouver coince comme c'est la cas avec le projet 2, cependant l'installation transparente du serveur de base de donnees grace a Jet est un plus, et je me dis qu'Access est quand meme bien pratique. Ou existe-t'il d'autres solutions faciles a mettre en oeuvre ?

[Alberto]

Bonjour,

J'ai suivi ce débat avec attention. Etant jeune développeur et n'ayant que peu d'expérience je ne me suis donc pas permis de critiquer (positivement ou négativement) quelque avis que se soit...

Je tiens tout de même à accentuer une phrase dite par hkhan13 :

c pas le langage qui fait la difference dans un programme mais le developpeur...

Selon moi c'est un point très important que certains d'entre vous avez oublié dans bon nombre de vos messages.

Pour revenir à la question de départ, je trouve dommage que la personne ayant posé le problème ne soit plus intervenue pour nous donner plus de détails concernant le projet à affectuer.

Car si Access est déjà à disposition et que c'est un projet de petite taille (entendez par la simple dans son niveau graphique et au niveau du stockage) et bien je trouve qu'il faut le faire en access. Pas besoin de faire le truc super fou en dieu sait quelle language. Si on dispose d'outils utilisables pour le besoin en question, alors pourquoi aller en chercher d'autres ?

Enfin si l'initiateur du sujet pouvait repasser afin d'approfondir la chose, je pense que ca serrait très bien

Bonne journée à tous

PS : J'ai 25 ans et je pense que la plupart d'entre vous êtes plus agés que moi... Mais en regardant certaines réactions on croirait que vous avez 10 ans ! Arrettez de vous entretuer bon sang !!!

[hkhan13]

1) les limites d'access en terme de volumetrie ?
2) les limites d'access en terme de nombre d'utilisateur ?
3) Mr DRH toi qui a de l'experience, en moyenne quel est le budget a mettre en place pour une application viable sous Access (grossomerdo) ?
4) Quand on veut migrer de Access vers un autre SGBD est ce simple, quels sont les problemes rencontres en general (je sais cf FAQ Access) ?
...

1) ca depends de ce que tu fais de tes donnees, je pense que sur une table avec un certain nombre de champs "standard" :p tu peux aller jusqu'a 30000 lignes, apres tout depends du nombre de personne accedant aux donnees en meme temps (important ca) mais aussi du reseau en place et des machines (proc+memoire)


2) sur une application full access 4-5 utilisateurs lancant des operations en meme temps c la limite (je parle d'operation et non de lecture)


3) impossible de repondre a cette question, c'est la 4eme application que je developpe sur access et chaque fois son cout est tres tres variable... ca depends du temps de developpement et nombre de personne dessus, mais ca peut monter haut (dans le monde du service compte 450 euros /jour/personne)...donc un projet etalonne sur qlq annees....


4) je l'ai fait pour passer de full access a sql server et full access a oracle sur des projets de taille moyenne.... dans l'absolu c rapide a mettre en place et tres facile si on connait les sgbd. pour l'application sur sql, qlq semaines (mais pas tout a ete passe et ct mon 1er projet :p), sur oracle : 3 mois complets (securite, requetes, proc stock etc...). pas de gros pb insolubles a rencontrer....