OVH Cloud OVH Cloud

BASE DE DONNEES !!!!!!

29 réponses
Avatar
Julien
Bonjour, je suis débutant sur le développement sous visual basic, en général
je développe sous VBA...
J'utilise donc Visual Basic 6, mais j'ai un petit problème... Je ne sais pas
comment créer une base de données !!
Si quelqun pouvais m'aider un petit peu ça serai gentil

Merci par avance.

10 réponses

1 2 3
Avatar
Jean-Marc
"Julien" a écrit dans le message de
news:
Bonjour, je suis débutant sur le développement sous visual basic, en


général
je développe sous VBA...
J'utilise donc Visual Basic 6, mais j'ai un petit problème... Je ne


sais pas
comment créer une base de données !!
Si quelqun pouvais m'aider un petit peu ça serai gentil



Hello,

peux tu préciser un peu?

Tu veux:
- Créer une base: pas ouvrir une existante, mais la créer?

Tu veux donc ensuite créer tes tables, les index, etc?

Est ce bien cela?

Car en général, on créé la base avec Access, et le programme VB
se contente de la manipuler.

A moins que tu veuilles faire un programme dont le but est
justement de CREER des bases de données ?

--
Jean-marc
Tester mon serveur (VB6) => http://myjmnhome.dyndns.org
"There are only 10 kind of people
those who understand binary and those who don't."
mailto: remove '_no_spam_' ;
Avatar
Julien
Non c'est exactement cela, je veux savoir comment créer une base de données
dans laquelle VB vas stocker les données que je vais y saisir
Mon programme se basera sur cette base de données pour modifier ou supprimer
des informations.


"Jean-Marc" a écrit dans le message de news:
440083c8$0$3803$
"Julien" a écrit dans le message de
news:
Bonjour, je suis débutant sur le développement sous visual basic, en


général
je développe sous VBA...
J'utilise donc Visual Basic 6, mais j'ai un petit problème... Je ne


sais pas
comment créer une base de données !!
Si quelqun pouvais m'aider un petit peu ça serai gentil



Hello,

peux tu préciser un peu?

Tu veux:
- Créer une base: pas ouvrir une existante, mais la créer?

Tu veux donc ensuite créer tes tables, les index, etc?

Est ce bien cela?

Car en général, on créé la base avec Access, et le programme VB
se contente de la manipuler.

A moins que tu veuilles faire un programme dont le but est
justement de CREER des bases de données ?

--
Jean-marc
Tester mon serveur (VB6) => http://myjmnhome.dyndns.org
"There are only 10 kind of people
those who understand binary and those who don't."
mailto: remove '_no_spam_' ;



Avatar
Jean-Marc
Re hello,

Tu n'as pas précisé quelle DB tu voulais utiliser.
Si c'est Access, tu peux créer ta base avec Access lui même, c'est le
plus facile.
Si tu n'as pas Access, tu peux le faire avec VB en utilisant
depuis l'IDE (en anglais, en français ça doit être dans le même coin):

MENU => Add-Ins/Visual Data Manager

Le programme te permet de créer une DB (un .mdb), des tables, etc.
Ton programme n'a plus ensuite qu'à manipuler cette DB.
Pour la création proprement dite, c'est toi qui doit savoir faire
Pour l'utilisation depuis VB, tu peux poser tes questions ici.

--
Jean-marc
Tester mon serveur (VB6) => http://myjmnhome.dyndns.org
"There are only 10 kind of people
those who understand binary and those who don't."
mailto: remove '_no_spam_' ;



"Julien" a écrit dans le message de
news:
Non c'est exactement cela, je veux savoir comment créer une base de


données
dans laquelle VB vas stocker les données que je vais y saisir
Mon programme se basera sur cette base de données pour modifier ou


supprimer
des informations.


"Jean-Marc" a écrit dans le message de


news:
440083c8$0$3803$
> "Julien" a écrit dans le message de
> news:
>> Bonjour, je suis débutant sur le développement sous visual basic,


en
> général
>> je développe sous VBA...
>> J'utilise donc Visual Basic 6, mais j'ai un petit problème... Je ne
> sais pas
>> comment créer une base de données !!
>> Si quelqun pouvais m'aider un petit peu ça serai gentil
>
> Hello,
>
> peux tu préciser un peu?
>
> Tu veux:
> - Créer une base: pas ouvrir une existante, mais la créer?
>
> Tu veux donc ensuite créer tes tables, les index, etc?
>
> Est ce bien cela?
>
> Car en général, on créé la base avec Access, et le programme VB
> se contente de la manipuler.
>
> A moins que tu veuilles faire un programme dont le but est
> justement de CREER des bases de données ?
>
> --
> Jean-marc
> Tester mon serveur (VB6) => http://myjmnhome.dyndns.org
> "There are only 10 kind of people
> those who understand binary and those who don't."
> mailto: remove '_no_spam_' ;
>




