Firedac - Application multi utilisateurs

Version imprimable

21/01/2020, 21h37
Clint77

Firedac - Application multi utilisateurs

Bonjour,

Je programme une appli multi utilisateurs avec le RAD XE7, chaque utilisateur devant y saisir ses heures ouvrées sur un serveur.

J’utilise donc FIREDAC qui se connecte à une BD Access.

Mon souci est que le premier connecté verrouille la base pour les utilisateurs connectés après.
Après avoir fait plusieurs recherches, je me demande ou trouver mes réponses :

• Un simple paramétrage du TFDCONNECTION suffit ? si oui lequel ?
• Faut-il sérialiser les accès à la base ?
• Autres ?

J’ai beau chercher mais je ne trouve pas comment aborder le probleme ! si quelqu’un peux m’aiguiller dans mes recherches cela m’aiderait beaucoup.

Merci d’avance.
22/01/2020, 09h37
SergioMaster

Bonjour,

Citation:

Envoyé par Clint77

J’utilise donc FIREDAC qui se connecte à une BD Access.

AMHA c'est là que le bât blesse,MS Acces n'est certainement pas le SGBD que je qualifierai de multi-utilisateurs !
22/01/2020, 10h02
ALWEBER

Si tu as la bonne version de Delphi tu peux faire un application Client/serveur (Datasnap...)
22/01/2020, 11h06
Clint77

Citation:

Envoyé par SergioMaster

Bonjour,

AMHA c'est là que le bât blesse,MS Acces n'est certainement pas le SGBD que je qualifierai de multi-utilisateurs !

Mince ! vu que je partais d'une base access existante : je pensais pouvoir utiliser ce fichier !
Quel SGBD me conseilles-tu ?
22/01/2020, 11h43
SergioMaster

Citation:

Envoyé par Clint77

Quel SGBD me conseilles-tu ?

voir https://www.developpez.net/forums/d2...r-sgbd-delphi/ quoique, on y cite Paradox :ptdr: et on ne peut pas écrire que ce soit un SGBD Multi utilisateurs :roll:

Je ne serais certainement pas objectif, pour moi le premier choix serait Firebird (tant qu'à faire la dernière version c.a.d 3.0.5)
ensuite viennent plus ou moins en ordre de préférence PostGresSQL, Interbase, MS SQL
Je n'opterais pour MySQL qu'en dernier recours
Mais cela dépendra encore du besoin (même futur) et des moyens (Firebird et PostGresSQL sont OpenSource).
Cela dépend aussi de la "déclinaison" du XE 7 (pro ou entreprise) il faut vérifier les possibilités d'accès donc, vérifier la matrice des fonctionnalités
22/01/2020, 11h49
Clint77

Citation:

Envoyé par SergioMaster

voir https://www.developpez.net/forums/d2...r-sgbd-delphi/ quoique, on y cite Paradox :ptdr: et on ne peut pas écrire que ce soit un SGBD Multi utilisateurs :roll:

Je ne serais certainement pas objectif, pour moi le premier choix serait Firebird (tant qu'à faire la dernière version c.a.d 3.0.5)
ensuite viennent plus ou moins en ordre de préférence PostGresSQL, Interbase, MS SQL
Je n'opterais pour MySQL qu'en dernier recours
Mais cela dépendra encore du besoin (même futur) et des moyens (Firebird et PostGresSQL sont OpenSource).
Cela dépend aussi de la "déclinaison" du XE 7 (pro ou entreprise) il faut vérifier les possibilités d'accès donc, vérifier la matrice des fonctionnalités

Merci beaucoup pour ton aide !

Citation:

Envoyé par SergioMaster

Je n'opterais pour MySQL qu'en dernier recours

Pour ma j'utilise maintenant MariaDB à la place de MySQL depuis qu'Oracle à repris les rennes de MYSQL AB

Pour utiliser une base access en multi-utilisateurs il faut passer par ADODB, les composants Delphi dbGO marchent parfaitement bien pour ceci
Je n'ai encore essayé de faire de l'ADODB avec Firedac et je ne sais pas si c'est possible... J'utilise Firedac principalement avec Firebird et MariaDB

Ta chaine de connexion ADODB sera comme ceci :
Code:

1 2 3 4 5 6 'Provider=Microsoft.ACE.OLEDB.12.0;Mode=Share Deny None;Extended Properties="";Locale Identifier=1033; Jet OLEDB:Engine Type=4;Jet OLEDB:Database Locking Mode=0;Jet OLEDB:Global Partial Bulk Ops=2;Jet OLEDB:Global Bulk Transactions=1; Jet OLEDB:New Database Password="";Jet OLEDB:Create System Database=False;Jet OLEDB:Encrypt Database=False; Jet OLEDB:Don't Copy Locale on Compact=False;Jet OLEDB:Compact Without Replica Repair=False; Jet OLEDB:SFP=False;Data Source=\\Serveur\Dossier\Fichier.mdb;User ID=<user>;Password=<password>"
User ID et Password sont optionnels cela dépend de ton fichier Access
Certains autres paramètres sont aussi optionnels, tu peux trouver des exemples ici : https://www.connectionstrings.com/access/

Après il faut que les permissions sur le répertoire partagé qui contient le fichier Access soient correctes pour que les différents utilisateurs puissent se partager le fichier (Contrôle total)
En effet lors de la première connexion cela va créer un fichier lock (.ldb) qui va servir à gérer les verrous partagés
Lors de la fermeture de la dernière connexion le fichier lock est supprimé

Pour finir, comme mes condisciples, je ne recommande pas Access mais il y a des fois on a pas le choix et il faut bien trouver une solution...

22/01/2020, 13h07
SergioMaster

Citation:

Envoyé par sergio_is_back

Après il faut que les permissions sur le répertoire partagé qui contient le fichier Access soient correctes pour que les différents utilisateurs puissent se partager le fichier (Contrôle total)

Rien que cette phrase me fait sursauter (:vomi: enfin pas autant que ça ;)) c'est la porte ouverte à des problèmes de sécurité

Après, je ne connaissais pas cette possibilité ADODB mais bon moi les surcouches ADO, ADO et MS ACCESS je ne le cache pas ça n'a jamais été mon truc :ptdr:
22/01/2020, 13h34
sergio_is_back

Citation:

Envoyé par SergioMaster

Rien que cette phrase me fait sursauter (:vomi: enfin pas autant que ça ;)) c'est la porte ouverte à des problèmes de sécurité

