Yes... but is there a clear rationale for this?
Sure. The rationale is to make it easy to do updates, repetitive joins. For many people, the Join dialog is not a one time process. For example, every week they get a new report that has to be joined into the same drawing in exactly the same way, just using updated weekly numbers. They do not have to alter the destination drawing every time, because the first time they do it, it is already equipped with any new fields that need to be added. After that, every week all they need is to update an already configured destination. From the above, you can see that the first time you do the join entirely in SQL you need a different query than any subsequent runs. What is the best way to handle that, especially given the accelerating trend of people not reading user manuals? The prior approach was to generate a query that had two parts to it: a setup part that was only valid the first time the query ran, but which blows things up when run in subsequent updates, plus an update part that was valid for both the first run and subsequent runs. That resulted in a query text that ran OK the very first time, but which failed every subsequent time, and , unfortunately, it failed too often for too many people. Why? Because too many people don't read documentation and just would run it blindly without commenting out the one-time set up portion. The new way, in contrast, always works. The query that is generated never fails, even in the hands of people who don't read documentation. It's a much safer approach. It may, of course, alter the destination table by adding fields if that's part of the commanded Join, but it will never delete any fields or alter any of the data in the table. So it's a benign modification that's completely safe in that it doesn't alter or delete any data. It's just setting up the table for routine updates. The task the button accomplishes is to generate a query that always works as an update query, both the first time and subsequent times. The task is not to generate a query that does a one-time alteration to a table, but which then fails every other time you run it. I suppose the query could be modified to add the setup portions but have them commented out. But there are advantages and disadvantages to that. The only advantage I see is that it writes a query that if somebody wants to use it, it will only be used one time by uncommenting the setup part, and then after that it will be wrong unless the person remembers to remove that setup part. The disadvantage of that is that it confuses people who don't understand commenting out query text, and who expect just to see an update portion. Another disadvantage is that it risks reviving the problem of less careful people having queries fail on them, if they uncomment and try to re-run the setup part. I agree that's likely to be less of an issue, but it's something to consider.
|