> Is this the right solution?
Possible. Try to switch to MyConnection.Options.Direct := False mode and repeat a test.
Fetchall = False reopens connection
The Direct option is not the problem.
I've found the bug. It is not a real bug of MyDAC, it only reaches the limit of 5000 in Windows XP, 2003.
It is a known bug of Windows XP, see Microsft KB:
http://support.microsoft.com/kb/q196271.htm
How to reproduce:
- On a Windows XP machine
- a program that simply open and close 10000 a TMyQuery with FetchAll = False, without any other operation:
- the "Open" statement will raise a connection error after about 3000-4000 cycles.
I've applied the solution proposed in Microsoft's articol, and the problem disappear.
At now, I'm proposing you a way to optimize your use of fetchall = False.
I think you miss a method to "change" the sql statement of a query without closing the "swap" connection (this superfluous operating raise the problem).
I've try to modify you source introducing the method
procedure TMyQuery.ChangeSQL(SQLStatement: String);
begin
FDontCloseSwap := True;
SQL.Text := SQLStatement;
Open;
FDontCloseSwap := False;
end;
and modify your ReleaseSwapConnection method
procedure ReleaseSwapConnection;
begin
if FDontCloseSwap then Exit;
[...]
end;
and modify your QuerySwapConnection method
procedure QuerySwapConnection;
begin
if FDontCloseSwap and Assigned(FConnectionSwap) then Exit;
[...]
end;
So your component does not reopen the swap connection at every query change without a real need to do this.
What do you think about this?
Thanks you for your component. Is really great and fast!
I've found the bug. It is not a real bug of MyDAC, it only reaches the limit of 5000 in Windows XP, 2003.
It is a known bug of Windows XP, see Microsft KB:
http://support.microsoft.com/kb/q196271.htm
How to reproduce:
- On a Windows XP machine
- a program that simply open and close 10000 a TMyQuery with FetchAll = False, without any other operation:
Code: Select all
for j := 1 to 10000 do
begin
q.Open;
q.Close;
end;
I've applied the solution proposed in Microsoft's articol, and the problem disappear.
At now, I'm proposing you a way to optimize your use of fetchall = False.
I think you miss a method to "change" the sql statement of a query without closing the "swap" connection (this superfluous operating raise the problem).
I've try to modify you source introducing the method
procedure TMyQuery.ChangeSQL(SQLStatement: String);
begin
FDontCloseSwap := True;
SQL.Text := SQLStatement;
Open;
FDontCloseSwap := False;
end;
and modify your ReleaseSwapConnection method
procedure ReleaseSwapConnection;
begin
if FDontCloseSwap then Exit;
[...]
end;
and modify your QuerySwapConnection method
procedure QuerySwapConnection;
begin
if FDontCloseSwap and Assigned(FConnectionSwap) then Exit;
[...]
end;
So your component does not reopen the swap connection at every query change without a real need to do this.
What do you think about this?
Thanks you for your component. Is really great and fast!
> I've found the bug.
We are not sure that the reason of the problem is in it.
> How to reproduce:
This code doesn't cause an error at us.
> So your component does not reopen the swap connection at every query change
> without a real need to do this.
We are planning to optimize this part but taking on account FetchAll=False restrictions not at the nearest time.
We are not sure that the reason of the problem is in it.
> How to reproduce:
This code doesn't cause an error at us.
> So your component does not reopen the swap connection at every query change
> without a real need to do this.
We are planning to optimize this part but taking on account FetchAll=False restrictions not at the nearest time.