C'est en fait deux questions en une :

1/ Si je veux pouvoir de manière dynamique ajouter des infos non prévues initialement dans la structure d'une table, la solution est-elle d'avoir une StreamMemory dedans dont je peux modifier le contenu ?

2/ Est-il préférable en terme de rapidité d'exécution de séparer les infos dans des champs identifiés, ou bien vaut-il mieux regrouper les infos sur lesquelles on ne fait jamais de requète dans un RecordSet dans une StreamMemory ?

Je ne suis pas sur que ton pb vient de ta base.

Regarde plutot les query que tu fais

La gestion des chaines etc...

Je suis d'accord avec toi. Mais cette question est en fait un peu en marge du problème de temps d'exécution

1/ Oui, c'est une solution. Et tu peux sérialiser le contenu dans une Class pour un accès plus facile.

Effectivement

Toujours à propos des tables...

Lorsque je dois utiliser une même table parfois en lecture, d'autres fois en écriture, de même parfois avec un opentable ou alors un openrecorset...

Est-il préférable de définir plusieurs objets se rapportant à la même table ou bien un seul que je rédéfinis à chaque fois

Alors en general on a une table en lecture seul qu'on ouvre dans le load de la form et que l'on ferme dans le unload
Et une en écriture qu'on ouvre et ferme uniquement en cas de modif

Trois autres questions si tu permets :
1/ Si la même table en lecture est utilisée dans plusieurs forms, je l'ouvre et la ferme dans chaque form ou bien au niveau de l'appli ?
2/ J'utilise le même objet en passant alternativement d'un opentable à un openrecordset ?
3/ On ouvre et on ferme la base en écriture à chaque modif ?

En général, Je la ferme et l'ouvre à chaque passage de form


J'utilise en général deux objets
Comme cela je sais si je suis sur une requete ou non
Mais la je ne pense pas qu'il y a de règle


C'est ce que je fais et je requerise mes requetes (db.Requery)

Merci

Je le dis ici, un de ces jours, il faudra que je trouve le moyen de te remercier avec Snark (une petite bouffe par exemple)

oui... ils sont forts, nos amis ... et toi, tu emboîtes bien le pas ... bravo ..

Pas si vite... Je n'y suis pas encore

Désolé, encore une question

Est-ce qu'une boucle de lecture sur une base avec un GridEx.LoadItem sera beaucoup plus long en exécution qu'un GridEx.Populate Db

Pas trop d'idée la dessus mais je pense que le populate est mieux

Je le pense aussi à la base mais il ne me permet pas une chose :
J'ai lors du remplissage du GridEx des conditions pour savoir si un article doit être chargé dans le GridEx qui peuvent être intégrées dans le OpenRecorSet.

D'autres conditions, qui résultent de calculs sur des champs de la table ne peuvent pas être gérés par le OpenRecordSet.

Donc l'intérêt de la boucle est de ne pas faire de LoadItem si ces conditions ne sont pas remplies. Alors qu'avec le Populate, je suis contraint de balayer le contenu de GridEx après coup pour faire des RemoveItem

La je n'hesite pas je fait une boucle.

VOire je lis les enregistrements par page (10 à la fois par exemple ) et lis les enreg au fur est à mesure que l'on bouge l'ascenseur (par exemple).

Ok.

Lire les enregistrements par 10 est une solution pour gagner du temps en affichage non ?

Oui mais aussi ne pas surcharger la mémoire quand on a une base avec beaucoup d'enregistrements par exemple.
C'est pas non plus trivial à mettre en oeuvre.
Le chargement classique c'est bien pour j'imagine une bonne majorité de cas

A quel niveau doit-on situer "beaucoup d'enregistrements" ? Je me pose la question pour PlacMag car je pense que des utilisateurs arriveront rapidement à des bases de 500 à 1000 articles.

1000 selon mois c'est gérable et courant.

Merci. Alors pour l'instant je laisse ça comme ça. Concernant PlacMag, j'ai quand même trouvé pas mal de possiblités, ou plutôt de corrections ( ) à apporter pour optimiser le code. Je suis en train de les faire. Je pense quand même que ce sera plus rapide qu'avant

Une question qui me trotte dans la tête :

Quand on a déjà ouvert une table avec un openrecorset, il n'y a pas d'autre solution que de refaire un nouveau openrecordset sur le même objet si on veut changer la requête ?

Je n'ai pas trouvé d'autres solutions que celle dont tu parles