Avatar
Geo
Bonjour à Julien qui nous a écrit :

Non c'est exactement cela, je veux savoir comment créer une base de données dans
laquelle VB vas stocker les données que je vais y saisir
Mon programme se basera sur cette base de données pour modifier ou supprimer des
informations.



Tu peux faire un simple fichier texte dont tu lis et écris les lignes
comme tu veux.

--
A+
Avatar
Aski
Salutatoi Geo,

Tu as donc déclaré :

Bonjour à Julien qui nous a écrit :

Non c'est exactement cela, je veux savoir comment créer une base de
données dans laquelle VB vas stocker les données que je vais y saisir
Mon programme se basera sur cette base de données pour modifier ou
supprimer des informations.



Tu peux faire un simple fichier texte dont tu lis et écris les lignes
comme tu veux.



Le fichier texte est le plus simple à manipuler, mais il faut tout lire et
toute écrire chaque fois. Il est donc recommandé pour les petites bases.

Cependant, lorsque le fichier est stucturé (champs de longueurs fixe) et que
le nombre de données est important, il est recommandé d'utiliser un fichier
à accès direct dans lequel on ne manipule qu'une fiche à la fois.
Avatar
Geo
Bonjour à Aski qui nous a écrit :

Salutatoi Geo,

Tu as donc déclaré :

Bonjour à Julien qui nous a écrit :

Non c'est exactement cela, je veux savoir comment créer une base de
données dans laquelle VB vas stocker les données que je vais y saisir
Mon programme se basera sur cette base de données pour modifier ou
supprimer des informations.



Tu peux faire un simple fichier texte dont tu lis et écris les lignes
comme tu veux.



Le fichier texte est le plus simple à manipuler, mais il faut tout lire et toute écrire
chaque fois. Il est donc recommandé pour les petites bases.



Et on peut le modifier avec le bloc-note ou tout traitement de texte
:-)

Cependant, lorsque le fichier est stucturé (champs de longueurs fixe) et que le nombre
de données est important, il est recommandé d'utiliser un fichier à accès direct dans
lequel on ne manipule qu'une fiche à la fois.



Chiche qu'on peut accéder en direct sur un fichier texte créé en vb.
Suffit de faire des lignes de longueur fixe.
Quand on débute en VB vaut mieux faire des trucs simples.


--
A+
Avatar
Jean-Marc
"Aski" a écrit dans le message de
news:
Salutatoi Geo,

Tu as donc déclaré :

> Bonjour à Julien qui nous a écrit :
>
>> Non c'est exactement cela, je veux savoir comment créer une base


de
>> données dans laquelle VB vas stocker les données que je vais y


saisir
>> Mon programme se basera sur cette base de données pour modifier ou
>> supprimer des informations.
>
> Tu peux faire un simple fichier texte dont tu lis et écris les


lignes
> comme tu veux.

Le fichier texte est le plus simple à manipuler, mais il faut tout


lire et
toute écrire chaque fois. Il est donc recommandé pour les petites


bases.

Cependant, lorsque le fichier est stucturé (champs de longueurs fixe)


et que
le nombre de données est important, il est recommandé d'utiliser un


fichier
à accès direct dans lequel on ne manipule qu'une fiche à la fois.



Hello,

ne pas oublier non plus que tout est question d'échelle.
Exemples:

* Gestion de son carnet d'adresse ou répertoire téléphonique:
-> Fichier plat, taille fixe ou non, tout en RAM
-> Access comme alternative

* Gestion d'une vidéothèque de taille moyenne
(disons 5000 films, 500 clients)
-> Base Access car besoin de requêtes.
-> Alternative: fichiers plats indexés (voir fin du post)

* Gestion centralisée des comptes d'une grande banque
(dison 30.000.000 comptes)
-> Grande Base de données : DB2, Oracle, autres grandes bases

<HS>
Autrefois (< 1970), il y a eu des implémentations
purement fichiers, mais sur des OS ou la gestion des fichiers
en particulier des fichier indexés (VSAM) était autrement
plus performante que sur un PC (grands systèmes IBM sous
OS360 ou OS390), Vax (VMS)). Certains grand systèmes d'information
utilisent toujours cela, et sont encore en production aujourd'hui
(banques, etc.). Ils songent doucement à migrer car les
dernières personnes connaissant vraiment bien ces systèmes
approchent de l'age de la retraite à grands pas, alors qu'on
trouve des spécialistes DB assez facilement.
</HS>

* Historisation des données de production
(10000 records par jours, mais que des ajouts)
-> Grande Base de donnée OU fichier plat!

