Difference between Flat File Source Output ?

Can someone tell me the difference between the Flat File Source Output - External Columns and Output Columns ?

I always end up changing the datatype properities in both to make things work :-)

? Hi, Have you tried setting the datatypes for the external columns using the Advanced pane of the Flat File Connection Manager? What you set there ought to be carried through to the Output columns. Andrew Watt [MVP] <cgpl@.discussions.microsoft..com> wrote in message news:760e2f6b-3480-4430-850e-8b30237e462d@.discussions.microsoft.com... Can someone tell me the difference between the Flat File Source Output - External Columns and Output Columns ? I always end up changing the datatype properities in both to make things work :-)|||

By definition, output columns represent the column schema of the component itself. External columns represent the column schema of the database that the component is connected to.

Try editing the column defs in the connection manager and see if that eases the experience.

difference between COUNT(*) & COUNT(1)

Hi,
1 - select count(*) from tablename
2 - select count(1) from tablename
query 1 and 2 return the same value as output.
what is the difference between count(*) and count(1) ?
which is efficient?
Please advise
Thanks,
Soura
do
set statistics io on , client statistics ,server statistics and
execution plan in query analyzer.
you will no major different for your both queries, What you need to have
proper cluster index on the table to improve count performancae.
Regards
Amish
*** Sent via Developersdex http://www.codecomments.com ***
|||SouRa wrote:
> Hi,
> 1 - select count(*) from tablename
> 2 - select count(1) from tablename
> query 1 and 2 return the same value as output.
> what is the difference between count(*) and count(1) ?
> which is efficient?
> Please advise
> Thanks,
> Soura
No difference. If you check the execution plans you should find that
they are identical.
David Portas
SQL Server MVP
|||> you will no major different for your both queries, What you need to have
> proper cluster index on the table to improve count performancae.
Actually, a non-clustered index will be better. A non-clustered index on any column will cover that
query, so SQL Server can scan the leaf-level in that index instead of scanning the leaf-level in the
clustered index (which are the data pages). The more narrow the non-clustered index, the better.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Amish Shah" <shahamishm@.gmail.com> wrote in message news:%23ulIsi2EGHA.1508@.TK2MSFTNGP15.phx.gbl...
> do
> set statistics io on , client statistics ,server statistics and
> execution plan in query analyzer.
> you will no major different for your both queries, What you need to have
> proper cluster index on the table to improve count performancae.
>
> Regards
> Amish
> *** Sent via Developersdex http://www.codecomments.com ***
|||It's just a matter of what you prefer - which can result in discussions of
religious fervour.
Just stick to count(*) being correct and count(1) being stupid.
I think of count(*) as counting the number of rows but I have heard people
liking count(1) as meaning count where the existence of the row is true (1
meaning true).
I believe there are (or were) lesser databases where count(1) gives better
performance.
In sql server it doesn't matter for performance - just avoid count(fld)
(unless that's what you want.
"SouRa" wrote:

> Hi,
> 1 - select count(*) from tablename
> 2 - select count(1) from tablename
> query 1 and 2 return the same value as output.
> what is the difference between count(*) and count(1) ?
> which is efficient?
> Please advise
> Thanks,
> Soura
>

difference between COUNT(*) & COUNT(1)

Hi,
1 - select count(*) from tablename
2 - select count(1) from tablename
query 1 and 2 return the same value as output.
what is the difference between count(*) and count(1) ?
which is efficient?
Please advise
Thanks,
Sourado
set statistics io on , client statistics ,server statistics and
execution plan in query analyzer.
you will no major different for your both queries, What you need to have
proper cluster index on the table to improve count performancae.
Regards
Amish
*** Sent via Developersdex http://www.codecomments.com ***|||SouRa wrote:
> Hi,
> 1 - select count(*) from tablename
> 2 - select count(1) from tablename
> query 1 and 2 return the same value as output.
> what is the difference between count(*) and count(1) ?
> which is efficient?
> Please advise
> Thanks,
> Soura
No difference. If you check the execution plans you should find that
they are identical.
David Portas
SQL Server MVP
--|||> you will no major different for your both queries, What you need to have
> proper cluster index on the table to improve count performancae.
Actually, a non-clustered index will be better. A non-clustered index on any
column will cover that
query, so SQL Server can scan the leaf-level in that index instead of scanni
ng the leaf-level in the
clustered index (which are the data pages). The more narrow the non-clustere
d index, the better.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Amish Shah" <shahamishm@.gmail.com> wrote in message news:%23ulIsi2EGHA.1508@.TK2MSFTNGP15.ph
x.gbl...
> do
> set statistics io on , client statistics ,server statistics and
> execution plan in query analyzer.
> you will no major different for your both queries, What you need to have
> proper cluster index on the table to improve count performancae.
>
> Regards
> Amish
> *** Sent via Developersdex http://www.codecomments.com ***|||It's just a matter of what you prefer - which can result in discussions of
religious fervour.
Just stick to count(*) being correct and count(1) being stupid.
I think of count(*) as counting the number of rows but I have heard people
liking count(1) as meaning count where the existence of the row is true (1
meaning true).
I believe there are (or were) lesser databases where count(1) gives better
performance.
In sql server it doesn't matter for performance - just avoid count(fld)
(unless that's what you want.
"SouRa" wrote:

> Hi,
> 1 - select count(*) from tablename
> 2 - select count(1) from tablename
> query 1 and 2 return the same value as output.
> what is the difference between count(*) and count(1) ?
> which is efficient?
> Please advise
> Thanks,
> Soura
>

difference between COUNT(*) & COUNT(1)

Hi,
1 - select count(*) from tablename
2 - select count(1) from tablename
query 1 and 2 return the same value as output.
what is the difference between count(*) and count(1) ?
which is efficient?
Please advise
Thanks,
Sourado
set statistics io on , client statistics ,server statistics and
execution plan in query analyzer.
you will no major different for your both queries, What you need to have
proper cluster index on the table to improve count performancae.
Regards
Amish
*** Sent via Developersdex http://www.developersdex.com ***|||SouRa wrote:
> Hi,
> 1 - select count(*) from tablename
> 2 - select count(1) from tablename
> query 1 and 2 return the same value as output.
> what is the difference between count(*) and count(1) ?
> which is efficient?
> Please advise
> Thanks,
> Soura
No difference. If you check the execution plans you should find that
they are identical.
--
David Portas
SQL Server MVP
--|||> you will no major different for your both queries, What you need to have
> proper cluster index on the table to improve count performancae.
Actually, a non-clustered index will be better. A non-clustered index on any column will cover that
query, so SQL Server can scan the leaf-level in that index instead of scanning the leaf-level in the
clustered index (which are the data pages). The more narrow the non-clustered index, the better.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Amish Shah" <shahamishm@.gmail.com> wrote in message news:%23ulIsi2EGHA.1508@.TK2MSFTNGP15.phx.gbl...
> do
> set statistics io on , client statistics ,server statistics and
> execution plan in query analyzer.
> you will no major different for your both queries, What you need to have
> proper cluster index on the table to improve count performancae.
>
> Regards
> Amish
> *** Sent via Developersdex http://www.developersdex.com ***|||It's just a matter of what you prefer - which can result in discussions of
religious fervour.
Just stick to count(*) being correct and count(1) being stupid.
I think of count(*) as counting the number of rows but I have heard people
liking count(1) as meaning count where the existence of the row is true (1
meaning true).
I believe there are (or were) lesser databases where count(1) gives better
performance.
In sql server it doesn't matter for performance - just avoid count(fld)
(unless that's what you want.
"SouRa" wrote:
> Hi,
> 1 - select count(*) from tablename
> 2 - select count(1) from tablename
> query 1 and 2 return the same value as output.
> what is the difference between count(*) and count(1) ?
> which is efficient?
> Please advise
> Thanks,
> Soura
>

Determining output schema for a stored procedure

How would I go about retrieving this information without actually executing
the stored proc? Similar I guess to the .NET DataAdapter generation in the
configuration wizard. I've been tasked with scripting some home grown tests
against a rapidly changing set of procs. It was easy determining the parms
to setup for a call but without actually executing the proc I don't see how
to get the output schema...
SQL 2005 SP1/ WinXP SP2
Thanks all....It's not possible, unfortunately. The best things you can do are:
- Make sure to keep output tables CONSISTENT, and not change output format
depending on input arguments. For instance, the following would be a
worst-practice:
IF @.ReturnCounts = 0
BEGIN
SELECT
CustomerId,
CustomerName
FROM Customers
END
ELSE
BEGIN
SELECT
C.CustomerId,
C.CustomerName,
COUNT(*) AS SalesCount
FROM Customers C
JOIN Sales S ON C.CustomerId = S.CustomerId
END
- Document outputs as well as possible, and write unit tests that verify
them. Remember that each stored procedure's inputs and outputs define an
interface, and although there is no enforceable contract, you can enforce an
implied contract via tests.
... By the way, how are you planning to dynamically test? Are you just
looking for exceptions? How will you know if your test is actually
successful?
Adam Machanic
Pro SQL Server 2005, available now
http://www.apress.com/book/bookDisplay.html?bID=457
--
"Tim Greenwood" <tim_greenwood A-T yahoo D-O-T com> wrote in message
news:O%23QpqTwcGHA.1792@.TK2MSFTNGP03.phx.gbl...
> How would I go about retrieving this information without actually
> executing
> the stored proc? Similar I guess to the .NET DataAdapter generation in
> the
> configuration wizard. I've been tasked with scripting some home grown
> tests
> against a rapidly changing set of procs. It was easy determining the
> parms
> to setup for a call but without actually executing the proc I don't see
> how
> to get the output schema...
> SQL 2005 SP1/ WinXP SP2
> Thanks all....
>

Determining output schema for a stored procedure

How would I go about retrieving this information without actually executing
the stored proc? Similar I guess to the .NET DataAdapter generation in the
configuration wizard. I've been tasked with scripting some home grown tests
against a rapidly changing set of procs. It was easy determining the parms
to setup for a call but without actually executing the proc I don't see how
to get the output schema...
SQL 2005 SP1/ WinXP SP2
Thanks all....It's not possible, unfortunately. The best things you can do are:
- Make sure to keep output tables CONSISTENT, and not change output format
depending on input arguments. For instance, the following would be a
worst-practice:
IF @.ReturnCounts = 0
BEGIN
SELECT
CustomerId,
CustomerName
FROM Customers
END
ELSE
BEGIN
SELECT
C.CustomerId,
C.CustomerName,
COUNT(*) AS SalesCount
FROM Customers C
JOIN Sales S ON C.CustomerId = S.CustomerId
END
- Document outputs as well as possible, and write unit tests that verify
them. Remember that each stored procedure's inputs and outputs define an
interface, and although there is no enforceable contract, you can enforce an
implied contract via tests.
... By the way, how are you planning to dynamically test? Are you just
looking for exceptions? How will you know if your test is actually
successful?
Adam Machanic
Pro SQL Server 2005, available now
http://www.apress.com/book/bookDisplay.html?bID=457
--
"Tim Greenwood" <tim_greenwood A-T yahoo D-O-T com> wrote in message
news:O%23QpqTwcGHA.1792@.TK2MSFTNGP03.phx.gbl...
> How would I go about retrieving this information without actually
> executing
> the stored proc? Similar I guess to the .NET DataAdapter generation in
> the
> configuration wizard. I've been tasked with scripting some home grown
> tests
> against a rapidly changing set of procs. It was easy determining the
> parms
> to setup for a call but without actually executing the proc I don't see
> how
> to get the output schema...
> SQL 2005 SP1/ WinXP SP2
> Thanks all....
>