PC SOFT

PROFESSIONAL NEWSGROUPS
WINDEVWEBDEV and WINDEV Mobile

Home → WEBDEV 2024 → Bonnes pratiques - Exécution requêtes SQL sous SQL Server avec l'accès natif
Bonnes pratiques - Exécution requêtes SQL sous SQL Server avec l'accès natif
Started by Développeur de Feu, Dec., 31 2019 11:44 AM - 5 replies
Registered member
48 messages
Popularité : +0 (2 votes)
Posted on December, 31 2019 - 11:44 AM
Bonjour à tous !

Dans le but d'augmenter les performances, mon équipe a décidé de dupliquer notre base sur un SQL Server et de passer donc d'une connexion HF Client/Serveur à une connexion utilisant l'accès natif SQL Server proposé par PCSoft.

Le serveur est en place et la base de données est migrée.

Après quelques tests d'un site WEBDEV sur ce nouveau serveur, le temps de traitement est très loin de nos espérances, nous perdons beaucoup de temps, et je voulais savoir quelles sont les meilleures pratiques dans ce cas particulier (utilisation de l'accès natif SQL Server) pour exécuter des requêtes et traiter chaque ligne le plus rapidement possible.

(PS: nous faisons du BIG Data, nous avons des tables ayant plusieurs millions d'enregistrements, et certaines requêtes de mon site Webdev n'ont pas été créées via l'éditeur de requête mais sont "construites" en concaténant ou non certaines chaines de caractères en fonction des filtres choisis par l'utilisateur final, j'utilisais donc la fonction HExecuteRequeteSQL pour exécuter ma requête sous forme de chaine de caracteres)

Dois-je utiliser HExecuteRequeteSQL ? Si oui avec quels paramètres, quel mode d'exécution ? Ou plutôt SQLExec ? Mais avec SQLPremier, SQLAvance ? Est-ce mieux de passer par l'éditeur de requêtes ?

J'ai un peu tout testé et je ne constate pas de nette amélioration, rien qui ne donne un temps de traitement acceptable, au mieux des bugs dans certains cas sans savoir si je vais dans la bonne direction....
Je viens alors demander vos lumières sur ma situation.

Mon code de connexion à la base (dans l'initialisation du projet) :

GCON_CONNEXION..Provider = hAccèsNatifSQLServer
GCON_CONNEXION..Utilisateur = G_sParametre("CONNEXIONSQL", "UTILISATEUR")
GCON_CONNEXION..MotDePasse = G_sParametre("CONNEXIONSQL", "MDP")
GCON_CONNEXION..Serveur = G_sParametre("CONNEXIONSQL", "SERVEUR")
GCON_CONNEXION..BaseDeDonnées = G_sParametre("CONNEXIONSQL", "BASE")
GCON_CONNEXION..Accès = hOLectureEcriture

SI PAS HOuvreConnexion(GCON_CONNEXION) ALORS
L_sMessage = "Erreur de connexion à la base de données" + RC + "La connexion à la base de données a échoué, veuillez recommencer ultérieurement."
SINON
bResultat = HChangeConnexion("*",GCON_CONNEXION)
FIN


Mon code de connexion au site (cette exécution ci fonctionne, c'est pour vous montrer la méthode utilisée avant la migration de la base avec un exemple simple)
sSQL est une chaîne = [
SELECT IDUTILISATEUR
FROM UTILISATEUR
WHERE LOGIN='%1' AND MDP='%2' AND ACTIF=1
]

sdREQ est une Source de Données
maRequete est une chaîne = ChaîneConstruit(sSQL, Minuscule(sIdentifiant), Crypte(sMotDePasse,CST_GENERATEMDP))

SI PAS HExécuteRequêteSQL(sdREQ, hRequeteDefaut, maRequete) GOTO erreur_proc

SI HNbEnr(sdREQ)<>1 GOTO erreur_saisie

HLitPremier(sdREQ)

SI PAS GC_UTILISATEUR.bConnexionUtilisateur(Val(sdREQ.IDUTILISATEUR)) GOTO erreur_proc

RENVOYER Vrai



Voilà j'espère avoir été clair dans ma demande et vous avoir donné suffisamment d'informations.
Merci d'avance pour votre aide vous êtes de belles personnes <3
Registered member
48 messages
Popularité : +0 (2 votes)
Posted on December, 31 2019 - 12:01 PM
Pour info, je suis en Webdev 23, et joyeuses fêtes
Registered member
12 messages
Posted on January, 10 2020 - 10:13 AM
Bonjour,

Pourquoi utiliser l'accès natif ? Pourquoi ne pas utiliser OLEDB ? (GCON_CONNEXION..Provider = hOledbSQLServer)

C'est bien mieux, et beaucoup plus rapide.

Ensuite, concernant les requêtes, certaines choses marchant avec HF, et pas avec SQLServer, j'utilise les HExecuteRequeteSQL avec comme option hSansCorrection.
Posted on January, 17 2020 - 3:30 PM
Le 10/01/2020, Mosko a supposé :
Bonjour,

Pourquoi utiliser l'accès natif ? Pourquoi ne pas utiliser OLEDB ?
(GCON_CONNEXION..Provider = hOledbSQLServer)

C'est bien mieux, et beaucoup plus rapide.

Ensuite, concernant les requêtes, certaines choses marchant avec HF, et pas
avec SQLServer, j'utilise les HExecuteRequeteSQL avec comme option
hSansCorrection.


bonjour
je rencontre justement un problème avec sqlserver.
Avec un accès oledb sur sqlserver, cela ne fonctionne pas si la base
sqlserver est avec des shema et plusieurs espaces de nom
monespace.monsousespace.monsoussousespace.matable

je précise que je ne suis pas responsable de cette organisation "à la
c..." et que je dois faire avec.

Donc l'analyse ne peut pas être utilisée.
Le ST m'a confirmé (au bout d'un moment) le problème mais q'avec
l'accès natif sqlserver (payant) cela marcherait.

Ce dont je doute ...
Si vous avez un accès natif sqlserver, utilisez vous les espaces de
noms ?
et sinon pourrais-je vous envoyer un script de création de base pour
tester si l'accès natif résoufrait mon problème ?
Merci de vos réponses.
Posted on January, 19 2020 - 12:57 PM
Bonjour,

J'utilise beaucoup des connexions oledb vers SQL serveur avec des schemas spécifiques (non dbo).
Dans la configuration de connexion dans les applications j'ai prévu un mapping de schema (ou dans un fichier de configuration).
p.e. {dta}=proddta / {ctl}=ctrldta / {sys}=sysdta
Cela peut être aussi le 'full qualified path': p.e. {dta}=servername.schemaname

Les SQL sont écrit comme cela après:
select a, b, c, d, e from {dta}.TableName etc...

Après en execution ce paramêtre est remplacé par le nom d'accès complet à la table.

Bonne journée,

Peter Holemans
Posted on January, 20 2020 - 1:10 PM
Peter Holemans avait énoncé :
Bonjour,

J'utilise beaucoup des connexions oledb vers SQL serveur avec des schemas
spécifiques (non dbo).
Dans la configuration de connexion dans les applications j'ai prévu un
mapping de schema (ou dans un fichier de configuration).
p.e. {dta}=proddta / {ctl}=ctrldta / {sys}=sysdta Cela peut être aussi le
'full qualified path': p.e. {dta}=servername.schemaname

Les SQL sont écrit comme cela après: select a, b, c, d, e from
{dta}.TableName etc...

Après en execution ce paramêtre est remplacé par le nom d'accès complet à la
table.

Bonne journée,

Peter Holemans


Bonjour Peter

Merci beaucoup de ta réponse
Oui en Ole db, j'arrive aussi à lire ma requete
mais seulement avec des hexecuterequetesql sasn correction ou des
SQLEXEC

Par exemple le code ci-dessous focntionne

bRes est un booléen
bRes=HOuvreConnexion(MaConnexionClient)
i est un entier
REQ est une Source de Données
sCmd est une chaîne
sCmd="SELECT permalink FROM
[MaSociete.EMonAppli.Core].[BusinessEntity]"

SI PAS HExécuteRequêteSQL(REQ,
MaConnexionSocoda,hRequêteSansCorrection, sCmd) ALORS
Erreur(HErreurInfo())
SINON
Info("La requête contient " + HNbEnr(REQ) + " enregistrements.")
FIN

par contre importer dans l'analyse cette base avec une table précédée
de 3 noms de schema; cela ne marche pas !
et cela m'a été confirmé par Pcsoft.

MaSociete.EMonAppli.Core.BusinessEntity

et il paraitrait que cela marcherait avec les heureux possesseurs de
l'accès natif SQLserver ??

L'outils OUTILS_SQL.exe disponible sur le site des ressource a
d'ailleurs été gentiment adapté ces derniers mois par Pascal pour
fonctionner avec ces multi-schema. (en oledb)
Mais côté produit PCSOFT (en 24 au moins), cela ne marche pas.

Bonne journée