Mettre une application de Bdd Delphi VCL en réseau local

Bjr
J’ai développé 1 application de base de données Delphi 10 Seattle VCL

Voici la description :
J’ai utilisé le mode d’accès aux bases de données, FireDAC
Cette application contient 4 Bases de données en Ms Access

Citation:

---

1. Bdd_Fret.mdb
2. Bdd_Douane.mdb
3. Bdd_Camion.mdb
4. Bdd_Airport.mdb

---

Dans Delphi, J’ai créé 4 DATA MODULE correspondant à mes 4 bdd
(composants utilisés : TFDConnection, TFDTable et TFDQuery), comme suit :

Citation:

---

1. dm_Fret
2. dm_Douane
3. dm_Camion
4. dm_Airport

---

J’utilise les TForm pour la saisie ou l’édition des enregistrements/données
J’utilise le composant TDBNavigator (Insert, Delete, Post, Cancel, Prior, Next) sur toutes mes Fiches (TForm)
Et j’utilise les TDBGrid pour afficher et visualiser mes enregistrements/données.

Ma question :
Comment puis-je mettre en réseau (plusieurs PC) cette application ?
Est-ce qu’une modification effectuée par un utilisateur (PC), peut être visible par un autre utilisateur (PC) ?

Merci d’avance pour votre aide.

ACCESS pour une base de données partagées par plusieurs utilisateurs est un mauvais choix
ACCESS c'est bien pour bricoler des formulaires intégrés pas pour une utilisation avec une application Client\Server
Quel SGBD choisir ?

Citation:

---

Envoyé par tleboukaka

Comment puis-je mettre en réseau (plusieurs PC) cette application ?

---

Plusieurs approches
- Un exe par poste installé localement
- Un exe commun installé sur un serveur mais lancé localement
- Un exe commun installe sur un serveur mais via une session TSE ou via CITRIX

Quoi qu'il arrive,
les fichiers de base de données doivent être sur un serveur accessible par le poste où est exécuté l'exe (que ce soit le poste client ou un serveur TSE)

Citation:

---

Envoyé par tleboukaka

Est-ce qu’une modification effectuée par un utilisateur (PC), peut être visible par un autre utilisateur (PC) ?

---

Pour qu'une donnée soit visible lors d'accès concurrentiel, il faut que les postes actualisent leur donnée, un Refresh ou un Close/Open

Je ne connais pas assez FireDAC et ACCESS pour évoquer la gestion du Flush
Avec le BDE + Paradox, pour les TTables, il fallait soit faire un Close soit un FlushBuffer pour valider pleinement les modifications
Avec IBX, ADO, DBX, ODAC, MyDAC, UniDAC et un vrai SGBD digne de ce nom comme Interbase, MySQL, Sybase, SQL Server, ORACLE ... tout est géré via des transactions implicites et explicites, certains proposent même des évènements pour l'application soit notifié des mises à jour concurrentiel

Bonjour,

je pense, comme ShaiLeTroll, que Access n'est pas du tout le bon choix pour des applications réseaux sauf en cas de programmes multi-tiers (une approche supplémentaire aux propositions de ShaiLeTroll, à savoir un programme sur le serveur s'occupant de la partie données et un programme sur chaque poste envoyant et récupérant les informations)

En tout cas votre description de l'existant me fait un peu peur

Citation:

---

Cette application contient 4 Bases de données en Ms Access
1. Bdd_Fret.mdb
2. Bdd_Douane.mdb
3. Bdd_Camion.mdb
4. Bdd_Airport.mdb

---

une seule base devrait suffire mais avec 4 tables (ou plus) à l'intérieur

Citation:

---

J’utilise le composant TDBNavigator (Insert, Delete, Post, Cancel, Prior, Next) sur toutes mes Fiches (TForm)
Et j’utilise les TDBGrid pour afficher et visualiser mes enregistrements/données.

---

Si les DBGrid sont très bien pour l'affichage, en environnement réseau elles sont pénalisantes car il faut rafraichir l'ensemble de données régulièrement

Le choix d'un SGBDR digne de ce nom, ayant une possibilité de signaler des évènements à l'application est ce que je recommande
http://docwiki.appmethod.com/appmeth...erts_(FireDAC)

Bonjour

