Discussion :

[cuiny]

Bonjour,

J'aurai une question concernant la fonctionnalité sqlconnecte.

J'ai créé une procédure pour centraliser la connexion SQL.

Quand je n'ai plus besoin de ma connexion SQL je lance un sqldeconnecte.
Evidemment le sqldeconnecte est appelé en dehors de la procédure de connexion.

J'ai l'impression que cela pose soucis et qu'au final la déconnexion ne se fait pas.
Pourtant je gère qu'une connexion à la fois et selon l'aide, le sqldeconnete coupe la connexion SQL en cours.

Ma question est la suivante: Est ce qu'il est obligatoire que la fonction sqlconnecte et sqldeconnecte doivent être présents dans le même champ de code ?

Par exemple j'ai un bouton "Requete" dans l'événement "clic" dois-je impérativement mettre sqlconnecte et sqldeconnecte ?
Est ce que je peux mettre le sqldeconnecte dans le code de fermeture de la fenetre à la place ?

[tbc92]

Je pense que si tu veux faire les choses proprement, c'est mieux d'utiliser les variables de type connexion. Là, tu passes du niveau amateur au niveau professionnel.
Dans ton programme, tu peux alors (éventuellement) avoir plusieurs connexions.

Code :

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

1
2
3
4
5
6
7
HOuvreConnexion(MaConnexion1)
Travail avec  MaConnexion1
HOuvreConnexion(MaConnexion2)
Travail avec  MaConnexion2 et/ou Maconnexion1
HFermeconnexion(MaConnexion2)
Travail avec  MaConnexion1
HFermeconnexion(MaConnexion1)

Et en plus, tu peux gérer des transactions beaucoup plus proprement.
Et évidemment, les codes d'ouverture / fermeture / traitement peuvent être dans des portions de code différentes. Il faut juste que les déclaratives de MaConnexion1 et MaConnexion2 soient suffisamment haut (code de la fenêtre ou code du projet).

Tout ça pour te dire que je ne connais pas la réponse à ta question précise

[frenchsting]

Bonjour,

Je n'utilise pas SQLConnecte / SQLDéconnecte.

Ce que je pense, c'est qu'il faut que tu déclares la variable de l'id de connexion en variable globale "à l'endroit" ou est utilisée ta connexion SQL.

Code :

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

id = SQLConnecte(...)

[cuiny]

Merci pour vos retours.

@tbc92 :
Je ne savais pas qu'il y avait des fonctions amateur et pro dans Windev.
Pour ma part je n'ai pas confiance en la fonction houvreconnexion quand on utilise régulièrement des changements de connexions.
Sur l'une de nos applications, le changement ne s'effectue pas toujours, il n'y a pas d'erreur, on croit donc travailler sur les autres données qu'alors on est toujours connecté sur la première base ce qui est extrêmement dangereux.

Du coup pour le nouveau projet auquel je suis affecté j'ai décidé d'utiliser une autre fonction pour la gestion des connexions.

Tout ça pour te dire que je ne connais pas la réponse à ta question précise

Effectivement, mais merci de ton intervention


@frenchsting :
J'ai déclaré ma connexion dans une procédure globale.
Mais en jouant en parallèle sur le manager sql je remarque que lorsque je veux supprimer manuellement ma table fraichement créé je ne peux pas le faire ce qui m'a soulevé cette question.

Je vais voir dans le temps ce que cela donne.

Merci pour vos retours

[tbc92]

Sur l'une de nos applications, le changement ne s'effectue pas toujours, il n'y a pas d'erreur, on croit donc travailler sur les autres données qu'alors on est toujours connecté sur la première base ce qui est extrêmement dangereux.

J'ai des gros doutes là-dessus.Et si c'est le cas, je pense qu'il faut faire remonter le point à PCSoft (je sais, la réaction sera inexistante)
Je n'ai pas accès à Windev ici, et je ne peux pas vérifier comment je fais sur un gros projet où je gère des connexions. Mais à l'occasion, je vérifierai.

Je parle de fonctions pro et amateurs ... Windev a beaucoup de fonctionnalités qui sont faites pour des utilisateurs qui n'ont aucune connaissance en développement, c'est la spécificité de Windev. Et il y a des fonctionnalités beaucoup plus pointues, pour les vrais développeurs.
Une commande HExécuteRequêteSQL() où on ne dit pas si on travaille sur la connexion A ou la connexion B, c'est simple à utiliser, mais ça sous entend qu'on a une seule connexion ouverte. Ce que j'appelle Amateur.
L'autre syntaxe de HExécuteRequêteSQL() où on dit qu'on travaille sur telle connexion précise permet d'avoir simultanément des connexions ouvertes sur différentes bases de données ...
C'est pour ça que je parle de PRO vs AMATEUR.

[frenchsting]

Je pense que si tu veux faire les choses proprement, c'est mieux d'utiliser les variables de type connexion. Là, tu passes du niveau amateur au niveau professionnel.
Dans ton programme, tu peux alors (éventuellement) avoir plusieurs connexions.)

Alors là, je me marre.

Pas à propos de ta réponse tbc92, mais juste parce que je repense à mes ex collègues qui ne juraient que par les commandes SQLxxxx. Le reste n'était, pour eux, pas censé exister. Et ils se pourrissaient la vie à faire des trucs hyper lourds, là où, ils auraient pu utiliser des choses bcp plus simples.

C'est le coup du "pas pro" qui me fait me bidonner.

Merci pour ta réponse, elle va égailler ma journée (pour ne pas dire ma semaine).

[Jon Shannow]

@tbc92) Merci pour le pas pro, mais comme je gère une seule et unique base, je ne vois pas pourquoi préciser la connexion, ce qui alourdi inutilement la syntaxe. Mais, c'est mon coté amateur, je suppose...

[frenchsting]

Meuh non, mon Jon. tu es le baroudeur du code, c'est au dessus de tout ça.

[Jon Shannow]

Vieux schnock, plutôt que baroudeur

[frenchsting]

Avec moi, on va faire la paire Waldorf et Statler du forum

[PointCarreJo]

Bonjour à tous,

Sur l'une de nos applications, le changement ne s'effectue pas toujours, il n'y a pas d'erreur, on croit donc travailler sur les autres données qu'alors on est toujours connecté sur la première base ce qui est extrêmement dangereux.

Je confirme bien que le changement de base de données ne se fait pas toujours avec hChangeConnexion.
Vu que je travaille essentiellement en SQL Server, j'ouvre la connnexion, je change la connexion et en plus je préfixe toujours le nom de ma base avant d'attaquer une table.

Cordialement.