PowerBuilder à Donf ! / Datastore ou SQLbrut de pomme ?

GrowGeorges · 03-01-2013 08:23:18

Salut les coupains !

J'ai une interrogation, voilà j'ai découvert depuis peu les datastore ... yahou !
Mais l'utilisation que j'en fait n'est peut être pas des plus pertinente :

Dans mes fenetres lorsque j'ai des mises a jour a faire sur de grosses tables (genre 80colonnes) et que j'utilise pas de datawindow
pour les afficher, j'instancie un datastore au runtime avec une requete type : "Select * from BigTable where 0=1" pour etre peinard et faire
un insertrow et mettre les champs que je veux et laisser les autres s'initialiser a leur valeur par défaut.

Ca marche bien, mais est-ce que c'est correct ?
J'était partit là dessus pour éviter la syntaxe sql du update qui pour moi est source d'erreurs lorsque je dépasse la 20aine de colonnes

rincevent · 03-01-2013 08:38:37

Intéréssant comme technique mais tu fais comment pour ajouter tes colonnes à mettre à jour dans ta datastore ?(c'est la partie "Select * from BigTable where 0=1" qui me fait m'interroger)

Sinon LE gros point fort de PB c'est la DataWindow/Datastore et ses possibilité de génération automatique de SQL donc à priori je dirai que c'est une bonne utilisation du point fort de PB.

GrowGeorges · 03-01-2013 08:42:51

Bah du coup ça me génére une datastore vide mais avec toutes les colonnes de la table,
après jai plus qu'à faire

mydatastore.insertrow(1)

mydatastore.object.colonne1[1]=toto
mydatastore.object.colonne2[1]=titi

mydatastore.update()

Bon j'fais pas n'importe quoi alors ? :O

rincevent · 03-01-2013 09:00:41

au temps pour moi la pièce est tombé, BigTable c'est bien sûr le nom de ta table tout simplement...

j'avais pensé que c'était un mot-clé particulier de ton SGBD genre "dual" pour Oracle qui est une table bidon à utiliser quand tu veux avoir la date du QSGBD par exemple tu fais 'Select today() from dual' et donc je me disais OK il génère d'abord un DW object "bidon" et après il ajoute ses colonnes...

bon j'crois que j'ai encore besoin d'un café ce matin

GrowGeorges · 03-01-2013 09:05:04

Woups, j'aurais pu être plus explicite

J'avais juste besoin d'une confirmation comme quoi c'était pas une hérésie en pb de faire ça, bon bah j'ai plus qu'à
me lancer à corps perdu dans mon code en conservant cette méthode ^^

Yanis · 03-01-2013 09:59:00

Salut,

Le where 0= 1 est inutile sur ton datastore. Si tu n'effectue pas de retrieve ( exemple lds_client.retrieve() ) tu n'as pas de soucis. Tu peut insérer directement tes nouvelles lignes. Pour info il est très performant d'utiliser des datastores plutot que des datawindows invisible.

Cdt
Yanis

GrowGeorges · 03-01-2013 10:04:39

Ha oui exact, le where est useless, je vais enlever ça, ça ajoutera de la clarté au code.

"il est très performant d'utiliser des datastores plutot que des datawindows invisible."
Oui mais là, je l'instancie au runtime mon datastore (avec un create datastore), ça demande ptetre plus de ressource, et ça ralentit ptetre plus le systeme
que si j'avais fait une requete sql update en plusieurs paragraphes ?
Des infos là dessus ?

elfeliz · 03-01-2013 10:11:03

Bonjour,
Un senior m'a un jour dit que les datawindows invisibles étaient plus performantes que les datastores...
Ajoutant que les datawindows étant le plus important argument "technico-commercial" de PB, elles avaient été plus particulièrement optimisées : ceci expliquant cela.

Bien sur, ça m'a toujours laissé rêveur
D'autant que j'ai lu ici ou là (càd je ne sais plus où...) que les datastores n'étaient que des datawindows dont la propriété visible étant forcée à false.

On dit et lit beaucoup de choses...

J'ai déjà maintenu quelques applications (pas si anciennes : début 2000... ) où les datastores n'étaient pas utilisées : on leur préféraient systématiquement les datawindows cachées.
Vu l'expertise constatée sur d'autres points de ces applications, j'ai peine à croire que ce soit par erreur...

Qu'en pensez-vous ?

A bientôt !

ElFeliz

