Login mot de passe
forum - Tous les messages
   Tous les messages (JMDGFR)

 Bas   Précédent   Suivant

« 1 2 3 (4) 5 6 7 ... 13 »


#31 Re: DATA_CENTER
JMDGFR Posté le : 2019/1/29 23:01
Je confirme bien qu'il y a un soucis.

En version 23 cette fois. Il ne reconnaît pas mon analyse ...

Erreur à la ligne 8 du traitement Méthode MySQLListeTables.
Vous avez appelé la fonction HListeFichier.
Le WDD <F:\ANALYSE DES PROJETS\WHD Last\Dialyse.wdd> n'a pas été trouvé.
Ce WDD doit être au format compris entre 4.1 et 5.5. Il va être utilisé par le moteur Hyper File 5 pour ouvrir les fichiers au format Hyper File 5.

Informations techniques

Projet : Data Center

Dump de l'erreur du module <WD120HF.DLL> <12.00Kg>.

- Appel WL :
Traitement de <c_HF4WD.MySQLListeTables>, ligne <8>, thread <0>
Fonction <HListeFichier>, n° de syntaxe <1>

- Niveau : erreur fatale (EL_FATAL)

- Code erreur : 73500

- Code erreur WD55 : 3500

- Pas de code d'erreur système

- Pas de message d'erreur système

- Que s'est-il passé ?
Le WDD <F:\ANALYSE DES PROJETS\WHD Last\Dialyse.wdd> n'a pas été trouvé.
Ce WDD doit être au format compris entre 4.1 et 5.5. Il va être utilisé par le moteur Hyper File 5 pour ouvrir les fichiers au format Hyper File 5.

- Infos de debug :
IEWDHF=8019
Module=<WDHF>
Version=<12.00Kg>
Fonction (7,43)

- Infos attachées :
EIT_PILEWL :
Méthode MySQLListeTables (c_HF4WD.MySQLListeTables), ligne 8
Procédure globale ListeTables (Procedures globales de Data Center.ListeTables), ligne 30
Procédure locale ConstruitArbre (w_mainSQL.PROCEDURE.ConstruitArbre), ligne 23
Initialisation de w_mainSQL (w_mainSQL), ligne 21
EIT_COMPOSANT :

EIT_DATEHEURE : 29/01/2019 22:57:42

- Identifiant dans le .err : 70548


#32 DATA_CENTER
JMDGFR Posté le : 2018/11/13 22:18
Salut,

Cela faisait un petit temps que ce problème se posait ....

Connexion sur HFSQL 22 ...

Erreur à la ligne 8 du traitement Méthode MySQLListeTables.
Vous avez appelé la fonction HListeFichier.
Le WDD <F:\ANALYSE DES PROJETS\WHD Last\Dialyse.wdd> n'a pas été trouvé.
Ce WDD doit être au format compris entre 4.1 et 5.5. Il va être utilisé par le moteur Hyper File 5 pour ouvrir les fichiers au format Hyper File 5.

Informations techniques

Projet : Data Center

Dump de l'erreur du module <WD120HF.DLL> <12.00Kg>.

- Appel WL :
Traitement de <c_HF4WD.MySQLListeTables>, ligne <8>, thread <0>
Fonction <HListeFichier>, n° de syntaxe <1>

- Niveau : erreur fatale (EL_FATAL)

- Code erreur : 73500

- Code erreur WD55 : 3500

- Pas de code d'erreur système

- Pas de message d'erreur système

- Que s'est-il passé ?
Le WDD <F:\ANALYSE DES PROJETS\WHD Last\Dialyse.wdd> n'a pas été trouvé.
Ce WDD doit être au format compris entre 4.1 et 5.5. Il va être utilisé par le moteur Hyper File 5 pour ouvrir les fichiers au format Hyper File 5.

- Infos de debug :
IEWDHF=8019
Module=<WDHF>
Version=<12.00Kg>
Fonction (7,43)

- Infos attachées :
EIT_PILEWL :
Méthode MySQLListeTables (c_HF4WD.MySQLListeTables), ligne 8
Procédure globale ListeTables (Procedures globales de Data Center.ListeTables), ligne 30
Procédure locale ConstruitArbre (w_mainSQL.PROCEDURE.ConstruitArbre), ligne 23
Initialisation de w_mainSQL (w_mainSQL), ligne 21
EIT_COMPOSANT :

EIT_DATEHEURE : 13/11/2018 22:15:39

- Identifiant dans le .err : 70548

On ne peut pas se connecter sur les derniers serveurs ?


#33 Re: probleme de suppression de ligne...
JMDGFR Posté le : 2017/10/11 22:54
SI ZR_articles[nVindice].LIB_post_type ="nav_menu_item"
ALORS
ZR_articles[nVindice]..Visible=Faux
FIN

Bonsoir,

pourquoi ne sélectionnes tu pas d'emblée via ta requête ce type d'égalité ?

Si tu exclus d'emblée ce type de ligne, tu ne dois pas te casser la tête à ne pas les afficher puisqu'elle ne sont pas sélectionnée ....

A plus

JMDG


#34 Re: Fichoer ZIP***.tmp
JMDGFR Posté le : 2017/9/1 8:53
Zut .... les Chiefs ne sont pas supprimes .....y a un truc qui cloche ....


#35 Re: Fichoer ZIP***.tmp
JMDGFR Posté le : 2017/8/29 23:49
Merci ....


