Discussion :

[dj_techno]

salut
j'ai une application de gestion des ressources humaine, créer avec delphi manipullant une table access, cette application est monoposte.
SVP comment je peux rendre mon application multiposte c'est à dire qui fonctionne sous reseau sur la même table? quels modifications vous suggérez, sans faire aucune modification sur l'interface de mon application?
Je sais que peut être qu'il faut changer la table (malgré qu'elle est trés grande et aussi elle contient d'enregistrement, plus que 3000 enregistrements) mais je ne sais pas quels décision je peux prendre et comment procéder.
merci

[Franck SORIANO]

Ton appli utilise une seule table ?

Combien d'utilisateurs est-ce que tu veux que ton appli accepte ?
Access est déjà capable de travailler en réseau. Il suffit d'indiquer un chemin UNC pour se connecter au fichier mdb à travers le réseau.

Donc tu peux avoir du multi-poste très facilement.

Par contre, la monté en charge ne va être terrible (nombre d'utilisateurs très limités).

Ensuite, selon la façon dont ton appli est écrite tu va peux-être avoir des problèmes de concurrence d'accès (c'est même presque sûr si tu as une seule table...).
C'est à dire des problèmes du genre, ton appli charge des données en mémoire au début.
Un autre utilisateur fait la même chose de son côté. Il en profite pour les modifier.
Puis le premier utilisateur fait des modifications et enregistre les nouvelles valeurs à partir de ce qu'il avait lu et conservé en mémoire.
Au final, les données du deuxième sont perdues...

[dj_techno]

bonjour,
mon application se connecte à une base grh.mdb qui contient plus que 10 tables, concernant les utilisateur j'ai au minimum 5 utilisateurs..
Pouvez vous mieu expliquer comment je peux procéder à immigrer mon application pour le rendre fonctionnelle sous reseau, aussi je n'ai pas bien compris se que vous venez de dire ici

Ensuite, selon la façon dont ton appli est écrite tu va peux-être avoir des problèmes de concurrence d'accès (c'est même presque sûr si tu as une seule table...).
C'est à dire des problèmes du genre, ton appli charge des données en mémoire au début.
Un autre utilisateur fait la même chose de son côté. Il en profite pour les modifier.
Puis le premier utilisateur fait des modifications et enregistre les nouvelles valeurs à partir de ce qu'il avait lu et conservé en mémoire.
Au final, les données du deuxième sont perdues...

merci

[Franck SORIANO]

j'ai au minimum 5 utilisateurs..

Ca commence mal. Je ne peux pas te donner de limite précise, mais pour de l'accès en réseau j'aurais plutôt tendance à dire que 5 utilisateurs est un maximum.

Pouvez vous mieu expliquer comment je peux procéder à immigrer mon application pour le rendre fonctionnelle sous reseau

Je te sugèrerais de commencer par copier le fichier grh.mdb sur un poste serveur.
Puis depuis le poste client, au lieu d'ouvrir le fichier "c:\Program files\xxxx\grh.mdb", tu ouvre le fichier en utilisant un chemin UNC :
"\\NOM_DU_SERVEUR\PARTAGE_RESEAU\grh.mdb".
Ca devrait suffir pour commencer.

Ensuite tu n'as plus qu'à commencer à tester ton appli avec plusieurs utilisateurs. Tu verras vite si tu rencontres des problèmes de concurrence d'accès lorsque deux utilisateurs travaille sur le même salarié, et qu'ils perdent des données.

Ca te permettra de mieux appréhender les problèmes, puis de chercher les méthodes pour les éviter et les résoudre.

[Pascal Jankowski]

Ensuite, selon la façon dont ton appli est écrite tu va peux-être avoir des problèmes de concurrence d'accès (c'est même presque sûr si tu as une seule table...).
C'est à dire des problèmes du genre, ton appli charge des données en mémoire au début.
Un autre utilisateur fait la même chose de son côté. Il en profite pour les modifier.
Puis le premier utilisateur fait des modifications et enregistre les nouvelles valeurs à partir de ce qu'il avait lu et conservé en mémoire.
Au final, les données du deuxième sont perdues...
merci

