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
Pour utilserle code que tu m'as donné, j'ouvre Access, je fais nouveau module et j'insère le code?
De mon côté, je me suis contenté du minimum, en procédant ainsi :
Après avoir ouvert Access :
Base de données : Nouveau
Requêtes : "Créer une requête en mode création"
Afficher la table : "Fermer"
Barre d'outils, "Création de requête" : Mode SQL
Codage en dur de la requête SQL et exécution.
Ok, j'avais pas pensé à sa.
Bien j'avance, me reste plus qu'à trouver un moyen de convertir le champ lastlogon en entier et de manière utomatique puis d'appliquer tous ça à ma table
C'est bon tout roule sous Access et la conversion du lastlogon marche très bien.
Merci pour votre aide
Pour avoir travailler pendant 2 ans sur Access sur une application qui se voulait être professionnelle dans une grande compagnie d'assurance, je suis le premier à dire qu'Access n'est pas un outil professionnel au sens où il n'est pas performant pour un sou (> 300 000 enreg. => en vrac) et il dispose de beaucoup moins de fonctionnalités que des SGBD de pro tels que Oracle ou DB2.
Mais justement, Access se positionne sur ce pourquoi il est fait : des petites bases gérées par des amateurs le dimanche à la maison...
Donc, compte-tenu du besoin de harlockbaz, ravalons notre fierté mal placée de pros ou pseudo-pros des SGBD qui ricanent en entendant le mot "Access", ne l'envoyons pas au casse-pipe vers des SGBD surdimensionnés qui nécessitent de bien s'y connaître, et conseillons-lui Access qui convient parfaitement à ses besoins et qui est plus simple d'utilisation grâce à ses nombreux assistants (qui contribuent par ailleurs, selon moi, à faire d'Access un SGBD d'amateur car ces assistants génèrent du code pourri).
Pour le chargement de ton fichier CSV, tu peux l'attacher en tant que table sous Acces, et un assistant t'aide à le mapper (format fixe, variable, positionnement des colonnes, ...)
C'est totalement réducteur comme affirmation et ne représente pas forcément la réalité....il n'est pas performant pour un sou (> 300 000 enreg. => en vrac)...
Je peux donner un contre exemple pour démentir celà. J'ai développé une application de moins grande envergure en terme d'utilisateurs mais qui a aujourd'hui plus de 500000 enreg dans la table des principales saisies utilisateur. Elle est utilisée quotidiennement et fonctionne toujours bien et rapidement.
Je sais que globalement votre réponse va dans le bon sens mais cette affirmation ne devrait pas être lue par quelqu'un qui peut considérer Access comme une solution pour lui.
Access répond en tout point à mes attentes.
OK vmolines, faut l'interpréter comme un ordre de grandeur...
Le fait est que Access permet de gérer quelques centaines de milliers de lignes, alors que Oracle ou DB2 quelques centaines de millions !
Donc, ce n'est pas si réducteur que ça...
300 000 ou 500 000, même combat !
Moi je demande seulement de gérer environ 1000 lignes donc je pense pas avoir besoin d'Oracle pour le faire. Access sans sort très bien et j'ai bien avancé dans le projet. Je reste sous Access
Envoyé par gregory.broissard
VB + SQL Server en édition Express dans ce cas... sinon Access tout seul mais ce serait dommage
Comment sa dommage?VB + SQL Server en édition Express dans ce cas... sinon Access tout seul mais ce serait dommage
bah tant qu'à faire une appli autant bosser sur les outils actuels ce sera plus utile pour ton expérience. Et VB et SQL Server c'est pas inutile de les maitriser
Par comparaison, pour mes applications personnelles, je n’ai pas besoin d’une machine à 100 teraflops.
Pour sa part, harlockbaz n’a manifestement pas besoin d’un marteau-pilon, quand un casse-noix lui convient. Ne pas oublier que DB2 et Oracle ça peut coûter beaucoup de sous (licences, embauches de DBA pour arriver à les faire fonctionner, systèmes assurant un service 24h/24, une logistique non négligeable). Access n’a assurément pas les mêmes prétentions, mais il me permet de faire tranquillement du relationnel sans guère de problèmes.
Ne comparons pas ce qui n’est pas comparable. Demandons déjà à tous ces SGBD de respecter le Modèle Relationnel de Données, ça serait bien. On peut rêver...
tu oublies juste les versions Express de MS et Oracle totalement gratuite. Je maintiens que travailler sur Access c'est s'enlever la possibilité d'apprivoiser des SGBD professionnels.
fsmrel, tu prends la conversation en cours, donc si tu relis depuis le début, tu verras que je soutenais exactement la même chose que toi (cf. mon post #24). Je suis content d'avoir enfin un soutien !
orafrance, c'est un peu pareil, si tu relis tout le post, tu verras que le souci de harlockbaz est plus d'avoir un outil facile à gérer que se faire la main sur des technos porteuses. Peut-être que l'informatique n'est pas son principal centre d'intérêt, même s'il y a recours...
VB n'est pas plus compliqué qu'Access
Si, quand même...VB n'est pas plus compliqué qu'Access
Bonsoir,
Vous oubliez à votre tour qu'avec dgi77 nous en étions à évoquer des tables de quelques centaines de millions de lignes, hors de portée des versions Express.
Concernant les SGBD "professionnels", ne vous inquiétez pas, j'utilise aussi bien DB2 for z/OS ou MS SQL Server que ce pauvre Access et je ne vois pas en quoi ce dernier conduirait quiconque à mettre en œuvre la théorie relationnelle de façon moins "professionnelle" qu’avec les autres (déjà, avec le Sorry Query Language —SQL si vous préférez—, ça n’est pas toujours très évident...). Connaître un minimum de la théorie relationnelle, c’est ce qu’on exige en 1er lieu n'est-ce pas ? Celui qui connaît bien cette théorie peut faire du très beau travail avec Access. En revanche il a fallu un jour que je m’occupe d’un prétendu expert parfaitement incompétent ayant été à l’origine d’un désastre sur une machine Bases de données à deux millions d’euros : j’ai fourni un rapport d’audit accablant, démontant le mode de fonctionnement de ce branquignol (on aurait pu me demander de m’en occuper plus tôt, mais bon...) Une entreprise du secteur privé n'aurait pas survécu, suite à l’incurie d’un pareil danger public, totalement inconscient, mais qui avait su faire illusion. Il se serait au moins fait la main avec Access, on n’en serait pas arrivé là, il aurait compris certaines choses. Il n' y a pas de mauvais outils...
Comme je l'écris de temps en temps ici, je répète que j'ai eu la responsabilité de la conception et de la mise en oeuvre de bases de données de plus de 1000 tables dont certaines dépassant les cent millions de lignes et je vois mal comment j’aurais pu m'en sortir sans les ressources ad-hoc et un SGBDR taillé pour (ressources toujours déterminées par un prototypage de performance approprié). Ayant utilisé pendant plus de 30 ans bon nombre de SGBD "professionnels" dans de très grandes entreprises françaises, pour avoir audité ces SGBD, les avoir secoués comme des pruniers, je maintiens ce que je dis. J'aime bien utiliser Access ou MS SQL quand je traite d’applications où l’on manipule des volumes de données réduits, comme j'aime bien DB2 for z/OS quand il y a du volume, avec des tas de connexions actives. Du point de vue du Modèle Relationnel de Données, Access est pratiquement à niveau. Il me permet de structurer les tables de façon satisfaisante (sinon que je ne peux pas définir mes propres types ce qui est parfois agaçant, je l’avoue). Il me permet de mettre en œuvre l’algèbre relationnelle (d'accord, INTERSECT et EXCEPT (MINUS) ne sont pas fournis —au moins dans la version 2003 dont je dispose—, comme dans d'autres SGBDR du reste, mais avec UNION et [NOT] EXISTS, on s'en sort très bien, en attendant la version rendant Access formellement algébriquement complet). Il me permet de garantir l'intégrité d'entité, l'intégrité référentielle, tout comme les grands, c’est déjà pas mal.
Je ne sais pas si Access permet "d’apprivoiser les SGBD professionnels" (au fait, qu'entendez-vous par cela ?), mais je sais qu’il permet, si on veut s’en donner la peine, de s’assurer que l’on a apprivoisé la théorie relationnelle et à titre de preuve par neuf, on toujours peut se faire ses propres travaux pratiques, entamer les phases de prototypage, avec les versions Express ou tous autres SGBDR gratuits.
Je vous salue bien.
Hum... on est parfois en phase, mais on est aussi parfois en désaccord (cf. mon post #37).fsmrel, tu prends la conversation en cours, donc si tu relis depuis le début, tu verras que je soutenais exactement la même chose que toi (cf. mon post #24).
Le fait est que je débute totalement en SGBD, donc oui je cherche quelque chose de facile a prendre en main et qui me donne le résultat escompté. Je suis déjà très content de ce que j'ai pu réaliser avec Access. De plus, il fau que quelqu'un qui n'y connaisse pas plus que moi puisse aussi s'occuper de la base. Si le temps me permets alors peut-être j'essayrai d'utiliser vb et sql server en version express voir oracle qui apparement à une version gratuite.
dans ce cas, j'vois pas comment on peut conseiller Access
Et pour les SGBD professionnels, j'entends par là, utilisé dans un contexte professionnel exigent : grosse volumétrie et concurrence d'accès forte. Sinon, je crois comprendre que tu ne considères pas MS SQL comme un SGBD robuste... c'est plutôt étonnant
PS : le S de SQL c'est Structured pas Sorry
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager