PC SOFT

FORUMS PROFESSIONNELS
WINDEVWEBDEV et WINDEV Mobile

Accueil → WINDEV 25 → Natif postgresSql
Natif postgresSql
Débuté par Vincent, 18 sep. 2020 10:54 - 12 réponses
Membre enregistré
2 messages
Posté le 18 septembre 2020 - 10:54
Bonjour, j'ai 2 problèmes avec windev et le contrôleur natif postgres `

Problème N1 :
L'analyse n'arrive pas à prendre en compte mes relations, spécialement mes foreing key
Impossible de créer la relation "testclecomposee_fk" (Colonne source : "public.testclecomposee.col_pk1,col_pk2", Colonne reliée : "public.testclecomposee.col_akey1,col_akey2") dans l'analyse.
La rubrique "public.testclecomposee.col_pk1,col_pk2" n'existe pas dans l'analyse.
La rubrique "public.testclecomposee.col_akey1,col_akey2" n'existe pas dans l'analyse.


Problème N2 :
Mes types ne sont pas toujours les mêmes, par exemple un char 1 byte dans ma dll est reconnu par un texte 8 bytes dans mon analyse.
De même il ne reconnait pas les bon types quand j'utilise de datatype(ou domaines).

J'ai déjà essayer de changer les dll de postgres dans le repertoire exe et dans windows.

Merci beaucoup de votre aide
Membre enregistré
757 messages
Popularité : +3 (5 votes)
Posté le 18 septembre 2020 - 18:25
Bonjour
J’ai très vite abandonné l’ODBC ainsi que l'accès natif de PostgreSQL à cause de ce genre de problèmes.
J’utilise la dll libpq dans une classe compatible Windows et linux

--
«Nos clients sont nos meilleurs beta testeur.» H. Mintzberg
«Un programme informatique fait ce que vous lui avez dit de faire, pas ce que vous voulez qu'il fasse» Troisième loi de Greer
Membre enregistré
2 104 messages
Posté le 18 septembre 2020 - 21:02
Tout n'est pas noir ou blanc. L'accès natif permet de faire certaines choses plutôt rapidement. Personnellement j'ai importé la définition de la base dans l'analyse et j'ai eu la désagréable surprise de voir tous mes numeric transformés en réel, donc je me suis retapé le tout à al main.

J'aurais bien utilisé la libpq, mais le transfert des données dans les tableaux de classe est plus que fastidieux et long.

--
Cordialement,

Philippe SAINT-BERTIN
Membre enregistré
757 messages
Popularité : +3 (5 votes)
Posté le 22 septembre 2020 - 17:10
Bonjour
pouriez-vous developper : " le transfert des données dans les tableaux de classe est plus que fastidieux et long."
'long' en terme de rapidité d'exécution ?

--
«Nos clients sont nos meilleurs beta testeur.» H. Mintzberg
«Un programme informatique fait ce que vous lui avez dit de faire, pas ce que vous voulez qu'il fasse» Troisième loi de Greer
Membre enregistré
2 104 messages
Posté le 22 septembre 2020 - 20:47
Oui en terme de temps de traitement ou alors je m'y prends mal, ce qui est possible...

--
Cordialement,

Philippe SAINT-BERTIN
Membre enregistré
757 messages
Popularité : +3 (5 votes)
Posté le 23 septembre 2020 - 18:11
Bonjour
@ Philippe SB
En utilisant l’API libpq.dll, l'enregistrement d'une photo de 240 ko octets prend 5.02 secondes
Connexion internet qui plafonne lamentablement à 931 Kb/s en upload… ;(
Le serveur situé en Allemagne est sous Ubuntu 18.04.5 LTS avec PostgreSQL 11.9
Le PC de test est sous Windows 10 pro avec Windev24
Pour les requêtes « standard » j’avais à l’époque testé que c’était plus rapide que l’ODBC qui en plus n’acceptait pas les champs binaires > 32 ko.
Quant à l’accès natif les conversions de type n’étaient pas franchement au point.
Le seul problème que j’ai c’est dans le cas des applications Windows quand je change de version pour la dll je dois modifier l’ordre de chargement des dll. Heureusement j’ai l’utilitaire Dependency Walker pour me simplifier le travail.
Dans le cas des sites Web hébergés sur le serveur Linux c'est du local donc très rapide.

--
«Nos clients sont nos meilleurs beta testeur.» H. Mintzberg
«Un programme informatique fait ce que vous lui avez dit de faire, pas ce que vous voulez qu'il fasse» Troisième loi de Greer
Membre enregistré
2 104 messages
Posté le 24 septembre 2020 - 07:51
Perso les temps de réponse pour les requêtes me vont. Ce n'est pas très différent d'une exécution sur un utilitaire quelconque. Je précise que j'utilise principalement hrequetesanscorrection, sauf pour des requêtes simples type:
select * from table where id = parametre


Par contre le FichierVersTableau sur un tableau de classe est particulièrement lent (c'est pareil en faisant un parcours classique, j'ai essayé). aux alentours de 3 secondes pour 10 000 enregistrements quand il faut à peu près quelques centaines de millisecondes à c# pour le faire. Je prends volontairement C# car il est basé sur un Framework tout comme Windev.

Il serait temps que PC Soft se mette à travailler sur des améliorations qui vont dans ce sens à savoir l'optimisation !!!

Pour libpq.dll, j'avais fait des tests mais au final le remplissage d'un tableau est fastidieux donc pour afficher une liste de plusieurs milliers d'enregistrements c'est extrêmement long car il faut également composer avec le framework de windev. Par contre rien à dire quant à la rapidité d'exécution de requête est de récupération des tuples.

Il est aujourd'hui difficile de choisir une technologie d'accès aux données plutôt qu'une autre car le framework est toujours pénalisant.

--
Cordialement,

Philippe SAINT-BERTIN
Membre enregistré
757 messages
Popularité : +3 (5 votes)
Posté le 24 septembre 2020 - 19:23
Bonjour
@ Philippe SB
"Pour libpq.dll, j'avais fait des tests mais au final le remplissage d'un tableau est fastidieux donc pour afficher une liste de plusieurs milliers d'enregistrements c'est extrêmement long car il faut également composer avec le framework de windev. "

J'ai refait des tests avec une méthode «PGRequeteVersTableExtend» de ma classe, qui prend 2 paramétres :
1° le nom d'une table contenant juste une colonne cachée au nom fixe
2° une requête sql
Toujours avec mon super débit de 1Mbits en download l'affichage pour 1000 enregistrements pour la requête :

- SELECT Id, first_name, last_name -> en moyenne 0.70 et 0.17 s sur le serveur avec psql
- SELECT Id, first_name, last_name, first_name || last_name, upper(last1_name), lower(first_name), now() -> en moyenne 0.90 s et 0.27s sur le serveur avec psql

--
«Nos clients sont nos meilleurs beta testeur.» H. Mintzberg
«Un programme informatique fait ce que vous lui avez dit de faire, pas ce que vous voulez qu'il fasse» Troisième loi de Greer
Membre enregistré
2 104 messages
Posté le 25 septembre 2020 - 09:02
ok. Je suis curieux de savoir par quelle méthode tu passes pour faire des tests de mon côté en utilisant les même méthodes que toi.

Il y a moyen de discuter par mail pour échanger un peu sur le sujet ?

--
Cordialement,

Philippe SAINT-BERTIN
Membre enregistré
757 messages
Popularité : +3 (5 votes)
Posté le 25 septembre 2020 - 16:33
Bonjour
l y a moyen de discuter par mail pour échanger un peu sur le sujet ? pas de problème c'est pasquali(point)philippe(at)gmail.com

--
«Nos clients sont nos meilleurs beta testeur.» H. Mintzberg
«Un programme informatique fait ce que vous lui avez dit de faire, pas ce que vous voulez qu'il fasse» Troisième loi de Greer
Membre enregistré
249 messages
Posté le 04 octobre 2020 - 18:30
Nous aussi, on est intéressé par la discussion :(

--
———————————————————————————————————
Ce qui se conçoit bien se code clairement et se débogue facilement...

- Pastiche d’une citation de Nicolas Boileau -
Membre enregistré
757 messages
Popularité : +3 (5 votes)
Posté le 04 octobre 2020 - 20:25
bonsoir
pas de problème, vous avez mon adresse

--
«Nos clients sont nos meilleurs beta testeur.» H. Mintzberg
«Un programme informatique fait ce que vous lui avez dit de faire, pas ce que vous voulez qu'il fasse» Troisième loi de Greer
Membre enregistré
2 104 messages
Posté le 05 octobre 2020 - 07:31
Autant créer un groupe de discussion que là dessus. Il y avait un groupe slack mais je ne sais pas s'il tourne encore.

--
Cordialement,

Philippe SAINT-BERTIN