Discussion :

[kournane]

Bonjour à toutes et à tous;
J'ai un fichier dbf (une table dbase) situé sur une machine A, le serveur. Plusieurs applications situées sur le même réseau que ce serveur peuvent lire et écrire sur cette table. Il y a également une application (miroir) située sur le serveur (La machine A) qui lit et écrit également sur cette table. J'aimerai faire en sorte que l'activité de cette dernière application ne gène pas du tout celle des autres application situées sur le réseau, en d'autres termes qu'elle soit la dernière servie. J'ai essayé en minimisant au maximum la priorité attribuée à cette application. Pour cela j'ai mis ce code dans le OnCreate de l'application :

Code :

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

 SetPriorityClass(GetCurrentProcess(), IDLE_PRIORITY_CLASS);

J'ai ensuite fait plusieurs tests, ça marche quelques fois, c'est à dire que la vitesse de lecture et d'écriture des autres application augmente lorsque je met la priorité de cette application au plus bas. Mais ça ne marche pas tout le temps, je pense que d'autres facteurs entrent en compte.

J'aimerai savoir si je suis sur la bonne voie. Est-ce seulement une question de priorité entre les processus ? Il est vrai que les application ne sont pas sur la même machine mais le fait que l'application présente sur le serveur aie une priorité basse implique qu'elle consulte moins souvent le fichier mais je pense que ça ne suffit pas. Est-ce qu'il y aurait un moyen de savoir à un instant 't' qu'une application essaie de consulter la table, comme ça je pourrais stopper l'activité de l'application "Miroir" pour céder la priorité aux autres. J'aurais de toutes façons besoin que la priorité du "miroir" soit au minimum pour ne gêner les applications présentes sur le serveur aussi.

Je vous remercie d'avance pour toute réponse ou aide.

[ShaiLeTroll]

J'aimerai savoir si je suis sur la bonne voie.

Tout simplement NON

Tu prévois un serveur applicatif plus un remplacement à chaud du principal ?
Si le serveur principale tombe, le miroir prend la main ?
Dans ce cas, il faut qu'il puisse savoir qu'il la reprendre et remonter sa Prorité

Une telle architecture en dBase
Etrange d'utiliser une vieille technologie mais avec des principes de redondance pour assurer la robustesse d'un système

Tu évoques un serveur mais tu as d'autres applications sur la même base ?

Vouloir faire du client serveur avec dBase ?
Change de DB, utilise MySQL par exemple, en InnoDB, tu auras moins le phénomène de blocage qu'en MyISAM
Pense aussi à FireBird (Interbase)

Si l'on commence à faire une application miroir autant faire aussi une DB miroir avec de la réplication

MySQL ou SQL Server peuvent le faire automatiquement
en SQL Server ou ORACLE, tu pourrais limiter le CPU et le débit réseau d'une session

Tu oublies la charge CPU
ton serveur principal est peut-être très occupé, même avec une priorité haute, il peut parfois avoir d'autres traitements qui l'occupe
ton serveur miroir, si cela se trouve, lui n'a rien à faire, et même si ton process a une faible priorité, il a souvent la main puisque la machine n'a rien d'autre à faire

tu oublies la charge réseau et du serveur de fichier
Pour améliorer les perf de Paradox, à l'époque, un serveur de fichier SAMBA c'est plus efficace que WindowsNT4
Pour dBase, on peut penser que c'est similaire, tu as des contraintes liées à l'accès fichier !

Quelle provider pour dBase utilises-tu ?
Il faut une version récente pour gérer correctement les Windows récents
J'ai utilisé Apollo pour accéder à du dBase
Plus performance que le BDE, d'ailleurs, lui est obsolète, à éviter donc !


J'ai eu le même soucis en Paradox lorsque j'étais apprenti,
à la différence que l'un des programmes (le serveur) aurait plutôt été mis en Proriété Haute car il traitait 100 requetes par secondes
Au final, les clients ne pouvaient pas accéder aux tables, tout le temps bloqué car au début les tables étaient ouverte en permanence.
Une version suivante, je fermais et ouvrait les tables juste au moment opportun ou j'utilisais du SQL
les Clients fonctionnaient un poil mieux mais les performances du programme serveur en baisse n'était plus acceptable pour les contraintes du projet
Même le PdxUsers n'a pas améliorer les choses

On est passé à InterBase, et là plus de problème d'accès concurrent,
j'ai juste découvert un peu tard que le Prepared devait être explicite en IBX, sinon, il refaisait le Prepare à chaque fois.

Dans d'autres sociétés,
un grand nombre de projet dBase ont été migré vers MySQL lorsque le client souhaitait plus de connexion
dBase c'est un peu dépassé

Est-ce une contrainte de ton devoir d'utiliser une vieille base de données ?

[kournane]

