|
| WD9, table et requête... ca me prend la tête |
| Débuté par arnaud.s, 10 jan. 2006 10:17 - 6 réponses |
| |
| | | |
|
| |
Posté le 10 janvier 2006 - 10:17 |
Bonjour,
Je vous expose mon souci. J'ai un programme en WD9 avec une base SQL, cette base à un fichier article de 60 000 enregistrements. Je voudrais afficher la totalité dans une table, et pourvoir faire des recherches dessus, pouvoir modifier un enregistrement et que l'es informations dans la table soit visible de suite en gardant le bandeau sur ce meme enregistrement.
Solution 1 : Table fichier avec loupe
+ Rapide à l'affichage (même si le temps de chargement de la totalité est important)
- Bug (vu avec pc soft), il n'affiche pas obligatoirement tous les enregistrements
Solution 2 : Table fichier basée sur une requête avec des champs de sélections
+ Rapide à l'affichage (même si le temps de chargement de la totalité est important)
+ Possibilité de faire des recherches multicritères
- Si je fais une modification sur un enregistrement, il faut recharger la requête et la réafficher en totalité (ce qui est assez long), et on perd le positionnement courant .
Une solution a ce problème sera de pointer sur l'enregistrement de la base et de récuperer les infos pour les recopier dans la table (TableModifie), mais ces informations sont perdues si on change la position du bandeau, il faudrait les récuperer pour chaque "Affichage d'une ligne de table", ce qui multiplie les accès serveur, donc pas terrible
Solution 3 : Table Mémoire
+ Gestion des modification d'un enregistrement tres simple
- Tres long à charger (40 secondes)
Merci de m'avoir lu, si vous avez d'autres sugestions, je suis preneur. |
| |
| |
| | | |
|
| | |
| |
Posté le 10 janvier 2006 - 10:51 |
Bonjour,
Malheureusement je n'ai pas de répomse à te donner mais
*******
Solution 1 : Table fichier avec loupe
+ Rapide à l'affichage (même si le temps de chargement de la totalité est important)
- Bug (vu avec pc soft), il n'affiche pas obligatoirement tous les enregistrements
*******
qu'est-ce que ce bug?
Je suis un peu inquiet, dans quel cas celà se produit?
Merci d'éclairer ma lanterne.
Hubert |
| |
| |
| | | |
|
| | |
| |
Posté le 10 janvier 2006 - 11:25 |
La loupe sur une table relié avec une table SQL ne marche pas tres bien.
Exemple : sur 2000 enregistrements j'en ai deux qui ont une valeur commune '99' (par exemple) (le 1er à un id égal 20eme et le 2eme égal à 1220, dans le fichier)
Par le WDMAP (ou par une fenêtre avec une table, meme souci), j'active la fonction loupe, je tape '99'. le bandeau se positionne sur le premier enregistrement, le deuxieme ne suit pas, mais de plus est introuvable dans la table, il faut desactiver la fonction loupe pour le revoir dans la table.
J'ai signalé ce probleme a Pc soft qui me l'a confirmé.
A savoir que ce senario identique fonctionne correctement avec un fichier hyperfile.
L'exemple ci dessus est un cas parmi d'autre, en resumé, il ne faut utiliser la loupe avec une base SQL. |
| |
| |
| | | |
|
| | |
| |
Posté le 10 janvier 2006 - 13:40 |
Merci beaucoup pour ta réponse. |
| |
| |
| | | |
|
| | |
| |
Posté le 10 janvier 2006 - 13:40 |
Bonjour,
J'ai exactement la même configuration ( base SQL, 65000 fiches), et les mêmes besoins.
Voici la solution retenue:
J'ai un ensemble de critères de sélection ( 65 actuellements ), qui gèrent les jockers et les listes de valeurs, à partir de laquelle je lance une requête SQL d'extraction dans la base.
Je stocke l'ensemble des fiches retournées par la requête dans des fichiers HF temporaires ( un jeu de fichier par client ).
Pour l'affichage, j'utilise des tables fichiers liées aux fichiers HF. Comme l'ensemble des champs de mes fichiers HF cont indexés, il est possible de faire des recherche dans la table sur toutes les colonnes avec la loupe.
En cas de modifications, j'enregistre tout dans le fichiers HF, puis sur demande uniquement je reporte ces modifications dans la base SQL. La sauvegarde est encadrée par une transaction, donc en cas de soucis ma base reste intègre.
Pour éviter les conflits en cas de modification, je gère un table des ressources réservées. Une seule personne peut réserver une ressource à un instant donné.
J'ai actuellement 5 applications et 50 utilisateurs simultanés qui attaque cette base en même temps avec ce mode de fonctionnement, et les performances sont au rendez-vous.
Frédéric. |
| |
| |
| | | |
|
| | |
| |
Posté le 10 janvier 2006 - 14:17 |
Bonjour,
J'ai opté pour une solution identique à celle de Frédéric pour résoudre ce
type de problème.
Bien à vous.
Jacques. |
| |
| |
| | | |
|
| | |
| |
Posté le 10 janvier 2006 - 16:38 |
| |
| |
| | | |
|
| | | | |
| | |
|