Discussion :

[Hibernatus34]

Merci.
Le plus gros souci c'est l'accès aux colonnes par leur numéro, c'est l'horreur à relire et/ou à maintenir.

[Thomad]

Merci.
Le plus gros souci c'est l'accès aux colonnes par leur numéro, c'est l'horreur à relire et/ou à maintenir.

Oui tout à fait d'accord avec toi !

L'accès natif n'apporte pas grand chose. Perso. une appli. avec ~25 users, j'utilise OLE DB et c'est nickel.

Maintenant passer par des H... à la place de bonnes vieilles requêtes SQL, il n'y a pas photo. De toute façon le mix des deux est toujours possible, voir même EcranVersFichier si on va par là.

[Lo²]

Je suis tout à fait d'accord.

Personnellement, pallier ce problème, je rajoute en commentaire le nom réel du champ remonté et sur le texte de la requête, je me fais une ligne de 10 champs pour avoir le numéro plus rapidement.

[Al-Soultani]

Bonjour Luludev et à tous les autres,

J'ai moi même toujours été friand de développements de projets plutôt en OLE DB qu'avec l'Acces Natif SQL Server (essentiellement pour des raisons de coûts).

Simplement, il y a une information qui est tombée il y a quelques semaines de cela qui pourrait changer la donne.

Voici le topic qui y fait référence :

http://www.developpez.net/forums/d11...db-sql-server/

Bonne journée.

[Lo²]

Bonne remarque, je l'avais également vu.

On a un bout de temps avant l'abandon de l'OLEDB, mais il semble plus viable de se focaliser sur l'ODBC dorénavant, pour avoir les derniers correctifs par exemple.

[luludev]

Je l'avais vu aussi car il l'avait fait passer dans leur news-lettre.

OLEDB n'est pas encore mort, nous avons le temps de voir venir semble-t-il.

[Hibernatus34]

Je ne savais pas ça.
On utilisera "ODBC via OLE DB".

[Tober]

Je rajoute ma pierre en faveur des fonctions SQL*.

