“SQL command” vs “Table or view” when importing entire tables
When using an OLEDB source editor, is there a performance benefit or difference in using "Sql Command" over "Table or View" when you want the entire table?
This is a variation on this question, in which the asker is talking about scenarios where they only want one or some columns in a table - in which case there is a benefit to using "Sql Command", as a select * from is still executed in the background when using "Table or View" even when columns are unticked.
I've also found this entry on the MSDN blog which states it is more efficient when looking at views due to the use of OpenRowset and a SET ROWCOUNT 1 which results in an inefficient query plan being cached and reused for the actual execution.
But if you're loading in a table and want every column, is there still an advantage to using the "Sql Command" option over "Table or View"?
sql-server sql-server-2012 ssis ssis-2012
asked Jun 21 '18 at 14:46
KaiKai
1405
bumped to the homepage by Community♦ 21 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
add a comment |
When using an OLEDB source editor, is there a performance benefit or difference in using "Sql Command" over "Table or View" when you want the entire table?
This is a variation on this question, in which the asker is talking about scenarios where they only want one or some columns in a table - in which case there is a benefit to using "Sql Command", as a select * from is still executed in the background when using "Table or View" even when columns are unticked.
I've also found this entry on the MSDN blog which states it is more efficient when looking at views due to the use of OpenRowset and a SET ROWCOUNT 1 which results in an inefficient query plan being cached and reused for the actual execution.
But if you're loading in a table and want every column, is there still an advantage to using the "Sql Command" option over "Table or View"?
sql-server sql-server-2012 ssis ssis-2012
asked Jun 21 '18 at 14:46
KaiKai
1405
bumped to the homepage by Community♦ 21 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
Are you able to capture the SQL that is sent to the database with both options?
– Joe Obbish
Jun 25 '18 at 23:50
add a comment |
When using an OLEDB source editor, is there a performance benefit or difference in using "Sql Command" over "Table or View" when you want the entire table?
This is a variation on this question, in which the asker is talking about scenarios where they only want one or some columns in a table - in which case there is a benefit to using "Sql Command", as a select * from is still executed in the background when using "Table or View" even when columns are unticked.
I've also found this entry on the MSDN blog which states it is more efficient when looking at views due to the use of OpenRowset and a SET ROWCOUNT 1 which results in an inefficient query plan being cached and reused for the actual execution.
But if you're loading in a table and want every column, is there still an advantage to using the "Sql Command" option over "Table or View"?
sql-server sql-server-2012 ssis ssis-2012
asked Jun 21 '18 at 14:46
KaiKai
1405
When using an OLEDB source editor, is there a performance benefit or difference in using "Sql Command" over "Table or View" when you want the entire table?
This is a variation on this question, in which the asker is talking about scenarios where they only want one or some columns in a table - in which case there is a benefit to using "Sql Command", as a select * from is still executed in the background when using "Table or View" even when columns are unticked.
I've also found this entry on the MSDN blog which states it is more efficient when looking at views due to the use of OpenRowset and a SET ROWCOUNT 1 which results in an inefficient query plan being cached and reused for the actual execution.
But if you're loading in a table and want every column, is there still an advantage to using the "Sql Command" option over "Table or View"?
sql-server sql-server-2012 ssis ssis-2012
sql-server sql-server-2012 ssis ssis-2012
asked Jun 21 '18 at 14:46
KaiKai
1405
asked Jun 21 '18 at 14:46
KaiKai
1405
asked Jun 21 '18 at 14:46
KaiKai
1405
asked Jun 21 '18 at 14:46
KaiKai
1405
asked Jun 21 '18 at 14:46
KaiKai
1405
1405
bumped to the homepage by Community♦ 21 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
bumped to the homepage by Community♦ 21 mins ago
This question has answers that may be good or bad; the system has marked it active so that they can be reviewed.
Are you able to capture the SQL that is sent to the database with both options?
– Joe Obbish
Jun 25 '18 at 23:50
add a comment |
Are you able to capture the SQL that is sent to the database with both options?
– Joe Obbish
Jun 25 '18 at 23:50
Are you able to capture the SQL that is sent to the database with both options?
– Joe Obbish
Jun 25 '18 at 23:50
Are you able to capture the SQL that is sent to the database with both options?
– Joe Obbish
Jun 25 '18 at 23:50
add a comment |
1 Answer
1
active
oldest
votes
At one point in the product's past, selecting the table name from the drop down versus writing an explicit SELECT * FROM MyTable resulted in one fewer operation being performed. The table name selection did...something I can't reproduce now. It'd issue a command like though that resulted in a SELECT * but with an outer wrapper around it.
Profiler reports for 2014, it issued the command select * from [SB].[EventLog] A 2005/2008 instance would have indicated it did something like sp_somethingweird [SB].[EventLog]
answered Jun 27 '18 at 13:17
billinkcbillinkc
13.2k43775
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "182"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f210267%2fsql-command-vs-table-or-view-when-importing-entire-tables%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
At one point in the product's past, selecting the table name from the drop down versus writing an explicit SELECT * FROM MyTable resulted in one fewer operation being performed. The table name selection did...something I can't reproduce now. It'd issue a command like though that resulted in a SELECT * but with an outer wrapper around it.
Profiler reports for 2014, it issued the command select * from [SB].[EventLog] A 2005/2008 instance would have indicated it did something like sp_somethingweird [SB].[EventLog]
answered Jun 27 '18 at 13:17
billinkcbillinkc
13.2k43775
add a comment |
At one point in the product's past, selecting the table name from the drop down versus writing an explicit SELECT * FROM MyTable resulted in one fewer operation being performed. The table name selection did...something I can't reproduce now. It'd issue a command like though that resulted in a SELECT * but with an outer wrapper around it.
Profiler reports for 2014, it issued the command select * from [SB].[EventLog] A 2005/2008 instance would have indicated it did something like sp_somethingweird [SB].[EventLog]
answered Jun 27 '18 at 13:17
billinkcbillinkc
13.2k43775
add a comment |
At one point in the product's past, selecting the table name from the drop down versus writing an explicit SELECT * FROM MyTable resulted in one fewer operation being performed. The table name selection did...something I can't reproduce now. It'd issue a command like though that resulted in a SELECT * but with an outer wrapper around it.
Profiler reports for 2014, it issued the command select * from [SB].[EventLog] A 2005/2008 instance would have indicated it did something like sp_somethingweird [SB].[EventLog]
answered Jun 27 '18 at 13:17
billinkcbillinkc
13.2k43775
At one point in the product's past, selecting the table name from the drop down versus writing an explicit SELECT * FROM MyTable resulted in one fewer operation being performed. The table name selection did...something I can't reproduce now. It'd issue a command like though that resulted in a SELECT * but with an outer wrapper around it.
Profiler reports for 2014, it issued the command select * from [SB].[EventLog] A 2005/2008 instance would have indicated it did something like sp_somethingweird [SB].[EventLog]
answered Jun 27 '18 at 13:17
billinkcbillinkc
13.2k43775
answered Jun 27 '18 at 13:17
billinkcbillinkc
13.2k43775
answered Jun 27 '18 at 13:17
billinkcbillinkc
13.2k43775
answered Jun 27 '18 at 13:17
billinkcbillinkc
13.2k43775
13.2k43775
add a comment |
add a comment |
Thanks for contributing an answer to Database Administrators Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fdba.stackexchange.com%2fquestions%2f210267%2fsql-command-vs-table-or-view-when-importing-entire-tables%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Are you able to capture the SQL that is sent to the database with both options?
– Joe Obbish
Jun 25 '18 at 23:50