Créer application multiposte utilisant la meme base

[invite0ee73e60]

Bonjour a tous,

Voila ma problématique, je dois développer une application informatique, et une base de donnée commune, ou chaque membre de chaque service puissent accéder à cette base et la mettre à jour.

Je developpe l'application sous c#, et je me demandais comment j'allais mettre en place cette application, sachant que je dois utiliser Ms Access comme base de donnée.
Je pense que cela intègrera des notions de réseaux ?

Bref, je demande donc des conseils et astuces ou pistes pour pouvoir terminer mon analyse et commencer le developpement complet!

Merci d'avance pour vos réponses,
Cordialement,
-----

[invite3222ab58]

bonsoir safaben,

J'ai déjà développé des applications avec bases Access en réseau en tant que professionnel et
elles sont toujours utilisées à ce jour.

Le principe consiste en des verrous ou lock à introduire à l'ouverture de l'enregistrement de la base primaire.
La base de travail est simplement une copie de la base primaire qui est remis à jour dés la fin
de la validation de l’enregistrement verrouillé précédemment.

Soit base Access ORIGINE créer un programme (quelque soit le langage) qui ouvre une copie de la base au démarrage.

lors de la mise à jour d'une grille de saisie :
Si création bloquer le compteur qui sert de clé primaire (index) via une table ou tout autre moyen pour éviter
que quelqu'un créer le même enregistrement (avec la même clé).

Si modification bloquer la mise à jour de l'enregistrement par tout autre poste via la clé.

Si suppression bloquer la mise à jour de l'enregistrement par tout autre poste via la clé.


remarque: le verrou crée doit contenir la date, l'heure, le numéro ou l'id du poste en réseau, la clé de l'enregistrement.

A l'intérieur du programme à l'appel d'un enregistrement il suffit de vérifier dans la table verrou sa présence ou non.

Au moment de la validation appeler la base primaire ORIGINE et la mettre à jour et rafraîchir la copie .
Enfin ôter le verrou de la table.

Cela semble travailler en doublon mais cela permet un contrôle de l'intégrité de la base principale plus rigoureux.
Les ordinateurs actuels travaillant sur des bases Access volumineuses dans des temps satisfaisants.

Merci en retour d'indiquer le nombre d'enregistrements que tu auras dans ta base au maximum.
(100 000, 500 000, + 1 Million, + 10 Millions, + 100 Millions)


Bon courage,
FRED.

[polo974]

Autant bosser directement sur la base, car des copies, ça fini toujours par poser des problème de synchronisme...

Ensuite, il y a les begin.... commit pour emballer une transaction (attention comme toujours à ne pas monopoliser trop longtemps la ressource commune...).

[Bluedeep]

Bonjour a tous,

Voila ma problématique, je dois développer une application informatique, et une base de donnée commune, ou chaque membre de chaque service puissent accéder à cette base et la mettre à jour.

Je developpe l'application sous c#, et je me demandais comment j'allais mettre en place cette application, sachant que je dois utiliser Ms Access comme base de donnée.
Je pense que cela intègrera des notions de réseaux ?

Pourquoi faire ce choix de Access ? Les contraintes qu'il impose en accès concurrent sont absurdes du fait, entre autre, de l'absence de processus serveur de base de données ayant connaissance des utilisateurs connectés.

On peut toujours les gérer mais c'est du bricolage absolu (cf. le message de frederric46000).

Ce choix n'a aucun sens actuellement (il en avait il y a 20 ans par exemple) dans la mesure où on dispose de SGBD gratuits pour des applications légères avec toutes les fonctionnalités des grands (rien que chez Microsoft, on a Sql Server Express, qui est parfait si les bases ne dépassent pas 50 Go, ce qui laisse de la marge).

[A voir en vidéo sur Futura]

[Bluedeep]

Autant bosser directement sur la base, car des copies, ça fini toujours par poser des problème de synchronisme...

Ensuite, il y a les begin.... commit pour emballer une transaction (attention comme toujours à ne pas monopoliser trop longtemps la ressource commune...).

T'as vu la tronche de la gestion des transactions sous MS-Access ????

[JPL]

Pourquoi faire ce choix de Access ?

Cela lui est peut-être imposé :