Tout dépend aussi de l'usage (besoin)
- fréquence des ajouts et/ou suppressions
- fréquence des mises à jour
- proportion relative Ajouts/Mise à jour/Suppressions
- besoins en perfs (requêtes temps réel ou traitements batchs?)
- coûts? usage perso, petite boîte, grosse boîte, énorme boîte?

Et enfin, paramètre crucial, l'exploitation:
* Besoin de faire des requêtes complexes ou sur de gros volumes
-> Base de données, utilisation de SQL
* Besoin de faire de l'historisation pour Audit, etc
-> Base ou fichier
* Compétences? Coûts?

On peut tout à fait écrire une bibliothèque de fonctions permettant
de simuler une vraie DB relationelle, avec uniquement des fichiers.
C'est très amusant comme exercice, et ça peut être efficace. Evidemment,
c'est souvent plus pour le sport qu'autre chose: on se retrouve à
implémenter un subset de SQL, à réinventer les Index, etc.

Je l'ai fait autrefois (pas en VB mais peu importe) pour un projet
ou la contrainte (débile) était:
tout sur fichiers, pas de DB "commerciale".

--
Jean-marc
Tester mon serveur (VB6) => http://myjmnhome.dyndns.org
"There are only 10 kind of people
those who understand binary and those who don't."
mailto: remove '_no_spam_' ;
Avatar
Aski
Salutatoi Jean-Marc,

Tu as donc déclaré :

ne pas oublier non plus que tout est question d'échelle.
Exemples:

* Gestion de son carnet d'adresse ou répertoire téléphonique:
-> Fichier plat, taille fixe ou non, tout en RAM
-> Access comme alternative

* Gestion d'une vidéothèque de taille moyenne
(disons 5000 films, 500 clients)
-> Base Access car besoin de requêtes.
-> Alternative: fichiers plats indexés (voir fin du post)

* Gestion centralisée des comptes d'une grande banque
(dison 30.000.000 comptes)
-> Grande Base de données : DB2, Oracle, autres grandes bases

<HS>
Autrefois (< 1970), il y a eu des implémentations
purement fichiers, mais sur des OS ou la gestion des fichiers
en particulier des fichier indexés (VSAM) était autrement
plus performante que sur un PC (grands systèmes IBM sous
OS360 ou OS390), Vax (VMS)). Certains grand systèmes d'information
utilisent toujours cela, et sont encore en production aujourd'hui
(banques, etc.). Ils songent doucement à migrer car les
dernières personnes connaissant vraiment bien ces systèmes
approchent de l'age de la retraite à grands pas, alors qu'on
trouve des spécialistes DB assez facilement.
</HS>

* Historisation des données de production
(10000 records par jours, mais que des ajouts)
-> Grande Base de donnée OU fichier plat!

Tout dépend aussi de l'usage (besoin)
- fréquence des ajouts et/ou suppressions
- fréquence des mises à jour
- proportion relative Ajouts/Mise à jour/Suppressions
- besoins en perfs (requêtes temps réel ou traitements batchs?)
- coûts? usage perso, petite boîte, grosse boîte, énorme boîte?

Et enfin, paramètre crucial, l'exploitation:
* Besoin de faire des requêtes complexes ou sur de gros volumes
-> Base de données, utilisation de SQL
* Besoin de faire de l'historisation pour Audit, etc
-> Base ou fichier
* Compétences? Coûts?

On peut tout à fait écrire une bibliothèque de fonctions permettant
de simuler une vraie DB relationelle, avec uniquement des fichiers.
C'est très amusant comme exercice, et ça peut être efficace.
Evidemment, c'est souvent plus pour le sport qu'autre chose: on se
retrouve à implémenter un subset de SQL, à réinventer les Index, etc.

Je l'ai fait autrefois (pas en VB mais peu importe) pour un projet
ou la contrainte (débile) était:
tout sur fichiers, pas de DB "commerciale".



On parle bien de fichiers à gérer depuis VB.
Gérer un fichier ADR est quand-même plus simple que de gérer un fichier
Access depuis VB.
Avatar
Aski
Salutatoi Geo,

Tu as donc déclaré :

Bonjour à Aski qui nous a écrit :

Salutatoi Geo,

Tu as donc déclaré :

Bonjour à Julien qui nous a écrit :

Non c'est exactement cela, je veux savoir comment créer une base
de données dans laquelle VB vas stocker les données que je vais y
saisir Mon programme se basera sur cette base de données pour
modifier ou supprimer des informations.



Tu peux faire un simple fichier texte dont tu lis et écris les
lignes comme tu veux.



Le fichier texte est le plus simple à manipuler, mais il faut tout
lire et toute écrire chaque fois. Il est donc recommandé pour les
petites bases.



