Voici quelques mois que je travaille sur la globalisation (pr=E9sentation=
=20
en plusieurs langues), et =E7a commence =E0 tourner pas trop mal.
Ce que j'ai fait en dernier est de d=E9velopper la m=EAme chose avec appe=
l=20
d'une page ma=EEtresse. Sur ma machine =E7a marche bien.
Quand j'essaie d'envoyer =E7a sur un serveur de test, pas de pot, erreur =
500, probl=E8me d'acc=E8s =E0 SQL.
Ah, SQL pour traduire mes pages alors que toutes les traductions sont=20
dans des pages de ressources ?
Alors je r=E9essaie sur ma machine apr=E8s avoir renomm=E9 le r=E9pertoir=
e=20
App_Data, et l=E0 je m'aper=E7ois que c'est la persistance du profil qui =
requiert une base SQL, puisque l'exception se l=E8ve sur un code=20
auto-g=E9n=E9r=E9, =E0 l'instruction GetPropertyValue("LanguagePreference=
"),=20
voir ci-dessous.
Alors j'en arrive =E0 ma question : est-ce que juste pour se rappeler=20
quelle langue on parle (s'agissant d'une culture neutre, l'information,=20
c'est : "fr" ou "en", et puis c'est tout) il n'y a point de salut=20
en-dessous de 10 Mo et demi ? C'est la taille de la base par d=E9faut=20
pondue par SQL Express =E0 condition d'ex=E9cuter le programme avec les=20
droits administrateur -si cette condition n'est pas remplie et qu'il n'y =
a pas de base c'est erreur 500.
On a beau dire que les prix des disques descendent tout le temps, sur un =
forfait d'h=E9bergement, ce n'est pas vraiment n=E9gligeable.
Sur le serveur en ligne les autres pages fonctionnent et je ne vois pas=20
de fichier de base de donn=E9es, mais =E7a, il est peut-=EAtre cas=E9 ail=
leurs.
public class ProfileCommon : System.Web.Profile.ProfileBase {
public virtual string LanguagePreference {
get {
return ((string)(this.GetPropertyValue("LanguagePreference")=
));
}
set {
this.SetPropertyValue("LanguagePreference", value);
}
}
public virtual ProfileCommon GetProfile(string username) {
return ((ProfileCommon)(ProfileBase.Create(username)));
}
}
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Gloops
Oops, lors de la sauvegarde de la culture pour sa persistance, j'ai ce problème de rejet de la connexion SQL sur une page, qui fait appel à une page maîtresse dérivée d'une classe téléchargée toute prête (LitWare, pour ceux à qui ça évoque quelque chose), et pas sur une autre page , que j'ai mise au point individuellement (avec toute la lourdeur que représente le fait de refaire une partie du travail à chaque page).
Je viens de comprendre pourquoi. Ce n'est pas le principe de la page maîtresse qui pose problème, mais c'est que la classe dérivée fai t appel au profil, tandis que pour ma part j'ai fait appel aux données de session. Finalement, je viens probablement de proposer la seule réponse qui puisse se trouver à ma question, alors que je ne croyais pas vraiment au départ en recevoir une.
Ensuite, certes les bases de données ont d'autres utilisations et j'ai en perspective un autre problème, à gérer avec mon hébergeur, à la suite de quoi je regarderai de combien la base grossit quand on stocke un profil dedans. C'est vrai qu'il y a lieu de distinguer les notions de coût global et de coût marginal ...
Je crois que je tiens là un sujet pour une autre page, euh ... dans un petit paquet de semaines, quand même.
Bon alors on dit quoi, déjà ... merci à ceux qui ont pris le temps de lire.
http://www.zailes.org _____________________________________ Gloops a écrit, le 01/05/2008 14:47 :
Bonjour tout le monde,
Voici quelques mois que je travaille sur la globalisation (présentati on en plusieurs langues), et ça commence à tourner pas trop mal.
Ce que j'ai fait en dernier est de développer la même chose avec ap pel d'une page maîtresse. Sur ma machine ça marche bien.
Quand j'essaie d'envoyer ça sur un serveur de test, pas de pot, erreu r 500, problème d'accès à SQL.
Ah, SQL pour traduire mes pages alors que toutes les traductions sont dans des pages de ressources ?
Alors je réessaie sur ma machine après avoir renommé le réperto ire App_Data, et là je m'aperçois que c'est la persistance du profil qu i requiert une base SQL, puisque l'exception se lève sur un code auto-généré, à l'instruction GetPropertyValue("LanguagePreferen ce"), voir ci-dessous.
Alors j'en arrive à ma question : est-ce que juste pour se rappeler quelle langue on parle (s'agissant d'une culture neutre, l'information, c'est : "fr" ou "en", et puis c'est tout) il n'y a point de salut en-dessous de 10 Mo et demi ? C'est la taille de la base par défaut pondue par SQL Express à condition d'exécuter le programme avec les droits administrateur -si cette condition n'est pas remplie et qu'il n' y a pas de base c'est erreur 500.
On a beau dire que les prix des disques descendent tout le temps, sur u n forfait d'hébergement, ce n'est pas vraiment négligeable.
Sur le serveur en ligne les autres pages fonctionnent et je ne vois pas de fichier de base de données, mais ça, il est peut-être casé a illeurs.
public class ProfileCommon : System.Web.Profile.ProfileBase {
public virtual string LanguagePreference { get { return ((string)(this.GetPropertyValue("LanguagePreference" ))); } set { this.SetPropertyValue("LanguagePreference", value); } }
public virtual ProfileCommon GetProfile(string username) { return ((ProfileCommon)(ProfileBase.Create(username))); } }
Oops, lors de la sauvegarde de la culture pour sa persistance, j'ai ce
problème de rejet de la connexion SQL sur une page, qui fait appel à une
page maîtresse dérivée d'une classe téléchargée toute prête (LitWare,
pour ceux à qui ça évoque quelque chose), et pas sur une autre page , que
j'ai mise au point individuellement (avec toute la lourdeur que
représente le fait de refaire une partie du travail à chaque page).
Je viens de comprendre pourquoi. Ce n'est pas le principe de la page
maîtresse qui pose problème, mais c'est que la classe dérivée fai t appel
au profil, tandis que pour ma part j'ai fait appel aux données de
session. Finalement, je viens probablement de proposer la seule réponse
qui puisse se trouver à ma question, alors que je ne croyais pas
vraiment au départ en recevoir une.
Ensuite, certes les bases de données ont d'autres utilisations et j'ai
en perspective un autre problème, à gérer avec mon hébergeur, à la suite
de quoi je regarderai de combien la base grossit quand on stocke un
profil dedans. C'est vrai qu'il y a lieu de distinguer les notions de
coût global et de coût marginal ...
Je crois que je tiens là un sujet pour une autre page, euh ... dans un
petit paquet de semaines, quand même.
Bon alors on dit quoi, déjà ... merci à ceux qui ont pris le temps de lire.
http://www.zailes.org
_____________________________________
Gloops a écrit, le 01/05/2008 14:47 :
Bonjour tout le monde,
Voici quelques mois que je travaille sur la globalisation (présentati on
en plusieurs langues), et ça commence à tourner pas trop mal.
Ce que j'ai fait en dernier est de développer la même chose avec ap pel
d'une page maîtresse. Sur ma machine ça marche bien.
Quand j'essaie d'envoyer ça sur un serveur de test, pas de pot, erreu r
500, problème d'accès à SQL.
Ah, SQL pour traduire mes pages alors que toutes les traductions sont
dans des pages de ressources ?
Alors je réessaie sur ma machine après avoir renommé le réperto ire
App_Data, et là je m'aperçois que c'est la persistance du profil qu i
requiert une base SQL, puisque l'exception se lève sur un code
auto-généré, à l'instruction GetPropertyValue("LanguagePreferen ce"),
voir ci-dessous.
Alors j'en arrive à ma question : est-ce que juste pour se rappeler
quelle langue on parle (s'agissant d'une culture neutre, l'information,
c'est : "fr" ou "en", et puis c'est tout) il n'y a point de salut
en-dessous de 10 Mo et demi ? C'est la taille de la base par défaut
pondue par SQL Express à condition d'exécuter le programme avec les
droits administrateur -si cette condition n'est pas remplie et qu'il n' y
a pas de base c'est erreur 500.
On a beau dire que les prix des disques descendent tout le temps, sur u n
forfait d'hébergement, ce n'est pas vraiment négligeable.
Sur le serveur en ligne les autres pages fonctionnent et je ne vois pas
de fichier de base de données, mais ça, il est peut-être casé a illeurs.
public class ProfileCommon : System.Web.Profile.ProfileBase {
public virtual string LanguagePreference {
get {
return ((string)(this.GetPropertyValue("LanguagePreference" )));
}
set {
this.SetPropertyValue("LanguagePreference", value);
}
}
public virtual ProfileCommon GetProfile(string username) {
return ((ProfileCommon)(ProfileBase.Create(username)));
}
}
Oops, lors de la sauvegarde de la culture pour sa persistance, j'ai ce problème de rejet de la connexion SQL sur une page, qui fait appel à une page maîtresse dérivée d'une classe téléchargée toute prête (LitWare, pour ceux à qui ça évoque quelque chose), et pas sur une autre page , que j'ai mise au point individuellement (avec toute la lourdeur que représente le fait de refaire une partie du travail à chaque page).
Je viens de comprendre pourquoi. Ce n'est pas le principe de la page maîtresse qui pose problème, mais c'est que la classe dérivée fai t appel au profil, tandis que pour ma part j'ai fait appel aux données de session. Finalement, je viens probablement de proposer la seule réponse qui puisse se trouver à ma question, alors que je ne croyais pas vraiment au départ en recevoir une.
Ensuite, certes les bases de données ont d'autres utilisations et j'ai en perspective un autre problème, à gérer avec mon hébergeur, à la suite de quoi je regarderai de combien la base grossit quand on stocke un profil dedans. C'est vrai qu'il y a lieu de distinguer les notions de coût global et de coût marginal ...
Je crois que je tiens là un sujet pour une autre page, euh ... dans un petit paquet de semaines, quand même.
Bon alors on dit quoi, déjà ... merci à ceux qui ont pris le temps de lire.
http://www.zailes.org _____________________________________ Gloops a écrit, le 01/05/2008 14:47 :
Bonjour tout le monde,
Voici quelques mois que je travaille sur la globalisation (présentati on en plusieurs langues), et ça commence à tourner pas trop mal.
Ce que j'ai fait en dernier est de développer la même chose avec ap pel d'une page maîtresse. Sur ma machine ça marche bien.
Quand j'essaie d'envoyer ça sur un serveur de test, pas de pot, erreu r 500, problème d'accès à SQL.
Ah, SQL pour traduire mes pages alors que toutes les traductions sont dans des pages de ressources ?
Alors je réessaie sur ma machine après avoir renommé le réperto ire App_Data, et là je m'aperçois que c'est la persistance du profil qu i requiert une base SQL, puisque l'exception se lève sur un code auto-généré, à l'instruction GetPropertyValue("LanguagePreferen ce"), voir ci-dessous.
Alors j'en arrive à ma question : est-ce que juste pour se rappeler quelle langue on parle (s'agissant d'une culture neutre, l'information, c'est : "fr" ou "en", et puis c'est tout) il n'y a point de salut en-dessous de 10 Mo et demi ? C'est la taille de la base par défaut pondue par SQL Express à condition d'exécuter le programme avec les droits administrateur -si cette condition n'est pas remplie et qu'il n' y a pas de base c'est erreur 500.
On a beau dire que les prix des disques descendent tout le temps, sur u n forfait d'hébergement, ce n'est pas vraiment négligeable.
Sur le serveur en ligne les autres pages fonctionnent et je ne vois pas de fichier de base de données, mais ça, il est peut-être casé a illeurs.
public class ProfileCommon : System.Web.Profile.ProfileBase {
public virtual string LanguagePreference { get { return ((string)(this.GetPropertyValue("LanguagePreference" ))); } set { this.SetPropertyValue("LanguagePreference", value); } }
public virtual ProfileCommon GetProfile(string username) { return ((ProfileCommon)(ProfileBase.Create(username))); } }