sachant que je dois utiliser Ms Access comme base de donnée.

Ce n'est pas la première fois que je vois critiquer l'usage d'Access dans des réponses sans demander d'abord si celui qui doit faire le travail est libre de son choix.

[invite0ee73e60]

Bonjour,
je vous remercie pour votre réponse.
@frederic46000 : mon application consiste à développer une application de gestion commerciale,mais j'ai pas pris en considération le nombre d'enregistrements que j'aurai dans ma base.
Est ce que vous me conseil de changer ma base de donnée?
on me conseille d'utiliser le web service, est ce je peux avec ma base access ou je dois changer la base?
si oui, comment je dois utiliser ce web service ?

[bisou10]

Salut,

en 2014 on ne developpe plus un outil de gestion, on l'intègre (dolibarr, openerp, apache ofbiz...)

Access est un choix souvent hasardeux: la base de donnée montre trés mal en charge (et gère plutot mal la concurrence, cf le post de Frederic46000 qui expose plus une bidouille qu'un algotrithme sain), la gestion des transactions est hasardeuse, et enfin, il vaut mieux que le parc soit homogène (version d'office identique). Attention, c'est aussi parce qu'access est une base de donnée fichier, ce qui inclut certaines limitations, et certains avantages (le principal etant que formulaires, base de donnée, code soient integrés dans un unique fichier).

Alors qu'il existe des bases de données dignes de ce nom, et surtout pérennes (postgreSQL, ou en base de donnée fichier, sqlite).
Bref, même si des milliers de bricolages existent sous Access, je ne pense pas que ca soit un bon choix de nos jours.

@JPL: imposé ou pas, un peu de pré-étude est aussi une part du métier, et je trouve qu'en parler est une bonne chose (même si 99% des cas doivent ne pas faire changer d'avis OP mais plutot parce qu'il va voir cela comme 'trop compliqué', pas forcément parce que la personne en face est bloquée sur un choix).
Je vois trop de solutions techniques bancales qui ont une dette technique monstrueuse.... D'autant plus mon point 1: en 2014, je trouve, hors cas exceptionnels, que ré-inventer pour la 10000eme fois la roue est un non-sens (c'est comme coder un site from scratch, alors que les CMS prennent en charge une énorme partie du boulot, ou faire son e-boutique au lieu d'utiliser Magentoo/Prestashop), et ne donne que des résultats moisis

[invite3222ab58]

bonjour safaben,
Effectivement une gestion commerciale ne se développe pas au jour d'aujourd'hui il existe sur le marché
des tas de solutios de la solution gratuite ERP comme DOLIBARR à des solutions 'chères' comme
les lignes 100 300 de SAGE.

Ce que tu dois faire c'est connaître de la part du décideur (payeur final) :

1°) L'existant s'il y en a un
2°) Le secteur d'activité (profession) qui utilisera la gestion commerciale.
3°) Le nombre d'articles et de clients à gérer (pour calcul du débit sur l e réseau informatique)
4°) Le nombre de postes en simultanés qui se connecte à la base ( Le flux sur le réseau)

et enfin l'essentiel : Le budget en K€. (de 0 € à 10 000 €).
Avant que tout le monde crie au scandale 10 000 € peut être le minimum d'une application
pour mini système (AS400) ou gros système (IBM 4381)

Seul un spécifique avec de gros volumes et des demandes temps réel d'interrogation et
de mise à jour (temps<3s) nécessite mini ou gros système.

@bisou10 :
Il ne faut pas être sectaire, seulement attendre les réponses aux bonnes questions avant de choisir.

J'ai d'abord répondu à la question sur Access en attendant la réponse de 9h22


Fred.

[Bluedeep]

Avant que tout le monde crie au scandale 10 000 € peut être le minimum d'une application
pour mini système (AS400) ou gros système (IBM 4381)
.

Vraiment le strict minimum (ca fait de facto 6j RTU + recette + pilotage, autant dire rien) mais on ne voit pas bien ce que le système cible vient faire dans le budget.

[invite3222ab58]

bonsoir bluedeep,

ce message pour répondre à ton interrogation.

