Le serveur d'application de WEBDEV qui héberge vos sites et webservices, se charge à chaque interrogation d'un client d'exécuter les traitements serveurs, afin de renvoyer :

• une page dans le cas d'un site en mode awp, ou la première page d'un site en mode session,
• le résultat d'une procédure dans le cas d'un webservice.

Avant de renvoyer une page d'un site, ou le résultat d'une fonction d'un webservice, le serveur d'application doit effectuer les actions suivantes :

• exécuter le code serveur de déclaration de toutes les classes,
• exécuter le code serveur de déclaration de toutes les collections de procédure,
• exécuter le code serveur d'initialisation du projet,
• dans le cas d'un site, s'il s'agit du lancement de la page première page d'un site dynamique, on d'une page d'un site en mode awp :
  
  • exécuter le code serveur d'initialisation de tous les champs de la page,
  • exécuter le code serveur d'initialisation de la page elle-même.
• dans le cas d'un webservice, exécuter le code de la procédure, jusqu'au "RENVOYER" de son résultat.

Si l'un de ces traitements serveurs ne va pas à son terme car une fonction appelée déclenche le mécanisme de sécurité du WLangage, le serveur d'application de WEBDEV va renvoyer la réponse :

• ERR_NO_CURRENT_PAGE s'il s'agissait d'une page d'un site,
• ERR_NO_CURRENT_PAGE_WEBSERVICE dans le cas d'une procédure d'un webservice.

Par exemple, un appel de la fonction FinProgramme dans l'un des codes serveurs appelé, provoquera le retour ERR_NO_CURRENT_PAGE puisqu'il ne sera pas possible de finaliser toutes les l'exécutions nécessaires pour aller jusqu'au résultat. FinProgramme est l'exemple le plus parlant, mais tout appel d'une fonction WLangage qui va échouer en déclenchant le mécanisme de sécurité du WLangage, sans qu'on ne fasse le test de son résultat, provoquera l'arrêt comme un FinProgramme. Exemples :

• utilisation d'une connexion à une base de données sans avoir testé son ouverture : la fonction HOuvreConnexion a retourné faux mais son résultat n'a pas été testé, et on tente de lire des données via cette connexion,
• utilisation des données d'une requête sur une base de données, sans avoir testé sa bonne exécution : la fonction HExécuteRequete a retourné faux, mais sont résultat n'a pas été testé, et on tente de parcourir le résultat de la requête.
• lecture d'un fichier de paramètres, sans avoir testé son existence ou les droits d'accès à son contenu...

Lorsque le retour ERR_NO_CURRENT_PAGE apparaît sur un serveur après déploiement, sans apparaître sur le poste de développement (*), c'est donc qu'une fonction d'un traitement serveur stoppe l'exécution, sans que le développeur ne teste le résultat de la fonction. Dans le cas d'un site, la fonction DBGActiveLog peut rapidement permettre d'obtenir un log d'exécution des fonctions appelées lors de l'ensemble de l'initialisation du site. Le fichier .Wlog obtenu permet alors de repérer la fonction qui a terminé l'exécution. La fonction TraceConstruit est également pratique, car elle peut être configurée pour afficher une trace à l'écran tant que l'on se trouve sur le poste de développement, et être redirigée vers un fichier en production par un simple appel de la fonction TraceDébut.

(*) pour un site ou un webservice, une différence de résultat entre le test sur le poste de développement et la version déployée, vient le plus souvent d'une différence dans les droits d'accès (cf. avec un serveur Web il y a deux ordinateurs dans un !).