Tester l'ouverture du port 19812 au démarrage

Y a t’il un moyen simple de le faire afin de quitter le client si ce port n’est pas correctement ouvert sur la machine ou sur le serveur.

Le probleme étant que 4D se lance et semble fonctionner si ce port est fermé jusqu’au moment où l’on se sert du moteur SQL (interne de 4D) :-?

J’ai tenté dans le terminal :
lsof -t -i :19813
ça répond “1316”, qui est le PID de mon application 4D.

Bonjour
Ne suffirait il pas de lancer une requete sql au démarrage ?
Si elle n’aboutie pas on quitte 4d

Cordialement
Didier

Pourquoi tester avec le 19813 c’est le 19812 qui m’intéresse ?

Pour ton information le 19812 est obligatoire pour pouvoir utiliser le SQL (y compris interne) de 4D (même si tu n’actives pas le server SQL !)
Donc ta base doit répondre sur le 19812 TOUJOURS.

Sauf que je ne comprends pas que 4D ne mette pas un test en place qui s’il s’avere négatif prévient l’utilisateur ou au moins affiche DIRECTEMENT une erreur au lieu de ça, on se trouve dans des situations ubuesques où le client fonctionne jusqu’au moment où du code interrogeant la base SQL interne flanche et là c’est le drame… :-?

: Didier BARBERIN

Ne suffirait il pas de lancer une requete sql au démarrage ?
Si elle n’aboutie pas on quitte 4d

C’est une piste, mais il faudrait le faire au démarrage de chaque poste client.
Je ne comprends toujours pas que c’est à moi de gérer ça … :-?

Effectivement je comprends bien ce point de vue.
L’autre façon de voir les choses est de dire : Comme on n’est pas sûr que l’on en aura besoin, pourquoi tester un port qui ne sera pas utilisé ?.

A+
Didier

Je vais me limiter déjà a tester la connexion au démarrage du client mais dans la pratique comme l’interrogation de la base SQL peut se faire n’importe quand dans le code 4D rien n’empêcherait que ce port ne soit plus disponible et on retombe dans le problème.

Ce qui est choquant c’est que ce port est normalement devenu OBLIGATOIRE.

: Manuel PIQUET

Pourquoi tester avec le 19813 c’est le 19812 qui m’intéresse ?
Ça s’appelle un exemple…

: Manuel PIQUET

Pour ton information le 19812 est obligatoire pour pouvoir utiliser
le SQL (y compris interne) de 4D (même si tu n’actives pas le server
SQL !)
J’ai deux bases, A et B, qui toutes deux souhaitent dialoguer sur le 19812 (prefs de la base). Je lance A en premier, elle s’approprie le 19812. Je lance B ensuite, elle proteste à l’ouverture qu’elle a un problème de port :
[]28750835;“Your comment here…”[/]
Ça ne m’empêche pas dans B de faire des requêtes en SQL (Debut SQL…Fin SQL), tout comme j’ai des bases dont le serveur SQL est “coupé”, sans que ça empêche d’y faire des requêtes SQL. Ces requêtes là passent par le 19814. Je ne pige pas ce que tu appelles “requête interne”.

il doit y avoir un problème

J’ai du code qui fait ceci:

avec $sql un requête SQL qui fonctionne

<code 4D>
SQL LOGIN(SQL_INTERNAL;“NOMDEMABASE”;"")
SQL EXÉCUTER($sql;$TabTauxTVA;$TabLibTVA;$TabIDTVA)
Si (Non(SQL Fin de séléction))
SQL CHARGER ENREGISTREMENT(SQL tous les enregistrements)
Fin de si
SQL LOGOUT

</code 4D>

Si pour une raison ou une autre le port SQL 19812 est fermé la requête qui interroge la base interne de 4D ne s’execute PAS !

Et malheureusement ce genre de code on peut l’executer n’importe où dans le code 4D !
Et le problème ne remontera que lors de son execution.

T’as lu où que ces requêtes passaient par le port 19814 ? de par mon experience c’était le cas à un moment mais uniquement si le 19812 n’était pas dispo et avec un timeout de fou !
Ce n’est PAS(plus ?) le cas avec le code ci dessus…

l’erreur obtenu est : SQL error 9918. Generic SQL error

