Discussion :

[GuillaumeN]

Bonjour,

une requête SQL renvoie (entre autres) le champ "idActAffectation" d'une table, champ contenant une série de chiffres séparées par des points-virgules.

Dans l'environnement de développement, tout se passe bien.
Cependant, quand on passe en production, la chaine est tronquée à 200 caractères.
Coïncidence ou pas, cette taille de 200 correspond à l'ancienne taille du champ "idActAffectation".(SQL Server : nchar(200) passé à nchar(300))

Tentatives avec une requête stockée dans le GDS ou avec une variable 'source de données', vérification de l'analyse (le champ est un champ Texte de 300), synchronisation de l'analyse, réparation et recompilation de l'analyse et du projet, sans changement...

Quels que soient mes tests et tentatives, le résultat de la requête SQL est tronqué en production mais pas en développement ! (ce qui rend les tests d'autant plus fastidieux ....)

La BDD utilisée (SQL Serveur) est la même en test et en production !

Avez vous une suggestion sur cette anomalie?
D'avance, merci pour votre aide.

[WDKyle]

Bonjour,

Est-ce que la requête fonctionne depuis SQL Server Management Studio ? Si oui, comment est exécuté la requête depuis Windev ?

[Invité]

Bonjour,

On pourrait-voir la requête?

[GuillaumeN]

Bonjour,

oui la requête fonctionne sans soucis avec Management Studio (2014)
Dans Windev, j'utilise HExécuteRequêteSQL (testé avec la requête passée en variable chaîne ou en requête stockée)

Voici ma requête complète :

Code sql :

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
SELECT 
API_site.idSite,
API_site.LibelléSite,
API_TypeAffectation.idTypeAffectation,
API_TypeAffectation.LibTypeAffectation,
api_region.idRegion,
api_region.LibelleRegion,
API_ChefSecteur.CodeCS,
API_ChefSecteur.LibelleCS,
API_ChefSecteur.IdActeur,	
API_ChefSecteur.idChefSecteur,
API_region.CodeRegion,		
API_Site_Region.idActAffectation

FROM  API_Site_Region

INNER JOIN API_site ON API_Site_Region.idSite = API_site.idSite
INNER JOIN API_TypeAffectation ON API_TypeAffectation.idTypeAffectation = API_Site_Region.idTypeAffectation
INNER JOIN API_Region ON api_region.idRegion = API_Site_Region.idRegion
LEFT OUTER JOIN API_ChefSecteur ON API_ChefSecteur.idChefSecteur = API_Site_Region.idSuivi		

WHERE 
API_site.idSite = %1
AND API_Site_Region.idtypeAffectation = %2

ORDER BY
APi_site.idSite,API_TypeAffectation.idTypeAffectation

%1 et %2 sont mes paramètres
le champ qui me pose problème est en rouge


Ce qui me gène le plus, c'est que ce n'est qu'en production que c'est tronqué, mes tests pendant le développement sont OK...

[Invité]

j'avais en tête que vous faisiez une concaténation des champs. A tout hasard, est-ce que les paramètres de connexion en production pointent bien sur la bonne instance et bdd? la connexion ne se fait pas sur une instance de test, où votre champ serait de longueur 200 caractères?

EDIT : que vous retourne la requête suivante en production :

Code sql :

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

1
2
3
4
select CHARACTER_MAXIMUM_LENGTH
from INFORMATION_SCHEMA.COLUMNS
WHERE table_name = 'API_Site_Region'
and COLUMN_NAME='idActAffectation'

[GuillaumeN]

Re,

Non, il s'agit bien d'une simple lecture de champ mais la lecture est tronquée.

les paramètres de connexion en production et en tests sont les mêmes : je pointe sur la même BDD (et ne possède pas de BDD test)
L'analyse Windev et les propriétés SQL du champ sont bien à 300 caractères.


EDIT : @romulus001 : testé ta requete via Management, en environnement de test et de prod, la requête retourne à chaque fois 300

[philouZ]

Si tu affiches ta valeur dans un champ de saisie par exemple, as-tu vérifié que la longueur de ce champ n'est pas fixée à 200 caractères ?

Lorsque tu compiles ton application, tu pointes bien vers la bonne analyse ? As-tu tenter une réparation complète du projet ?

[tbc92]

Essaie des choses comme ça :

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
SELECT 
API_Site_Region.idActAffectation,
API_site.idSite,
API_site.LibelléSite,
API_TypeAffectation.idTypeAffectation,
API_TypeAffectation.LibTypeAffectation,
api_region.idRegion,
api_region.LibelleRegion,
API_ChefSecteur.CodeCS,
API_ChefSecteur.LibelleCS,
API_ChefSecteur.IdActeur,	
API_ChefSecteur.idChefSecteur,
API_region.CodeRegion

FROM API_Site_Region ....

tu mets la colonne 'fautive' en 1ère colonne, pour voir.

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
SELECT 
API_Site_Region.idActAffectation || '$' as idActAffectation ,
API_site.idSite,
API_site.LibelléSite,
API_TypeAffectation.idTypeAffectation,
API_TypeAffectation.LibTypeAffectation,
api_region.idRegion,
api_region.LibelleRegion,
API_ChefSecteur.CodeCS,
API_ChefSecteur.LibelleCS,
API_ChefSecteur.IdActeur,	
API_ChefSecteur.idChefSecteur,
API_region.CodeRegion

FROM API_Site_Region ....

Selon les résultats de ces essais, peut-être que tu y verras plus clair.

[GuillaumeN]

Hi


j'ai fait le premier test proposé par tbc92 et, surprise, ça fonctionne !
par curiosité, j'ai retenté mon "ancien" code et..... ça a aussi fonctionné !!

y a clairement quelque chose qui s'est passé dans mon dos et qui m'échappe là.. .. ..
dommage, j'aurais bien aimé comprendre ce qui se passait


@ philouZ :
j'affichais directement la valeur de ma requête dans un trace, sans faire aucun traitement dessus.
Et le stockage de l'info se fait dans un colonne d'une table, format "texte"
Je n'ai qu'une seule analyse, donc pas de soucis sur ce point.
et oui j'avais tenté recompilation et réparation complète, sans succès.


Merci à vous d'avoir répondu.

@+