bonjour
jusqu'à présent, pour travailler avec delphi 6 et un un SGBD comme Access,
j'ouvrais toutes les tables au début, je faisais ce que je voulais, et je
refermais tout à la fin.
là je me rend compte qu'avec des tables de plusieurs dizaines de milleirs
d'enregistrements, ça prend toute la mémoire et tout un temps fou à
l'execution (le fait de faire , avec un TADOTable, table1.open prend 5
minutes car il passe tout en mémoire).
alors, comment doit je transformer mon programme pour travailler avec de
tres grosses tables et Delphi ?
merci de vos lumières, je ne vois pas trop de solution !
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
J-Pierre
Tiens, j'ai l'impression de vous avoir déjà vu quelque part..... :-)))))
1) Proposer à l'utilisateur d'aller boire un café.
2) Je ne vois pas où est l'avantage d'ouvrir tes tables et de les avoir en mémoire. Peut-être pour éviter d'avoir à extraire des lignes du serveur avec chaque formulaire (comment ça s'appelle, avec Delphi, un formulaire ?) ? Mais là, tu es exactement à l'opposé de la philosophie client/serveur.
Je suppose que la connexion ODBC est établie. Chacun de tes formulaires devrait exécuter une requête SELECT avec une condition WHERE pour ne transférer que les lignes dont tu as réellement besoin. Tu veux afficher les informations relatives à un client: ? SELECT ...... WHERE codeClient = xxxx. L'utilisateur veut voir un autre client ? SELECT ...... WHERE codeClient = yyyy.
Et bien sûr, ta sélection ne se fait que sur des colonnes indexées, sinon, tu vas "coucher" ton serveur, même s'il ne te renvoie qu'une ligne.
La solution, c'est ça, reprendre chacun de tes formulaires ou états, ou procédures cataloguées. C'est fastidieux, mais pour te consoler, dis-toi que des milliers y sont passés, et que des milliers y passeront.
Le problème n'est pas spécifique à Access, mais se produit avec tous les SGDBR. Certains, SQL serveur par exemple, sont plus performants qu'Access, mais sur le fond, même problème, même solution.
J-Pierre
"ACCESS" a écrit dans le message de news:br2sd8$qn$
bonjour jusqu'à présent, pour travailler avec delphi 6 et un un SGBD comme Access, j'ouvrais toutes les tables au début, je faisais ce que je voulais, et je refermais tout à la fin. là je me rend compte qu'avec des tables de plusieurs dizaines de milleirs d'enregistrements, ça prend toute la mémoire et tout un temps fou à l'execution (le fait de faire , avec un TADOTable, table1.open prend 5 minutes car il passe tout en mémoire). alors, comment doit je transformer mon programme pour travailler avec de tres grosses tables et Delphi ?
merci de vos lumières, je ne vois pas trop de solution !
Tiens, j'ai l'impression de vous avoir déjà vu quelque part..... :-)))))
1) Proposer à l'utilisateur d'aller boire un café.
2) Je ne vois pas où est l'avantage d'ouvrir tes tables et de les avoir en mémoire. Peut-être pour éviter d'avoir à extraire des
lignes du serveur avec chaque formulaire (comment ça s'appelle, avec Delphi, un formulaire ?) ? Mais là, tu es exactement à l'opposé
de la philosophie client/serveur.
Je suppose que la connexion ODBC est établie.
Chacun de tes formulaires devrait exécuter une requête SELECT avec une condition WHERE pour ne transférer que les lignes dont tu as
réellement besoin.
Tu veux afficher les informations relatives à un client: ?
SELECT ...... WHERE codeClient = xxxx.
L'utilisateur veut voir un autre client ?
SELECT ...... WHERE codeClient = yyyy.
Et bien sûr, ta sélection ne se fait que sur des colonnes indexées, sinon, tu vas "coucher" ton serveur, même s'il ne te renvoie
qu'une ligne.
La solution, c'est ça, reprendre chacun de tes formulaires ou états, ou procédures cataloguées.
C'est fastidieux, mais pour te consoler, dis-toi que des milliers y sont passés, et que des milliers y passeront.
Le problème n'est pas spécifique à Access, mais se produit avec tous les SGDBR. Certains, SQL serveur par exemple, sont plus
performants qu'Access, mais sur le fond, même problème, même solution.
J-Pierre
"ACCESS" <ACCESS44@hotmail.com> a écrit dans le message de news:br2sd8$qn$1@news-reader3.wanadoo.fr...
bonjour
jusqu'à présent, pour travailler avec delphi 6 et un un SGBD comme Access,
j'ouvrais toutes les tables au début, je faisais ce que je voulais, et je
refermais tout à la fin.
là je me rend compte qu'avec des tables de plusieurs dizaines de milleirs
d'enregistrements, ça prend toute la mémoire et tout un temps fou à
l'execution (le fait de faire , avec un TADOTable, table1.open prend 5
minutes car il passe tout en mémoire).
alors, comment doit je transformer mon programme pour travailler avec de
tres grosses tables et Delphi ?
merci de vos lumières, je ne vois pas trop de solution !
Tiens, j'ai l'impression de vous avoir déjà vu quelque part..... :-)))))
1) Proposer à l'utilisateur d'aller boire un café.
2) Je ne vois pas où est l'avantage d'ouvrir tes tables et de les avoir en mémoire. Peut-être pour éviter d'avoir à extraire des lignes du serveur avec chaque formulaire (comment ça s'appelle, avec Delphi, un formulaire ?) ? Mais là, tu es exactement à l'opposé de la philosophie client/serveur.
Je suppose que la connexion ODBC est établie. Chacun de tes formulaires devrait exécuter une requête SELECT avec une condition WHERE pour ne transférer que les lignes dont tu as réellement besoin. Tu veux afficher les informations relatives à un client: ? SELECT ...... WHERE codeClient = xxxx. L'utilisateur veut voir un autre client ? SELECT ...... WHERE codeClient = yyyy.
Et bien sûr, ta sélection ne se fait que sur des colonnes indexées, sinon, tu vas "coucher" ton serveur, même s'il ne te renvoie qu'une ligne.
La solution, c'est ça, reprendre chacun de tes formulaires ou états, ou procédures cataloguées. C'est fastidieux, mais pour te consoler, dis-toi que des milliers y sont passés, et que des milliers y passeront.
Le problème n'est pas spécifique à Access, mais se produit avec tous les SGDBR. Certains, SQL serveur par exemple, sont plus performants qu'Access, mais sur le fond, même problème, même solution.
J-Pierre
"ACCESS" a écrit dans le message de news:br2sd8$qn$
bonjour jusqu'à présent, pour travailler avec delphi 6 et un un SGBD comme Access, j'ouvrais toutes les tables au début, je faisais ce que je voulais, et je refermais tout à la fin. là je me rend compte qu'avec des tables de plusieurs dizaines de milleirs d'enregistrements, ça prend toute la mémoire et tout un temps fou à l'execution (le fait de faire , avec un TADOTable, table1.open prend 5 minutes car il passe tout en mémoire). alors, comment doit je transformer mon programme pour travailler avec de tres grosses tables et Delphi ?
merci de vos lumières, je ne vois pas trop de solution !
ACCESS
mais pour faire un simple 'insert' ou 'update', je dois bien faire un open sur la table ?? ou alors, je peux le faire avec une query sans rien ouvrir ? et pour( filter tous les enregistrements d'une grosse base, ça prend du temps ?
suis assez novice en la matiere !
"J-Pierre" a écrit dans le message de news:
Tiens, j'ai l'impression de vous avoir déjà vu quelque part..... :-)))))
1) Proposer à l'utilisateur d'aller boire un café.
2) Je ne vois pas où est l'avantage d'ouvrir tes tables et de les avoir en mémoire. Peut-être pour éviter d'avoir à extraire des
lignes du serveur avec chaque formulaire (comment ça s'appelle, avec Delphi, un formulaire ?) ? Mais là, tu es exactement à l'opposé
de la philosophie client/serveur.
Je suppose que la connexion ODBC est établie. Chacun de tes formulaires devrait exécuter une requête SELECT avec une condition WHERE pour ne transférer que les lignes dont tu as
réellement besoin. Tu veux afficher les informations relatives à un client: ? SELECT ...... WHERE codeClient = xxxx. L'utilisateur veut voir un autre client ? SELECT ...... WHERE codeClient = yyyy.
Et bien sûr, ta sélection ne se fait que sur des colonnes indexées, sinon, tu vas "coucher" ton serveur, même s'il ne te renvoie
qu'une ligne.
La solution, c'est ça, reprendre chacun de tes formulaires ou états, ou procédures cataloguées.
C'est fastidieux, mais pour te consoler, dis-toi que des milliers y sont passés, et que des milliers y passeront.
Le problème n'est pas spécifique à Access, mais se produit avec tous les SGDBR. Certains, SQL serveur par exemple, sont plus
performants qu'Access, mais sur le fond, même problème, même solution.
J-Pierre
"ACCESS" a écrit dans le message de news:br2sd8$qn$
bonjour jusqu'à présent, pour travailler avec delphi 6 et un un SGBD comme Access,
j'ouvrais toutes les tables au début, je faisais ce que je voulais, et je
refermais tout à la fin. là je me rend compte qu'avec des tables de plusieurs dizaines de milleirs
d'enregistrements, ça prend toute la mémoire et tout un temps fou à l'execution (le fait de faire , avec un TADOTable, table1.open prend 5 minutes car il passe tout en mémoire). alors, comment doit je transformer mon programme pour travailler avec de tres grosses tables et Delphi ?
merci de vos lumières, je ne vois pas trop de solution !
mais pour faire un simple 'insert' ou 'update', je dois bien faire un open
sur la table ??
ou alors, je peux le faire avec une query sans rien ouvrir ?
et pour( filter tous les enregistrements d'une grosse base, ça prend du
temps ?
suis assez novice en la matiere !
"J-Pierre" <pas.de.pub.jpberchtold@hotmail.com> a écrit dans le message de
news:uJyQqIevDHA.1196@TK2MSFTNGP12.phx.gbl...
Tiens, j'ai l'impression de vous avoir déjà vu quelque part..... :-)))))
1) Proposer à l'utilisateur d'aller boire un café.
2) Je ne vois pas où est l'avantage d'ouvrir tes tables et de les avoir en
mémoire. Peut-être pour éviter d'avoir à extraire des
lignes du serveur avec chaque formulaire (comment ça s'appelle, avec
Delphi, un formulaire ?) ? Mais là, tu es exactement à l'opposé
de la philosophie client/serveur.
Je suppose que la connexion ODBC est établie.
Chacun de tes formulaires devrait exécuter une requête SELECT avec une
condition WHERE pour ne transférer que les lignes dont tu as
réellement besoin.
Tu veux afficher les informations relatives à un client: ?
SELECT ...... WHERE codeClient = xxxx.
L'utilisateur veut voir un autre client ?
SELECT ...... WHERE codeClient = yyyy.
Et bien sûr, ta sélection ne se fait que sur des colonnes indexées, sinon,
tu vas "coucher" ton serveur, même s'il ne te renvoie
qu'une ligne.
La solution, c'est ça, reprendre chacun de tes formulaires ou états, ou
procédures cataloguées.
C'est fastidieux, mais pour te consoler, dis-toi que des milliers y sont
passés, et que des milliers y passeront.
Le problème n'est pas spécifique à Access, mais se produit avec tous les
SGDBR. Certains, SQL serveur par exemple, sont plus
performants qu'Access, mais sur le fond, même problème, même solution.
J-Pierre
"ACCESS" <ACCESS44@hotmail.com> a écrit dans le message de
news:br2sd8$qn$1@news-reader3.wanadoo.fr...
bonjour
jusqu'à présent, pour travailler avec delphi 6 et un un SGBD comme
Access,
j'ouvrais toutes les tables au début, je faisais ce que je voulais, et
je
refermais tout à la fin.
là je me rend compte qu'avec des tables de plusieurs dizaines de
milleirs
d'enregistrements, ça prend toute la mémoire et tout un temps fou à
l'execution (le fait de faire , avec un TADOTable, table1.open prend 5
minutes car il passe tout en mémoire).
alors, comment doit je transformer mon programme pour travailler avec de
tres grosses tables et Delphi ?
merci de vos lumières, je ne vois pas trop de solution !
mais pour faire un simple 'insert' ou 'update', je dois bien faire un open sur la table ?? ou alors, je peux le faire avec une query sans rien ouvrir ? et pour( filter tous les enregistrements d'une grosse base, ça prend du temps ?
suis assez novice en la matiere !
"J-Pierre" a écrit dans le message de news:
Tiens, j'ai l'impression de vous avoir déjà vu quelque part..... :-)))))
1) Proposer à l'utilisateur d'aller boire un café.
2) Je ne vois pas où est l'avantage d'ouvrir tes tables et de les avoir en mémoire. Peut-être pour éviter d'avoir à extraire des
lignes du serveur avec chaque formulaire (comment ça s'appelle, avec Delphi, un formulaire ?) ? Mais là, tu es exactement à l'opposé
de la philosophie client/serveur.
Je suppose que la connexion ODBC est établie. Chacun de tes formulaires devrait exécuter une requête SELECT avec une condition WHERE pour ne transférer que les lignes dont tu as
réellement besoin. Tu veux afficher les informations relatives à un client: ? SELECT ...... WHERE codeClient = xxxx. L'utilisateur veut voir un autre client ? SELECT ...... WHERE codeClient = yyyy.
Et bien sûr, ta sélection ne se fait que sur des colonnes indexées, sinon, tu vas "coucher" ton serveur, même s'il ne te renvoie
qu'une ligne.
La solution, c'est ça, reprendre chacun de tes formulaires ou états, ou procédures cataloguées.
C'est fastidieux, mais pour te consoler, dis-toi que des milliers y sont passés, et que des milliers y passeront.
Le problème n'est pas spécifique à Access, mais se produit avec tous les SGDBR. Certains, SQL serveur par exemple, sont plus
performants qu'Access, mais sur le fond, même problème, même solution.
J-Pierre
"ACCESS" a écrit dans le message de news:br2sd8$qn$
bonjour jusqu'à présent, pour travailler avec delphi 6 et un un SGBD comme Access,
j'ouvrais toutes les tables au début, je faisais ce que je voulais, et je
refermais tout à la fin. là je me rend compte qu'avec des tables de plusieurs dizaines de milleirs
d'enregistrements, ça prend toute la mémoire et tout un temps fou à l'execution (le fait de faire , avec un TADOTable, table1.open prend 5 minutes car il passe tout en mémoire). alors, comment doit je transformer mon programme pour travailler avec de tres grosses tables et Delphi ?
merci de vos lumières, je ne vois pas trop de solution !
jerome
Tu utilise un TQuery avec INSERT, UPDATE, etc... Mais en aucun cas tu ne dois ouvrir toutes tes tables.
Jerome
PS : Pour ce genre de question passe plutot par news.vienneinfo.org/nzn.fr.delphi
Tu utilise un TQuery avec INSERT, UPDATE, etc...
Mais en aucun cas tu ne dois ouvrir toutes tes tables.
Jerome
PS : Pour ce genre de question passe plutot par
news.vienneinfo.org/nzn.fr.delphi
Tu utilise un TQuery avec INSERT, UPDATE, etc... Mais en aucun cas tu ne dois ouvrir toutes tes tables.
Jerome
PS : Pour ce genre de question passe plutot par news.vienneinfo.org/nzn.fr.delphi
J-Pierre
Bonjour,
Le simple fait d'avoir une connexion ODBC ouverte te permet d'exécuter des requêtes de tous types, dans le monde Microsoft, pas besoin d'ouvrir la base ou une table, dans le monde Delphi, je ne sais pas.....
Récemment, j'ai fait un essai sur une table Access avec 3 millions de lignes, la base faisait 400 megs, extraction de 500 lignes avec une condition WHERE sur une colonne index, temps de réponse immédiat, non mesurable visuellement.
J-Pierre
"ACCESS" a écrit dans le message de news:br47vf$nhg$
mais pour faire un simple 'insert' ou 'update', je dois bien faire un open sur la table ?? ou alors, je peux le faire avec une query sans rien ouvrir ? et pour( filter tous les enregistrements d'une grosse base, ça prend du temps ?
suis assez novice en la matiere !
Bonjour,
Le simple fait d'avoir une connexion ODBC ouverte te permet d'exécuter des requêtes de tous types, dans le monde Microsoft, pas
besoin d'ouvrir la base ou une table, dans le monde Delphi, je ne sais pas.....
Récemment, j'ai fait un essai sur une table Access avec 3 millions de lignes, la base faisait 400 megs, extraction de 500 lignes
avec une condition WHERE sur une colonne index, temps de réponse immédiat, non mesurable visuellement.
J-Pierre
"ACCESS" <ACCESS44@hotmail.com> a écrit dans le message de news:br47vf$nhg$1@news-reader1.wanadoo.fr...
mais pour faire un simple 'insert' ou 'update', je dois bien faire un open
sur la table ??
ou alors, je peux le faire avec une query sans rien ouvrir ?
et pour( filter tous les enregistrements d'une grosse base, ça prend du
temps ?
Le simple fait d'avoir une connexion ODBC ouverte te permet d'exécuter des requêtes de tous types, dans le monde Microsoft, pas besoin d'ouvrir la base ou une table, dans le monde Delphi, je ne sais pas.....
Récemment, j'ai fait un essai sur une table Access avec 3 millions de lignes, la base faisait 400 megs, extraction de 500 lignes avec une condition WHERE sur une colonne index, temps de réponse immédiat, non mesurable visuellement.
J-Pierre
"ACCESS" a écrit dans le message de news:br47vf$nhg$
mais pour faire un simple 'insert' ou 'update', je dois bien faire un open sur la table ?? ou alors, je peux le faire avec une query sans rien ouvrir ? et pour( filter tous les enregistrements d'une grosse base, ça prend du temps ?
