ACCESS aide program..

Voila j'dois faire une ptite DB qui permetrait de gérer des cables et des connections entre des machines.
En gros un cable est connecté a une machine d'origine et a une autre. Faut identifier uniquement chaque cable, et repertorier tout ça ds une db...
C une ptite application en locale koi, vous me conseillez de programmer ça en koi? PTite db access jm'etais dis mais pr po vous mentir access g juste utilisé pr avoir une db qd je programmais en java mais jamais independament...

Est il possible de creer cette db en access et ensuite de la gerer (formulaire, conditions,...) uniquement en access, je ne connais pas trop les possibilités de ce prog.
Grand merci c assez precé

Si c'est pas trop grand access c'est le top tu sais faire presque tout avec ca

Tolk a dit:

Si c'est pas trop grand access c'est le top tu sais faire presque tout avec ca

Cliquez pour agrandir...

Pour les controles de tables à plusieurs niveaux c'est laid quand même le système de liaisons Access. En résumé, il est plus difficile de contrôler totalement les données (pour un prog de facturation ... par exemple ... ca sent pas le vécu )

comment ça si c po trop grand? J'sais pas faire une bd ac un nombre important d'enreg sous access?

Si tu comptes avoir des centaines de milliers d'enregistrements, ACCESS ça devient vite dépassé.
Ou si tu veux créer des procédures stockées et autres joyeusetés du genre ben ACCESS ça pue.

Mais bon avec un peud e VBa tu fais quand même pas mal de trucs

LEM01 a dit:

comment ça si c po trop grand? J'sais pas faire une bd ac un nombre important d'enreg sous access?

Cliquez pour agrandir...

Le système de gestion d'access est différent des BDD traditionnelles, ce qui le rend moins performant, mais suffisant selon tes besoins.

Petit conseil, lorsque tu crées ton programme VBA access, crée une bdd uniquement avec les données, et une autreavec les formulaires et les queries en les liants avec les datas. Lorsque tu devras mettre à jour ton programme, tu es sur de n'avoir aucun problème de mise à jour du prog et il te sera possible de gérer la sécurité impécablement (sinon, c'est impossible car il y a quelques moyens pour un simple utilisateur d'avoir accés aux données ... au cas où tu veux gérer la sécu bien sur :wink: )

LEM01 a dit:

comment ça si c po trop grand? J'sais pas faire une bd ac un nombre important d'enreg sous access?

Cliquez pour agrandir...

Si tu peux mais acces est vite dépassé. Pour te donner un exemple, un base de données access de 350 M doublait (voir triplait) de taille a la suite de pas mal d'opération effectuée sur les tables (a peu prêt 2 heures de manipulation de données effectuées à la suite). Du coup, on était obligé de faire un compactage de la Db après chaque calcul --> invivavle, on a du passer a une vrai DB.

AcidBird a dit:

LEM01 a dit:

comment ça si c po trop grand? J'sais pas faire une bd ac un nombre important d'enreg sous access?

Cliquez pour agrandir...

Si tu peux mais acces est vite dépassé. Pour te donner un exemple, un base de données access de 350 M doublait (voir triplait) de taille a la suite de pas mal d'opération effectuée sur les tables (a peu prêt 2 heures de manipulation de données effectuées à la suite). Du coup, on était obligé de faire un compactage de la Db après chaque calcul --> invivavle, on a du passer a une vrai DB.

Cliquez pour agrandir...

On a eu des bd jusqu'à 1.8 giga avec des perf tout à fait acceptables mais bon à 2 giga elles ont crashé (invalid argument). On a du passé à Businessobjects.

AcidBird a dit:

LEM01 a dit:

comment ça si c po trop grand? J'sais pas faire une bd ac un nombre important d'enreg sous access?

Cliquez pour agrandir...

Si tu peux mais acces est vite dépassé. Pour te donner un exemple, un base de données access de 350 M doublait (voir triplait) de taille a la suite de pas mal d'opération effectuée sur les tables (a peu prêt 2 heures de manipulation de données effectuées à la suite). Du coup, on était obligé de faire un compactage de la Db après chaque calcul --> invivavle, on a du passer a une vrai DB.

Cliquez pour agrandir...

Fallait passer par une autre bdd pour les tables temporaires tout simplement. Il était même possible de la créer manuellement et de l'effacer après traitement pour éviter de devoir la compacter à chaque fois. On sait aussi la compacter par code.

AGain a dit:

Fallait passer par une autre bdd pour les tables temporaires tout simplement. Il était même possible de la créer manuellement et de l'effacer après traitement pour éviter de devoir la compacter à chaque fois. On sait aussi la compacter par code.

Cliquez pour agrandir...

Oui mais à partir du moment où tu dois prendre autant de précautions pour conserver des performances, il est parfois plus intéressant de passer à un vrai SGBD.

Sit-Nikko a dit:

AGain a dit:

Fallait passer par une autre bdd pour les tables temporaires tout simplement. Il était même possible de la créer manuellement et de l'effacer après traitement pour éviter de devoir la compacter à chaque fois. On sait aussi la compacter par code.

Cliquez pour agrandir...

Oui mais à partir du moment où tu dois prendre autant de précautions pour conserver des performances, il est parfois plus intéressant de passer à un vrai SGBD.

Cliquez pour agrandir...

Je n'ai pas dit le contraire :wink:

Access peut-être bien selon les besoins.

Oui je sais, je l'utilise tous les jours
Les requêtes dans Informix, c'est pas top.
Par contre, un lien ODBC et c'est tout de suite plus simple dans ACCESS

Pour moi, le meilleur compromis prix/performance/facilité de développement, c'est une DB MSDE avec un FrontEnd Access.
On ne paye pas plus que Access (MSDE est gratuit), c'est pas plus difficile à gérer qu'un Backend en Access, et le moteur de DB de MSDE, qui est celui de SQL serveur, est carrément meilleur que JET (je commence personnellement à en avoir ras-le-bol des corruptions de DB en JET, ce qui n'arrive presque jamais en SQL serveur).