Close before Open

[aehimself]

Yes, I kept an eye on the test suite. After applying my patch I saw no more failures with this message so I think we are good to go :)

[marsupilami]

I merged the changes into Zeos 8.0. Waiting for Jenkins to finish his job...

[miab3]

Hi aehimself and All

I believe that it is necessary to restore autoClose before change SQL (or TableName) at least in designtime.
And even better in any case, also in runtime.
Currently, work at designtime has become unbearable. After each change, the message "Resultset is alredy open" is thrown (if I forget to close first, and I always forget .
UniDAC uses autoClose befor Change always.
FireDAC(AnyDac) applies autoClose before Change to designtime.
I totally don't understand how, when missing autoClose could be useful.

Michał

[aehimself]

Now everyone can laugh. Zeos DOES have a "protection".
It closes the dataset. See TZAbstractRODataset.UpdateSQLStrings.

I was in the process of creating a property when I saw that even with the default behavior the dataset closed, so I started to investigate. This is how I found it.

If I make a small test application with 3 LOC:

Code: Select all

 ZQuery1.Open;
 ZQuery1.SQL.Text := 'a';
 ZQuery1.Open;

The property updates and I get the exception that the command is not valid. If I enter a valid query, everything updates (verified with .RecordCount).
I'll continue with the property thing and by default it will auto-close as it did now. Should be ready in an hour or so.

In Zeos 8.0 or Trunk, there is the problem, that the query isn't refreshed.

Can you please clarify what exactly you meant by the query is not refreshed?

[aehimself]

Pull request is ready on GitHub.
Exception raising can be enabled with ZQuery.Properties.Add('ActiveChangeException=True'), default value is False (dataset will close).
The new property is also added to the IDE's property editor.

Following MJFShark's design if this is set on a connection, all query objects will inherit this setting unless specified directly.

I also rolled back the change in ZSQLStrings and moved the verification to TZAbstractRODataSet so the private variable is not exposed.

[miab3]

Hi aehimself

Did you also include the automatic Closing of the ZTable after changing the TableName?

Michał

[marsupilami]

Pull request is ready on GitHub.

I applied the pull request to trunk / master and synced it to the github repository. Will wait for the test results, before I apply it to Zeos 8.0.

[miab3]

Now after the Zeos 8 trunk 7629 patch, changing SQL.Text or TableName in Delphi 10.3.3 Win32/Win64
works as expected, i.e. close dataset before change, in designtime and runtime.

Michał

[aehimself]

Did you also include the automatic Closing of the ZTable after changing the TableName?

I'm not completely sure but I believe the TableName property of ZTable only sets the .SQL property of itself to SELECT * FROM TableName.
I did not specifically touch TZTable but the change should affect it too.

[miab3]

Hi aehimself.

After all, I wrote above that it also works for TableName.
Thanks for restoring comfortable functionality.

Michał

[aehimself]

After a second thought and a discussion we decided that a compiler directive is better suited to control this behavior.

If you want to have exceptions if the .SQL property is changed in an active dataset, enable the ACTIVE_DATASET_SQL_CHANGE_EXCEPTION directive in Zeos.inc (or add it to your project options). At the moment exceptions are raised in design- and runtime too to avoid datasets being deactivated in DFMs and to have a streamlined behavior. If needed a second directive can be added to disable designtime exceptions - this is a matter of discussion and decision only.
By default exceptions are disabled and Zeos will simply close the dataset - as it did before.

[miab3]

The previous(svn7629) solution was better. Manageable from the program. I don't know why you changed it again.

Michał

[aehimself]

Michal,
Conditional directives can be changed from the compiler options of your project:

CompilerOptions.PNG

The reason behind moving the property to a conditional directive is it should have been done like this at the first place. It's a behavioral change affecting the whole component suite, not only specific datasets (you want it for all or none). If you want to have exceptions then you'd have to set the property in EVERY connection, even the ones created on runtime which can be easily forgotten. A directive fixes this.