单击“编辑模板”链接时防止 Gridview 上的数据绑定

发布于 2024-09-13 09:43:14 字数 187 浏览 4 评论 0原文

单击编辑按钮时,我的 Gridview 正在刷新其数据源。我怎样才能防止这种情况发生?当记录不多时这不是什么大问题,但当记录很多时就需要一些时间了。数据已加载,因此编辑按钮不需要重新加载数据。编辑按钮是一个模板编辑按钮,我使用的是连接到 Oracle 数据库的 SQL 数据源。 SQL 数据源使用指向下拉列表的控制参数。

任何指导将不胜感激。

My Gridview is refreshing its datasource when the edit button is clicked. How can I prevent this from happening? This isn't much of a problem when there aren't a lot of records, but when there are many it takes awhile. The data is already loaded so the edit button shouldn't need to reload the data. The edit button is a template edit button, and I'm using an SQL Datasource that connects to an Oracle database. The SQL datasource uses a control parameter that points to a dropdownlist.

Any guidance would be appreciated.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

绻影浮沉 2024-09-20 09:43:14

我看到两种可能性,都利用 SqlDataSource 控件。

我最喜欢在 SqlDataSource 控件上启用缓存。但这可能并不能真正解决您的问题。不过,将缓存设置为合理的值有可能在简单的编辑场景之外加快页面的速度,所以我喜欢在那里调整一些东西。

第二个选项是处理 SqlDataSource 控件上的 Updating 事件。在更新事件期间,如果您确定您受到回发编辑的影响,则可以将 e.Cancel 设置为 true。这样做将导致更新被跳过。不过,如果 GridView 依赖更新来记住先前显示请求中拉取的项目,这实际上可能不起作用。我最近没有使用它来确定是否是这种情况。如果是这样,您最终可能必须在初始页面显示时处理 Updated 事件,并将结果数据存储在自滚动的虚假缓存中。您可以看到这可能会很快变得复杂......

您使用哪个(以及如何使用它们)在很大程度上取决于用例细节。不过,这应该会让您开始寻找正确的方向。

I see two possibilities, both leveraging the SqlDataSource control.

Enabling caching on the SqlDataSource control is my favorite. This might not actually solve your problem, though. Setting the cache to something reasonable has the potential to speed up a lot of your page beyond the simple editing scenario, though, so I favor tweeking things there.

The second option would be to handle the Updating event on the SqlDataSource control. During the Updating event, you can set e.Cancel to true if you determine that you are under the influence of a post back for editing. Doing so will cause the update to be skipped. This might not actually work if the GridView relies on the update to remember the items pulled in a prior display request, though. I haven't used it recently enough to be certain if this is the case. If it is, you may end up having to handle the Updated event on initial page display and store the resulting data in a self-rolled faux-cache. You can see that this might get complicated fast...

Which you use (and how you use them) depends a lot on use case details. This should get you started looking in the right direction, though.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文