Exactly my thoughts. This is why I said at the first place - if someone is re-using a query object for different resultsets - just call .Close before changing the command. Worst case scenario it won't do anything.marsupilami wrote: ↑26.07.2021, 17:17it is the users responsibility to know that he modified properties.
This is where we disagree. It's not about the technical limitations, it's about making sense. This is why this topic is causing me headaches - I simply can not tell a simple scenario when changing the .SQL makes sense when we have a dataset open.marsupilami wrote: ↑26.07.2021, 17:17When it comes to modifying the current SQL statement, I tink that we should forbid changing it if there is a technical reason to do so.
If we allow this it'll only open up endless trapdoors... If we have a select statement and a dataset open, change the SQL to UPDATE, INSERT or DELETE and call .ExecSQL what is supposed to happen? Keep the dataset and execute the new statement? Raise an exception as the dataset is open? If the later - why do we allow to change it in the first place?
If you are responsible for designing / assembling a car, there are no technical difficulties to install an eject mechanism on the driver's seat when you accelerate hard. Or a rocket-powered turbo. We can put blades all around our cars just like they did in Carmageddon, but we are not.
You see where I'm going with this I suppose.
See above. It does not make sense - at least to me.marsupilami wrote: ↑26.07.2021, 17:17So - this means to decide wether we should forbid changing the SQL statement or not, we should first know if there is a technical reason to forbid it.
The KISS coding approach says otherwise. Why to have one more flag, one more thing to consume memory, one more thing to consider if we simply can stop the avalanche before it even starts?marsupilami wrote: ↑26.07.2021, 17:17Another option migt be this one: If somebody changes the SQL statement we could set a flag FSqlHasChanged or something like this. If somebody calls Refresh and FSqlHasChanged is true, we could raise an exception, that says "Sorry, guy - you changed the SQL statement, so we cannot do a refresh."
Final thoughts:
Being only a contributor the choice is not mine; as I previously stated: if you think the modification does not fit the codebase roll it back. In my opinion this topic was created because of a "user" error and could have been avoided if the code is well written - it won't affect any of my programs in any way.
But looking at the test suite .Close was occasionally called before changing the SQL while the dataset is open; see ZTestCompADOBugReport.TestTrailingSpaces for example.
Just please let me know if I should continue fixing the tests as I have no intention of spending hours on something which will be discarded at the end.