GridView perd des données au cours de publication

J'ai un aspx.Page contenant un gridview. Le contrôle gridview est lié dans le code derrière à une source de données uniquement lorsque aucune publication prend de la place et a enableviewstate = true (La page). Au cours d'une publication, les données liées au contrôle gridview sont perdus. Quelle pourrait être la raison. Demandez si le code est nécessaire.

Un exemple de code est dans la plupart du temps nécessaire comme outil de vous fournir à la collectivité qui nous permet de vous assister au mieux.

OriginalL'auteur AGuyCalledGerald | 2010-12-22

  1. 12

    Résolu, le problème a été j'ai fait une Page.Databind() dans l'événement Page_Load de la masterpage de la page avec le gridview, donc il lié à la gridview lors de chaque publication en l'absence de données.
    Merci pour tous les efforts.

    même problème exact, Page.Databind() dans un de mes masterpages. merci de répondre à votre propre question 🙂
    même problème, merci

    OriginalL'auteur AGuyCalledGerald

  2. 3

    C'est par la conception. Ces données ne sont pas stockées n'importe où natif de chargement de la page de chargement de la page. Vous devrez effectuer l'une de ces 3 tâches:

    1. Stocker les données dans l'état d'affichage (pas forcément recommandé si la données est grande)
    2. Stocker les données dans un objet de Session (même histoire, les grandes données est égale à la mauvaise utilisation de la mémoire)
    3. Faire un voyage de retour à relier les données à chaque fois que le chargement de la page (pauses vers le bas si il y a trop d'activité sur la base de données ou si la requête est lent)

    Ma préférence est de faire des allers-retours à la base de données quand j'en ai besoin et de garder mes SQL optimisé pour les performances. Lourd chargement de la page sont ennuyeux et trop de mémoire de session peut causer un ralentissement sur le serveur. Je crois que vous pouvez également stocker ces données dans le cache, mais je n'ai jamais essayé donc je ne sais pas quelles sont les limites ou les capacités.

    Il semble que la publication de données de liaison est rompue dans ce cas (comme, pour eux, "retrait de la DataBind fixe") .. mais bon des suggestions au sujet de si +1.

    OriginalL'auteur Joel Etherton

  3. 0

    à partir de la description du problème. il semble que si vous faites la liaison de données dans le code derrière. dans de tels cas asp.net ne permet pas de conserver la source de données dans le viewstate pour vous. essayez de récupérer les données et de les stocker dans l'état d'affichage de table de hachage de l'objet avec quelque chose comme ViewState["GridviewData"] = GridviewData

    et de récupération à partir de là entre les publications

    Oui, c'est vrai, je ne la liaison de données dans le code derrière.
    Êtes-vous sûr? Habituellement, je peux utiliser EnableViewState = true pour conserver les données même si elles sont liées, dans le code derrière

    OriginalL'auteur Exoas

  4. 0

    Ok je sais que la réponse est vraiment en retard, mais je viens de rencontré le même problème.

    J'ai été liaison de données à chaque fois que j'ai chargé la page, et quand il y avait un message de retour de la gridview réinterrogée. Mais à l'aide de:

    if(!IsPostBack)
{ //code used to bind on first page load }

    dans l'événement Page_Load semblait avoir aidé 🙂

    Ceci fonctionne si tous les contrôle de l'état d'affichage est utilisé. Cependant, sans état d'affichage utilisé un DataBind doit être invoquée à tous les contrôles pour chaque chargement de la page.

    OriginalL'auteur Kevin P

  5. 0

    Il vous manque le concept ici. C'est un très élémentaire question qui google peut répondre pour vous.

    De toute façon, la chose est "source de données" de tous les contrôle lié aux données se comportent comme en lecture seule et il va lire quand il en a besoin pour lier le contrôle. Pour conserver les données existantes, vous avez besoin de quelque autre façon. Par exemple ViewState ou de la Session

    • ViewState est comme une poche incorporer à la page. Plus fera de chargement de la page plus si il est plus grand. Les objets que vous magasin sera sérialisée de la chaîne de base de données. Plus grand objet de provoquer une plus grande viewstate et une plus grande bande passante. Gardez à l'esprit que l'objet doit être sérialisable.

    • Session est comme une poche pour chaque utilisateur et il reste sur le serveur, des moyens plus rapides que viewstate. Mais grosse session va consommer plus de MO en RAM

    modifier
    noooon u toujours eu tort. Permettre à l'état d'affichage n'aide pas. prenons un oeil à la structure.

    <html>
 <head>  
 </head>
 <body>
  <input type="hidden" name="__VIEWSTATE" id="__VIEWSTATE" value="..." />
 </body>
</html>

    l'entrée est un (réel)ViewState. Lorsque u la case activer ViewState contrôles webcontrols il va stocker " certains serializable(principalement du type de données. Dans votre cas, GridView.EnableViewState signifie qu'il va stocker certains de propriété sur elle-même (logique)ViewState pas page ViewState.

    Dans le code derrière.ViewState["abc"] = ...; agit de la page ViewState. Jetons un coup d'oeil dans le code côté serveur.

    this.ViewState["someName"] = somDataTable; //this won't work
this.ViewState["someID"] = "abc"; //this work fine

    Parce que DataTable n'a ISerializable qui viewstate besoins de convertir n'importe quel objet en chaîne de caractères de la base. U pourrait mettre en place votre propre serilization et de céder à l'état d'affichage par exemple convertir DataTable byte[] et attribuer à l'état d'affichage.

    essayer de Session au lieu

    Oui, j'utilise EnableViewState attribut de conserver les données.
    Non, vous êtes tout à fait tort, il fonctionne très bien sans tous de vos suggestions. S'il vous plaît vérifier.
    u verrez bientôt y cela ne fonctionne pas. bonne et heureuse année. tiens je me trompe
    DataTable en fait mise en œuvre ISerializable et il "fonctionne", lorsqu'il est mis dans le VS. La seule exigence est le nom de la table est set pour une valeur non nulle. (Cela étant dit, la Table de données sérialisation est très inefficace et de ne pas profiter de la .NET VS sérialiseur.)

    OriginalL'auteur Bonshington