Vous devez avoir le détail de l'erreur dans le fichier de Log.
Merci de le communiquer sur le Forum ou l'envoyer à support@toolware.fr.

Il s'agit peut-être d'un cas de figure particulier générant un bug.

Voici le message que j'ai récupérer dans le fichier de log:
2010-09-20 14:38:02 ** ERROR ** on file 'C:wampwwwprojecttooljsonPlanning.php' at line (128)
2010-09-20 14:38:02 ** ERROR ** cause = Undefined variable: pStart

Effectivement la variable est initialisée avec un 's' minuscule dans 'pstart' (ligne 127 du fichier tooljsonPlanning.php). En mettant un 'S' majuscule le problème a été résolu.

Merci.

Curieux...
Lorsque je lance l'impression du planning avec le compte administrateur, l'aperçu du planning débute en février, alors qu'avec le compte chef de projet il commence bien à la date indiqué (21/09/2010)? Ceci se produit après avoir modifié la déclaration de la variable pStart (ligne 127 du fichier tooljsonPlanning.php).

Si j'annule cette opération, l'aperçu pour impression est correct avec le compte administrateur mais indique l'erreur décrite précédemment avec le compte chef de projet.

Je ne comprend pas trop pourquoi?

Bonjour,

Effectivement , le comportement indiqué semble bizarre.
L'erreur signalée n'est pas reproduite sur la version en cours de développement.

Cette édition a été retouchée sur la version en cours de développement (V1.2.0).
Elle sera alors accessible à partir du menu "Etats", et pourra prendre la date de fin en paramètre.

Je vous propose de tester le comportement constaté sur la nouvelle version dés qu'elle sera disponible (d'ici la fin du mois).

Cordialement,
Babynus.

Bonjour,

La version V1.2.0 vient d'être déployée.
Pouvez-vous vérifier que le comportement que vous constatiez n'est pas reproduit sur vos données ?

Merci.

Babynus.

Lorsque je clic sur le planning je n'ai aucun affichage. Le logo de temporisation tourne sans fin. Le fichier de log m'indique:

2010-09-30 15:38:14 ** ERROR ** ERROR **
2010-09-30 15:38:14 ** ERROR ** on file 'C:wampwwwprojecttoolhtml.php' at line (291)
2010-09-30 15:38:14 ** ERROR ***** cause = htmlspecialchars() [function.htmlspecialchars]: Invalid multibyte sequence in argument

-> Par contre si je clic sur le bouton pour imprimer le planning j'y ai alors accès sur l'écran de visualisation avant impression.

Bonjour,

L'erreur que vous signalez semble venir de l'unicode.
Un des caractères utilisé dans vos données doit être un caractère spécial (copié de word, ou format non européen).

J'investigue...

Babynus.

bonjour,

L'anomalie vient bien d'un problème avec l'UTF-8.
Par contre je n'arrive pas à la reproduire.

J'ai ouvert le bug #206 sur la base de track :
http://projectorria.toolware.fr/track/view/main.php
et j'ai attaché un fichier de test : html.php
Login : guest/guest ou invité/invité

Pourriez-vous récupérer ce fichier, le déposer dans le répertoire /tool en remplacement de l'existant, re-tester et me transmettre le résultat ?

Merci.
Babynus.

Bonjour,

J'ai renommé le fichier toolhtml.php en toolhtml_old.php
J'ai copier dans le répertoire tool le fichier que vous m'avez indiqué.

Le message d'erreur sur le fichier de log reste le meme lorsque je clic sur planning:
2010-10-01 10:04:16 ** ERROR ** ERROR **
2010-10-01 10:04:16 ** ERROR ** on file 'C:wampwwwprojecttoolhtml.php' at line (291)
2010-10-01 10:04:16 ** ERROR ***** cause = htmlspecialchars() [function.htmlspecialchars]: Invalid multibyte sequence in argument

Pour information j'ai essayé la version 1.2.0 avec une base de données vierge et le planning s'affiche correctement.
Je vous indique la manière de procéder pour la mise à jour de la version V1.2.0. Il y a peut être une manip de ma part qui ne convient pas.

J'ai installé les fichiers sources dans un nouveau répertoire à la racine de mon site web. J'ai dupliquer la base de données utilisée pour la version V1.1.0. J'ai lancé l'application en tapant l'url d'accès. J'ai modifié les paramètres de connexion. J'ai ensuite taper l'url http://monserveur/project/db/maintenance.

Encore une information (je pense qu'elle est liée): lorsque je clic sur Tickets ou sur Activités, la fenetre affichant la liste indique "Une erreur est survenue" et le message d'erreur du fichier de log est le meme. Par contre la liste des Jalons s'affiche normalement.

---------------------------------------
Après quelques recherche j'ai identifié un élément qui pose problème. Dans le champ "nom" des activités, le caractère "à" génère une erreur (pas les autres caractères accentué).

Ce qui est curieux c'est que si je crée une activité dans l'application avec comme nom "Mise à jour" cela marche très bien. Mais si je crée une activité nommée "test" (qui s'enregistre parfaitement) et que je modifie dans la base de données la valeur du champ "name" de la table "activity" en faisant un copier/coller de la valeur de l'activité précédente à savoir "Mise à jour", l'application génère alors l'erreur décrite plus haut.

J'espère que ces informations pourront vous être utile. Merci pour votre aide précieuse et pour votre travail remarquable.

Merci pour vos précisions.

Je vous confirme que l'anomalie vient de vos données.
C'est pour cela que tout marche bien sur une base vierge.
La procédure d'installation que vous appliquez n'est pas en cause

Pourriez-vous m'indiquer avec quel outil vous modifiez vos données directement dans la base ?
- phpMyAdmin ? quelle version ?
- TOAD pour MySQL ?
- autre ?
Je pense que cet outil gère mal l'UTF-8 est génère des données UTF-8 mal formées.
Je voudrais pouvoir reproduire l'anomalie pour apporter une solution "qui ne plante pas".

Merci.

J'utilise:
PHPMyAdmin 2.10.1
Client MySql 5.0.45
Serveur MySql 5.0.45
----------------------------
Pour information j'ai trouvé un moyen pour éviter les erreurs décrites en utilisant phpmyadmin. J'ai une application Project'Or de production. Pour tester une nouvelle version je crée donc une version de pré-production avec une nouvelle base de données. Cela me permet d'éviter toute perte de données en cas de dysfonctionnement.

Auparavant je réalisais les opérations suivantes :
1) Création d'une nouvelle base de données
2) Export au format sql de la base de données existante
3) Coller le script généré au point 2 dans la fenetre de commande sql de phpmyadmin => exécuter
Cette méthode génère les erreurs décrite jusqu'ici.

Voici une procédure PhpMyAdmin pour éviter ces erreurs:
1) Création d'une nouvelle base
2) Dans la base de production : onglet "Opération" => "Copier la base de données vers" : indiquer le nom de la nouvelle base de données
3) Décocher l'option "Faire CREATE DATABASE avant la copie"
4) Exécuter.

Le problème semble être résolu ainsi.

Heureux d'apprendre que votre problème est résolu.

Effectivement l'exécution d'une requête copiée-collée à la main dans phpMyAdmin (ou dans tout autre outil) peut avoir des conséquences inattendues si toute la chaîne n'est pas en UTF-8.

J'espère que votre retour d'expérience pourra profiter à d'autres.
Merci pour votre contribution.

Bonne continuation.
Babynus.