rincevent · 03-01-2013 10:18:21

Ce que je ne suis pas encore sûr de comprendre ( need 3eme café ? ) c'est que tu parles souvent de faire des Updates mais tu explique que tu ne retrieve pas tes données dans ta DS.

Concernant les perfs la première question à se poser c'est est-il pertinent de s'occuper des perfs dans le cas présent ?

La création d'une DS ne prends pas spécialement longtemps, à mon avis l'opération la plus longue ici sera quand même toujours la mise à jour au niveau SGBD qui durera le même temps que le SQL soit envoyé d'une DS ou bien envoyé par toi.

à mon avis ici tu ne devrais pas te préoccuper des quelques micro secondes que ça va prendre de créer une DS

Il y a tjrs des cas particuliers bien sûr mais en général moi j'optimise ~~très peu~~ pas du tout mon code dans le sens des performances, je préfère optmiser la lisibilité du code ce qui facilite aussi la maintenance.

Je n'optimise que quand c'est vraiment nécessaire c'est à dire des traitements lourds ET répétitifs.

tout ceci dans le cadre d'un ERP client lourd, si on parle d'embarqué temps réel je n'aurai évidemment pas le même discours.

rincevent · 03-01-2013 10:21:58

elfeliz a écrit:
J'ai déjà maintenu quelques applications (pas si anciennes : début 2000... ) où les datastores n'étaient pas utilisées : on leur préféraient systématiquement les datawindows cachées.
Vu l'expertise constatée sur d'autres points de ces applications, j'ai peine à croire que ce soit par erreur...

C'est peut être pas pour une question de performance.

Une DataStore étant de base un objet non visuel il ne déclenche jamais qqchose de visuel comme une DW

ex :
Retrieve() une DW avec un retrieval argument non spécifé : apparition de la fenêtre "specify retr. arg. alors qu'avec une DS il n'apparait pas.

GrowGeorges · 03-01-2013 10:38:53

Je n'utilise pas de retrieve() pour mes datastore dans ce cas de figure car je ne veux pas récupérer de données de ma table mais bien
insérer une nouvelle ligne.

Niveau lisibilité du code, c'est top par rapport à la requete je trouve.

xlat · 03-01-2013 11:01:53

Yanis a écrit:
Salut,

Le where 0= 1 est inutile sur ton datastore. Si tu n'effectue pas de retrieve ( exemple lds_client.retrieve() ) tu n'as pas de soucis. Tu peut insérer directement tes nouvelles lignes. Pour info il est très performant d'utiliser des datastores plutot que des datawindows invisible.

Cdt
Yanis

il me semblait que lors de l'appel à "transaction.SyntaxFromSQL" PB exécute bien cette requête et qu'avoir une clause "where 0=1" permettait de gratter en performance, il faudrait que je teste çà un de ces jours.

Yanis · 03-01-2013 11:30:42

Salut,
Ce que je peux affirmer c'est que le datastore est plus performant que la datawindow invisble.

elfeliz a écrit:
Un senior m'a un jour dit que les datawindows invisibles étaient plus performantes que les datastores...
Ajoutant que les datawindows étant le plus important argument "technico-commercial" de PB, elles avaient été plus particulièrement optimisées : ceci expliquant cela.

Oui la datawindow est l'objet le plus important de PB , mais le datastore c'est la datawindow sans l'aspect visuel donc il ne peut être que plus rapide que la datawindow.
Tu n'as pas le traitement des evt visuel comme le clicked , le doubleclicked etc... tu n'as pas le traitement des fonts de l'autosize éventuel ETC... et la liste est longue.
Et ce n'est pas une propriété visible à false qui a été mise. le datastore n'a pas les mêmes propriétés , evt ou fonctions que la datawindow. ( Il s'agit d'un objet à part entière )

Mais si les datawindows cachés sont utilisées c'est souvent parce que les développeurs ne savent pas exactement ce qu'ils ont comme données et donc ils les rendent visible pendant le développement et les rendent invisibles une fois le devt terminés. Moi je préfère travailler avec un datastore directement dans mon développement et si j'ai besoin de voir les données de mon datastore je met un control datawindow sur ma fenêtre et je fais un sharedata de mon datastore comme celà quand je supprime la datawindow de ma fenêtre mon code continue à utiliser le datastore ( je supprime bien sur le sharedata).

