Discussion :

[Dolphy35]

Bonjour,

Je travail avec WinDev depuis 3 mois. Je dois retranscrire un fichier Excel en application WinDev.

Etant plus habitué à Access, je me pose une question de conception par rapport à WinDev :

J'ai plusieurs tableaux qui contiennent des valeurs calculées par différentes fonctions. Le soucis est que je dois stocker ces données afin d'en extraire des informations pour d'autres calcul. J'aimerai avoir votre retour d'expérience à savoir comment stocker ces données.

les tableaux possèdent 7 colonnes par ~70 lignes qui peuvent ou non avoir des données. j'ai 7 typologies qui ont 5 tableaux chacun ce qui donnent 35 tableaux d'une même structure.

Solution 1 : créer 35 champs tables dans la fenêtres, juste pour le traitement, sans affichage. Je ne sais pas si au niveau ressources ceci va alourdir le fonctionnement.

Solution 2 : Fichier ini, le niveau de hiérarchisation étant très faible, cela me bloque un peu. Je ne connais pas les fonctions permettant de travailler sur des fichiers ini, comptage d'éléments d'un même groupe.

Solution 3 : Fichier XML, le niveau de hiérarchisation étant illimité, ceci conviendrait, mais là aussi je ne connais les fonctions permettant de traiter les XML. de ce que j'ai vu, il y a quelques fonctions intéressantes.

Solution 4 : Fichier de données FIC en rajoutant des colonnes pour hiérarchiser les données. Ce mode me plait car je peux récupérer plus d'informations par SQL, comme le max, le min car sur les autres solutions cela oblige à plus de traitement, je pense.

pour la solution 4, j'aimerais que ce fichier ne soit pas dans l'analyse et que je le créer à la volée.

merci pour retour et vos retour d'expériences.

Dolphy

[Dolphy35]

re,

au lieu de créer 35 tableaux je pense créer 1 tableau structuré comme l'aurait été le fichier de données.

par contre est-il possible de réaliser des extractions de données par SQL dans une table ?
je regarde du côté de TableCherche()

@+ Dolphy

[laurent30s]

Pour créer un fichier à la volée regarde les fonctions HDécritFichier(), HDécritRubrique() et HCréation() (il existe même HDécritLiaison())

http://doc.pcsoft.fr/fr-FR/?hdecritrubrique_exemple

[hpascal]

Bonjour

On peut aussi créer des fichiers HF par CREATE TABLE, mais je crois (à vérifier) que c'est possible à partir de la version 18 seulement

Autre possibilité : si tu préfères faire du SQL, tu peux utiliser SQLite qui est géré par Windev sans aucune installation supplémentaire

Un exemple simple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
cnxTest est une Connexion
sdReq est une Source de Données
sTxtReq est une chaîne
 
