Looks like my suspicion was correct; in the join scenario, you're
dragging the complete recordset over and attempting to do the join
client side. If your data set is large (or your machine is
over-taxed), then it'll take a while to do the updates all at once.
In the second scenario (VBA), you're updating one record at a time on
the SQL Server, so the machine is not dealing with multiple records.
Does that make sense? As to how to fix it, not sure.
StuOn 7/29/2005 1:22 PM, Stu wrote:
> Looks like my suspicion was correct; in the join scenario, you're
> dragging the complete recordset over and attempting to do the join
> client side. If your data set is large (or your machine is
> over-taxed), then it'll take a while to do the updates all at once.
> In the second scenario (VBA), you're updating one record at a time on
> the SQL Server, so the machine is not dealing with multiple records.
> Does that make sense? As to how to fix it, not sure.
> Stu
>
In the join scenario, the msaccess process spikes the CPU but I/O is
stagnant. So I think there is a bug somewhere as the update join query
originally worked.
Dan|||On 8/1/2005 12:44 PM, Stu wrote:
> Which I/O? Disk or network? I don't think Access manages ODBC by
> writing it to a temporary file; I believe it tries to do it in-memory.
> I could be wrong about that.
>
Both.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment