Bonjour;
Free a fait une modification de structure sur les sites et apparemment utilise php4 maintenant.
Depuis je ne peux plus faire de réservation avec OpenFlyers.
Je me connecte à la base je peux cliquer pour faire une réservation mais lorsque je valide j'ai l'erreur suivante:

Error: Access denied for user: 'sans.borne@212.27.40.172' to database 'sans.borne'

Tout le reste semble fonctionnel je peux optimiser la base en 'admin" etc.Seule la réservation coince.
Avec un navigateur
si je lance en url:
http://sans.borne@212.27.40.172 j'ai comme résultat:
ERREUR 404
The requested URL / was not found on this server.

Apache1.3.29 - ProXad [Feb 23 2004 01:38:11] Server at 212.27.40.172 Port 80

En mode console nslookup me renvoie:
172.40.27.212.in-addr.arpa name = perso42-g.free.fr.

Par contre http://sans.borne@212.27.40.130 me connecte bien sur la base de données sans.borne@sql.free.fr
Donc je ne sais pas où dans OpenFlyers cette adresse IP 212.27.40.172 est récupérée pour être utilisée.Est ce dans l'ancienne config avant la modif Free mais puis je la modifier ?
L'optimisation des tables est Ok.
Si vous avez un tuyau merci d'avance.Je précise que je n'ai pas modifié quoi que ce soit et que cela est vraiment suite à la modif de structure chez Free:
Voici les messages de Free25 Mars)

L'ancienne architecture pages persos est coupée aujourd'hui. Certains comptes peuvent toujours etre inacessibles le temps des mises à jour DNS. (1 jour maximum)

(du 18 au 25 Mars)
Dans le cadre de l'amélioration du service, l'ensemble des pages personnelles étant toujours sur l'ancienne architecture web seront migrées. Cela entrainera une coupure des acces FTP ainsi que des acces en lecture seule (php/sql).

Merci d'avance.
Patrick



Envoyer mon message (26-03-04 19:48)

Désolé mais l'application marchant avant le changement chez Free, l'aide ne pourra venir que d'eux a priori...

Pour ma part, je vous invite à demander au support de Free, quelles sont les "droits SQL" donnés à l'utilisateur que vous êtes. En effet, le seul droit qui est utilisé dans les réservations qui ne le soit pas ailleurs est UNLOCK et LOCK. Si Free ne vous autorise pas à utiliser ces commandes alors que MySQL n'est pas transactionnelle (du moins par défaut), une application du type d'OpenFlyers est incompatible avec leur formule d'hébergement.

Le LOCK/UNLOCK est là pour éviter des manipulations simultanées de la table de réservation.

Cordialement,

Patrick Hubscher

Bonjour,

Je me suis un peu penché sur le problème Free. Il semble qu'ils aient migré leur base MySQL en version 4 également. Or, les droits changent par rapport à la version 3 pour obtenir celui de locker une table.

Ils auraient donc dû metter à jour les droits en même temps que la version de MySQL. Il est possible qu'ils fassent cette modification si on la leur demande.

En attendant, j'ai découvert que dans le manuel MySQL, on suggère plutôt d'éviter l'usage intensif des lock. Préférer plutôt l'usage d'update simples qui sont elles même des transactions atomiques. On propose également de se référer aux fonctions Get_lock/Release_lock, qui posent un verrou le temps d'une transaction.
En espérant que j'ai bien compris leur fonctionnement, j'ai remplacé les lignes suivantes dans le fichier includes/record_booking.php :

if($result=$database->query('lock tables clubs read, members read, profiles read, instructors read, authentication read, exceptionnal_inst_dates read, regular_presence_inst_dates read, booking write, logs write'))

par :

if($result=$database->query('select get_lock(\'booking\',600)'))

et :

//$database->query('unlock tables');

par :

$database->query('select release_lock(\'booking\')');

C'est à dire un time out de 10 minutes sur la transaction... Ca marche en tout cas et je pense que ceci peut remplacer le lock interdit par Free en attendant qu'il soit rétabli.

Cordialement,
Côme.

Merci pour ses informations...

Je vous avouerais que l'intégration d'un support des transactions serait bien plus utile que le système de lock... Apparemment cela existe avec le type de table innoDB mais ce type est désactivé par défaut.

Cordialement,

Patrick Hubscher

Attention, la méthode get_lock() ne vérouille aucune table, ni aucun enregistrement. C'est juste un outil de synchronisation entre les clients.
Donc, l'exemple ci dessus peut fonctionner, mais si une des tables que l'on souhaite vérouiller en écriture (booking, logs) est modifiée par une autre partie de l'application, on peut s'attendre à des problèmes...

Soeren,
Equipe OpenFlyers

Bonjour,
J'avais signalé ce problème il y a quelque temps avec serveur free. Un ancien compte free fonctionnait alors qu'un nouveau donnait le resultat décrit. Je suis preneur d'une solution.

La solution supposée est exposée juste un peu plus haut.

Cordialement,

Patrick

Ok cela fonctionne après modifs,
Merci

Ok, merci pour l'info. La doc MySQL n'était pas trés claire à ce sujet.... Je me doutais que ce type de lock était moins solide.

Côme

J'ai contacté Free au sujet du problème de droits concernant les LOCK/UNLOCK via http://question.free.Fr

Réponse :

"L'utilisation de LOCK/UNLOCK n'est pas autorisé."


C'est tout aussi clair que regrettable.

Soeren,
Equipe Openflyers

Re bjr,

comme je l'ai dis dans mon post (doublon http://forums.openflyers.org/read.php?f=1&i=151&t=151), çà fonctionne... mais seulement pour les réservations avion. Quand on veut mettre les dispo des instructeurs, çà ne fonctionne plus.
Que faire ? Si le pb vient de free, existe-t-il un autre hebergeur gratuit qui accepte le php mysql ?
à bientôt,
Bruno.

Ca fonctionne aussi pour les instructeurs. Il suffit de faire exactement la même modification telle qu'exposée dans mon post précédent mais cette fois dans le fichier /includes/record_instructors_rests.php. Rechercher la ligne à modifier en cherchant le mot "lock". Par sécurité, donner le même nom "booking" au lock logiciel (car il y a des tables en commun avec la réservation "pilotes".

J'avais oublié ce fichier dans ma correction initiale, mais a priori il s'agit de la seule autre modification à réaliser.

Cordialement,
Côme