IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Débats sur le développement - Le Best Of Discussion :

Quel outil choisir pour un développement SQL-Server ?


Sujet :

Débats sur le développement - Le Best Of

  1. #21
    Futur Membre du Club
    Profil pro
    Inscrit en
    juillet 2003
    Messages
    6
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juillet 2003
    Messages : 6
    Points : 6
    Points
    6
    Par défaut
    Pour te donner une idée :
    ~15 utilisateurs

    Appli (~13 Mo)
    - 75 Tables (dont les tables servant occasionnellement)
    - 145 Formulaires
    - 130 requêtes externes (sans compter celle qui sont dans les formulaires, Etats ou modules
    - 78 Etats
    - 24 modules

    Qd tu dois charger le formulaire principal et que tu dois attendre 20 secondes voir plus, ne penses tu pas que j'aurai un gain de perfs avec un SGBD C/S comme SQL Server ou PostgeSQL ?

  2. #22
    Membre régulier
    Inscrit en
    mai 2003
    Messages
    58
    Détails du profil
    Informations forums :
    Inscription : mai 2003
    Messages : 58
    Points : 70
    Points
    70
    Par défaut C'est Typique ACCESS
    Salut,
    D'aprés ce que tu décris, tu as atteind la limite typique de la gestion ACCESS. La lenteur ne vient pas du Serveur de donnée mais de l'architecture qui est autour... Avec ACCESS c'est la facilité mais on a aucun controle sur le traffic de données. On rajoute des sous formulaires, des sous requetes etc... Tout ca pose des verrous, engendre un traffic colossal sans que l'on s'en rende compte. Un exemple simple: avec ACCESS on ouvre une table et celui ci renvoie sans broncher 3.000.000 de lignes...
    Aucun client sérieux ne propose de telles inepties par défaut !
    Si tu veux accelerer ton appli il ne faut surtout pas passer sur un serveur avec Access en client car celui-ci va continuer sa gestion mais avec plusieurs couches logicielles pour dialoguer avec le serveur, au mieux il faudra quelques heures pour lancer ton appli et au bout de quelques jours il y aura tellement de verrous (il faut les virer à la main...) que la base sera inutilisable.
    Il faut que tu analyses le traffic de données sous Access et le réduire...
    De toute facon 13 Mo de code c'est énorme pour une seule appli, la aussi il faut voir ce qui prend du temps.
    Par exemple j'avais fait une appli sous Access qui copiait des menus d'un formulaire sur un autre et mon appli ralentissait de plus en plus. J'ai fini par m'apercevoir que ces menus n'étaient jamais détruit et qu'ACCESS chargeait 20.000 Menus au démarrage... Il doit t'arriver un truc comme ça.

  3. #23
    Membre à l'essai
    Inscrit en
    mars 2003
    Messages
    10
    Détails du profil
    Informations forums :
    Inscription : mars 2003
    Messages : 10
    Points : 11
    Points
    11
    Par défaut Re: Faut pas cracher sur access
    Citation Envoyé par TheFreeman
    Citation Envoyé par seb98
    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,
    En fait, j'ai pas eu le choix du sgbd. c'est le boss qu'a choisi.
    mais à l'époque, c'était le deuxième sgbd le plus vendu (aprés Oracle).
    Et il avait bonne réputation (bien que ce soit un produit microsoft).

    Pour ton appli,

    moi, j'essairais de migrer la base sous sql server et tester quelques formulaires sur un projet adp. (pas un mdb avec des tables attachées, ça c'est du access. pour erick ).

    Sinon, pour ton probleme de temps de réponse,
    je pense pas qu'un utilisateur est besoin d'un formulaire avec 20 000 enregistrements devant lui. Ou sinon c'est un bon.
    Filtre le formulaire avant de l'ouvrir, n'ouvrir que les dix premiers, etc...

  4. #24
    Membre à l'essai
    Inscrit en
    mars 2003
    Messages
    10
    Détails du profil
    Informations forums :
    Inscription : mars 2003
    Messages : 10
    Points : 11
    Points
    11
    Par défaut
    Citation Envoyé par erick.mouret
    Salut,

    - 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.

    Access 2000 -> Nouveau Projet Adp -> Clique droit sur une table -> Déclencheurs

    C'est vrai c'est en francais, ca peut perdre les gens.

    T-SQL :

    Public Sub gSQLEcrire(s As String)

    Dim rs As New ADODB.Recordset

    rs.Open s, CurrentProject.Connection, adOpenForwardOnly, adLockReadOnly

    If rs.State = adStateOpen Then rs.Close
    End Sub

Discussions similaires

  1. Quel SGBD choisir : Oracle ou Microsoft SQL-Server ?
    Par dellibmdell dans le forum Décisions SGBD
    Réponses: 94
    Dernier message: 06/03/2013, 23h42
  2. Quel outil choisir pour mon développement?
    Par ghargamaster dans le forum Windows
    Réponses: 3
    Dernier message: 24/04/2009, 14h49
  3. Quel statut choisir pour les développers webs
    Par Dung-Tri dans le forum Freelance
    Réponses: 2
    Dernier message: 02/09/2008, 11h18
  4. quel outil choisir pour une application: gestion d'un centre de formation
    Par timaa dans le forum Langages de programmation
    Réponses: 10
    Dernier message: 20/03/2008, 09h29
  5. [Forum][Conseil] Quel outil choisir pour créer son forum?
    Par idamarco dans le forum EDI, CMS, Outils, Scripts et API
    Réponses: 18
    Dernier message: 26/02/2007, 00h19

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo