John_attend

Bonjour à tous, Je crois que tout est dans le titre. Je suis à la recherche d'une classe PHP (ou d'un script tout fait) qui convertit un fichier Excel en HTML, avec conservation intégrale des couleurs et de la mise en forme. Je souhaiterais faire quelque chose un peu comme la fonction "View as HTML" intégrée à Gmail qui permet d'afficher les fichier Excel, Word etc. sans avoir besoin de les télécharger. (mais juste le cas Excel m'intéresse) Je vois beaucoup l'inverse sur Internet, mais pas vraiment XLS => HTML... Merci d'avance de l'aide que vous pourrez m'apporter

Fonctionne parfaitement sur Firefox 3. Sous IE 7, il fonctionne à l'affichage sur la page mais pas à l'affichage dans les infobulles (le caractère n'est pas reconnu dans les infobulles). Pas testé sur les autres navigateur

KaRaK > Justement la fonction que tu me propose permet de faire des césures, moi c'est tout le contraire que je veux (je veux empêcher les césures provoquées par les tirets). jcaron > Merci !! C'est exactement ce qu'il me fallait Merci à vous!

Bonjour à tous, Lorsque l'on affiche un texte dans une page HTML, le tiret (ou trait d'union) "-" peut faire faire des sauts de lignes automatiquement. Comment faire pour empêcher cela ? Je voudrais que le tiret soit considéré comme toutes les autres lettres, c'est à dire comme un caractère ne pouvant pas donner lieu à la coupure d'un mot entre deux lignes. Merci d'avance.

Si tu restaures le dump sur une autre base temporaire je vois pas pourquoi cela affecterait les tables de la base principale... Par contre penses bien à préciser un nom de base différent que celle sauvegardée lors de la restauration, sinon ça va tout restaurer sur ta base principale

Ok, c'est aussi ce à quoi j'avais pensé. Merci de vos réponses

Bonjour à tous ! Mon problème est simple. Pour mes export de base de données, j'utilise la commande mysqldump en sauvegardant toute ma base de données. Pour la restaurer à partir de ces backup, j'utilise la commande mysql database < fichier.sql. Mais j'aimerais ne pouvoir restaurer que certaines tables. Je sais qu'il n'est possible d'exporter que certaines tables avec mysqldump, mais je ne vois pas comment ne restaurer que certaines tables. Il n'est par exemple pas possible de faire mysql --database=mabase --tables table1 table2 table3 < fichier.sql. Quelqu'un saurait comment faire ça ?? Merci d'avance

Bonjour à tous ! Mon problème est très simple. J'essaye d'exécuter un script PHP5 avec la commande system, mais ça ne fonctionne pas : system("/usr/local/bin/php-v5 /home/monsite/www/monscript.php5"); Voilà ce que renvoit ce code : Le fichier contenant le code se trouve dans /home/monsite/www/. J'obtiens à chaque fois une erreur 404, quelque soit le répertoire que je met en paramètre. Quelqu'un a une idée ? Après avoir tout essayé, je sèche complètement. Petite précision : vous me direz surement qu'il s'agit réellement d'une erreur 404. Mais quand je tape : /usr/local/bin/php-v5 /home/monsite/www/monscript.php5 sous putty, ça fonctionne bien. Sous la commande PHP system, non. Merci d'avance de l'aide que vous pourrez m'apporter

Merci de vos réponses La liste n'est pas longue comme le bras, je n'ai donc pas à m'inquiéter. Mais alors concrètement, qu'est ce qui provoque cela au niveau des scripts PHP ? Est ce que je peux changer quelque chose dans mes scripts pour arrêter de voir ces zombies ? Cela va peut être vous paraître bête, mais cela n'aurait il pas un rapport avec la fonction PHP exit() qui arrête l'éxecution ?

Bonjour tout le monde, Quand j'utilise la commande top sur putty, il n'est pas rare de voir ce genre de ligne : 22970 mysite 17 0 0 0 0 Z 2 0.0 0:00.07 php-v5 <defunct> 15488 mysite 17 0 28420 8004 6416 R 2 0.2 0:00.06 php-v5 19339 mysite 17 0 0 0 0 Z 1 0.0 0:00.03 php <defunct> J'aimerais savoir ce que signifie le "defunct" qui survient visiblement avec certains scripts PHP ou PHP5. Qu'est ce que ça signifie concrètement ? Doit on s'inquiéter quand on voit ce genre de chose ou est ce que cela signifie forcément qu'il y a un problème ? En cherchant sur Google je ne trouve pas réellement la réponse à cette question. Merci d'avance