Et on peut le modifier avec le bloc-note ou tout traitement de texte
:-)

Cependant, lorsque le fichier est stucturé (champs de longueurs
fixe) et que le nombre de données est important, il est recommandé
d'utiliser un fichier à accès direct dans lequel on ne manipule
qu'une fiche à la fois.



Chiche qu'on peut accéder en direct sur un fichier texte créé en vb.
Suffit de faire des lignes de longueur fixe.
Quand on débute en VB vaut mieux faire des trucs simples.



Tu as raison, mais le fichier se gère alors comme un fichier à ADR avec des
Seek().
Comme le fait remarquer Jean-Marc, cela dépend de ce que l'on veut gérer.
Attendons que Julien nous en dise plus.
Avatar
Julien
Bon je vais exposer mon projet pour vous mettre sur la voie
Je souhaite créer un index de document. pour chaque document on retrouvera
plusieurs informations (au total 11).
Mon programme devra etre capable d'ajouter des information concernant un
document, de modifier les informations saisies auparavant, ou tout
simplement de supprimer un élément de cet index.
La finalité de ce programme est de pouvoir gérer plus de 200 documents qui
sont codifier, de les ouvrir et de consulter les informations d'un document
sans passer son temps a chercher des heures dans les dossiers du pc.
De plus mon programme integrera un moteur de recherche a mot clé.

Et mon soucis principal est que je ne sais pas comment lier mon programme a
une base de donnée.

Ce programme existe deja sous excel via VBA. Donc ma base de données se
trouve dans un tabeau excel.
Pour accelerer le processus de recherche et gagner en stabilité j'avais
pensé a le redevelopper sous Visual basic, mais lorsque j'eu fini de créer
toute mes forms je suis rester bete au moment de savoir ou j'allais stocké
mes données.

Note : Je possede Windows XP SP2, et Office 2003 (Access, Word, excel, ppt,
outlook, infopath)


"Aski" a écrit dans le message de news:

Salutatoi Jean-Marc,

Tu as donc déclaré :

ne pas oublier non plus que tout est question d'échelle.
Exemples:

* Gestion de son carnet d'adresse ou répertoire téléphonique:
-> Fichier plat, taille fixe ou non, tout en RAM
-> Access comme alternative

* Gestion d'une vidéothèque de taille moyenne
(disons 5000 films, 500 clients)
-> Base Access car besoin de requêtes.
-> Alternative: fichiers plats indexés (voir fin du post)

* Gestion centralisée des comptes d'une grande banque
(dison 30.000.000 comptes)
-> Grande Base de données : DB2, Oracle, autres grandes bases

<HS>
Autrefois (< 1970), il y a eu des implémentations
purement fichiers, mais sur des OS ou la gestion des fichiers
en particulier des fichier indexés (VSAM) était autrement
plus performante que sur un PC (grands systèmes IBM sous
OS360 ou OS390), Vax (VMS)). Certains grand systèmes d'information
utilisent toujours cela, et sont encore en production aujourd'hui
(banques, etc.). Ils songent doucement à migrer car les
dernières personnes connaissant vraiment bien ces systèmes
approchent de l'age de la retraite à grands pas, alors qu'on
trouve des spécialistes DB assez facilement.
</HS>

* Historisation des données de production
(10000 records par jours, mais que des ajouts)
-> Grande Base de donnée OU fichier plat!

Tout dépend aussi de l'usage (besoin)
- fréquence des ajouts et/ou suppressions
- fréquence des mises à jour
- proportion relative Ajouts/Mise à jour/Suppressions
- besoins en perfs (requêtes temps réel ou traitements batchs?)
- coûts? usage perso, petite boîte, grosse boîte, énorme boîte?

Et enfin, paramètre crucial, l'exploitation:
* Besoin de faire des requêtes complexes ou sur de gros volumes
-> Base de données, utilisation de SQL
* Besoin de faire de l'historisation pour Audit, etc
-> Base ou fichier
* Compétences? Coûts?

On peut tout à fait écrire une bibliothèque de fonctions permettant
de simuler une vraie DB relationelle, avec uniquement des fichiers.
C'est très amusant comme exercice, et ça peut être efficace.
Evidemment, c'est souvent plus pour le sport qu'autre chose: on se
retrouve à implémenter un subset de SQL, à réinventer les Index, etc.

Je l'ai fait autrefois (pas en VB mais peu importe) pour un projet
ou la contrainte (débile) était:
tout sur fichiers, pas de DB "commerciale".



On parle bien de fichiers à gérer depuis VB.
Gérer un fichier ADR est quand-même plus simple que de gérer un fichier
Access depuis VB.



1 2 3