Merci à SergioMaster et à ShaiLeTroll pour vos réactions...
J’ai pris bonne note de vos remarques sur le choix du SGBD…
Dans ma prochaine version, je pourrai choisir MySQL-Delphi ;
Pour l’instant, à cause du délai/timing, mon client doit utiliser cette application en mode Access-Delphi.
Notez que j’aurai à gérer maxi 9 postes (PC).

En effet j’ai l’habitude de créer mes EXE avec Inno setUp pour mes applications mono poste ;
Etant donné que je n’ai jamais effectué des installations en réseau de mes applications ;

Citation:

---

Plusieurs approches
- Un exe par poste installé localement
- Un exe commun installé sur un serveur mais lancé localement
- Un exe commun installe sur un serveur mais via une session TSE ou via CITRIX

---

Je souhaiterai que parmi les approches proposés, que vous puissiez choisir la plus simple pour moi, et si possible,
détailler la démarche pour créer ce genre de EXE.
apparemment la 2e me semblerai aisée -

Merci d'avance

Il n'y a pas grand chose à détailler, je ne vois pas ce qui te bloques, il n'y a rien de plus basique

Dans ton Setup tu proposes un mode installation Serveur ou Client

Comme tu sembles totalement perdu, surement par peur de l'inconnu, je te détaille les deux premiers cas

* Cas 1
- Un exe par poste installé localement (à mon avis le plus simple pour toi, cela ne changera quasiment rien à tes habitudes. Inconvénient : le déploiement d'une version nécessite de passer sur les 9 postes)
Sur le serveur, cela installe uniquement les fichiers DB
Sur le client, cela installe L'EXE, les DLL et toutes les autres dépendances, et un fichier INI/BDR qui contient le chemin vers la base \\server\dossier\logiciel\data.
Le Fichier INI/BDR est créé par InnoSetup qui inclu un prompt indiquant le chemin de la base (cela requiert que l'installation soit fait par un utilisateur averti ayant des notions correctes en partage réseau Windows)

Code:

---

1 2	[DB] Path=\\server\dossier\logiciel\data

---

Au lieu d'un fichier Ini, tu peux aussi utiliser la base de registre (BDR), si tu préfères et moins de problèmes avec l'UAC

Sur le bureau, un raccourci qui pointe sur "c:\Progam files(x86)\societe\logiciel\bin\programme.exe" "c:\Progam files(x86)\societe\logiciel\conf\programme.ini".




* Cas 2
- Un exe commun installé sur un serveur mais lancé localement (plus délicat pour la gestion des chemins, surtout si tu utilises beaucoup de chemin relatif au chemin courant. Avantage : le déploiement d'une version se fait uniquement sur le serveur )
Sur le serveur, cela installe les fichiers DB, L'EXE, les DLL et toutes les autres dépendances
Sur le client, cela installe un raccourci vers le serveur (tu inclus un prompt pour choisir le chemin réseau sous la forme d'un dossier partagé sur le serveur), quelques fichiers de configuration locale ( INI/BDR pour stocker le chemin de la base si celui n'est pas relatif au chemin de l'exe)

Sur le bureau, un raccourci contiendra une chaine comme \\server\dossier\logiciel\bin\programme.exe "c:\Progam files(x86)\societe\logiciel\conf\programme.ini".
Penser à mettre comme chemin de travail dans la section 'Démarrer dans' du raccourci c:\Progam files(x86)\societe\logiciel\tmp\ pour que le programme soit par défaut en local pour d'éventuel fichier créé sans le chemin complet.

merci déjà pour cette réponse
que je vais déjà me mettre à exécuter

je reviens vers vs début de semaine pour la suite favorable, surement

AMHA MySQL n'est certainement pas le meilleur choix, si vous envisagez SGBDR libre et gratuit voir plutôt du coté de Firebird.
D'ailleurs contrairement à ce qui est cru MySQL n'est ni un vrai libre ni un vrai gratuit

Citation:

---

Envoyé par SergioMaster

D'ailleurs contrairement à ce qui est cru MySQL n'est ni un vrai libre ni un vrai gratuit

---

Effectivement, pour un logiciel non libre, il faut en réalité payer une licence par serveur
Du moins surtout pour logiciel vendu à des tiers, pour une application interne utilisé strictement en interne, c'est théoriquement pas payant : il y a même un article dans la :faq:

A l'époque de MySQL 4, un de mes anciens employeurs avait négocié la licence à 45€ par serveur car même un Embedded est considéré comme un Server et lorsque tu en distribue dans le monde entier pour 5000 poste utilisateur, ça commence à couter cher !