Should a TDataSet allow changing the .SQL property while being open?

[aehimself 396]

Long story short: I'd like to get the popular opinion / correct way to handle a situation in a TDataSet descendant - and DelphiPraxis does have the userbase for it.

What do you think, does it make sense to be able to change the .SQL property (the SQL query to be executed) of a dataset component while it is open and contains a resultset? Keep in mind that this can be an INSERT, UPDATE, DELETE command too, not necessarily an other SELECT.

 

The full discussion with pros and cons can be read here for those interested.

Edited July 28, 2021 by aehimself

[Uwe Raabe 2057]

I expect the dataset to be closed when SQL changes. Otherwise the records would not match the SQL anymore. One can easily extend this to all other properties that have influence on the data retrieved and the way it can be accessed. 

 

What would be the benefit of an immediate exception here? The author of the code wants to change the SQL, so what would be the gain from that exception (which happens at runtime btw.)? The dataset has to be closed anyway to change the SQL, so why not closing it automatically?

 

Unfortunately this option is not available in the poll (at least as I understand it).

[Attila Kovacs 629]

I'd say do it like the competitors, doesn't matter if it's right or not. It will be interchangeable.

[Cristian Peța 103]

I prefer that changing the SQL to simply close the dataset. Then possibly I want to set some parameters. I will open it again when all is ready.

But sincerely I always call Close before changing SQL.

If this is a documented behavior then it's OK but otherwise this can change anytime.

 

I voted for the last. It's closer to what I prefer.

Edited July 28, 2021 by Cristian Peța

[Fr0sT.Brutal 900]

#3. Auto-close (and auto-reopen too) is not obvious and may lead to unpredictable cases.

[miab 25]

#4 Auto-close

[aehimself 396]

I added auto-close as an option now 🙂

[Guest]

Do Zeos "skip" or hide the prepare/unprepare stage?

 

Anyway/anyhow, these implementation specifics would be the "way the library works" and would/could be different for each library. The most convenient behaviour for the lib users should be the goal (easily said...).

Regarding this specific case i tend to agree that i would like to get an exception, otherwise i might do something resource-intensive by mistake.

Here, IMHO, devs will use trial-and-error (i'm not advocating it, simply stating). If an exception is thrown (would be done at #4 too upon access w/o open?) "they" will be "nudged" to read-up and handle the resources correctly.

And if a reprepare/reopen is called, the dev intentionally requested that. So at first glance #4 looks good.