Ce que Frank a voulu te dire c'est que si deux personnes sont sur le même enregistrement, il faut que dès qu'une des deux personnes effectue une modification que la seconde ne puisse plus enregistrer les siennes.
Sinon, les modifications de l'une des deux personnes seront perdues.

Ces sont les problème engendrés par les accès concurrents. Tu seras imanquablement confronté au problème puisque tu désires rendre ta base de données accessible à plusieurs personnes simultanément.

Par ailleurs, je trouve dommage que tu ne penses seulement maintenant après avoir développé ton application en monoposte vouloir la rendre compatible multi-poste.
En général, c'est quelque chose qu'il faut prévoir au départ.

Si je peux te fournir une piste, pense à te renseigner également sur les transactions.

[Graffito]

Bonjour,

Comme dit précédemment, rendre l'appli multi-user à posteriori n'est pas idéal.

Une solution qui, dans ce cas, ne requière pas de repenser l'application consiste à gérer les accès concurrents via une table supplémentaire qui enregistre les vérouillages.
Cette nouvelle table contient alors les champs suivants :
Champ1: Nom de la table à laquelle appartient l'enregistrement verouillé,
Champ2: Clé primaire de l'entregistrement vérouillé,
Champ3: Date/heure du vérouillage (pour limiter le temps de vérouillage).

