Merci de t'intéresser à mon sujet. Voici le contexte :
Il s'agit d'une évolution d'une application dont la 1ère version remonte à plus de 10 ans, en BDE avec Paradox. Je souhaiterais repousser encore un peu la migration vers autre chose.
Préalablement à une session, plusieurs fichiers sont préparés. Lors de la session, un PC maître (PCM) exploite ces données.
Ces fichiers sont également installés sur un PC esclave (PCE) qui transmet, lors de la session via une messagerie Indy, des modifications que doit prendre en compte le PCM en temps presque réel (quelques sec).
La liaison était unidirectionnelle : le PCE n'intervenait sur des données que lui seul pouvait modifier.
L'évolution consiste à avoir plusieurs PCE (<= 20) qui peuvent transmettre des modifications. Avant de modifier un enregistrement, un PCE doit disposer de la dernière version.
Pour éviter une complexité de distribution des maj je souhaite remplacer la messagerie Indy par une connexion directe sur la base de données.
Les modifications concernent un seul fichier de 10 000 lignes max et une trentaine de champs (~5 Mo). Le nombre de ligne est invariable pendant une session et les modifications concernent quelques champs (alphanumérique et entier) (~200 k0).
Le PCE travaillait avec un DGrid pointant sur un TQuery. Lorsque le fichier est résidant sur le PC, c'est Ok. Lorsque le chemin d'accès est sur le réseau il l'ignore. J'avais compris que c'était une limitation du TQuery mais c'est peut être parce que je n'avais pas reconfiguré le NetDir. Avec le TTable, ça a l'air de marcher.
TTable complet ou avec FieldDefs : j'ai cherché à comparer mais ce n'est pas très probant. J'ai quand même eu une surprise que je n'explique pas.
Sur le PCE, alors que j'ai fait un close/open sur le TTable avec FieldDefs, il m'a aussi actualisé le TTable complet ???
Je cherche à optimiser car la lenteur se traduit par un temps de réponse pour l'utilisateur. Je crains aussi certaines situations où le réseau Wifi serait moins performant.
Partager