Data structure et TFrame [Résolu]

Signaler
Messages postés
273
Date d'inscription
samedi 13 juin 2009
Statut
Membre
Dernière intervention
18 avril 2015
-
Messages postés
4715
Date d'inscription
dimanche 26 février 2006
Statut
Modérateur
Dernière intervention
27 mars 2018
-
Bjr tous,
Je reviens avec une question. Plus un conseil.
Je bosse sur un DB dont la table des signalétiques principaux est à multi-format (gros systèmes).
Je simplifie la structure
   ID_TABLE char(3),
   ID_REC   char(20),
   Libl     char(30),
   DATA     char(3000)
primary key (ID_TABLE, ID_REC)
la zone data contient des structures <> selon ID_TABLE (la table '001' étant la table des tables).
001 001         Liste des tables       info sur recs de T 001, format ecran, droits d'accès, ...
001 070         Type d'opération                        T 070    ""
001 071         Devises                                 090      "" 
001 090         Pays
070 OPE_ACHAT   Achat divers - info sur l'opé d'achat selon struct '070'
070 VTE_EXPORT  Vente de march - info                 selon struct '070' 
071 826         USD .... info sur USD selon struct '071'
071 978         EUR ....   ""     EUR
090 001         USA ....   ""     USA               090
090 033         FRA .....
 and so on ...
DATA ira dans des records avec des struct <> (ou restera DATA et j'utiliserai des propriétés pour maj, sais pas encore, mais ma question:
Je vais avoir jusqu'à maxi 999 formats d'écran pour maintenir ma table, qui manipuleront les 3000 char de DATA.
J'aurai donc une partie commune (les 2 clés + libell) et pour chaque ID_TABLE des formats <> dans - des tabsheet - des form - des forms dans un panel - des frame ?.
Dans ce cas, ai-je intéret à utiliser des frames ou des forms <> ? avoir max 999 frames et séléctionner visible/enabled la bonne selon ID_TABLE est-ce une bonne solution ?
Mon idée est de faire un mdiform avec en haut à gauche 1 dbcombobox pour séléctionner la table (ID_TABLE), dessous un dbgrid les rec de la table selectionnée, et à droite un panel avec 999 max formats possibles). 
je peux avoir +- 1.000.000 de recods répartis dans 450 ID_TABLE (certains utilisent le même format d'écran, env 200 écrans réellements différents ET la clé pour trouver le bon écran  se trouve dans le DATA de la desc de
la table en '001', c'est tout simple (et imposé).
Tout marche bien avec 1 format 1 ID_REC, 2, 3 j'y arrive, controles messages, ... mais avec 10, 100, 999 possibilités quel est le meilleurs choix ?
Tcho tous.
solilog

6 réponses

Messages postés
4715
Date d'inscription
dimanche 26 février 2006
Statut
Modérateur
Dernière intervention
27 mars 2018
13
bonsoir,

Dans ce cas, ai-je intéret à utiliser des frames ou des forms <> ? avoir max 999 frames et séléctionner visible/enabled la bonne selon ID_TABLE est-ce une bonne solution ?

je ne sens ni l'un ni l'autre pour l'instant et le char(3000) m'inquiète beaucoup..

pourrais-tu préciser le type de table (dbase, paradox ou autre ..)
autre chose, appli existante à modifier ou tout à construire
en local ou en réseau ?

on y verra plus clair..

cantador
Messages postés
273
Date d'inscription
samedi 13 juin 2009
Statut
Membre
Dernière intervention
18 avril 2015
10
Bonjour
  - la base tourne sur AS/400 (DB2), donc le format de la table est imposé.
  - il s'agit de remplacer une appli en mode terminal (AS/400 5250) par une appli wysiwig (donc delphi).
  - on est bien-sur en multi-users, c'est l'AS400 qui gère ça, moi je tape dans la base avec des drivers ODBC ou ADO fournis par IBM.
Le prob n'est pas la DB, tout-ça marche, mover mes 3000 chars dans un record puis dans des contrôles, c'est ok, c'est comment gérer plusieurs 100 d'écrans <> sur la même table.
Les frames m'apporteront-elles 1 + par rapport à des mdichilds ?
Tcho
solilog
Messages postés
4715
Date d'inscription
dimanche 26 février 2006
Statut
Modérateur
Dernière intervention
27 mars 2018
13
c'est ok, c'est comment gérer plusieurs 100 d'écrans <> sur la même table.
on peut gérer plusieurs écrans sur la même table avec le mode transactionnel
mais pourquoi autant d'écrans différents ?
Quelle est cette nécessité puisqu'il est possible de les créer dynamiquement ?

cantador
Messages postés
273
Date d'inscription
samedi 13 juin 2009
Statut
Membre
Dernière intervention
18 avril 2015
10
J'ai sans  doute mal posé le prob.
Y a un max de 999 tables (pays, type d'op, mois de l'année, jour semaine, devises, tarif, utilisateurs, ... tu veux le PDF doc de ces tables, c'est 20Mo!).
qui sont stockés dans la même table. (voir struc + haut).
Dans un form, j'ai en haut gauche un dbcombo (lié sur un tQuery type SELECT * from TABLE WHERE ID_TABLE ='001' (la table des tables), de ce dbcombo je select un rec, qui est un n° de table, qui sera le mastersource d'une autre tTable qui aff un dbgrid. Là ok tout roule. A droite j'ai un panel avec les data du record select du dbgrid qui extractent de DATA ce qu'on affiche/edit. Mais la struct de DATA pour les dev est <> de celle des type d'op ou des pays, ...
 - si je select la table '070' dans le combo j'aurai dessous le dbgrid de tous les types d'ope et à droite une form / frame avec le détail de l'opé select., format 070,
 - si je select dans le combo la 071 devises, j'aurai les devises dans le dbgrid et la form / panel ou  frame des champs de desc de la devise.
Je peux avoir 999 ID_TABLE <> donc 999 struct <> dans DATA et 999 écrans pour les maj. En fait y en a 450 utilisés.
Je aurai donc 1 mdiform pour le combo + dbgrid et dedans à droite UNE form prise dans 450 possibles selon la select du combo. 
Suis-je clair ?

solilog
Messages postés
4715
Date d'inscription
dimanche 26 février 2006
Statut
Modérateur
Dernière intervention
27 mars 2018
13
Messages postés
4715
Date d'inscription
dimanche 26 février 2006
Statut
Modérateur
Dernière intervention
27 mars 2018
13
oui mais on va traduire autrement :
Tu as une table principale TABLE en relation 1-n avec une autre table REC


 TABLE                                        REC
                                                     Id_REC
 Id_TABLE      ->>>>>>>>         Id_TABLE


Ensuite cette table REC affichée dans un DBGrid est aussi en
relation 1-n avec une autre table DATA dont tu indiques :


"Mais la struct de DATA pour les dev est <> de celle des type d'op ou des pays, ..."


A partir de là, tu peux effectivement envisager les deux solutions indiquées (frame ou mdiform)


Moi je prendrai mdiform bien que la programmation soit un peu délicate.
et je construirai aussi une forme design type (bref un modèle)


je mettrai si possible un type BLOB à la place de char(3000)


Voilà tiens nous au courant de la suite..

cantador