TADOQuery bug and workaround (persisted data)

TADOQuery bug and workaround (persisted data)

Post by John Co » Mon, 08 Nov 2004 01:34:48

There appears to be a problem with the implementation of TADOQuery. When
loading persisted data from a local file (i.e. briefcase model) the
protected property CommandType is set to cmdFile. Once set, this property
cannot be changed back to cmdText to allow connection to a database for

For example:
//Get last saved data from file
//Do stuff, then refresh from server
ADOQuery1.SQL.Text := 'SELECT * FROM MyTable';
ADOQuery1.Connection := ADOConnection1;

At this point, ADOQuery should have been refreshed with the latest version
of MyTable from the server, right? Wrong! The last line simply loads the
(outdated) data from the local file again. The reason is because
LoadFromFile sets CommandText to cmdFile with no way to ever change it back
(since it is protected). You would have to free and create another
TADOQuery to get the data from the server.

A workaround for this is to derive a new class from TADOQuery that
implements a method to restore the CommandType property to cmdText.

procedure TMyADOQuery.Refresh;
Active := False;
CommandType := cmdText;
CommandText := SQL.Text;
Active := True;


TADOQuery bug and workaround (persisted data)

Post by John Co » Thu, 11 Nov 2004 05:31:11


Then, the design was poor - not to mention undocumented. I fail to see how
resetting the CommandType property to cmdText, whenever the SQL property is
set, interferes with any existing TQuery code. Especially since TQuery
doesn't even have a LoadFromFile method. Without subclassing, it is
impossible to use a single instance of a TADOQuery to implement a briefcase
data model (at least one that works in a real world situation)