Asp.net GridView行在编辑数据时跳转

我有一个简单的intranet表单（ASP.NET2.0），其中GridView绑定到Active Directory中的数据。它使用一个SqlDataSource来实现这一点，SqlDataSource从一个从AD提取数据的视图中进行选择。这比直接从ASP.NET执行LDAP查询效果更好，因为我可以轻松地执行表联接等操作。GridView有一个带有编辑按钮的CommandField列，还有几个带有下拉列表的EditItemTemplates，用于选择有效值

另一方面，更新是通过直接连接到AD来完成的。为此，我必须处理GridView的OnRowUpdate事件，并将GridViewUpdateEventArgs中的Cancel设置为true，因为SqlDataSource没有定义update命令。然后它只创建一个DirectorySearcher，根据DiscrimitedName（GridView的数据键）查找用户，对结果调用GetDirectoryEntry（），设置几个属性，最后对DirectoryEntry调用CommitChanges（）。没有问题-它正在更新数据

然而，它的行为有点令人困惑。更新数据时，似乎有一点传播延迟。更新后大约需要十秒钟，用于SqlDataSource的视图才会反映更改。我不确定这是否是典型的广告行为，或者视图是否连接到与发布更新所针对的DC不同的DC。这种行为本身并不是问题，如果必要的话，我可以接受

但是，虽然这不是一个大问题，但它引起了另一个问题——默认情况下，GridView在“company”列上排序，这是允许用户编辑的属性之一。如果用户更改某一行上的公司，等待一段时间（或继续进行多次编辑），然后继续编辑另一行，则可能最终编辑与其所需行相邻的行。这是因为GridView重新绑定，突然，更改了公司的行在列表中的其他位置排序。GridView显然触发了基于该行索引的编辑，突然在该索引处出现了一个不同的行，因为用于数据源的视图突然赶上了现实

令人困惑的是GridView试图在每一篇文章的背面绑定数据。在过去，我必须确保在进行数据编辑后调用DataBind（），以确保数据是最新的，但现在它每次都能很好地命中数据源。然而页面的ViewState大约有66KB，所以我知道GridView正在把数据放在那里

因此，在我的脑海中，这些将是一些修复（我还没有成功实现）

停止GridView在每次页面加载时的数据绑定，并坚持使用ViewState中缓存的内容。GridView的OnDataBinding事件参数上没有“Cancel”属性，在数据源的OnSelecting事件期间设置Cancel只会留下一个空的GridView

修正传播延迟。再说一次，我并没有把我的心放在这上面，但如果这是一种修复突然跳来跳去的行的方法，那对我来说没关系。我是否需要确保在数据库视图中以及从ASP.NET更新AD时都显式连接到同一个DC？还是还有别的事情

根据行的主键而不是索引触发行编辑。我猜我必须在该行中创建一个CommandButton，将CommandArgument设置为该行的主键，然后在回发时遍历GridView中的所有行，并相应地手动设置EditIndex

---

我也愿意接受其他想法。如果ViewState最终为几百KB，那么这是可行的。此站点通过一个非常快速的局域网访问，并且严格用于内部使用。

从ASP.NET更新Active Directory时，无论您如何访问它，速度都会有点慢

由于不知道代码是什么样子，如果您使用默认的ASP.NET工具集，我建议使用UpdatePanel和UpdateProges工具

在更新完成之前，这将阻止对服务器的任何其他调用。像这样的

    <asp:UpdateProgress ID="updateMyGridViewProgress" runat="server">
        <ProgressTemplate>
            <img src="images/loading.gif" alt="Updating the information" />
        </ProgressTemplate>
    </asp:UpdateProgress>

    <asp:UpdatePanel ID="updateMyGridView" runat="server">
        <ContentTemplate>
            <asp:GridView 
                ID="myGridView" 
                OnRowUpdating="UpdateAdInfo"
                runat="server" >
            </asp:GridView>
        </ContentTemplate>
    </asp:UpdatePanel>

---

）
您是否考虑过完全不使用SqlDataSource并对整个应用程序进行编程绑定？我已经考虑过，但接下来我将不得不做更多的腿部工作来处理数据绑定、排序等。这不是不可能的，但如果有更简单的修复方法，我显然更愿意这样做。事实是，更新请求几乎立即完成，页面随后很快加载，因此我不知道如何检测并等待延迟，除了测量几次运行，并根据最佳猜测进行睡眠呼叫。但是没有必要故意放慢体验的速度。我可以接受在更新真正开始之前有一个延迟，只要我能发现当一行突然跳转到其他地方时愚蠢的编辑行为。