Je trouve que les fonctions H* permettent de faire des choses très intéressante, et les fonctions ecranversfichier et fichierversecran sont vraiment sympas. (j'ai vu ces fonctions et l'utilisation d'HF via les 2 premières formations de WinDev).
Cependant, un point qui n'a pas été discuté ici encore, c'est le fait que pour utiliser les fonctions H* et autres, il faut "apprendre" un nouveau fonctionnement pour gérer les données.
Je suis d'accord de dire que ce nouveau fonctionnement est très pratique et simple, mais il nécessite un apprentissage.
J'ai aussi un vrai problème avec l'éditeur de requête de WinDev (vu également en formation). C'est idéal pour un débutant complet en SQL, mais complètement improductif si on connait SQL. Surtout dès qu'on fait des "vrais" requêtes un peu complexe ou on perd du temps à essayer de la faire dans l'éditeur.
Bon j'ai peut être dis certaines absurdités, mais c'est ce que j'ai retenu de mes développements et formations.

[vmolines]

Je ne connais pas très bien SQLExec, mais il me semble qu'on ne peut pas écrire du code aussi clair que l'exemple suivant avec, si ?

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
 
sSQL est chaîne = [
SELECT
	Col1,
	Col2
FROM
	toto
WHERE
	titi = @Param1
]
sdReq est une source de données
 
sdReq.Param1 = "toto"	// Paramètres nommés, sans guillemets
// Basé sur HExécuteRequêteSQL :
SI ExécuteRequête(sdReq, sSQL) ALORS
	// Parcours simplifié
	POUR TOUT sdReq
		// Colonnes nommées, sans guillemets
		Trace(sdReq.Col1, sdReq.Col2)
	FIN
FIN
// Pas de code de libération de ressource, c'est implicite

J'avoue que dans la pratique je n'utilise pas "POUR TOUT" car il fait un HLitPremier sans l'option hSansRafraîchir, ce qui est rédhibitoire dans le cas d'une requête en curseur client.
Et pour les sources de données il a fallu ruser pour corriger le fait que WinDev les gère via un identifiant global.
Enfin, les paramètres nommés ne sont gérés qu'en accès natif normalement, c'est nous qui avons rajouté cette fonctionnalité à l'accès OLE DB.

Quel serait le code équivalent avec SQLExec ?

Concernant la mise à jour auto, ça n'existe que pour HF, donc la question ne se pose pas ici. Nous l'avons développée pour SQL Server via OLE DB et nous l'exécutons au démarrage de l'application, ce qui est plus pratique qu'à l'installation. Ça marche super bien jusqu'ici, on a gagné beaucoup de temps.
Celle de HF est mauvaise car si on rajoute des contraintes il ne s'assure pas qu'elles sont respectées, on peut donc avoir une clé unique avec des doublons par exemple. En SQL Server c'est pas possible donc on gère ça différemment.

Concernant les paramètres nommés directement dans le code natif, on est d'accord ce n'est pas possible car seule l'analyse nous permet d'avoir la connaissance du modèle directement dans le code.

Je vous rejoins tout à fait sur la nécessité de développer ses propres procédures de mise à jour du modèle de données. Idem pour les limitations de l'analyse qui ne permet pas de faire tout ce qu'il est possible de faire sur la base de données (exemple simple et nécessaire dans bien des modèles : une table qui a pour PK l'association de 2 FK, impossible à représenter dans l'analyse ).

Pour les paramètres nommés avec SQLExec sur OleDb, j'y ai eu recours pour l'appel de procédures stockées avec la forme suivante :

Code :

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

1
2
3
4
5
6
7
8
sReq est une chaîne ="REQ"+DonneIdentifiant()
sSQL est une chaîne = ChaîneConstruit([
DECLARE @pParam1 int
EXEC SP_ADDINT @pParam1 =%1
], 2)
 
SI PAS SQLExec(sSQL, sReq) ALORS
...

Ca fonctionne simplement.

Merci.
Le plus gros souci c'est l'accès aux colonnes par leur numéro, c'est l'horreur à relire et/ou à maintenir.

En effet la relecture est plus pénible et si c'est vraiment rédhibitoire, rien n'empêche d'y accéder par le nom avec SQLColonne. Il suffit d'encapsuler tout ça dans un objet requête qui gère :
- le nommage (comme vous l'avez si bien fait remarquer)
- l'association "nom de colonne"<=>"indice" en faisant automatiquement appel à SQLColonne à l'exécution
- la mise à disposition de ces colonnes via une méthode getColByName("Colonne1")

Certes, vous allez me dire que ce mécanisme ne garantit pas la cohérence à la compilation et que la maintenance reste donc difficile en cas de changement.

Je répondrai à ça qu'une simple convention de nommage des colonnes de ses tables permet de s'y retrouver avec un simple "rechercher".


Alors oui la conservation de l'analyse permet d'avoir accès aux nom dans le code, à la complétion pour les informations du modèle et à une certaine sécurité en contrôlant le SQL à la compilation. Mais à quel prix !

Je n'ai pas l'impression que mes temps de dev ont souffert de la nécessité d'écrire tout en SQL pur et à accéder à mes colonnes par leur indice. Je ne me suis même pas payé le luxe de faciliter l'accès aux colonnes par leur nom comme je vous le proposais car je n'ai jamais ressenti de gêne à le faire.

Par contre, quel temps perdu sur des projets où l'analyse m'était imposée...
. Les recherches incessantes pour comprendre comment la boîte noire "Hxxx" moulinait mes requêtes.
. Pourquoi COALESCE donnée comme compatible dans l'aide ne fonctionnait plus dès que je travaillais avec des paramètres et des fonctions d'agrégat.
. Pourquoi mon index n'est pas utilisé et rend ma requête inutilisable alors que cette même requête tourne parfaitement en SQL pur.
. Pourquoi l'analyse ne me permet pas de modéliser ce que je veux.

Utiliser une couche intermédiaire (ORM & co) est un nivellement par le bas, surtout quand on utilise celle de PCSoft. Moins elle en fait et mieux mes données se portent.

[Hibernatus34]

Tober : Rien n'empêche d'utiliser la même mécanique que SQL* avec H*.

. Pourquoi COALESCE donnée comme compatible dans l'aide ne fonctionnait plus dès que je travaillais avec des paramètres et des fonctions d'agrégat.
. Pourquoi mon index n'est pas utilisé et rend ma requête inutilisable alors que cette même requête tourne parfaitement en SQL pur.
. Pourquoi l'analyse ne me permet pas de modéliser ce que je veux.

Si COALESCE ne marche pas correctement c'est soit que vous êtes en HF, soit qu'il y a une "correction de requête" qui se fait. Mais ici on parle d'accès OLE DB à SQL Server avec les fonctions H- et l'option hRequêteSansCorrection.
Même chose concernant l'index.
En revanche, c'est vrai que l'analyse est limitée aux fonctionnalités très pauvres de HF. J'ai dû magouiller un peu pour rajouter une colonne de type ROWVERSION à certaines tables par exemple. Et concernant les contraintes, WinDev gère environ 0.01% de ce qui est possible en SQL Server.
Mais on n'a pas forcément besoin de tout.
Après on arrive peut-être à un point où il vaudrait mieux laisser tomber WinDev et utiliser les langages .NET qui sont plus modernes et mieux outillés de ce côté là.

[vmolines]

Pardon, il est vrai que je mets dans le même sac analyse et utilisations qui peuvent en être faites dans l'ensemble des fonctionnalités de l'EDI. Et j'attaquais la couche d'abstraction proposée par les requêtes interprétées.

Ceci étant dit et pour les avantages restants de l'analyse, il n'y a que la connaissance du modèle au niveau du code. L'analyse ne permet ni la modélisation de ce qui est modélisable, ni la mise à jour des bases par rapport au modèle. C'est un bien maigre retour sur investissement par rapport aux gênes occasionnées et je ne comprends toujours pas l'acharnement de beaucoup de développeurs Windev à la conserver. Un illusoire sentiment de bien faire les choses je pense...

[Hibernatus34]

Vous sous-estimez peut-être l'utilité de l'analyse :
Voici notre code pour faire un DELETE en SQL pur (mêmes performance et fiabilité que SQLExec, exécuté en curseur client et sans correction).

Code :

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

1
2
3
4
5
6
 
// Fichier.CléComposée est écrit sans guillemets, donc avec la complétion.
// Ça peut aussi être passé via une chaîne.
SI PAS gSupprimeEnreg(Fichier.CléComposée, Valeur1, Valeur2, Valeur3) ALORS
	Erreur()
FIN

Je vous le fais avec une clé composé pour montrer qu'on n'est pas limités à des clés simples et uniques.
On a des fonctions dans ce genre pour récupérer une valeur, un min/max, compter des enregs, etc. Avec les clés composées et les fonctions variadiques on fait plein de choses. Ça évite de cribler le code avec des déclarations de chaînes pour chaque commande SQL, ou pire, écrire du SQL en ligne directement dans les appels à SQLExec.

Et voici le chargement d'une fiche qui était en HF et qu'on convertit en SQL :

Code :

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

1
2
3
4
5
6
// HLitRecherchePremier avec hLimiteParcours
SI PAS gHLitRech(Fichier.CléComposée, Valeur1, Valeur2, Valeur3) ALORS
	Erreur()
	Ferme()
FIN
FichierVersEcran()

Et l'enregistrement :

Code :

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

1
2
3
4
5
6
 
// Fait un UPDATE uniquement des rubriques qui ont changé, d'où le "Utile"
EcranVersFichier()
SI PAS gHModifieUtile(Fichier) ALORS
	Erreur()
FIN

Moralité, on convertit le projet au SQL sans changer la mécanique, ça va bien plus vite. (ce n'est pas du vrai code de notre projet, mais vous voyez le principe)

Ensuite, on a plein de fonctions qui évitent de retaper du SQL inutilement et évite les fautes de frappe ou les requêtes qui ne seraient pas "index-friendly" : comparaisons de tuples, tris, etc.

Au final, quand on fait du SQL explicitement c'est pour des requêtes plus évoluées (< 50% des requêtes).

Enfin, pour rajouter/supprimer/modifier une colonne ou un index, c'est 3 clics dans l'analyse et c'est fini, on a automatisé la suite. L'analyse est synchrone avec la base, c'est le bonheur.

Ah oui, on a aussi une fonction qui charge une table mémoire à partir des noms de colonne qui est très pratique (en SQL la colonne est Toto, dans l'IHM c'est Col_Toto). Les fonctions de WinDev pour faire ça ne sont pas comme on le voudrait.

On a même mis les fichiers temporaires (#table) dans l'analyse, tellement on a trouvé ça pratique.

Il faut dire que notre projet était énorme, donc on savait forcément que ça valait le coup de préparer tout ça dès le début.
Avec des SQLExec et même avec une classe pour les encapsuler, je pense qu'on aurait mis beaucoup plus de temps.
On a des requêtes très complexes aussi, et devoir lire le résultat avec des numéros de colonnes ou des chaînes contenant le nom serait une véritable torture, ça dégraderait beaucoup la clarté de notre code.

Cependant, tout n'a pas été rose, il a fallu comprendre certains pièges de OLE DB. Mais ça valait le coup.

[fucce]

Je viens de tomber sur ce Post, j'ai effectué quelques tests entre accès natifs et OLEDB sous SQL Server 2008. Conclusion : je viens de migrer une application en OLEDB où les utilisateurs me disent qu'ils gagnent en rapidité (30% quand même). Je viens aussi d'envoyer un mail à PCSoft pour avoir leur version des faits par rapport à leur doc... Je suis un peu dèg quand même...

[fucce]

Réponse de PcSoft :

Je vous remercie de nous signaler ce dysfonctionnement. Malheureusement, celui-ci n'est pas connu de nos services et je ne suis pas parvenu à le reproduire.

Nous avons donc besoins d'éléments de reproduction pour poursuivre nos investigations.

Dans votre cas, les éléments à nous fournir sont peu nombreux :

- un projet WINDEV avec
- une fenêtre effectuant ce traitement
- votre répertoire d'analyse (<NomProjet>.WDxxx ou .ANA) sans ses sous répertoires ANAxxx (si nécessaire)
- le ou les fichiers de données utilisés par cette fenêtre (si nécessaire)
- la version de SQL server utilisée (2000, 2005, 2008 ...)
- un script SQL permettant de créer une base de données similaire à la votre (Create Table...Insert Into...)
- votre application est-elle en 32 ou 64bits
- utilisez-vous l'ancien ou le nouvel accès natif (SQLnCli ou DB-Library) :
http://doc.pcsoft.fr/fr-FR/?5515003&...-windev-webdev

Fini de perdre du temps, je lui renvoie le lien de la discussion.

[Lo²]

Pourquoi de la perte de temps ?

Le support te demande un exemple concret du dysfonctionnement pour l'étudier.
Je ne dis pas qu'ils vont sortir un correctif dans la journée, mais tu es développeur comme eux et à mon avis, comme eux, tu aimes bien qu'on te donne du grain à moudre au lieu du sempiternel "Ca marche pas"

[vmolines]

Ca ne va pas les avancer à grand chose. Ils demandent, à juste titre, un protocole de reproduction.

Non qu'ils nient un éventuel problème de performance mais ils veulent simplement des éléments facilement exploitables pour le constater. Partant du fait que vous rencontrez le problème, il ne doit pas être difficile de leur fournir vos scripts (base et jeu d'essai) et un projet minimal.

[fucce]

Je suis d'accord avec toi Lo². Mais ils ont sans doute une base SQL Server 2008, un accès natif, une analyse type, etc... J'ai simplement démarrer une requête de chaque avec une analyse de performance Windev...

[Hibernatus34]

Bonjour,

fucce : je trouve étonnant que toute votre appli soit plus rapide en OLE DB sans adapter le code. Dans notre, cas il a fallu une connexion en curseur client pour les requêtes de modif (update, delete, insert) sans quoi c'était plus lent. Évidemment il a fallu passer hRequêteSansCorrection aussi.
Ceci dit, je n'ai jamais testé l'accès natif pour comparer.

Enfin, on a aussi constaté un problème dans le cas de requêtes de type "agrégat" (sum() par exemple) : une nouvelle connexion était à chaque fois créée pour chacune de ces requêtes et n'était jamais recyclée. La connexion TCP passant alors par un état TIME_WAIT (4 minutes d'attente avant de libérer le port), on arrivait à une pénurie de ports TCP en exécutant une telle requête rapidement plus de 4000 fois dans une boucle. La solution était d'envelopper ces requêtes dans un "SELECT * FROM (la requête)", de manière à ce que l'agrégat disparaisse à la sortie. Pour ceux qui utilisent SQL Server via OLE DB en connexion TCP, c'est quelque chose à savoir, je peux développer si vous voulez.

[sHnouL]

Bonjour,

En lisant ce topic je vois que l’accès Natif SQL Server payant de Windev n'est pas aussi performant que l’accès ODBC. Cette discussion est de 2011, j'aimerais connaitre les évolutions depuis.

Actuellement je travail sous Firebird 2.1 avec un accès ODBC pour mes applications. Mes requêtes sont exécuté par la fonction HExecuteRequeteSQL().
J'ai devisé un changement de serveur hôte pour ma société avec un changement de base vers SQL Server 2012.

J'ai plusieurs questions avant l'achat ou non d'une licence accès natif SQL Server pour Windev :

- L’accès natif est il plus rapide de nos jours ?
- Quel est la différence entre l’accès "SQL Server (Microsoft OLE DB Provider for SQL Server), "Accès ODBC par OLEDB", "Acces natif SQL Server pour Windev"

Merci pour votre retour.

[Hibernatus34]

Bonjour,

L'accès natif est (un peu) plus rapide sur presque toutes les fonctions.
Mais il pose quelques problèmes pour le moment, comme un changement de session entre les transactions (à cause du mode MARS), ou la confusion entre NULL et 0 dans les paramètres de requêtes, une mauvaise gestion des messages d'erreur...
Personnellement, en ayant développé tous les outils pour m'en passer, je lui préfère l'accès OLE DB "normal", qui est mieux supporté (et pourtant gratuit).
L'accès natif existe en version ODBC, mais il ne fonctionne pas encore aussi bien que la version OLE DB.

L'accès ODBC par OLEDB posait des problèmes de blocages de tables, je pense qu'il faut l'éviter.

Sachez que l'accès OLE DB ou ODBC, que ça soit avec l'accès "natif" ou "normal", nécessite l'installation d'un driver côté client, au moins si on veut une gestion des dates correcte.