The claiming that "This task cannot be performed using Transact-SQL statements" make no sense, since these are client application which do the task using T-SQL, in the same way we can do it. It might be a bit complex, but we can always develop our own application which will do the same that these app do.
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
@pituach Thank you for the feedback.
Your statement is true for any task that needs to restructure the database, however column order is considered a cosmetic trait, see this post.
If this is a feature you'd like included, please start a thread in the SQL Server forums.
I am closing this issue now. You are welcome to @ mention me for any followup.
We hope to hear from you again.
Good day @msebolt
Claiming that "columns order is cosmetic " is a huge mistake, which marc_s did in the link you provided. In fact, I responded to his message in that specific thread long time ago and I explained this mistake in short. Search the comments for the respond from "Ronen Ariely", which is me by the way ("pituach" is just a nick name saying "developer" in Hebrew. I chose many years ago it in-contrast with all these who named themselves with nicknames like "The King", "The genius", "God" and so on... I decided to say that I am a simple developer as I mentioned in the interview here). I quote this thread and several other experts (without mention the names) when I lecture about "SQL Server internals - Table structure".
The order of columns can directly impact the table's and the database's size, and it can even be related to errors which will raise in one order and not in another order! The question "is the order of columns important" is VERY common in the forums, and I showed multiple times a full demo code to present this including at stackoverflow and in the MSDN forums. The impact of order can start when we start to change the table structure.
In fact, Just several day ago I spoke in the Israeli Data Platforms PASS group and I opened the meeting with this question, and full demo. This specific lecture was in Hebrew. In the summarize post of the lecture I added links to other posts which I wrote about physical table structure, including different demos. One of these is the full demo on this topic. The summarize post is in Hebrew, but the code and images are international and most of the other posts I have are in English. In addition, I spoke in other events on the same topic in English, and you can search for recording of one of these lectures to watch the demo.
Meeting summary: Physical Table Structure under the hood, and implementation on real case scenarios (Hebrew)
This link is a pure code (almost) without any explanation, which demonstrate this specific topic.
Back to the documentation:
As I see it, the documentation addresses regular users, and naturally it does not include any undocumented entities and internals information, which make sense as the name clearly speak about "undocumented". With that being said the documentation cannot say something that is wrong! It does not have to provide the full information, but it is wrong to say that it cannot be done with T-SQL. It does not mean that you need to provide the example to do it this way.
This statement is wrong: "This task cannot be performed using Transact-SQL statements."
As I see it, instead, the document should say something like "This task is not supported using Transact-SQL statements." which make it accurate. Microsoft do not support this task using direct T-SQL, but there are people who can do it.
@WilliamAntonRohm please read my message above. At this time the documentation simply wrong.
Have a great day
@pituach Thank you for that informative post.
I understand now and have updated the documentation per your suggestion.
We look forward to hearing from you again.
Awesome Matthew ( @msebolt )
Now it's look good👍
I glad I could help a bit😀
Most helpful comment
Good day @msebolt
Claiming that "columns order is cosmetic " is a huge mistake, which marc_s did in the link you provided. In fact, I responded to his message in that specific thread long time ago and I explained this mistake in short. Search the comments for the respond from "Ronen Ariely", which is me by the way ("pituach" is just a nick name saying "developer" in Hebrew. I chose many years ago it in-contrast with all these who named themselves with nicknames like "The King", "The genius", "God" and so on... I decided to say that I am a simple developer as I mentioned in the interview here). I quote this thread and several other experts (without mention the names) when I lecture about "SQL Server internals - Table structure".
The order of columns can directly impact the table's and the database's size, and it can even be related to errors which will raise in one order and not in another order! The question "is the order of columns important" is VERY common in the forums, and I showed multiple times a full demo code to present this including at stackoverflow and in the MSDN forums. The impact of order can start when we start to change the table structure.
In fact, Just several day ago I spoke in the Israeli Data Platforms PASS group and I opened the meeting with this question, and full demo. This specific lecture was in Hebrew. In the summarize post of the lecture I added links to other posts which I wrote about physical table structure, including different demos. One of these is the full demo on this topic. The summarize post is in Hebrew, but the code and images are international and most of the other posts I have are in English. In addition, I spoke in other events on the same topic in English, and you can search for recording of one of these lectures to watch the demo.
Meeting summary: Physical Table Structure under the hood, and implementation on real case scenarios (Hebrew)
This link is a pure code (almost) without any explanation, which demonstrate this specific topic.
Back to the documentation:
As I see it, the documentation addresses regular users, and naturally it does not include any undocumented entities and internals information, which make sense as the name clearly speak about "undocumented". With that being said the documentation cannot say something that is wrong! It does not have to provide the full information, but it is wrong to say that it cannot be done with T-SQL. It does not mean that you need to provide the example to do it this way.
This statement is wrong: "This task cannot be performed using Transact-SQL statements."
As I see it, instead, the document should say something like "This task is not supported using Transact-SQL statements." which make it accurate. Microsoft do not support this task using direct T-SQL, but there are people who can do it.