Si le décideur(payeur) n'as pas le budget de ces ambitions (que je ne connaît pas encore)
il faudra lui expliquer qu'il ne faut pas rêver.

D'où les autres questions pour cibler les ambitions du projet de l'application gestion commerciale.
Nonobstant les possibilités du logiciel les contraintes de flux et débit peuvent limiter le choix
du type de base relationnelle.

Rappel :
* Le flux nombre de connections simultanées en Mise A Jour sur la base et temps de réponse :
- le temps de réponse demandé sur Mini ou Gros système est que quelque soit la taille de la base et
le nombre de personnes connectés cela doit être du temps réel : < 3 secondes.
- le temps de réponse sur pc mono poste ou en réseau peut largement dépassé les 3 secondes si la base
commence à prendre du volume.

* Le débit est la grosseur du tuyau c.a.d. plus la base est énorme et le nombre de personnes
connectés augmente => physiquement l'outil informatique doit grossir.

Pour ma part mon ancienneté dans l'analyse et/ou la programmation est depuis 1985
sur IBM 4381, AS400 (Cobol pour les nostalgiques, Mantis-TIS pour ceux qui connaissent, Assembleurs 4381) et sur pc en assembleur,C, Pascal, Fortran (c'est pas tout jeune) , basic, multilog,visual basic, WINDEV,
et j'en passe....

je suis passé de la programmation de spécifique de gestion commerciale (du sur mesure) sur 4381 et pc
même des gestions sur Multiplan (l'ancêtre d'Excel) et bien sur Excel ou ACCESS avec VBA en fonction des
projets aux applications verticales de Sligos et autes : maintenant de Sage.

Rappel Sage a racheter la société API et à repris leur gestion commerciale pour des petites pme et/ou artisans
développé avec une base ACCESS.

Pour ma part en attendant les prochains disque durs à haute performance (quantique utilisant le Qubit)
pour équiper les salles blanches des Clouds je me réserve encore sur les ERP.
(même si je l'ai fait acheté à un client chez Sage et que je pense que c'est l'avenir)

La multitude de choix restant implique donc la réponse aux questions que j'ai posé précédemment
à safaben.

Fred.

[bisou10]

Salut Fred,

Sectaire ?! Bien sûr, je ne critique pas ton astuce technique, j'ai juste fait un état des lieux du dev sous access, en essayant d'être généraliste et objectif. Mais mon post avait vraiment pour ambition d'ouvrir la réponse à JPL, sur la nécessite d'un cahier des charges, et des documents d'étude préliminaire.

Pour le posteur initial, je subodore que le contexte soit:
- il est stagiaire ou developpeur juniorair
- il a été employé dans une TPE ou une PME sans aucune culture informatique
- on lui a dit qu'il faudrait une appli de gestion qui fait aussi le café
- on lui a dit qu'Access c'était bien parce que X ou Y avait déjà lancé par erreur Access.exe et que le patron a entendu ce mot
- et donc qu'il faut qu'il fasse ca pour dans 1 semaine

Et donc voila notre bon Safaben, avec 3 mois d'expérience scolaire en C, lâché sous Access, pour une appli monstrueuse. Appli qui de toute façon ne verra jamais le jour en prod, parce qu'a l'issue du stage, le besoin sera totalement différent, rien de sera terminé, et de toutes façons ca sera bancal.

J'exagère, enfin, j'aimerais.... malheureusement, il y a beaucoup de cas comme ça.

Après, toutes les reflexions que tu soulèves (analyse des besoins, des moyens, décisions, sont bien sûr tout à fait légitimes).
Quand à 10k€, le moindre chef de projet replace instantanément ce budget dans son contexte

[invite3222ab58]

bonjour à tous

OK bisou10 pour ton dernier message : il faut attendre la réponse de safaben sur tes interrogations.

Ma réponse quand à l'utilisation d'ACCESS ne préjuge en rien du niveau de connaissance de la personne.

Je pense lui avoir données toutes les infos pour répondre à sa demande avec ACCESS tout en le redirigeant
vers des solutions plus 'modernes'.

Reste évidemment le budget du décideur qui orientera le choix de la stratégie avec cahier des charges ou
de l'utilisation d'un standard gestion commerciale et les utilisateurs feront 'avec'.

Fred.