Formulaires access ou vb/access
tafiscobar
Messages postés
1277
Date d'inscription
Statut
Contributeur
Dernière intervention
-
tafiscobar Messages postés 1277 Date d'inscription Statut Contributeur Dernière intervention -
tafiscobar Messages postés 1277 Date d'inscription Statut Contributeur Dernière intervention -
Est ce que quelqu'un peut m'expliquer pourqoi choisir vb/access pour une application plutot que les formulaires de Access ? quelles st les limites des formulaires access par rapport aux feuilles vb? et qu'est ce q'on a à y gagner en performance pour une grande base sous access a faire l'application sous vb.
merci de votre reponse.
tafiscobar
merci de votre reponse.
tafiscobar
A voir également:
- Formulaires access ou vb/access
- Acer quick access - Forum Logiciels
- Access appdata - Guide
- Exemple base de données access à télécharger gratuit ✓ - Forum Logiciels
- Exemple de base de données access - Forum Access
- Vb - Télécharger - Langages
3 réponses
ton message est en double!
je t'ai répondu sur l'autre, c'était l'autre qui'l fallait remonter!
saucisson va...
kinder.surprise,
le maton du matou
je t'ai répondu sur l'autre, c'était l'autre qui'l fallait remonter!
saucisson va...
kinder.surprise,
le maton du matou
oui donc en substance ce que je disais, qui ne constitue qu'un avis personnel bien sûr, mais bon, c'est que tu n'as vraiment d'intérêt à utiliser VB que si l'appli doit être distribuée et que les postes n'ont pas Access installé, ou que ta version n'est pas la version Developer.
en admettant que ta version d'Access soit la version standard et que ce soit destiné à un poste sur lequel access est installé, tu n'auras d'intérêt à utiliser VB que si tu tiens à utiliser certains ActiveX qui ne sont pas dans la verison standard d'Access (encore que, si VB est installé sur le même poste, et sous réserve que ça ne pose pas de problème au déploiement mais ça je ne saurais dire, tu auras aussi accès aux ActiveX depuis Access)
Bon ben VB te fait une 'véritable' appli. Access, ça restera un fichier à faire tourner sous Access ou avec le runtime. Cela dit ça peut prendre une vraie tronche d'appli au point qu'on ne devine même plus que c'est Access qui se cache derrière.
Personnellement, je trouve que c'est beaucoup plus rapide de développer sous Access que sous VB, car c'est encore plus assité. Non pas que ce soit compliqué sous VB mais quasiment tout ce que tu fais sous VB tu peux le faire en VBA sous Access, et par ailleurs, vraiment le développement sous Access est _très_ rapide. Access a par ailleurs un gros avantage sur VB: la grille contenant des combos. Pour faire ça sous VB, accroche-toi au pinceau, à moins d'acheter un ActiveX qui le fasse (j'avais trouvé TrueDBGrid je crois qu'il s'appelait mais ça valait plusieurs milliers de francs je crois).
Avec Access, en deux coups de cuillère à pot, c'est réglé, quelques sous-formulaires et roule ma poule. Les Grid, DataGrid FlexGrid et consorts de VB sont nettement plus chiants à utiliser, encore que ce n'est pas la mort.
Non sérieusement, pour moi, dans le cas d'une appli devant tourner sur un poste où Access est installé, ou si je peux lui flanquer le runtime au train, la rapidité de développement sous Access l'emporte haut la main. Evidemment si tu veux utiliser le moindre treeview ben faut que tu aies VB ou Access DE sur ton poste de développement.
Voilà, ça dépend donc beaucoup de l'importance que tu donnes au temps de développement, ah et aussi, j'oubliais, si tu as besoin d'états. Sous Access c'est une rigolade, alors que sous VB, faut utiliser Crystal Report et je n'en ai lu QUE du mal...
kinder.surprise,
le maton du matou
en admettant que ta version d'Access soit la version standard et que ce soit destiné à un poste sur lequel access est installé, tu n'auras d'intérêt à utiliser VB que si tu tiens à utiliser certains ActiveX qui ne sont pas dans la verison standard d'Access (encore que, si VB est installé sur le même poste, et sous réserve que ça ne pose pas de problème au déploiement mais ça je ne saurais dire, tu auras aussi accès aux ActiveX depuis Access)
Bon ben VB te fait une 'véritable' appli. Access, ça restera un fichier à faire tourner sous Access ou avec le runtime. Cela dit ça peut prendre une vraie tronche d'appli au point qu'on ne devine même plus que c'est Access qui se cache derrière.
Personnellement, je trouve que c'est beaucoup plus rapide de développer sous Access que sous VB, car c'est encore plus assité. Non pas que ce soit compliqué sous VB mais quasiment tout ce que tu fais sous VB tu peux le faire en VBA sous Access, et par ailleurs, vraiment le développement sous Access est _très_ rapide. Access a par ailleurs un gros avantage sur VB: la grille contenant des combos. Pour faire ça sous VB, accroche-toi au pinceau, à moins d'acheter un ActiveX qui le fasse (j'avais trouvé TrueDBGrid je crois qu'il s'appelait mais ça valait plusieurs milliers de francs je crois).
Avec Access, en deux coups de cuillère à pot, c'est réglé, quelques sous-formulaires et roule ma poule. Les Grid, DataGrid FlexGrid et consorts de VB sont nettement plus chiants à utiliser, encore que ce n'est pas la mort.
Non sérieusement, pour moi, dans le cas d'une appli devant tourner sur un poste où Access est installé, ou si je peux lui flanquer le runtime au train, la rapidité de développement sous Access l'emporte haut la main. Evidemment si tu veux utiliser le moindre treeview ben faut que tu aies VB ou Access DE sur ton poste de développement.
Voilà, ça dépend donc beaucoup de l'importance que tu donnes au temps de développement, ah et aussi, j'oubliais, si tu as besoin d'états. Sous Access c'est une rigolade, alors que sous VB, faut utiliser Crystal Report et je n'en ai lu QUE du mal...
kinder.surprise,
le maton du matou