Pour ce qui concerne l'utilisation de sql embeded ou de l'utilisation d'un datastore lequel est le plus rapide j'ai un peu de mal à répondre. Ce que je dirais c'est que si tu n'effectues que quelques update ou insert tu seras plus rapide en sql embeded, si tu commences à effectuer une boucle sur beaucoup d'enregistrement ou tu dois préparer tout ton sql pour moi c'est le datastore qui gagne ( PB n'est pas très performant sur les boucles : for... Next etc.. )

Cdt
Yanis

buck · 03-01-2013 12:20:56

Bonjour,

Instinctivement, j'aurais donné la même réponse que toi du fait de l'absence de traitement visuel sur la datastore.

En réalisant le test suivant sous PB 11.5 (http://www.softtreetech.com/hightech/ds_vs_dw.htm) avec 10000 lignes :

Test1 : 4.945
Test2 : 4.54
Test3 : 4.462
Test4 : 0.14
Test5 : 0.187

La datawindow avec un SetRedraw(FALSE) donne un résultat légèrement meilleur que la datastore !!

rincevent · 03-01-2013 12:32:22

Yanis a écrit:
Salut,
Ce que je peux affirmer c'est que le datastore est plus performant que la datawindow invisble.

Et ce n'est pas une propriété visible à false qui a été mise. le datastore n'a pas les mêmes propriétés , evt ou fonctions que la datawindow. ( Il s'agit d'un objet à part entière )

Je pensais comme toi et ça paraitrait logique mais d'après ce lien ce n'est pas le cas, les Datastores seraient donc réellement des DW "bridées" au niveau visuel

L'article date un peu et ça parle des versions 5 et 6 de PB je dirais mais bon, y a des chances que Sybase n'ait pas subitement tout refait dans les versions suivantes.

seki · 03-01-2013 13:22:28

rincevent a écrit:
en général moi j'optimise ~~très peu~~ pas du tout mon code dans le sens des performances, je préfère optmiser la lisibilité du code ce qui facilite aussi la maintenance.

Tu as raison, un code clair vaut souvent mieux qu'un traitement tordu qui peut ne plus fonctionner de la même manière en cas d'évolution du langage (optimisation native, corrections de bugs...)

En matière d'optimisation :
- règle n°1 : n'essaie pas d'optimiser
- règle n°2 (pour les experts) : n'essaie pas d'optimiser pour le moment

rincevent a écrit:
la pièce est tombé

C'est du belge ? Ça veut dire quoi ?

rincevent a écrit:
y a des chances que Sybase n'ait pas subitement tout refait dans les versions suivantes.

C'est un euphémisme...

Dernière modification par seki (03-01-2013 13:24:17)

seki · 03-01-2013 13:32:49

Yanis a écrit:
Moi je préfère travailler avec un datastore directement dans mon développement et si j'ai besoin de voir les données de mon datastore je met un control datawindow sur ma fenêtre et je fais un sharedata de mon datastore comme celà quand je supprime la datawindow de ma fenêtre mon code continue à utiliser le datastore ( je supprime bien sur le sharedata).

<pub_inside>
Oui si tu n'as pas envie de t'embêter, tu utilises la Datawindow Debug machine, il suffit de wrapper l'ouverture de la debug machine par exemple dans une fonction globale de ton application, qui serait appelée simplement par un bouton que tu rajoutes sur la fenêtre. Pas la peine d'ajouter de contrôle dw et de sharedata(), l'ouverture de la debug machine se charge de tout...
</pub_inside>

rincevent · 03-01-2013 15:15:55

seki a écrit:
rincevent a écrit:
la pièce est tombé
C'est du belge ? Ça veut dire quoi ?

Oui, analogie avec un distributeur de boissons par exemple, dans lequel tu mets ta pièce, qui ne glisse pas dans le monnayeur et donc la machine te file pas ta boisson.
Après un ou deux coup de lattes dans la machine la pièce tombe et tu obtiens ta boisson.

La pièce est tombée, la machine a fonctionné
La pièce est tombée, mon cerveau viens de se mettre en route...

Sinon pour les Datastore une petite astuce facile à expliquer mais qui peut faire gagner un temps incroyable :

Vous êtes en debug et vous voudriez voir le contenu de votre datastore ? rien de plus facile, ajoutez comme nouveau "watch" dans le debuggeur ceci :

nom_de_ma_ds.SaveAs( filename, saveastype, colheading ) en remplacant évidemment les arguments du SaveAs

et hop ! vous voici avec une copie des données de votre DS dans un fichier sur votre disque.

P.S. je pense que ça marche aussi si on ne donne aucun des arguments, dans ce cas on a carrément une fenêtre SaveAs qui s'ouvre. Pour une DW c'est sûr, pour les DS y faudrait vérifier, normalement on devrait pas avoir la fenêtre de dialogue mais en fait je crois qu'on l'a quand même (ce qui est bien pratique finalement)

Yanis · 03-01-2013 15:26:11

Salut,

Merci pour l'info il a l'air très interessant cet outil. Mais perso j'ai mon propre outil au travers de mon framework pour afficher la contenu de mes datastores ainsi que l'affichage des statuts de colonnes et de lignes ( repris depuis l'outil de debug des PFC ).
Mais j'irais quand même regardé ces possibilités.

Cdt
Yanis

seki · 03-01-2013 16:04:12

rincevent a écrit:
Sinon pour les Datastore une petite astuce facile à expliquer mais qui peut faire gagner un temps incroyable :

Vous êtes en debug et vous voudriez voir le contenu de votre datastore ? rien de plus facile, ajoutez comme nouveau "watch" dans le debuggeur ceci :

nom_de_ma_ds.SaveAs( filename, saveastype, colheading ) en remplacant évidemment les arguments du SaveAs

et hop ! vous voici avec une copie des données de votre DS dans un fichier sur votre disque.

Oui, j'utilise très souvent ce truc :

Code: pb

ds.saveas("c:\test.xls", excel5!, true)

qui m'a souvent permis permis de débusquer des bugs de tri et / ou de filtre dans des datastores.

GrowGeorges · 07-01-2013 09:59:55

Encore une interrogation : parfois mon datastore ne s'update pas (et cest pour ça que j'hésite a juste faire du sql ^^ ) ... mais sans fournir aucun message d'erreur, il faut que moi meme je créée un messagebox sur le 'mydatastore.update()' pour
constater qu'il renvoie -1.
Et même en sachant cela, je ne vois pas d'où peut venir le problème, la clée que je fournis pour cette entrée dans ma table sql est unique, je suis dubitatif

seki · 07-01-2013 10:42:47

Après l'update qui retourne -1, regarde la valeur de sqlca.SQLErrText (si l'objet transaction de to datastore est bien sqlca, sinon il faut adapter) qui pourrait bien t'indiquer la nature du problème.
Tu peux aussi regarder sqlca.SQLDBCode si tu connais bien les codes d'erreur de ton moteur SQL.

GrowGeorges · 07-01-2013 11:01:30

J'ai fait quelques tests,

En ce qui concerne le sqlca, avant toute opération sur mon datastore je fais mon settransobject(sqlca) et suite au -1 de l'update le sqlca.sqlerrtext est vide et le sqlca.sqlbdcode me retourne 0,
par ailleurs en furetant sur le net, j'ai trouvé un post qui ressemble un peu a ce que je rencontre et sur lequel tu as sévi seki ! (sévi seki ? :O)

http://stackoverflow.com/questions/1228 … qldbcode-0

A ceci prêt que ma requete ne concerne qu'une seule table sql.

De plus, en investiguant du coté de ma base de donnée sql, et en bidouillant grassement voici ce que j'ai observé :

mydatastore.update() me renvoie 1 et fonctionne si :

je donne une valeur à toutes les colonnes qui sont concernées par tout les index de la table incriminée
je donne une valeur à toutes les colonnes pour lesquelles le null est interdit (et qui pourtant ont une valeur d'initialisation)

seki · 07-01-2013 12:12:23

GrowGeorges a écrit:
J'ai fait quelques tests,

En ce qui concerne le sqlca, avant toute opération sur mon datastore je fais mon settransobject(sqlca) et suite au -1 de l'update le sqlca.sqlerrtext est vide et le sqlca.sqlbdcode me retourne 0,
par ailleurs en furetant sur le net, j'ai trouvé un post qui ressemble un peu a ce que je rencontre et sur lequel tu as sévi seki ! (sévi seki ? :O)

http://stackoverflow.com/questions/1228 … qldbcode-0

A ceci prêt que ma requete ne concerne qu'une seule table sql.

Les questions que je pose sur SO sont valables ici : si update retourne -1 c'est qu'il ne fonctionne pas, et si SqlDBCode/SQLErrText n'indique rien, il est possible qu'un commit/rollback ait fait disparaître le message d'erreur de la base

GrowGeorges a écrit:
De plus, en investiguant du coté de ma base de donnée sql, et en bidouillant grassement voici ce que j'ai observé :

mydatastore.update() me renvoie 1 et fonctionne si :

je donne une valeur à toutes les colonnes qui sont concernées par tout les index de la table incriminée
je donne une valeur à toutes les colonnes pour lesquelles le null est interdit (et qui pourtant ont une valeur d'initialisation)

Une valeur pour toutes les colonnes des index, je ne vois pas trop pourquoi ce serait obligatoire (sauf évidemment pour l’index correspondant à la clé primaire), par contre pour les éventuelles contraintes d'intégrité et les "not null" c'est normal : quand tu parles de valeur d'initialisation, tu parles d'un "default" dans la base, ou d'une valeur initiale dans le datastore ?

GrowGeorges · 07-01-2013 12:29:19

seki a écrit:
Les questions que je pose sur SO sont valables ici : si update retourne -1 c'est qu'il ne fonctionne pas, et si SqlDBCode/SQLErrText n'indique rien, il est possible qu'un commit/rollback ait fait disparaître le message d'erreur de la base

J'appelle sqlerrtext et sqldbcode juste après l'update de mon datastore.

seki a écrit:
quand tu parles de valeur d'initialisation, tu parles d'un "default" dans la base, ou d'une valeur initiale dans le datastore ?

Je parle du champ 'valeur ou liaison par défaut' sous sqlserver. ;)

Après windows pour les nuls, voici PB pour les bons (ou presque).

Annonce

#1 03-01-2013 08:23:18

Datastore ou SQLbrut de pomme ?

#2 03-01-2013 08:38:37

Re: Datastore ou SQLbrut de pomme ?

#3 03-01-2013 08:42:51

Re: Datastore ou SQLbrut de pomme ?

#4 03-01-2013 09:00:41

Re: Datastore ou SQLbrut de pomme ?

#5 03-01-2013 09:05:04

Re: Datastore ou SQLbrut de pomme ?

#6 03-01-2013 09:59:00

Re: Datastore ou SQLbrut de pomme ?

#7 03-01-2013 10:04:39

Re: Datastore ou SQLbrut de pomme ?

#8 03-01-2013 10:11:03

Re: Datastore ou SQLbrut de pomme ?

#9 03-01-2013 10:18:21

Re: Datastore ou SQLbrut de pomme ?

#10 03-01-2013 10:21:58

Re: Datastore ou SQLbrut de pomme ?

elfeliz a écrit:

#11 03-01-2013 10:38:53

Re: Datastore ou SQLbrut de pomme ?

#12 03-01-2013 11:01:53

Re: Datastore ou SQLbrut de pomme ?

Yanis a écrit:

#13 03-01-2013 11:30:42

Re: Datastore ou SQLbrut de pomme ?

elfeliz a écrit:

#14 03-01-2013 12:20:56

Re: Datastore ou SQLbrut de pomme ?

#15 03-01-2013 12:32:22

Re: Datastore ou SQLbrut de pomme ?

Yanis a écrit:

#16 03-01-2013 13:22:28

Re: Datastore ou SQLbrut de pomme ?

rincevent a écrit:

rincevent a écrit:

rincevent a écrit:

#17 03-01-2013 13:32:49

Re: Datastore ou SQLbrut de pomme ?

Yanis a écrit:

#18 03-01-2013 15:15:55

Re: Datastore ou SQLbrut de pomme ?

seki a écrit:

rincevent a écrit:

#19 03-01-2013 15:26:11

Re: Datastore ou SQLbrut de pomme ?

#20 03-01-2013 16:04:12

Re: Datastore ou SQLbrut de pomme ?

rincevent a écrit:

Code: pb

#21 07-01-2013 09:59:55

Re: Datastore ou SQLbrut de pomme ?

#22 07-01-2013 10:42:47

Re: Datastore ou SQLbrut de pomme ?

#23 07-01-2013 11:01:30

Re: Datastore ou SQLbrut de pomme ?

#24 07-01-2013 12:12:23

Re: Datastore ou SQLbrut de pomme ?

GrowGeorges a écrit:

GrowGeorges a écrit:

#25 07-01-2013 12:29:19

Re: Datastore ou SQLbrut de pomme ?

seki a écrit:

seki a écrit:

Pied de page des forums