Passer en client /serveur

4D v16

En complément des manipulations expliquées dans la vidéo, il faut noter que :

L'utilisation en client/serveur est très facile.

Les triggers sont exécutés sur le serveur.

Il ne faut pas utiliser de commandes d'échange avec l'utilisateur (ALERTE, DIALOGUE, Confirmer, Demander, ...) car personne ne sera devant le serveur pour les valider d'autant plus si le serveur tourne en service.

On peut exécuter des process sur le serveur (procédures stockées)

Video script

Bonjour,

dans cette vidéo nous allons apprendre et utiliser une base en client/serveur.

Jusqu'à maintenant, nous avons programmé en mono-poste, voyons l'utilisation en client/serveur de ce que nous avons fait :

je quitte 4è Dimension
je reprends la même base et la démarre sur le serveur.
le serveur démarre et nous indique qu'actuellement il y a 0 utilisateur
je démarre le client.
je demande à me connecter à un 4D Serveur
je choisis dans la liste des bases de données publiées celle qui m'intéresse.

et j'obtiens bien en mode client :

la même interface et le même contenu qu'en monoposte
je peux afficher les technicens, les interventions
et faire toutes les manipulations que nous avons déjà réalisées.

Puisque 4D est multiplateformes, le même serveur peut distribuer les informations aux clients Mac et aux clients Windows :

je passe sur Windows
je démarre 4D.exe
je me connecte au même serveur
j'obtiens également la même interface et les mêmes données.

Je peux modifier une intervention sur Windows, je retrouve immédiatement les modifications sur Mac de la même manière. Bien sûr l'inverse est vrai aussi.

Le serveur gère également de manière automatique les conflits d'accès aux enregistrements. Si j'ouvre en modification une fiche technicien et que je veux ouvrir la même sur l'autre poste client :

un message m'indique que la fiche est déjà en cours d'utilisation
et précise l'utilisateur, le poste de travail et le process concerné.

Voilà pour les données en client/serveur.

Il se trouve que notre développement, les tables, les formulaires les méthodes, ... sont également des données : ce sont les données du programmeur.

Et bien le serveur gère également les répercussions des modifications sur les différents postes, ainsi que le verrouillage des enregistrements "programmeur".

Ici le formulaire Entrée [intervention] est ouvert, si je passe sur windows et que je termine, il m'ouvre de la même manière le formulaire entrée [intervention] mais précise qu'un autre utilisateur l'utilise actuellement.
Si je fais OK, un verrou m'indique que le formulaire est en cours d'utilisation sur un autre poste.

Si je ferme le formulaire sur l'autre poste, que je reviens sur Windows, je peux en cliquant sur le cadenas, déverrouiller le formulaire et donc le modifier.

En ce qui concerne la structure le principe est le même

je vais tout refermer sur mac
réouvrir la structure
et nous avons donc 2 structures identiques.
Si je prends la table [techniciens] et que je mets le lien droit, on voit automatiquement en arrière plan dans Windows la modification effectuée.

Ce principe permet à une équipe de développer simultanément puisqu'on a accès :

à la structure
aux méthodes
aux formulaires
et à l'ensemble des outils à disposition des développeurs.

Bien évidemment les modifications apportées en client/serveur seront réutilisables en mono-poste puisqu'il s'agit toujours de la même structure et des mêmes données.

Cette approche rapide vous permet de constater qu'il est très facile de développer soit sur un environnement mono-poste, soit directement à plusieurs en client-serveur.