Abstract DTS

Hello
I have a DTS package that loads an Sql Server Database with data from MS
Access datasource. The package works fine but I want to be able to change
either the source or destination connection or both (for reuse purposes) and
still have the package run.
Note that regardless of the connection the schemas remain the same.
My problem is that the DTS task seems to use the full path to the db
including server. For instance locally a destination connection table might
be referenced as aaa.dbo.MyTable1 whereas if i try to point the connection
at another instance of the database on a different server the reference for
the connection might be bbb.dbo.MyTable1.
How do i abstract out the server name in eitheer/or both the
source/destination connection? I want to be able to load clients tables with
data by using the same DTS package and just changing the connection
properties.
Thanks
TMHi
Check out:
http://www.sqldts.com/default.aspx?201
Global variables can be passed from the command line.
John
"Toff McGowen" wrote:

> Hello
> I have a DTS package that loads an Sql Server Database with data from MS
> Access datasource. The package works fine but I want to be able to change
> either the source or destination connection or both (for reuse purposes) a
nd
> still have the package run.
> Note that regardless of the connection the schemas remain the same.
> My problem is that the DTS task seems to use the full path to the db
> including server. For instance locally a destination connection table migh
t
> be referenced as aaa.dbo.MyTable1 whereas if i try to point the connection
> at another instance of the database on a different server the reference fo
r
> the connection might be bbb.dbo.MyTable1.
> How do i abstract out the server name in eitheer/or both the
> source/destination connection? I want to be able to load clients tables wi
th
> data by using the same DTS package and just changing the connection
> properties.
> Thanks
> TM
>
>|||Excellent thanks.
"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:85674B0C-13A0-481D-A7D3-241AD7824971@.microsoft.com...
> Hi
> Check out:
> http://www.sqldts.com/default.aspx?201
> Global variables can be passed from the command line.
> John
> "Toff McGowen" wrote:
>
change
and
might
connection
for
with

About Join OR Where

Hello
I've a really big doubt :) I've this two alternatives

SELECT *
FROM T1 a
INNER JOIN T1 b
ON a.F1 = b.F1
AND a.F2 = 1

SELECT *
FROM T1 a
INNER JOIN T1 b
ON a.F1 = b.F1
WHERE a.F2 = 1

I don't know when I've use a.F2 = 1
1) In the INNER JOIN statement OR
2) In the WHERE condition

I appreciate any idea
Thanks a lotOn 14 Feb 2006 14:09:09 -0800, mariohiga wrote:

>Hello
>I've a really big doubt :) I've this two alternatives
>SELECT *
> FROM T1 a
> INNER JOIN T1 b
> ON a.F1 = b.F1
> AND a.F2 = 1
>SELECT *
> FROM T1 a
> INNER JOIN T1 b
> ON a.F1 = b.F1
> WHERE a.F2 = 1
>I don't know when I've use a.F2 = 1
>1) In the INNER JOIN statement OR
>2) In the WHERE condition
>I appreciate any idea
>Thanks a lot

Hi mariohiga,

For an INNER JOIN, there's no difference. Use what you prefer best.

I'd choose the latter, because I like to keep the join conditions in the
JOIN clauses and the filter conditions in the WHERE clauses - but that's
purely personal preference.

--
Hugo Kornelis, SQL Server MVP|||mariohiga (mariohiga@.gmail.com) writes:
> Hello
> I've a really big doubt :) I've this two alternatives
> SELECT *
> FROM T1 a
> INNER JOIN T1 b
> ON a.F1 = b.F1
> AND a.F2 = 1
> SELECT *
> FROM T1 a
> INNER JOIN T1 b
> ON a.F1 = b.F1
> WHERE a.F2 = 1
> I don't know when I've use a.F2 = 1
> 1) In the INNER JOIN statement OR
> 2) In the WHERE condition

So in this example, it's only a matter of esthetics. The result will
always be the same. However consider this pair of queries:

SELECT ...
FROM A
LEFT JOIN B ON A.col = B.col
AND B.othercol = 1

SELECT ...
FROM A
LEFT JOIN B ON A.col = B.col
WHERE B.othercol = 1

Here it matters a lot, and you will get different result. Here is why:

The FROM clause runs all the way from FROM to WHERE, and by applying
join opertors it builds a virtual table, and then the WHERE clause
filters that table.

In both these queries, the virtual tables inlucdes all rows from A.
In the first query the virtual table includes all rows from B where
B.col = A.col AND b.othercol = 1. For other rows in A, there is a
NULL in the columns from B.

Whereas in the second query, the virtual table has more rows with
data in B, to wit all where B.col is = A.col, no matter the value
of B.othercol. But then we filter that table on B.othercol = 1.
Which means all rows with B.othercol NULL goes out the window -
and with them all rows in A that did not have a matching row in
B! This is a very common error with the LEFT JOIN operator, that about
everyone makes - at least I did it when I started to use this operator!

The same computation rules apply to your original queries with INNER
JOIN, but here the actual result is the same.

Note also that the computation rules I have described are logical only.
The optimizer may recast computation order as long as it does not
change the result.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pr...oads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodin...ions/books.mspx|||Thanks MVPs!! really thanks!