Bonjour à tous les webmasters du Hub ! Afin d'optimiser les performances de l'espace membre de mon site Web, je stocke les informations principales du membre dans des variables de sessions (exemple : pseudo, id, etc). (au lieu de faire une connexion à MySQL à chaque fois) Toutefois, mes fichiers de sessions commence à atteindre à un nombre de 30 variables dont certaines sont des tableaux d'entiers pouvant contenir eux même jusqu'à 20- 25 entiers... Au final, ça ne fait pas forcément un fichier très gros, mais un fichier avec beaucoup de variables. J'aimerais avoir votre avis, pensez vous que cela peut atténuer les performances du serveur ?? (c'est un Bixeon qui peut accueillir 400 - 450 connectés simultanément). Sachant que je fais un session_start sur la quasi totalité des pages (donc désérialisation de la session sur chaque page). Je ne demande pas exactement si c'est possible avec mon serveur mais si en règle général le nombre de variables influe beaucoup sur les performances (ou si c'est plutôt la taille du fichier de session en octets). Merci d'avance de votre avis PS : Au cas où, pensez vous que le fait de répartir ces fichiers de sessions dans plusieurs répertoires temporaires peut pallier à ce problème ??

Pour ceux que ça intéresse, je viens de trouver une info super importante (enfin, à mon goût). Avec MySQL 4, si vous avez un champ non signé auquel vous soustrayez une valeur plus grand que la valeur déjà dans le champ, cette valeur deviendra 0. Alors que sous MySQL 5, cette valeur prendra taille_max. Exemple, vous avez un champ int(11) "nombre" non signé qui vaut 4. Sous MySQL 4, si vous faites UPDATE SET nombre = nombre - 5; alors nombre vaudra 0. Sous MySQL 5, la valeur prendra 4294967295. Imaginez les bug...

Merci, je vais regarder ça plus en profondeur

Bonjour à tous, Dans quelques temps, je compte changer de serveur MySQL, et par la même occasion upgrader la base de données de 4.x vers 5.x. J'ai déjà entendu des echos comme quoi il n'y avait aucun problème de comptabilité entre les requêtes SQL, qui fonctionnent sur MySQL4 et ces mêmes requêtes sur MySQL5. Toutefois, je ne compte pas faire ça à la légère, si je dois changer de version ça concernera les quelques dizaines de milliers de membres du site concerné. Bien sûr, je compte d'abord tester toutes les requêtes (tous les scripts) sur ce nouveau serveur, avec cette nouvelle version. Mais j'appréhende que quelque chose m'échappe. En fait, y a t'il quelque chose qui fasse que, dans un certain cas, une requête qui fonctionnait sous MySQL 4 ait des réactions imprévisibles sur MySQL 5 ? Une infime modification qui fasse qu'une syntaxe soit interprétée differement, je sais pas... Toute info est bonne à prendre. ... et je vous serais reconnaissant des info que vous pourrez m'apporter John

J'espère que mon site ne sera pas coupé pendant plusieurs jours et / ou qu'il n'aura pas de coupure de plusieurs heures plusieurs fois par mois. J'espère également ne pas avoir a contacté le support pour que le problème se règle de lui même. Est ce vraiment exigeant ? Et le rêve devient réalité Mais est ce vraiment respecté ? D'autre part, et le titre de mon sujet était peut être trop précis, je ne cherche pas à tout prix à savoir si l'uptime en lui même est bon, mais si le service est bon, d'une manière générale. Est il arrivé qu'une perte de données résulte d'une coupure des serveurs (mutualisé) ? Ou leur infrastructure est elle prévue pour pallier à ces problèmes ? xgamer soulève dailleurs un problème important qui ne concerne pas l'uptime : C'est ce genre de petits problèmes en plus qui m'intéresse aussi. A quoi est ce due ? Un client d'OVH doit il se faire à l'idée d'oublier la fonction mail ? Enfin, Leonick aborde un sujet intéressant. Le service est il meilleurs chez les PLAN que chez les GP ? Ce n'est pas forcément évident en théorie... Mais en pratique ? Je ne cherche pas à dénigrer OVH, au contraire, si on ne pouvait m'en dire que du bien je n'aurais pas d'hésitation. Merci de vos réponses