Je sais mais c'est comme ça... le fichier lock est créé avec les identifiants (user et groupe) du premier utilisateur qui se connecte... Donc on a pas le choix...
Pour pouvoir créer un fichier dans un répertoire partagé il faut avoir le contrôle total sur ce répertoire (lecture/écriture/création/suppression)...

Note bien que si le fichier access est dans un sous-répertoire du dossier partagé, l'accès en contrôle total portera uniquement le sous-dossier (pas le dossier parent) et tu peux aussi créer un groupe pour y placer uniquement les utilisateurs qui sont concernés. Dans ce cas seul ce groupe aura le contrôle total sur ce sous dossier...

NOTA : Le fichier Access en lui même (dans le répertoire) n'a besoin que d'être en lecture/écriture (pas de contrôle total sur le fichier lui-même)

[Edit]Le "contrôle total" n'implique pas forcément que "Tout le monde" ai l'accès en contrôle total, seuls les utilisateurs concernés doivent avoir cet accès... et encore seulement sur le sous-répertoire du fichier (pas l'ensemble de l'arboréscence d'un partage)... L'erreur que beaucoup font c'est placer le groupe "Tout le monde" avec contrôle total au niveau de la sécurité du dossier partagé (pour éviter de se faire chier) du coup là oui effectivement c'est la, porte ouverte à toutes les conneries possibles par la suite.... [/Edit]

Citation:

Envoyé par SergioMaster

Après, je ne connaissais pas cette possibilité ADODB mais bon moi les surcouches ADO, ADO et MS ACCESS je ne le cache pas ça n'a jamais été mon truc :ptdr:

Ben ouais, mais y'a des clients qui n'utilisent que ça... soit par choix, soit parce que c'est historique
Avec ADODB tu même ouvrir des classeurs Excel et les utiliser comme une base de données et faire du SQL sur le contenu des feuilles...
C'est assez puissant, même si dois te l'avouer je ne m'en sert pas tous les jours non plus, je préfère avoir une base de données traditionnelle en face

Citation:
Envoyé par sergio_is_back
Pour ma j'utilise maintenant MariaDB à la place de MySQL depuis qu'Oracle à repris les rennes de MYSQL AB

Pour utiliser une base access en multi-utilisateurs il faut passer par ADODB, les composants Delphi dbGO marchent parfaitement bien pour ceci
Je n'ai encore essayé de faire de l'ADODB avec Firedac et je ne sais pas si c'est possible... J'utilise Firedac principalement avec Firebird et MariaDB

Ta chaine de connexion ADODB sera comme ceci :
Code:

1 2 3 4 5 6 'Provider=Microsoft.ACE.OLEDB.12.0;Mode=Share Deny None;Extended Properties="";Locale Identifier=1033; Jet OLEDB:Engine Type=4;Jet OLEDB:Database Locking Mode=0;Jet OLEDB:Global Partial Bulk Ops=2;Jet OLEDB:Global Bulk Transactions=1; Jet OLEDB:New Database Password="";Jet OLEDB:Create System Database=False;Jet OLEDB:Encrypt Database=False; Jet OLEDB:Don't Copy Locale on Compact=False;Jet OLEDB:Compact Without Replica Repair=False; Jet OLEDB:SFP=False;Data Source=\\Serveur\Dossier\Fichier.mdb;User ID=<user>;Password=<password>"
User ID et Password sont optionnels cela dépend de ton fichier Access
Certains autres paramètres sont aussi optionnels, tu peux trouver des exemples ici : https://www.connectionstrings.com/access/

Après il faut que les permissions sur le répertoire partagé qui contient le fichier Access soient correctes pour que les différents utilisateurs puissent se partager le fichier (Contrôle total)
En effet lors de la première connexion cela va créer un fichier lock (.ldb) qui va servir à gérer les verrous partagés
Lors de la fermeture de la dernière connexion le fichier lock est supprimé

Pour finir, comme mes condisciples, je ne recommande pas Access mais il y a des fois on a pas le choix et il faut bien trouver une solution...
Elle me plait bien cette solution ! Surtout que je n'ai pas des masses de temps ! Merci beaucoup !

23/01/2020, 22h46
Clint77

Citation:

Envoyé par sergio_is_back

Je sais mais c'est comme ça... le fichier lock est créé avec les identifiants (user et groupe) du premier utilisateur qui se connecte... Donc on a pas le choix...
Pour pouvoir créer un fichier dans un répertoire partagé il faut avoir le contrôle total sur ce répertoire (lecture/écriture/création/suppression)...

Note bien que si le fichier access est dans un sous-répertoire du dossier partagé, l'accès en contrôle total portera uniquement le sous-dossier (pas le dossier parent) et tu peux aussi créer un groupe pour y placer uniquement les utilisateurs qui sont concernés. Dans ce cas seul ce groupe aura le contrôle total sur ce sous dossier...

NOTA : Le fichier Access en lui même (dans le répertoire) n'a besoin que d'être en lecture/écriture (pas de contrôle total sur le fichier lui-même)

[Edit]Le "contrôle total" n'implique pas forcément que "Tout le monde" ai l'accès en contrôle total, seuls les utilisateurs concernés doivent avoir cet accès... et encore seulement sur le sous-répertoire du fichier (pas l'ensemble de l'arboréscence d'un partage)... L'erreur que beaucoup font c'est placer le groupe "Tout le monde" avec contrôle total au niveau de la sécurité du dossier partagé (pour éviter de se faire chier) du coup là oui effectivement c'est la, porte ouverte à toutes les conneries possibles par la suite.... [/Edit]

Ben ouais, mais y'a des clients qui n'utilisent que ça... soit par choix, soit parce que c'est historique
Avec ADODB tu même ouvrir des classeurs Excel et les utiliser comme une base de données et faire du SQL sur le contenu des feuilles...
C'est assez puissant, même si dois te l'avouer je ne m'en sert pas tous les jours non plus, je préfère avoir une base de données traditionnelle en face

Je suis assez d'accord avec toi : car dans ce cas j'ai du reprendre un modèle existant et pour des raisons de coût on a pas le temps de réinventer la roue, du coup on récup tout ce que l'on peut et on va au plus court en négligeant la qualité (c'est redondant dans notre société : on sacrifie tout pour la tune) ! et en effet y'a beaucoup de gens qui n'utilisent que ça !!! Alors faut faire avec ! en tout cas j'adore ce forum : c'est une vraie bible pour moi ! et un grand merci à ceux qui m'ont apporté leur aide !! Trop Cool les man !!
24/01/2020, 11h30
ShaiLeTroll

Vous devriez jeter un coup d'oeil à ODBCAdvanced dans les couche de FireDAC et vérifier si vous pouvez jouer sur "Mode=Share Deny None" et "Database Locking Mode=0" qui lorsque l'on s'intéresse un peu à la chaine de connexion fournie par sergio_is_back serait les éléments qui joue sur le problème de verrouillage

Cette propriété ODBCAdvanced est accessible depuis l'explorateur de données - Editeur de connection (FDConnectionDefs.ini)
24/01/2020, 12h03
sergio_is_back

Citation:

Envoyé par ShaiLeTroll

Vous devriez jeter un coup d'oeil à ODBCAdvanced dans les couche de FireDAC et vérifier si vous pouvez jouer sur "Mode=Share Deny None" et "Database Locking Mode=0" qui lorsque l'on s'intéresse un peu à la chaine de connexion fournie par sergio_is_back serait les éléments qui joue sur le problème de verrouillage

Cette propriété ODBCAdvanced est accessible depuis l'explorateur de données - Editeur de connection (FDConnectionDefs.ini)

Juste pour préciser : ODBC n'est pas ADODB même si ADODB permet l'utilisation de drivers et de sources de données ODBC

Après tu n'a pas tort, j'ai déjà fait de l'accès ODBC sur des fichiers access, ça fonctionnait, et l'ODBC de base fourni avec Windows comporte toujours un driver Access même à l'heure actuelle

Mais ODBC est plus ancien qu'ADODB et risque bien de finir par disparaitre, déjà dans les environnements 64 bits avec une appli 64 bits c'est parfois difficile de trouver un driver ODBC 64 bits
J'ai parfois du recompiler des application en 32 bits à cause de ça... Le driver ODBC est une DLL et l'alignement doit être le même que celui de l'application pour que ça fonctionne

De plus ADODB est plus versatible qu'ODBC et beaucoup plus flexible (on passe par les interfaces COM), certaines supportent le 32 ou 64 bits indifféremment, c'est pour ça que j'ai donné cette direction
24/01/2020, 12h49
ShaiLeTroll

Citation:

Envoyé par sergio_is_back

De plus ADODB est plus versatible qu'ODBC et beaucoup plus flexible (on passe par les interfaces COM),...

Je sais et si tu connais bien ADODB ou TADOQuery, j'ai un sujet qui pourrait titiller ta curiosité : ADO SQL Server - Performance et Fonctionnalité incompatible où je constate d'un défaut du TADOQuery par rapport au ADODB que je ne m'explique pas ... Je dois refaire l'essai en XE2, voir si c'est un bug récent
27/01/2020, 13h31
sergio_is_back

Citation:

Envoyé par ShaiLeTroll

Je sais et si tu connais bien ADODB ou TADOQuery, j'ai un sujet qui pourrait titiller ta curiosité : ADO SQL Server - Performance et Fonctionnalité incompatible où je constate d'un défaut du TADOQuery par rapport au ADODB que je ne m'explique pas ... Je dois refaire l'essai en XE2, voir si c'est un bug récent

Salut,

Je n'ai encore jamais rencontré ce phénomène avec TADOQuery à savoir "Plus l'on récupère d'enregistrement plus c'est lent, pas linéairement mais exponentiellement"
Cela dit les applis sur lesquelles j'ai travaillé avec MSSQL Server ont rarement plus de quelques milliers de lignes par table (peut être 30000 à 40000 pour l'un d'elle mais je ne suis pas sur d'avoir des parcours WHILE not EOF sur la totalité d'une table de cette taille) mais aucun client ne m'a signalé de ralentissement quelconque jusqu’à présent. Cependant j'ai aussi utilisé ZeosDBO pour certaines en lieu et place de dbGO et de tête je ne sais plus dire lesquelles...

Actuellement j'attaque sur dbGo pour une nouvelle appli avec un MSSQL Server Express 2017 et Delphi 10.3 donc d'ici quelques semaines je pourrai te dire si je rencontre ce problème.