Jump to content
aehimself

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

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

16 members have voted

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

    • Yes, and a following call to .Open should show the next resultset
      1
    • Yes, but a following call to .Open should raise an exception
      0
    • No, an exception should be raised immediately
      10
    • Yes, and close the active dataset
      5


Recommended Posts

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 by aehimself

Share this post


Link to post

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).

Share this post


Link to post

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 by Cristian Peța

Share this post


Link to post
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.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×