Base de données

1-Access ne connaît pas les triggers(sql server , oracle .... OUI ).

2-Access est trés bien pour gérer de "petites choses" et trés accessible au niveau de la programmation

3-Tu parles de gestion des stocks ...... ce qui est certain :
conceptuellement 2 tables seront insuffisantes

- oracle et sql server sont certainement inadaptés à tes besoins

petite question : veux tu gérer un historique de tes stocks et/ou des lignes de produits vendues

- access semble être adapté à ce que tu veux faire.
même s'il n'y a pas de triggers il suffit de taper un bout de code pour effectuer la mise à jour du stock automatiquement.

Si tu veux gérer un historique de tes stocks et/ou des lignes de produits vendues il faut revoir ton analyse au niveau du nombre de table
petit exemple :
avec ta table article (telle que tu me la decrite ) un article ne peut avoir qu'un seul prix de vente.
Il te faut donc une table

voici une solution (parmi d'autre ) :
PK : primary key
FK: foreign key

'table pour garder un historique des tarifs
HIST_TARIF (ID,PRIX,DATE-HEUR-MIN-SEC,ID_ARTICLE)
PK : ID ((autoincréménté)) + DATE-HEUR-MIN-SEC
FK : ID_ARTICLE

'table pour enregistrer tes articles
ARTICLES (ID_ARTICLE, LIBELLE, DESCRIPTION)
PK : ID_ARTICLE (autoincréménté)


'table pour l'historique des stocks
STCK (ID_ARTICLE, DATE-HEUR-MIN-SEC , QUANTITE DISP )
PK : ID_ARTICLE + DATE-HEUR-MIN-SEC
FK : ID_ARTICLE

'table pour enregistrer les ventes
VENTE (ID_VENTE,DATE-HEUR-MIN-SEC, ID_ARTICLE, RABAIS)
PK : ID_VENTE (autoincréménté)
FK : ID_ARTICLE

IL N'Y A PAS QUE CETTE SOLUTION
il faut en fait que tu analyse tes besoins en relevant toutes les informations que tu veux récupérer (prix , libéllé article,...)
Et seulement après tu commence la conception ........... et beaucoup plus tard ton dev


@+
A.N

Merci pour ta réponse. MAis en fait je crois que je n'ai pas besoin d'autant de table, car un article n'a qu'un prix de vente au départ, il est stocké dans la table article, et si il y a des soldes ou un rabais, le prix de vente réel est stocké dans la table vente ...
Je ne pense pas avoir besoin d'une table d'historique des stocks.

Comment est-ce q

Merci pour ta réponse. MAis en fait je crois que je n'ai pas besoin d'autant de table, car un article n'a qu'un prix de vente au départ, il est stocké dans la table article, et si il y a des soldes ou un rabais, le prix de vente réel est stocké dans la table vente ...
Je ne pense pas avoir besoin d'une table d'historique des stocks.

Comment est-ce que je défini une clé étrangère dans Access ? Et comment je défini un clé primaire qui a 2 attributs ?

Et si je dois ajouter du code pour pouvoir mettre à jour le stock ça sera en VB n'est-ce pas ? Je connais rien de rien au VB, ça ressemble un peu au C, ou a JAVA par hasard ???

a+

SEB

ce sera du VBA sous access

non non c'est pas du C
L'apprentissage est beaucoup plus rapide.

Tu ne connait certainement pas le SQL :
en utilisant l'interface graphique pur créer une clé primaire il faut sélectionner le champ et cliquer sur l'icône qui represente une clé jaune. (si ta clé comporte plusieurs champs il tous les séléctionner ).

pur la clé étrangére il faut définir des relations

Si je connais le sql justement, ça m'aurait plu de pouvoir construire mes tables en sql. Je suis débutant, ça m'aurait entraîner.

CREATE TABLE ARTICLE
(
ID COUNTER CONSTRAINT PrimaryKey PRIMARY KEY,
LIBELLE TEXT (60),
.................
.................
)


CREATE TABLE HIST_TARIF
(
ID ............ <------- pk
ID_ART ............. <------- fk
)

ALTER TABLE HIST_TARIF
ADD CONSTRAINT ID_FK FOREIGN KEY(ID) REFERENCES ARTICLE(ID)

est-ce que je peux insérer ça dans Access pour que çA me génère les tables ?
----->oui tu peux exécuter directo du sql dans l'onglet des requêtes


pour ce qui concerne ton autre question :
tu devras sans doutes utiliser les formulaires.
il faut utiliser soit des macros soit des procédures écrites en VBA
précision : les macros c'est plus lent

Si j'étais à ta place, avant de me lancer dans la conception et la réalisation d'une première appli sous Access, je ferais un ou deux tutoriels pour bien prendre en main l'outil : tu sembles hésitant (où faire du SQL directement ? étapes de création d'un formulaire, pourquoi créer des requêtes, attribuer du code VB à des éléments de formulaires, etc...), et ce genre d'hésitations fait perdre du temps, risque d'amener à faire des boulettes, etc...

Cela te permettra en plus de te familiariser avec l'EDI de VBA.

Tittom

Merci à tous pour vos réponses, je vais essayer tout ça et on verra bien

a+

sEb

Tu peux te faire aider pour réaliser ta petite application par WINDEV 5.5 .Tu peux retailler par la suite l'application qu'il contient
aux mesures du magasin de ta maman