Bonjour, oui c'est une contrainte.
Il existe un serveur contenant des tables "dbase" et sur lequel lisent et écrivent plusieurs applications situé sur les différents postes du réseaux.
"Miroir" est l'application que j'essaie de développer dans le but de lire et de copier vers des tables sql server les nouveaux enregistrements ainsi que les modifications effectuées sur certaines des tables "dbase" présentes sur le serveur, je ne dois pas copier les tables en entier. Cette application "Miroir" sera présente sur le serveur et la contrainte auquel je fais face est la suivante, l'application dite "Miroir" doit lire les nouveaux enregistrement sur les tables "dbase" et les copier vers les tables sql server sans alourdir le système car dbase est déjà excessivement lent. Je cherche un moyen de contourner les classiques boucles de requêtes de sélection et d'insertion qui prendrai un temps énorme ou plutôt faire que l'application ne soit pas encombrante pour les autres. Sur mon application "Miroir", j'accède à aux tables "dbase" en spécifiant le chemin sur un ADOConnection, je sais que ça n'aide pas mais je pensais que ça ne changerais pas grand chose. Les autres application utilisent BDE.
Je te remercie pour ta réponse et j'espère avoir bien expliqué mon problème.

[kournane]

Je choisi OLE DB Provider comme fournisseur.

[ShaiLeTroll]

Donc, tu fais une replication dBase vers SQL Server ...

Es-tu obligé de le faire en journée ?
Pourquoi ne pas faire une synchronisation la nuit, une opération bien brutale qui analyse les tables dBase pour les recopier vers SQL Server ?

Comment sais-tu ce qui a été modifié et ce qui a été inséré ?
Tu fais des boucles qui compare la version dBase avec la version SQL Server ?

Après, pour économiser au plus les recherches, le seul moyen c'est de "tagger" les tables
une colonne genre 'LastSync' dans chaque table dBase, si null, c'est une ligne à ajouter
Pour les modifications, cela se corse, faudrait gérer une colonne 'LastUpdate', si 'LastUpdate' est supérieur à 'LastSync' c'est une ligne à mettre à jour
le problème c'est qu'il faut que 'LastUpdate' soit gérer par toutes les autres applications, c'est peu probable
Les flag c'est toujours moins fiable qu'une comparaison complète

Si tu peux passer cela la nuit
Faudrait comparer les performances entre recopier tout systématiquement ou une copie partielle des modifications.
Car comme tu le dit, dBase c'est lent, si cela se trouve l'analyse des données pour faire une copie partielle est plus lente tu tout reprendre sans se poser de questions (cela dépend le volume et la complexité de critère de mise à jour)

Faudrait regarder SSIS (SQL Server integration Service), là où je travaille, cela échange des données entre l'Oracle de PROD et un SQL Server qui sert pour des stats, des exports, des EDI via SSIS

Je suppose qu'en parallèle, il y a un projet de ré-écriture des autres applications vers SQL Server

[kournane]

Tout le coté "Lecture des nouveaux enregistrement et copie vers la table sql server" est parfaitement gérer de mon coté. Il est impossible de modifier les codes sources en entier des applications qui écrivent sur les tables dbase et ça ne dépend même pas de moi. Mais il y a une colonne à chaque ligne qui permet de reconnaître si une ligne a été touchée, une fois cette colonne copier vers sql server après test (si elle y existe déjà, modification ou insertion), la valeur de la colonne est réinitialisée. J'avais plein d'autres idées mais, c'est celle ci qui a été choisi comme la plus adaptée au contexte.

Je ne peux pas le faire la nuit, il faut que ce soit en temps réel ou bien léger différé. La contrainte principale est de faire en sorte que ce soit rapide de façon à ce que ça n'alourdisse pas le serveur, déjà chargé de table "dbase" et "DBISAM", lancer une application pareille (avec boucles de requête sur des table "dbase") risquerait d'alourdir considérable l'exécution des application qui interroge les bases de données depuis les postes clients du réseaux.

C'est pour ça que J'ai pensé à la gestion de la mémoire, j'ai voulu faire en sorte que l'application n'utilise que l'espace mémoire libre, c'est pour ça que j'ai voulu baisser sa priorité. Mais j'aimerai aller plus loin en analysant régulièrement l'espace libre et forcer l'application à n'utiliser que ça. Mais je ne sais pas si : 1.C'est faisable 2.ça changera grand chose.

Je cherche aussi une solution qui pourrait m'éviter de passer par les boucles et les requête, j'ai pensé à faire un timer qui duplique régulièrement une table dbf concernée, puis converti cette copie en .csv et agir sur le .csv, voir même trouver un moyen de l'importer à sql server depuis delphi mais sans analyser ligne par ligne, plutôt comme le fait le gestionnaire de "Sql Management Studio". Mais faire une copie d'un ficher de 200 ou 300 méga chaque 5 secondes risquerait d’être encore pire que la première solution en terme de lenteur. C'est pour que j'ai pensé à ça : https://fr.wikipedia.org/wiki/Backgr...ansfer_Service Pour la duplication du fichier, ce composant est disponible pour delphi, mais je n'ai pas encore trouver une bonne source. Il utilise la bande passante libre pour le transfert des données. Je voudrais également savoir s'il y a un moyen d'exécuter une application delphi de cette façon, c'est à dire utiliser des ressources autres que celles qu'utilisent les autres applications, agir en parallèle ou en arrière plan sans gêner. Je sais que tout ça est vague pour l'instant mais j'espère juste trouver une piste.