On peut ainsi vérouiller un ou des enregistrements d'une table de l'application avant modification (ajout d'un enr. dans la table verrou),
les dévérouiller après modif (suppression d'enr.) et tester si un enregistrement est modifié(lecture).

Attention, pour garantir le fonctionnement du test/vérouillage, la clé primaire de la table Verrou sera constituée de Champ1 + champ2 et s'assurer que le champ3 (date/heure) n'a pas changé entre lecture et écriture du verrou.

[dj_techno]

bonjour,

Si je peux te fournir une piste, pense à te renseigner également sur les transactions.

c'est comme quoi les transactions?

Bonjour,

Comme dit précédemment, rendre l'appli multi-user à posteriori n'est pas idéal.

Une solution qui, dans ce cas, ne requière pas de repenser l'application consiste à gérer les accès concurrents via une table supplémentaire qui enregistre les vérouillages.
Cette nouvelle table contient alors les champs suivants :
Champ1: Nom de la table à laquelle appartient l'enregistrement verouillé,
Champ2: Clé primaire de l'entregistrement vérouillé,
Champ3: Date/heure du vérouillage (pour limiter le temps de vérouillage).

On peut ainsi vérouiller un ou des enregistrements d'une table de l'application avant modification (ajout d'un enr. dans la table verrou),
les dévérouiller après modif (suppression d'enr.) et tester si un enregistrement est modifié(lecture).

Attention, pour garantir le fonctionnement du test/vérouillage, la clé primaire de la table Verrou sera constituée de Champ1 + champ2 et s'assurer que le champ3 (date/heure) n'a pas changé entre lecture et écriture du verrou.

est ce que cette solution est bien pratique? si oui comment faire les verrou et comment tester si une table ou un enregistrement est bien occupé(e) ou en mode edition?
J'ai vu dans le forum que les tables SQL sont bien pratique, est ce que je peux les utiliser (biensûre tout reste le même surtout la codification car j'ai beaucoup de codes et instructions qui manipule la grh.mdb) et changer que les tables, si oui comment le faire car je ne sais rien en SQL.
merci

[Graffito]

est ce que cette solution est bien pratique?

Ce n'est pas la solution que l'on adopte à la conception d'une apppli multi-utilisateur.
Mais, elle a l'avantage de demander un minimum de modification sur une appli mono. Il suffit avant d'entrer en mise à jour d'appeler la fonction de vérouillage et en sortie d'appeler la procédure de dévérouillage.

La fonction de vérouillage commune à toute l'appli que tu devras écrire aura comme paramètres d'entrée :
- Nom_de_la_table_mise_à_jour (string),
- clé_primaire (string)
et retournera "Ok" ou "Echec: enregistrement vérouillé par un autre utilisateur.

La fonction de dévérouillage aura les paramètres d'entrée et retournera "Ok:" ou "Erreur: Impossible de supprimer le verrou".

si oui comment faire les verrou et comment tester si une table ou un enregistrement est bien occupé(e) ou en mode edition?

Chaque enregistrement vérouillé correspond à un un enregistrement de la table verrou. On créée un enbregistrement quand on pose un verrou, on le supprime pour l'enlever. Pour tester , si un enr. d'une table est vérouillé on vérifie l'existence dans la table verrou de <nom_de_table>, <Clé_primaire> et on contrôle éventuellement le temps Maximum de vérouillage.

[dj_techno]

je ne sais pas comment appliquer un verrou sur un enregistrement en mode modification ou utiliser par un autre utilisateur?

[Graffito]

Dans cette solution, c'est à toi de programmer les fonctions de vérrouillage/déverrouillage en utilisant une table "applicative" de verrous que tu crées pour ce besoin. Tu n'utilise pas les mécanismes standard de blocage (de type optimistic ou pessimistic), mais tes propres fonctions.

Appliquer un verrou, c'est écrire dans la table "applicative" des verrous la clé primaire (+nom de table+date/heure) de l'enregistrement à verrouiller.

[dj_techno]

bonjour
je vais essayer cette solution
merci

[Pascal Jankowski]

c'est comme quoi les transactions?

C'est un mécanisme employé en interne par un SGBD pour maintenir la cohérence de ses informations.
Par exemple du désires effectuer une opération sur les données, si le SGBD ne rencontre aucun problème lors de l'exécution de ces informations, alors les données seront effectivement mise à jour. Dans le cas contraire, le SGBD peut annuler la série d'opérations afin de préserver les données de toute incohérence.

Pour cela trois étapes:
1. beginTrans ou startTransaction ... (selon les composants tiers utilisés)
Permet de signifier au SGBD qu'une série d'opérations vont être exécutées et qu'il doit gérer l'historique des opérations dans son journal des transactions afin d'être capable d'annuler chaque opération passée dans le cas d'un échec éventuel.

2. Commit, CommitTrans... (selon les composants tiers utilisés)
Permet d'indiquer au SGBD que si aucune anomalie n'est rencontrée alors il doit valider la série d'opérations. Les données sont modifiées puis validées dans la base de données après cette instruction.

3. Rollback, RollbackTrans... (selon les composants tiers utilisés)
Cette instruction indique au SGBD d'annuler toute la série d'opérations dès qu'une anomalie est rencontrée.

Cette série d'instructions doit être utilisée dans un bloc d'exception afin de gérer les erreurs, de la façon suivante :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
try
  beginTrans;        //début de transaction
  op1;op2;...;opn;  //une série d'opérations;
  Commit;             //fin normale de la transaction
except
  Rollback;           //fin anormale de la transaction
end;

Les transactions permettent entr'autre la gestion des accès concurrents.

[dj_techno]

salut
je ne sais pas comment procéder et comment mettre la boucle try?
merci

[dj_techno]

salut
bon, maintenant si je mets la base de données (*.mdb) sur le serveur, dans une repertoire partager, quelle solution dois-je faire pour que l'application s'adapte sur n'importe quel reseau, c'est à dire pas tous les serveurs sont només "serveur", il y'a "server","partage","x",....
bon se que je veux dire, c'est que lors de l'installation de l'application, est ce que il y'a une solution de lui donner le chemin de la base (*.mdb):
"\\serveur\grh\gestion.mdb" ou n'importe quel chemin (exemple un poste client ou il y'a un repertoire partagé), qui sera stocker une fois pour toute dans la source de tous les ADOConnection, et il ne sera plus demander une autre fois, il sera le chemin par defaut et à chaque lancement ou ouverture de l'application il ne demande plus le chemin car il est déja sauvegarder.
merci

[BuzzLeclaire]

Le mieux :
1/ Tu mets en pace un DataModule
2/ dans l'evenement beforeConnect de ton ADOConnection tu recherche dans le registre du poste le lien de la base en unc puis tu gere ta connection.

Ensuite à chaque fois que tu Open ou autre une table il fera appel au 1/ et 2/

[dj_techno]

Le mieux :

2/ dans l'evenement beforeConnect de ton ADOConnection tu recherche dans le registre du poste le lien de la base en unc puis tu gere ta connection.

SVP, comment je peux le faire

[BuzzLeclaire]

Procédure qui te permet de lire ou d'écrire dans le registre windows, ne pas oublie de mettre dans tes uses Registry;

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
function LireDansLeRegistre(NomValeur: String) : String;
var
  Registre: TRegistry;
  base: String;
Begin
  Registre := TRegistry.Create; //Création de l'objet registre
  Try
    Try
      Registre.RootKey := HKEY_LOCAL_MACHINE; //Sélection de la clé principale
      Registre.OpenKey('SOFTWARE', False);
 
      if Registre.KeyExists('MaBase') then Begin
       Registre.OpenKey('\SOFTWARE\MaBase\', False);
       Base := (Registre.ReadString(NomValeur));
      end
      else Base := '';
    Except
      MessageDlg(Application.Title + ' a généré une erreur pendant l''éxécution : '
      +#10+#13 + 'Base de registre innaccessible.', mtError, [mbOk], 0);
    end;
  Finally
    Registre.Free; //Libération de la base de registre. A faire absolument !
  end;
  Result := Base;
end;
 
function EcrireDansLeRegistre(NomValeur: String; Const Valeur: String): Boolean;
var
  Registre: TRegistry ;
Begin
  Result := True;
  Try
    Try
      Registre := TRegistry.Create;
      Registre.RootKey := HKEY_LOCAL_MACHINE;
      Registre.OpenKey('\SOFTWARE\MaBase\', True);
      Registre.WriteString(NomValeur, Valeur);
    Except
      MessageDlg(Application.Title + ' a généré une erreur pendant l''éxécution : '
      +#10+#13 + 'Problème d''écriture dans la base de registre.', mtError, [mbOk], 0);
      Result := False;
    End;
  Finally
    Registre.Free; //Libération de la base de registre. A faire absolument !
  end;
end;

Et cela l'evenement Beforeconnect

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
procedure TModuleDeDonnee.ADOCnxBASEBeforeConnect(Sender: TObject);
Var
  BaseInterne: String;
begin
// Exemple en mono
  BaseInterne := ExtractFilePath(Application.ExeName) + 'Base.mdb';
// Essai en réseau 
  BaseInterne := '\\sr\ESSAI\' + 'Base.mdb';
 
    ADOCnxPlanning.Provider := 'Microsoft.Jet.OLEDB.4.0';
    ADOCnxPlanning.LoginPrompt := False;
    ADOCnxPlanning.ConnectionString :='Data Source='
    + BaseInterne + ';Persist Security Info=False';
end;

Il te faut donc remplacer base interne par un liredansregistre ou ecriredansregistre si il n'y a rien

je pense qu'avec cela tu pourra t'en sortir.

[dj_techno]

salut
j'essais toujours de fonctionner mon application sous réseau, mon problème c'est que j'ai essayé de mettre ma base .mdb dans un répertoire partager sur un autre poste et j'ai essayé de se connecter avec adoconnection manuellement (microsoft jet 4.0 OLE DB Provider) pour tester mais lors de l'exécution j'ai des erreurs

[Error] RLINK32: Error opening file "C:\gestion des ressources humaines\data.dfm"

ensuite

Invalid enum value

alors SVP comment se connecter sans aucun probléme
merci

[Cl@udius]

Salut

[Error] RLINK32

Ceci n'est pas une erreur d'exécution mais de compilation. C'est le lieur de ressources qui te fait des misères.
Tu as un problème avec le fichier data.dfm (corrompu ?).

Bref ce message n'a pas de rapport direct avec tes composants ADO.

@+ Claudius

[dj_techno]

Salut


Ceci n'est pas une erreur d'exécution mais de compilation. C'est le lieur de ressources qui te fait des misères.
Tu as un problème avec le fichier data.dfm (corrompu ?).

Bref ce message n'a pas de rapport direct avec tes composants ADO.

@+ Claudius

le problème c'est que j'utilise la chaine de connexion vers le réseau il y'a se message, mais si je change la chaine de connexion au locale c'est à dire monoposte (C:\gestion des ressources humaines\ma base.mdb) sa fonctionne normale sans aucune erreur