cnxTest..Provider = hAccèsNatifSQLite
cnxTest..Serveur = fRepExe() + ["\"] + "mabase.db"
 
SI HOuvreConnexion(cnxTest) ALORS
	sTxtReq = [
	CREATE TABLE MaTable (
	  IdMaTable int NOT Null UNIQUE ,
	  ColTest VARCHAR(30) NOT Null default('')
	)
	]
	SI HExécuteRequêteSQL(sdReq, cnxTest, hRequêteSansCorrection, sTxtReq) ALORS
		Info("table créée")
	SINON
		Erreur(HErreurInfo())
	FIN
	HAnnuleDéclaration(sdReq)
SINON
	Erreur(HErreurInfo())
FIN
HFermeConnexion(cnxTest)

Et bien sur on n'a pas besoin d'analyse pour faire ça

A noter : si la base n'existe pas elle est créée à l'ouverture de la connexion

[DelphiManiac]

Dans tes propositions tu mélanges des solutions éphémères (table dans des fenêtres, solution 1) et des solutions ou tu stockes les informations (solutions 2, 3, 4)

Si c'est pour stocker temporairement en mémoire je préconiserais des tableaux d'objets, si c'est pour persister l'information, la solution 4 me paraît la plus appropriée.

Difficile de fournir plus de réponses, ne sachant si l'information doit être persisté et quel type d'accès tu dois faire a cette information, parcours séquentiel, accès par une clé, principalement de la lecture ou de l'écriture, si le critère de performance est a prendre en considération, enfin plein de questions ^^

[Dolphy35]

Hello,

Pour créer un fichier à la volée regarde les fonctions HDécritFichier(), HDécritRubrique() et HCréation() (il existe même HDécritLiaison())

http://doc.pcsoft.fr/fr-FR/?hdecritrubrique_exemple

Merci pour le lien, j'avais survoler mais en regardant en détail. J'arrive à créer un Fichier et le remplir.

Bonjour

On peut aussi créer des fichiers HF par CREATE TABLE, mais je crois (à vérifier) que c'est possible à partir de la version 18 seulement

Autre possibilité : si tu préfères faire du SQL, tu peux utiliser SQLite qui est géré par Windev sans aucune installation supplémentaire

Un exemple simple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
cnxTest est une Connexion
sdReq est une Source de Données
sTxtReq est une chaîne
 
cnxTest..Provider = hAccèsNatifSQLite
cnxTest..Serveur = fRepExe() + ["\"] + "mabase.db"
 
SI HOuvreConnexion(cnxTest) ALORS
	sTxtReq = [
	CREATE TABLE MaTable (
	  IdMaTable int NOT Null UNIQUE ,
	  ColTest VARCHAR(30) NOT Null default('')
	)
	]
	SI HExécuteRequêteSQL(sdReq, cnxTest, hRequêteSansCorrection, sTxtReq) ALORS
		Info("table créée")
	SINON
		Erreur(HErreurInfo())
	FIN
	HAnnuleDéclaration(sdReq)
SINON
	Erreur(HErreurInfo())
FIN
HFermeConnexion(cnxTest)

Et bien sur on n'a pas besoin d'analyse pour faire ça

A noter : si la base n'existe pas elle est créée à l'ouverture de la connexion

en fait le côté SQL m'intéresse pour en extraire les données avec les fonction intégrées tel que Min et Max avec une clause. Je vais étudier cette proposition.

Dans tes propositions tu mélanges des solutions éphémères (table dans des fenêtres, solution 1) et des solutions ou tu stockes les informations (solutions 2, 3, 4)

Si c'est pour stocker temporairement en mémoire je préconiserais des tableaux d'objets, si c'est pour persister l'information, la solution 4 me paraît la plus appropriée.

Difficile de fournir plus de réponses, ne sachant si l'information doit être persisté et quel type d'accès tu dois faire a cette information, parcours séquentiel, accès par une clé, principalement de la lecture ou de l'écriture, si le critère de performance est a prendre en considération, enfin plein de questions ^^

merci de t'intéresser à mon cas . En fait les données à stocker ne servent que pour le calcul. Il y a tellement de paramètre d'entrée et de calcul intermédiaire que j'ai déjà plusieurs variables tableaux, champs table et des matrices. Le fait de rajouter encore des tableaux m'amène la réflexion de la lourdeur de traitement. Cette application est pour une diffusion cliente et donc je n'ai pas la maîtrise des PCs hôtes. D'où ma réflexion.
De plus je dois récupérer les informations en fonctions de 3 critères, qui me donnent environ une dizaine d'enregistrements. sur ces enregistrements je dois récupérer en fonction de mon besoin la valeur Min, Max et Max Absolue.

@++ Dolphy

[DelphiManiac]

Vu que ces sont des données temporaires qui ne servent que pour le calcul, et que de plus, tu as un volume limité de données et que tu ne cherche qu'a en récupérer le min et le max, je ne passerais pas par des fichiers. Le code SQL sera toujours plus lent que de maintenir les données en mémoire dans des tableaux d'objets.

Passer par des requêtes SQL pour extraire le min et le max de 10 enregistrements me fait penser à sortir un bazooka pour tuer un moustique

Tu créé une première classe qui stocke l'information élémentaire : Libellé, valeur par exemple.

Tu créé une deuxième classe qui stocke un tableau de valeurs élémentaires, dans cette deuxième classe, tu déclares une méthode "ajouter"qui permette de maintenir le min et le max des valeurs ajoutées sans devoir parcourir le tableau.

Exemple (vraiment fait à l'arrache)

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
CValeur est une Classe
	Libelle est une chaîne
	Valeur est un entier
FIN
 
PROCEDURE Constructeur()
 
 
PROCEDURE Destructeur()

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
CListeValeur est une Classe
	listeValeur est un tableau dynamique de CValeur
 
	// A toi ici de bien initialiser les bornes minimales et maximales
	valeurMin est un entier = 9999999999
	valeurMax est un entier = 0
FIN
 
PROCEDURE Constructeur()
 
 
PROCEDURE Destructeur()
 
 
 
PROCEDURE ajouter(libelle est une chaîne, valeur est un entier)
uneValeur est un CValeur dynamique <- allouer un CValeur
uneValeur.Libelle = libelle
uneValeur.Valeur = valeur
TableauAjoute(listeValeur, uneValeur)
 
SI valeur < valeurMin ALORS
	valeurMin = valeur
FIN
SI valeur > valeurMax ALORS
	valeurMax = valeur
FIN

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
// Code de test
uneListeDeValeur est une CListeValeur dynamique <- allouer un CListeValeur
uneListeDeValeur.ajouter("test 02", 999)
uneListeDeValeur.ajouter("test 01", 12)
uneListeDeValeur.ajouter("test 03", 45)
 
Trace("Valeur min = " + uneListeDeValeur.valeurMin)
Trace("Valeur max = " + uneListeDeValeur.valeurMax)
 
Trace("-------")
Trace("Parcours des éléments du tableau.")
POUR TOUT uneValeur DE uneListeDeValeur.listeValeur
	Trace(uneValeur.Libelle, uneValeur.Valeur)
FIN

Le résultat de l’exécution :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
Valeur min = 12
Valeur max = 999
-------
Parcours des éléments du tableau.
test 02 999
test 01 12
test 03 45

[Unkof]

+1 DelphiManiac.

Y a rien de plus rapide que le travail en ram direct, surtout quand t'as pas les données dans une table, je ne vois vraiment pas l'intérêt de tout sortir du ou des fichiers Excel, mettre en table, et après faire le boulot. Autant lire les données du/des fichiers, et bosser en ram directement via tableau, pourquoi passer par une table ?

La seule chose, j'aurai même pas fait des classes pour ca (ca revient un peu au bazooka .. ^^) .. j'aurai juste fait une procédure.

[Dolphy35]

+1 DelphiManiac.

Y a rien de plus rapide que le travail en ram direct, surtout quand t'as pas les données dans une table, je ne vois vraiment pas l'intérêt de tout sortir du ou des fichiers Excel, mettre en table, et après faire le boulot. Autant lire les données du/des fichiers, et bosser en ram directement via tableau, pourquoi passer par une table ?

La seule chose, j'aurai même pas fait des classes pour ca (ca revient un peu au bazooka .. ^^) .. j'aurai juste fait une procédure.

Tout dépend des logiciels que tu utilise. je n'ai pas de retour avec WinDev (trop récent) mais dans certain cas il est plus facile de stocker les données afin de les extraire au lieu de stocker dans la mémoire et d'alourdir les traitements. J'ai remarqué que les développeurs WinDev aimait bien globaliser les variables et stocker en mémoire. N'ayant pas d'expérience avec WinDev je n'ai pas l'habitude de fonctionner de tel sorte. Ensuite je n'ai pas la maitrise des PCs où seront installé l'application, si le PCs est une vieille charrette, je ne veux pas que le client est un traitement de 5 min.

@DelphiManiac : je vais regarder ta proposition et te donne retour.

Merci

@++ Dolphy

[Unkof]

Moi perso je ne viens pas de l'univers WinDev. Je l'utilise, mais plus ca va, et moins je l'utilise, mais le sujet n'est pas là.

Les PC depuis 7 ou 8 ans ont plusieurs gigas de ram, si t'as 35 tables avec 490 valeurs (tu as dit en gros 7 colonnes sur 70 lignes), ca te fait un total d'environ 17150 valeurs, qui prennent .. allez, 8 octets chacune (on va dire..). On a donc un total de 137200 octets soit grosse modo 134Ko. Même dans l'hypothèse folle ou tes données prendraient allez, 80 Octets chacune, on serait à 1,34 Mo.

Pense-tu vraiment que 1,34 Mo de tableau puisse poser un problème à un pc aujourd'hui, ou même à un PC qui a 10 ans ?

L'optimisation pour la vitesse d'exécution passe toujours pas la ram, et l'optimisation de la ram passe toujours par le disque au détriment de la vitesse, charge à toi de voir quel est ton besoin. Si t'as besoin d'un truc optimisé au niveau RAM, n'utilises pas WinDev, quand tu vas voir la taille de ton exe, tu vas être surpris.

[DelphiManiac]

...J'ai remarqué que les développeurs WinDev aimait bien globaliser les variables et stocker en mémoire...

Juste une petite remarque que ce point, il n'y a vraiment aucun rapport entre utiliser à outrance des variables globales et travailler en mémoire

Je ne suis pas une développeur Windev, à la base, je m'y suis mis par la force des choses. Je développe par ailleurs en c# actuellement, et je t'aurais proposer la même solution en c#, tout comme je l'aurais fait en Delphi dans un passé assez lointain !!

Concernant les lenteurs sur des PC anciens, si tu as un doute sur les performances de ces PC, tu peux être assuré que le problème de performance est généralement lié à des disques très faiblards et ce quelque soit la configuration. Mets un SSD dans un PC de 5 ans et tu as l'impression d'avoir un PC tout neuf.

[Dolphy35]

Moi perso je ne viens pas de l'univers WinDev. Je l'utilise, mais plus ca va, et moins je l'utilise, mais le sujet n'est pas là.

Les PC depuis 7 ou 8 ans ont plusieurs gigas de ram, si t'as 35 tables avec 490 valeurs (tu as dit en gros 7 colonnes sur 70 lignes), ca te fait un total d'environ 17150 valeurs, qui prennent .. allez, 8 octets chacune (on va dire..). On a donc un total de 137200 octets soit grosse modo 134Ko. Même dans l'hypothèse folle ou tes données prendraient allez, 80 Octets chacune, on serait à 1,34 Mo.

Pense-tu vraiment que 1,34 Mo de tableau puisse poser un problème à un pc aujourd'hui, ou même à un PC qui a 10 ans ?

L'optimisation pour la vitesse d'exécution passe toujours pas la ram, et l'optimisation de la ram passe toujours par le disque au détriment de la vitesse, charge à toi de voir quel est ton besoin. Si t'as besoin d'un truc optimisé au niveau RAM, n'utilises pas WinDev, quand tu vas voir la taille de ton exe, tu vas être surpris.

Ceci est une discussion ouverte. J'en fait appel à vos expériences car je connais peu WinDev, certes présenté comme ceci, cela fait peu mais comme expliqué plus haut j'ai déjà plein de tableaux mémoires et des matrices. Ensuite l'application réalise beaucoup de calcul matriciel et autre calculs. Ensuite si ton expérience dit que cela peu le faire, ensuite ma question portait également sur les traitements de ces données, à savoir le plus simple à extraire pour mon besoin.

Juste une petite remarque que ce point, il n'y a vraiment aucun rapport entre utiliser à outrance des variables globales et travailler en mémoire

Je ne suis pas une développeur Windev, à la base, je m'y suis mis par la force des choses. Je développe par ailleurs en c# actuellement, et je t'aurais proposer la même solution en c#, tout comme je l'aurais fait en Delphi dans un passé assez lointain !!

Concernant les lenteurs sur des PC anciens, si tu as un doute sur les performances de ces PC, tu peux être assuré que le problème de performance est généralement lié à des disques très faiblards et ce quelque soit la configuration. Mets un SSD dans un PC de 5 ans et tu as l'impression d'avoir un PC tout neuf.

pour moi une variable globale est toujours stockée tant que l'application est ouverte donc utilise de la ressource.

Bon la Question part en débat d'utilisation ressource , vous m'avez convaincu que je peux utiliser les variables tableaux dans mon cas.
Ensuite il y avait le point d'extraire les données selon besoin.

Maintenant je vais tester ta proposition.



@++ Dolphy

[Unkof]

l'application réalise beaucoup de calcul matriciel et autre calculs.

Ben raison de plus pour bosser en ram si tu as des calculs plus ou moins lourds à effectuer derrière ...

Enfin, chacun fait comme il veut ..

[Dolphy35]

Ben raison de plus pour bosser en ram si tu as des calculs plus ou moins lourds à effectuer derrière ...

Enfin, chacun fait comme il veut ..

tout à fait.

J'effectuerais des tests une fois que j'aurai plus de temps entre calcul avec stockage RAM et Stockage Fichier afin de déterminer les ressources utilisées.


@ DelphiManiac : j'ai repris ton principe d'utilisation d'une classe. Merci pour l'orientation.

@+ Dolphy