Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve accuracy for Table Value Constructor #2115

Open
wants to merge 1 commit into
base: live
from

Conversation

Projects
None yet
3 participants
@srutzky
Copy link
Contributor

commented May 10, 2019

This PR resolves issue #2090 .

  1. Reword main description such that it does not imply that the USING clause of the MERGE statement is a third and separate case from INSERT ... VALUES and derived tables. It is a derived table as the USING clause is really just a FROM clause (even the MERGE documentation states as much by directing the reader to view the documentation for the FROM clause: https://docs.microsoft.com/en-us/sql/t-sql/statements/merge-transact-sql#arguments ).
  2. Changed the wording of "directly in the VALUES list of an INSERT ... VALUES statement" to be "as the VALUES clause of an INSERT ... VALUES statement":
    a. removed "directly" since it is technically a "direct" usage whether here or as a derived table
    b. use "as ... clause" instead of "in ... list" since "in" implies that the "VALUES" keyword is already there, which would end up being "VALUES (VALUES (), (), ... )" which is incorrect. Since the "VALUES" keyword is an inherent part of the Table Value Constructor (TVC), it cannot be that a TVC is used "in" a VALUES list, which assumes that VALUES is already present. Yes, nit-picky, but this phrasing is more accurate.
  3. Removed the redundant restatement of the two places where the TVC can be used. That was stated clearly in the main description at the top of the page.
  4. State the actual limit. We know it's 1000 rows, so why not state it?
  5. State clearly that the row limit does not apply when using the TVC as a derived table.
  6. Add 2 methods for bulk inserting: .NET SqlBulkCopy class, and OPENROWSET(BULK ...)
  7. For all 4 bulk insert methods, link to the actual documentation (why make the reader do an extra search for them?). Not 100% sure about the relative path for the .NET documentation. That might need to be an absolute path. Not sure how to test that prior to submitting.
  8. Added newline to TVC in Example A to prevent forcing the reader to need to scroll sideways.
  9. Added Example E to illustrate what is meant by "use a derived table to insert more than 1000 rows".

I have tested on SQL Server 2012, 2017, and 2019 CTP 2.5.

For more details, please see: https://sqlquantumleap.com/2019/05/09/maximum-number-of-rows-for-the-table-value-constructor/

Improve accuracy for Table Value Constructor
1. Reword main description such that it does not imply that the `USING` clause of the `MERGE` statement is a third and separate case from `INSERT ... VALUES` and derived tables. It is a derived table as the `USING` clause is really just a `FROM` clause (even the `MERGE` documentation states as much by directing the reader to view the documentation for the `FROM` clause: https://docs.microsoft.com/en-us/sql/t-sql/statements/merge-transact-sql#arguments ).
2. Changed the wording of "directly _in_ the VALUES list of an INSERT ... VALUES statement" to be "_as_ the VALUES clause of an INSERT ... VALUES statement":
     a. removed "directly" since it is technically a "direct" usage whether here or as a derived table
     b. use "as ... clause" instead of "in ... list" since "in" implies that the "VALUES" keyword is already there, which would end up being "VALUES (VALUES (), (), ... )" which is incorrect. Since the "VALUES" keyword is an inherent part of the Table Value Constructor (TVC), it cannot be that a TVC is used "in" a VALUES list, which assumes that VALUES is already present. Yes, nit-picky, but this phrasing is more accurate.
3. Removed the redundant restatement of the two places where the TVC can be used. That was stated clearly in the main description at the top of the page.
4. State the actual limit. We know it's 1000 rows, so why not state it?
5. State clearly that the row limit does _not_ apply when using the TVC as a derived table.
6. Add 2 methods for bulk inserting: .NET SqlBulkCopy class, and OPENROWSET(BULK ...)
7. For all 4 bulk insert methods, link to the actual documentation (why make the reader do an extra search for them?). Not 100% sure about the relative path for the .NET documentation. That might need to be an absolute path. Not sure how to test that prior to submitting.
8. Added newline to TVC in Example A to prevent forcing the reader to need to scroll sideways.
9. Added Example E to illustrate what is meant by "use a derived table to insert more than 1000 rows".

I have tested on SQL Server 2012, 2017, and 2019 CTP 2.5.

For more details, please see: https://sqlquantumleap.com/2019/05/09/maximum-number-of-rows-for-the-table-value-constructor/
@PRMerger10

This comment has been minimized.

Copy link
Member

commented May 10, 2019

@srutzky : Thanks for your contribution! The author, @VanMSFT, has been notified to review your proposed change.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.