#36 Re: Fichoer ZIP***.tmp
JMDGFR Posté le : 2017/8/27 16:10
J'avais vu cette procedure.
Elle concerne le client et non le serveur or je retrouve ces zip temporaires dans le fichier temp du serveur (là où tourne php)

J'ai la dernière version de php4wx (normalement) sans phpzip.php...

Sur le serveur php4wd.php contient ceci :

if ($methode=='zip'){
$zip = new ZipArchive;
$zip->open($filename, ZipArchive::CREATE);
$zip->addFromString('resultat.txt',$value);
$zip->close();
$handle = fopen($filename, "rb");
$value = fread($handle, filesize($filename));
}

Est-ce lié car dans ce cas, je ne vois pas de suppression de fichier mais je ne connais que peu de chose en PHP

Voici un exemple de nom: ZIP9AF2.tmp
J'ai mis en place une routine qui les détruits mais c'est pas très propre comme système.
Bien à toi

J'espère que tu as bien profité de tes vacances.


#37 Re: Fichoer ZIP***.tmp
JMDGFR Posté le : 2017/8/19 13:47
C'est visiblement lié aux procédures php des accès.
Celle-ci sont censées supprimer ces fichiers temporaires mais cela ne semble pas fonctionner ....


#38 Fichoer ZIP***.tmp
JMDGFR Posté le : 2017/8/15 11:37
Bonjour,

De retour de vacances, je m'y remets.

Depuis quelques temps, j'ai une accumulation de fichier ZIP****.tmp qui s'accumule dans le répertoire des temporaires de windows. Le **** correspond à un donnée en HEXA .... Il y en a telement que cela perturbe le focntionnement du système ....

Je ne parvins pas à savoir de quel accès cela provient ....

Cela te dis quelque chose ?


#39 Placement des classes des tables
JMDGFR Posté le : 2017/6/13 0:29
Bonsoir,

1) J'ai créé des classes pour gérer l'extraction des données ainsi que l'injection de mes données dans les différentes DB.

En fait il n'y en a qu'une dans laquelle je fais des insert et des updates (avec utilisation de sqlmanagex donc). Les autres sont intouchables et donc je ne procède que par des requetes select, sans utiliser les classes des tables.

J'ai declaré comme membre de manière dynamique php4wd dans chacune d'entres elles. Ensuite l'instanciation de php est automatique lors l'instanciation la classe conteneur.

Pas de soucis.

Par contre j'ai eu des problèmes avec les tables .... j'ai tenté de les déclarer comme PHP comme membre dynamique de la classe conteneur puis de les instancier en fonction des besoins. Cela déconnait au moment de la description des fameuses tables. Je les donc ai rapatriées en début de projet ... quand j'ai découvert qu'il y avait d'autres bêtises .... et depuis lors cela roule. Néanmoins, tout mettre encapsulé dans une classe serait plus simple pour en faire un composant ..... encore que ....

Donc ma question est simple, cela marchera t'il si je les remet dans la classe ou faut-il qu'elles soient globales au projet....
2) Penses tu possible de pouvoir dans php de faire passer une requete mysqlexec ... en source de données ou équivalent ? Les sources de données sont je trouve faciles à manipuler et ce serait bien pratique de transformer une requête en source de données (hexecuterequetesql le fait)
De nouvelles méthodes pourraient être ajoutées comme mysqlexecverssourcededonnes .....
J'ai rechercher dans les possibilités du wlangage mais
Bien à toi

JMDG


#40 ..PHP4WD ... 2 touts petits bug ....
JMDGFR Posté le : 2017/6/5 16:12
En regardant les trace de mes instanciations de table ....je constate que cela déconne ....
"m_" n'existe pas dans la table ....
"m_NO" n'existe pas dans la table .....
"m_YES" n'existe pas .... gnagnagna

Bref

Dans DecritTable:

v_SQLQuery = "SELECT "
v_SQLQuery +="INFORMATION_SCHEMA.COLUMNS.Column_name,"
v_SQLQuery +="INFORMATION_SCHEMA.COLUMNS.data_type,"
v_SQLQuery +="INFORMATION_SCHEMA.COLUMNS.is_nullable,"
v_SQLQuery +="case"
v_SQLQuery +=" when INFORMATION_SCHEMA.KEY_COLUMN_USAGE.column_name is not null then 'PRI' else '' "
v_SQLQuery +="end AS 'CU',"
v_SQLQuery +=" INFORMATION_SCHEMA.COLUMNS .column_default,"
LA *****> v_SQLQuery +=" '' AS 'RIEN' "
v_SQLQuery +=" from INFORMATION_SCHEMA.COLUMNS "
v_SQLQuery +=" left join INFORMATION_SCHEMA.KEY_COLUMN_USAGE on "
v_SQLQuery +=" INFORMATION_SCHEMA.COLUMNS.table_name= INFORMATION_SCHEMA.KEY_COLUMN_USAGE.table_name"
v_SQLQuery +=" and INFORMATION_SCHEMA.COLUMNS.column_name= INFORMATION_SCHEMA.KEY_COLUMN_USAGE.column_name"
v_SQLQuery +=" where INFORMATION_SCHEMA.COLUMNS.table_name = '"+pNomTable+"'"

Oubli de nommer une colonne vide

et dans chaineSGBD:

sRetour+= " WHEN auto_inc.name is NOT Null THEN 'T' ELSE '' "
sRetour+= " END AS 'AI' "

Le AS 'AI' était avant le 'END'

Comme cela tout le monde ne se casse pas trop la tête !

A+



 Haut
« 1 2 3 (4) 5 6 7 ... 13 »