Discussion :

[philouZ]

Bonjour à tous,

Je viens vers vous en ce jour presque saint pour vous informer d'un joli bug qui peut se produire chez tout le monde.

J'utilise une analyse et la base PostgreSQL avec un accès natif qui est pratique à certains égards, mais pas là.

Si vous faites ceci, vous pouvez avoir des problèmes

Code :

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

1
2
3
4
5
6
MaReq est une Requête SQL = 
[
	SELECT * from table
]
 
 HExécuteRequête(MaReq)

En effet, vous pouvez avoir des problèmes si l'ordre des colonnes dans l'analyse n'est pas le même que dans la table PostgreSQL. En effet, mais j'ai de sérieux doutes, il semblerait que Windev suive l'ordre physique de description de l'analyse et ne fasse pas le mapping sur le nom des colonnes. Je vous laisse imaginer l'horreur que cela peut produire, le nom du client peut se retrouver dans les commentaires et le solde dans l'id par exemple.

Voici la réponse du ST (j'ai omis le copies écran et la partie me remerciant)

...Lorsque vous exécutez une requête en mode normale, c'est par définition pour qu'elle utilise la description de la table dans l'analyse. Dans votre exemple, la description de la table dans l'analyse, à un ordre physique des colonnes qui ne correspond pas à celui de la table créée dans la base Posgresql...

Pour que tous les résultats concordent, il faut nécessairement que l'ordre indiqué pour les colonnes dans l'analyse, corresponde à celui de la base de données. Pour cela, l'idéal est de toujours avoir la base et l'analyse synchroniser : créer la table dans l'analyse par importation de la base, ou à l'inverse à partir de l'analyse avec HCréationSiInexistant.
Dans votre exemple afin d'avoir le résultat attendu, vous pouvez corriger l'ordre des rubriques dans l'analyse. Il faut qu'il soit identique à celui renvoyé par la base avec un SELECT * pour que tout soit en phase

Bref les dev nous ot encore pondus une belle grosse bouse...

Sachez tout de même que s'i l'on déclare les colonnes à récupérer, même dans le désordre, comme ci-après, tout va bien il arrive à s'en sortir et les colonnes vont au bon endroit.

Code :

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

1
2
3
4
5
6
MaReq est une Requête SQL = 
[
	SELECT col1,col3,col7,col6,col4,col5,col2 from table
]
 
 HExécuteRequête(MaReq)

Le pire dans tout ça c'est que j'utilise une classe avec le mapping et que même là ça ne fonctionne pas. Bref un gros bug que PC Soft ne considère pas comme tel.

[tatayo]

Bonjour,
Pour moi un SELECT * n'a rien à faire dans un code en production.
En effet si la structure de la table concernée change (ajout d'une colonne, par exemple), le résultat de la requête change aussi, et des résultats imprévisibles.
Il faut toujours indiquer la liste des colonnes à récupérer.

Après est-ce un bug dans Windev ? Je pense que oui, puisque le lien entre la description dans l'analyse et la base de données doit se faire sur le nom des colonnes, et non sur l'ordre de celles-ci.
Surtout que ça fonctionne en listant les colonnes...

Tatayo.

[philouZ]

Pour moi un SELECT * n'a rien à faire dans un code en production.
En effet si la structure de la table concernée change (ajout d'une colonne, par exemple), le résultat de la requête change aussi, et des résultats imprévisibles.
Il faut toujours indiquer la liste des colonnes à récupérer.

Sur ce sujet nous ne sommes pas d'accord. L'ajout d'une colonne n'impacte le résultat d'une requête. La valeur de la colonne ne sera juste affectée à rien. J'en ai peu, je l'accorde mais j'en ai et ça ne me pose aucun problème. 0 partir du moment où le mapping est correct ça ne peut que fonctionner. Je te laisse imaginer, j'ai une table avec 170 colonnes, Si je veux récupérer toutes les colonnes, je ne m'embête pas à toutes les marquer une à une dans la requête.

Après est-ce un bug dans Windev ? Je pense que oui, puisque le lien entre la description dans l'analyse et la base de données doit se faire sur le nom des colonnes, et non sur l'ordre de celles-ci.
Surtout que ça fonctionne en listant les colonnes...

C'est clairement un bug mais la réponse de PC Soft est sans équivoque après leur avoir démontré l'anomalie

Les connecteurs natifs imposent en effet d'avoir une description "en phase", j'espère que cela pourra évoluer.

[Invité]

Bonjour,

Il y a pour moi une logique d'ordre dans le schema :

Si ton schema possède dans l'ordre : id, col1, col2, col3 et que tu fais un select * from table le résultat sera (id, col1, col2, col3)(id, col1, col2, col3) mais si tu change ton schema avec col1, id, col2, col3 le résultat de cette meme requête sera (col1, id, col2, col3)(col1, id, col2, col3).

D'un point de vue perso, je considère l'analyse comme une abstraction de ton schema de db qui devras être obligatoirement synchro avec cette meme analyse.
Pour moi c'est comme l'utilisation d'un ORM, le mapping object devra forcement refléter le schema de base de la DB. (si tu modifie l'un faut mettre à jour l'autre ).

Je pense pas que l'on puisse mettre en avant un bug de la part de Windev. Il y a peut être un problème de logique métier dans la conception et l'utilisation de chacun sur ce produit (je precise cette suite logiciel est une hérésie), qui mis en parallèle avec d'autres technos ou frameworks on une ressemblance de conception.

[tatayo]

Sur ce sujet nous ne sommes pas d'accord. L'ajout d'une colonne n'impacte le résultat d'une requête.

Si, justement. Si sur une table de 10 colonnes tu en ajoutes une, la requête ne renvoie plus 10 colonnes, mais 11. Donc le résultat n'est plus le même.
Je ne parle même pas de l'ajout d'une jointure dans la requête !

Je te laisse imaginer, j'ai une table avec 170 colonnes, Si je veux récupérer toutes les colonnes, je ne m'embête pas à toutes les marquer une à une dans la requête.

Heu, non, je ne veux même pas imaginer. 170 colonnes sur une même table, je pense qu'il y a un problème de modélisation. Mais ce n'est pas le sujet ici .

Pour en revenir au sujet initial, si on compare avec EF Core, ce dernier se base sur le nom des colonnes, et non leur "position" dans la définition de la table, pour faire le lien entre les deux:

Code C# :

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
 
    [Table("TRACKING", Schema = "wms")]
    public partial class Tracking
    {
        [Key]
        [Column("TRCK_I_IDENT")]
        public long TrckIIdent { get; set; }
        [Required]
        [Column("TRCK_C_NUM_DOC")]
        [StringLength(20)]
        public string TrckCNumDoc { get; set; }
        [Column("TRCK_I_UNITE_MANUTENTION")]
        public int TrckIUniteManutention { get; set; }
        [Required]
        [Column("TRCK_C_CODE_DEST")]
        [StringLength(50)]
        public string TrckCCodeDest { get; set; }
        [Required]
        [Column("TRCK_C_SOURCE")]
        [StringLength(4)]
        public string TrckCSource { get; set; }
...
}

Donc je peux sans problème recréer la table en changeant l'ordre des colonnes, il n'y aura aucun impact sur le code.

Côté PcSoft je trouve leur explication un peu "bancale", mais j'ai souvenir qu'il est assez difficile de leur faire admettre qu'il y a un bug quelque qu'il soit, même si une correction arrive dans le patch/la version suivante (ou celle d'après).

Tatayo.

[philouZ]

Heu, non, je ne veux même pas imaginer. 170 colonnes sur une même table, je pense qu'il y a un problème de modélisation

Non il n'y a aucun défaut de modélisation. Les données sont uniques pour un enregistrement et n'ont aucun intérêt à être réparties dans d'autres tables...

Pour en revenir au sujet initial, si on compare avec EF Core, ce dernier se base sur le nom des colonnes, et non leur "position" dans la définition de la table, pour faire le lien entre les deux

Je suis 100% d'accord avec toi et ça paraît totalement logique.

Pour moi c'est comme l'utilisation d'un ORM, le mapping object devra forcement refléter le schema de base de la DB. (si tu modifie l'un faut mettre à jour l'autre ).

Quelque soit l'ORM que tu utilises, le mapping n'est pas fait sur l'ordre de création des colonnes mais par leur nom. Mon analyse n'est pas désynchronisée de mes tables et reflètent bien le même schéma mais avec des colonnes dans un ordre différent.

Il y a donc bien un bug et vu le nombre d'objets que j'ai à vérifier, j'ai pas hyper envie d'y aller là...

Quant aux réponse de PC Soft, c'est un peu toujours la même

Vous les clients vous êtes trop nuls vous ne savez pas utiliser notre produit c'est tout. Windev c'est le top !!! Y'a pas mieux au monde...

[Invité]

Quelque soit l'ORM que tu utilises, le mapping n'est pas fait sur l'ordre de création des colonnes mais par leur nom. Mon analyse n'est pas désynchronisée de mes tables et reflètent bien le même schéma mais avec des colonnes dans un ordre différent.

Entièrement d'accord avec toi, mais de ce que je constate sur Windev, est que nous somme obligé de re-synchro analyse si on bouge l'ordre des champs dans une table.
Remarque la devise est faite rien on fait tout pour vous (Mouah aaaah ah ah).

[philouZ]

Je ne synchronise plus la base et l'analyse. Ca entraîne trop d'erreurs. Le numeric sont transformés en réel, il y a des index qui ne remontent pas... Je ne parle pas des double quotes rajoutées à la création des tables postgresql.

[tbc92]

Si tu as 170 caractéristiques (age, taille, poids, ... )
Tu peux envisager une table qui aurait a priori 3 colonnes, avec jusqu'à 170 lignes par individu au lieu de 170 colonnes

Id_Individu
Id_Attribut (170 valeurs possibles)
Valeur

L'information reste dans une seule table. Si demain, tu as une 171ème colonne, tu ne changes rien à l'analyse , tu as juste l'utilisateur qui insère une nouvelle ligne dans la table 'Liste des attributs', et qui insère les lignes pour les individus.

Aujourd'hui, ton application existe et fonctionne, donc ça ne fait pas trop sens de réorganiser les données ainsi. Mais dans l'absolu, c'était une solution envisageable.

[philouZ]

Si tu as 170 caractéristiques (age, taille, poids, ... )
Tu peux envisager une table qui aurait a priori 3 colonnes, avec jusqu'à 170 lignes par individu au lieu de 170 colonnes

Pourquoi pas j'y penserai pour autre chose.

Par contre juste pour la petite info, je continue d'avoir des discussions avec PC Soft et ils insistent, c'est un fonctionnement normal et c'est moi qui ne sait pas utiliser leur produit.

Je leur avais déjà dit que je partais sur un autre langage mais là je n'ai plus aucun état d'âme.