Je voudrais connaître les avis sur l'utilisation du data environment pour développer une application en VB6.
Une appli du type client-serveur avec une base sql serveur et une 20 d'utilisateurs.
Ne faut-il pas mieux prendre les objets ADO direct ?
Merci d'avance ....
Salut. Perso, je dirais ADO direct : plus de souplesse.
PS. Ca fait plaisir de trouver un autre Loïc :=)
-- ========== Gigfy
Le Bluesy masqué..... :=)
Bismark Prods
+ souplesse = + de debuggage
"Gigfy" a écrit dans le message de news:
Un certain loic écrivait ici même ce qui suit:
> Bonjour, > > Je voudrais connaître les avis sur l'utilisation du data > environment pour développer une application en VB6. > > Une appli du type client-serveur avec une base sql serveur > et une 20 d'utilisateurs. > > Ne faut-il pas mieux prendre les objets ADO direct ? > > Merci d'avance .... > >
Salut. Perso, je dirais ADO direct : plus de souplesse.
PS. Ca fait plaisir de trouver un autre Loïc :=)
-- ========== > Gigfy
Le Bluesy masqué..... :=)
+ souplesse = + de debuggage
"Gigfy" <nomail@nospam.com> a écrit dans le message de
news:Xns93BFEADF37468nomailnospamcom@195.34.132.71...
Un certain loic écrivait ici même ce qui suit:
> Bonjour,
>
> Je voudrais connaître les avis sur l'utilisation du data
> environment pour développer une application en VB6.
>
> Une appli du type client-serveur avec une base sql serveur
> et une 20 d'utilisateurs.
>
> Ne faut-il pas mieux prendre les objets ADO direct ?
>
> Merci d'avance ....
>
>
Salut. Perso, je dirais ADO direct : plus de souplesse.
> Bonjour, > > Je voudrais connaître les avis sur l'utilisation du data > environment pour développer une application en VB6. > > Une appli du type client-serveur avec une base sql serveur > et une 20 d'utilisateurs. > > Ne faut-il pas mieux prendre les objets ADO direct ? > > Merci d'avance .... > >
Salut. Perso, je dirais ADO direct : plus de souplesse.
PS. Ca fait plaisir de trouver un autre Loïc :=)
-- ========== > Gigfy
Le Bluesy masqué..... :=)
Gigfy
Un certain Bismark Prods écrivait ici même ce qui suit:
+ souplesse = + de debuggage
Moais.... Ca dépend de ton analyse préliminaire et de ka façon dont c'est codé... Perso, j'ai pas trop de problème... J'ai plusieurs programmes clients "moyens". J'ai défini un ensemble de fenêtres sur le principe suivant :
Une base (souvent access 97) une connexion DAO 3.6 - ODBC Direct (je suis en VB5) Un driver ODBC avec un nom défini Un ensemble de modules avec - Ouverture / Fermeture de base - Ouverture / Récup de données / Fermeture de requêtes - Requêtes actions (ajout,suppression,modif)
Dans une fenêtre une flexgrid avec les champs que je veux, remplis à la main, mais la rapidité est "bonne", et une fenêtre de modif.
Je gère toute la partie récup/envoi de données. J'entend par là que je passe par la propriété .text, et que je ne lie pas mes contrôles à un elément de base.
Avantage de la chose (amha) : - Je sais quand je vais chercher mes données (pas de problème de update) - Je peux formater mes données mes données - j'ai la main, et j'aime bien ça :=)
Inconvénients : - Ca fait du code, et bien que mon code soit commenté, quelqu'un d'autre que moi devra passer du temps à comprendre le fonctionnement avant d'apporter réellement les modifs éventuelles. Ceci dit, amha, ce problème existe aussi en 'lié'
Je réutilise mes codes au fur et à mesure et je ne passe pas beaucoup de temps à les adapter. J'ai passer du temps au début à monter mon système, mais maintenant, je n'ai plus à me poser de question sur la partie d'accès à une base. D'un autre coté, je cherche à simplifier le système pour encore simplifier les modifs nécessaire, mais je landerais un thread plus détaillé ultérieurement.
Tout ça pour dire : + de souplesse = + de temps à définir ce qu l'on veut = meilleure analyse = meilleurs outils = + de codage (pas forcément, d'ailleurs) = + de déguggage = + d'expérience = + de réutilisabilité
En espérant avoir apporté de l'eau au moulin .... -- ========== Gigfy
Le Bluesy masqué..... :=)
Un certain Bismark Prods écrivait ici même ce qui suit:
+ souplesse = + de debuggage
Moais....
Ca dépend de ton analyse préliminaire et de ka façon dont c'est codé...
Perso, j'ai pas trop de problème... J'ai plusieurs programmes clients
"moyens". J'ai défini un ensemble de fenêtres sur le principe suivant :
Une base (souvent access 97)
une connexion DAO 3.6 - ODBC Direct (je suis en VB5)
Un driver ODBC avec un nom défini
Un ensemble de modules avec
- Ouverture / Fermeture de base
- Ouverture / Récup de données / Fermeture de requêtes
- Requêtes actions (ajout,suppression,modif)
Dans une fenêtre une flexgrid avec les champs que je veux, remplis à la main,
mais la rapidité est "bonne", et une fenêtre de modif.
Je gère toute la partie récup/envoi de données. J'entend par là que je passe
par la propriété .text, et que je ne lie pas mes contrôles à un elément de
base.
Avantage de la chose (amha) :
- Je sais quand je vais chercher mes données (pas de problème de update)
- Je peux formater mes données mes données
- j'ai la main, et j'aime bien ça :=)
Inconvénients :
- Ca fait du code, et bien que mon code soit commenté, quelqu'un d'autre que
moi devra passer du temps à comprendre le fonctionnement avant d'apporter
réellement les modifs éventuelles. Ceci dit, amha, ce problème existe aussi
en 'lié'
Je réutilise mes codes au fur et à mesure et je ne passe pas beaucoup de
temps à les adapter. J'ai passer du temps au début à monter mon système, mais
maintenant, je n'ai plus à me poser de question sur la partie d'accès à une
base.
D'un autre coté, je cherche à simplifier le système pour encore simplifier
les modifs nécessaire, mais je landerais un thread plus détaillé
ultérieurement.
Tout ça pour dire :
+ de souplesse = + de temps à définir ce qu l'on veut = meilleure analyse =
meilleurs outils = + de codage (pas forcément, d'ailleurs) = + de déguggage =
+ d'expérience = + de réutilisabilité
En espérant avoir apporté de l'eau au moulin ....
--
========== Gigfy
Un certain Bismark Prods écrivait ici même ce qui suit:
+ souplesse = + de debuggage
Moais.... Ca dépend de ton analyse préliminaire et de ka façon dont c'est codé... Perso, j'ai pas trop de problème... J'ai plusieurs programmes clients "moyens". J'ai défini un ensemble de fenêtres sur le principe suivant :
Une base (souvent access 97) une connexion DAO 3.6 - ODBC Direct (je suis en VB5) Un driver ODBC avec un nom défini Un ensemble de modules avec - Ouverture / Fermeture de base - Ouverture / Récup de données / Fermeture de requêtes - Requêtes actions (ajout,suppression,modif)
Dans une fenêtre une flexgrid avec les champs que je veux, remplis à la main, mais la rapidité est "bonne", et une fenêtre de modif.
Je gère toute la partie récup/envoi de données. J'entend par là que je passe par la propriété .text, et que je ne lie pas mes contrôles à un elément de base.
Avantage de la chose (amha) : - Je sais quand je vais chercher mes données (pas de problème de update) - Je peux formater mes données mes données - j'ai la main, et j'aime bien ça :=)
Inconvénients : - Ca fait du code, et bien que mon code soit commenté, quelqu'un d'autre que moi devra passer du temps à comprendre le fonctionnement avant d'apporter réellement les modifs éventuelles. Ceci dit, amha, ce problème existe aussi en 'lié'
Je réutilise mes codes au fur et à mesure et je ne passe pas beaucoup de temps à les adapter. J'ai passer du temps au début à monter mon système, mais maintenant, je n'ai plus à me poser de question sur la partie d'accès à une base. D'un autre coté, je cherche à simplifier le système pour encore simplifier les modifs nécessaire, mais je landerais un thread plus détaillé ultérieurement.
Tout ça pour dire : + de souplesse = + de temps à définir ce qu l'on veut = meilleure analyse = meilleurs outils = + de codage (pas forcément, d'ailleurs) = + de déguggage = + d'expérience = + de réutilisabilité
En espérant avoir apporté de l'eau au moulin .... -- ========== Gigfy