Dans ton exemple tu lances le serveur SQL moi je ne démarre pas mon serveur SQL JAMAIS mais pourtant je l’utilise pour dialoguer avec ma base 4D interne et cela sur le port 19812 !!!

SQL EXECUTER : une contribution de Thomas Maul disait que n’était pas
la façon “moderne” d’interroger la base courante et qu’il vaut mieux
utiliser le “en ligne” (Debut/Fin SQL). C’est aussi moins rapide, en
termes de temps de réponse. La syntaxe (login, sql charger, tant que,
logout…) est franchement rébarbative. Quand tu regardes la doc de SQL
login, ça parle d’ODBC toutes les 3 lignes. J’ai utilisé ça pour
échanger avec une autre base 4D, mais en tant que client avec mon
propre serveur je pense que c’est une mauvaise idée.

: Manuel PIQUET

T’as lu où que ces requêtes passaient par le port 19814 ?
Je ne sais plus, mais comme mes requêtes SQL aboutissent alors que le port 19812 est fermé ou occupé par une autre appli et que je ne crois pas à la magie, ça me suffit.

On ne va pas redebattre de comment utiliser le serveur SQL et de
chaque limitation qui font que dans mon cas je préfère (et je n’ai pas
le choix) utiliser cette façon pour pouvoir utiliser des variables
locales…

Tu dois surement avoir de la chance (joue au loto) :twisted:

Sauf a être en mono poste, même si tu utilises (Debut/fin SQL) cela
doit utiliser le port 19812 et si celui-ci est fermé…

: Arnaud DE MONTARD
: Manuel PIQUET

T’as lu où que ces requêtes passaient par le port 19814 ?
Je ne sais plus

Désolé, mais tu conviendras que ta réponse est un peu courte… :roll:

: Manuel PIQUET

dans mon cas je préfère (et je n’ai pas le choix) utiliser cette
façon pour pouvoir utiliser des variables locales…
Moi, comme je ne préfère rien, j’ai le choix, et je peux recevoir mes requêtes SQL dans des locales et n’ouvrir le 19812 que si une base externe a besoin de me causer en SQL.

Sauf a être en mono poste, même si tu utilises (Debut/fin SQL) cela
doit utiliser le port 19812 et si celui-ci est fermé…
J’ai testé avant de répondre, tu devrais faire de même au lieu de supputer.

Je veux bien qu’on parle dans le vide à tour de rôle, mais je n’ai
aucune information écrite nulle part qui va dans ton sens ; donc, si
tu as des infos j’aimerais les voir :?:

Avec le code que je t’ai donné j’ai BESOIN que le port 19812 soit
ouvert. (testé et c’est pour cela que j’ai ouvert ce fil et posé cette
question !)

De par mon expérience, même en utilisant du code debut/fin SQL j’ai eu
des problèmes: il y avait un time out d’au moins 30 secondes pour que
le code fonctionne(ou pas).

Si tu as cette information que les requêtes SQL passent maintenant par
le port 19814 j’aimerais voir tes sources (autre que simplement :
“c’est ce que je constate” SVP).

De plus, si c’est le cas, il serait pour le moins intéressant que 4D
donne clairement cette information.

Actuellement dans
<https://doc.4d.com/4Dv17R3/4D/17-R3/Recevoir-le-resultat-d-une-requete
SQL-dans-une-variable.300-4034459.fr.html>la doc 4D> on a également
des phrases du style:

: Doc 4D

Attention : Vous constatez que dans ce dernier exemple, nous
utilisons des variables process. Ce principe est nécessaire si vous
souhaitez utiliser la base en mode compilé. Dans ce contexte en
effet, il n’est pas possible d’utiliser de variables locales avec la
commande EXECUTE IMMEDIATE.

donc, si toi tu réussis à t’affranchir des contraintes indiquées dans la doc tant mieux…

Manuel, je te fais des excuses : après vérification, je me suis mélangé les pinceaux entre un serveur SQL coupé et la dispo du port 19812. Les requêtes SQL “internes” (d’un client 4D à son serveur) passent bien par ce port, début/fin sql comprises. Ces requêtes là ne font également ni chaud ni froid au plan de recherche (dont je suppose qu’il traite ce qui passe par le 19814, le db4d).

… et de quoi vérifier que le SQL https://forums.4d.com/Post//28776757/1/#28776758est disponible>.