[TTable BDE FieldDefs] 2 tables pointant sur le même fichier: FieldDefs différents --> réduction charge réseau

Bonjour,

Dans le cadre d'une application Client-Serveur, les clients sont connectés à un fichier BDE via le réseau. Lors d'une session La majorité des champs sont invariables. Seuls quelques champs peuvent changer : environ 5% de la taille du fichier.

Lors d'une modification effectuée par un client, il effectue un close-open de la table pour travailler sur des données à jour.

Pour minimiser la charge réseau, j'ai choisi d'utiliser 2 tables pointant sur le même fichier mais avec des FieldDefs différents. Seule la table utilisant les champs variable est rafraichie par close-open.

Est-ce une bonne méthode ?

Est-ce une nouvelle application ?
BDE avec Paradox ?

Si oui, remplace le BDE par autre chose !
Si non, utilise plutôt du SQL, ne laisse jamais les TTable ouverts en permanence (cela nuit à l'accès concurrentiel), as-tu bien configuré tes WorkDir et NetDir (l'emplacement du fichier lock), utilise FlushBuffers si vraiment tu es obligé d'utiliser des TTable
As-tu testé sur des très grosses tables si entre un TTable complet et un TTable avec FieldDefs, tu avais un véritable gain ? Si c'est optimiser à ce point dans le BDE ?

Avec les Windows récents, je ne sais pas mais à il y a 15ans,
le mieux avec Paradox était un serveur de fichier Samba bien plus performant pour l'accès des fichiers que Windows 95 ou NT 4

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.

Bonjour,

d'expérience, je suggère la migration suivante, rapide
Mettre les/la table dans un SGBD Firebird (il y a un outil simple pour cela)
sans autre modification que le changement de l'alias tu auras un accès concurrentiel via TQuery/TTable très facilement à tes données en réseau local sans perte de performance.
J'ai encore en exploitation une 20 de PC (réseau ou filaire) avec de vieux programmes D3+BDE+Firebird qui donnent encore satisfaction aux utilisateurs.
Les performances de ces programmes ne se dégradent que parce que :
- écrits il y a 20 ans il y a plus d'utilisation de TTables que de TQuery , impliquant donc plus de trafic réseau (donc une catastrophe quand on veut accéder à la Base de Données via internet)