我一直在尝试用数据填充我的超组合框,但这需要大量时间。但是,当我从 withing sql server 运行相同的存储过程时,它相对没有时间。程序挂断的代码行是:
SprocPatientsTableAdapter.Fill(Me.PatientsDataSet.sprocPatients, SelectedCustomerID)
通过显着的时间差异,我的意思是在 sql server 中的差异小于 5 秒,而在程序中则超过三个小时。
我一直在尝试用数据填充我的超组合框,但这需要大量时间。但是,当我从 withing sql server 运行相同的存储过程时,它相对没有时间。程序挂断的代码行是:
SprocPatientsTableAdapter.Fill(Me.PatientsDataSet.sprocPatients, SelectedCustomerID)
通过显着的时间差异,我的意思是在 sql server 中的差异小于 5 秒,而在程序中则超过三个小时。
尝试使用 SQL Server Profiler 来查看您的程序正在向数据库发送什么查询。您可能会看到传递的其他一些参数会影响查询并显着减慢查询速度。
它返回的结果集有多大?如果您通过网络发送 2.5GB,将其存储在内存中并通过它旋转以填充集合,那么是的,它当然会很慢。
不过,我想最大的问题是:你真的在使用所有被交还的数据吗?请告诉我您没有抓取整个表格,然后过滤到七行并显示 ID 和用户名!
对于这个特定的结果,数据库发送了 45,522 行(~9.08mb)
至于我们是否需要所有这些数据的大问题,不,我们不需要,我一直在争论,直到我越过蓝色进入我脸上极度深海军色的领域,但不知何故,我们得到了“关键任务”一切(不仅仅是在特定时刻需要的东西)。我们获得的第一个线索超出了我们的需要,那就是我们首先使用了一个多列组合框(为了获得那个控制而花费了超过 1k),抱歉咆哮了。
过程是:用户输入他们的用户名和 id --> 选择他们想要查看(并有权访问)的医院 --> 然后将该医院中使用我们服务的所有患者加载到 ultracombobox auto由帐号填写(隐藏)。超组合框(多列)绑定到其他几个文本框(姓氏、名字、中间名等……),因此可以编辑信息。
我将感谢 RoadWarrior 指导我最终解决禁用数据集约束的问题。使用数据集的 UltraCombo 框仅显示数据而不对其进行操作,并且在禁用约束的情况下,我的 UltraCombo 框填充速度非常快