Showing posts with label disregard. Show all posts
Showing posts with label disregard. Show all posts

Wednesday, March 21, 2012

Disregard: SSIS not available as a data source

I have a full install of the June CTP on a brand new Win2K3 server.

When I attempt to add a data source to my report project, the list of possible data sources is:

Microsoft SQL Server
OLE DB
Microsoft SQL Server Analysis Services
Oracle
ODBC
XML

That's it. SSIS is not on the list (neither is SAP which I though was going to be an option as well).

Anyone have any ideas why this might be?Disregard - Never let your enterprise architects download anything for you if the edition matters :)|||Hi

I was also under the impression that SSIS could be directly used as a data source. So does that require a specific version?sql

Disregard: SSIS as data source for reporting?

I'm trying to develop a report using an SSIS DataReaderDestination as the reports data souce. When I attempt to create the report DataSet, SSIS is not an option for the Data Source parameter....

Is there an OLE DB or .NET provider for SSIS that I need to install apart from installing reporting services?Had the wrong edition. Never let your architects download things for you :)|||

Hello,
I am experiencing the same problem you described. I have Visual Studio Team Suite installed with SQL Server 2005 Developer Edition. I would expect this setup should allow me to use any of the functionality available in Integration Services. What edition did you have to install to get the SSIS option to appear?

Thanks for your help.

Disregard: SSIS as data source for reporting?

I'm trying to develop a report using an SSIS DataReaderDestination as the reports data souce. When I attempt to create the report DataSet, SSIS is not an option for the Data Source parameter....

Is there an OLE DB or .NET provider for SSIS that I need to install apart from installing reporting services?Had the wrong edition. Never let your architects download things for you :)|||

Hello,
I am experiencing the same problem you described. I have Visual Studio Team Suite installed with SQL Server 2005 Developer Edition. I would expect this setup should allow me to use any of the functionality available in Integration Services. What edition did you have to install to get the SSIS option to appear?

Thanks for your help.

Disregard some parameters

Hi,

I am building a search Query which takes 7 parameters:

Lets call them @.P1 .. @.P7 (all Int's)

The query is a simple select query like:

SELECT * FROM MyTable WHERE (Field1 = @.P1) AND (Field2 = @.P2) ...

My problem is that if some parameters are -1 they shall be disregarded.

Is there any way to set a parameter to a value meaning "Anything", or do I
have to
remove the criteria from the select clause?

(In the latter case I cannot use a stored procedure, which is what I prefer)

Cheers
GunnarGunnar,

if your columns do not contain NULLs, then you can use

WHERE Field1 BETWEEN COALESCE(NULLIF(@.P1,-1),-2147483648) AND
COALESCE(NULLIF(@.P1,-1),2147483647)

This WHERE clause assumes that the value "-1" is your indication of a
missing parameter. If you use NULL instead of -1, then you can replace
NULLIF(@.P1,-1) with @.P1. It also assumes the int datatype. If the column
is of a different integer datatype (for example bigint), then the
minimum and maximum value need to be adjusted.

If your column do contain NULLs, then you can use

WHERE CASE WHEN @.P1=-1 THEN 1
CASE WHEN Field1=@.P1 THEN 1
ELSE 0 END = 1

But in general, the first approach will perform better.

Hope this helps,
Gert-Jan

Gunnar Liknes wrote:
> Hi,
> I am building a search Query which takes 7 parameters:
> Lets call them @.P1 .. @.P7 (all Int's)
> The query is a simple select query like:
> SELECT * FROM MyTable WHERE (Field1 = @.P1) AND (Field2 = @.P2) ...
> My problem is that if some parameters are -1 they shall be disregarded.
> Is there any way to set a parameter to a value meaning "Anything", or do I
> have to
> remove the criteria from the select clause?
> (In the latter case I cannot use a stored procedure, which is what I prefer)
> Cheers
> Gunnar

--
(Please reply only to the newsgroup)|||Hi,

One way to do the trick is to write:

SELECT * FROM MyTable WHERE ((@.P1 = -1) OR (Field1 = @.P1)) AND ...

If @.P1 is -1, the OR-clause will simply be true for all rows, effectively
ignoring the comparison with Field1.

-Jrgen

"Gunnar Liknes" <g_liknes.Tabortunderscores@.g_lobal-satcom.com> skrev i en
meddelelse news:4110a27d$1@.news.broadpark.no...
> Hi,
> I am building a search Query which takes 7 parameters:
> Lets call them @.P1 .. @.P7 (all Int's)
> The query is a simple select query like:
> SELECT * FROM MyTable WHERE (Field1 = @.P1) AND (Field2 = @.P2) ...
> My problem is that if some parameters are -1 they shall be disregarded.
> Is there any way to set a parameter to a value meaning "Anything", or do I
> have to
> remove the criteria from the select clause?
> (In the latter case I cannot use a stored procedure, which is what I
prefer)
> Cheers
> Gunnar
>|||"Gert-Jan Strik" wrote

> if your columns do not contain NULLs, then you can use
> WHERE Field1 BETWEEN COALESCE(NULLIF(@.P1,-1),-2147483648) AND
> COALESCE(NULLIF(@.P1,-1),2147483647)
> This WHERE clause assumes that the value "-1" is your indication of a
> missing parameter. If you use NULL instead of -1, then you can replace
> NULLIF(@.P1,-1) with @.P1. It also assumes the int datatype. If the column
> is of a different integer datatype (for example bigint), then the
> minimum and maximum value need to be adjusted.
> If your column do contain NULLs, then you can use
> WHERE CASE WHEN @.P1=-1 THEN 1
> CASE WHEN Field1=@.P1 THEN 1
> ELSE 0 END = 1
> But in general, the first approach will perform better.

Thank you both (Gert-Jan and Jrgen) for two excellent working solutions to
my problem. The COALESCE function was interesting. Will it perform better
than the "WHERE ((@.P1 = -1) OR (Field1 = @.P1)) "
approach?

Thanks,
Gunnar|||Gunnar Liknes wrote:
> Thank you both (Gert-Jan and Jrgen) for two excellent working solutions to
> my problem. The COALESCE function was interesting. Will it perform better
> than the "WHERE ((@.P1 = -1) OR (Field1 = @.P1)) "
> approach?
> Thanks,
> Gunnar

Yes, because if the column is indexed, index seeks can be used. The OR
solution needs an index scan.

Gert-Jan
--
(Please reply only to the newsgroup)|||Gunnar Liknes (g_liknes.Tabortunderscores@.g_lobal-satcom.com) writes:
> Thank you both (Gert-Jan and Jrgen) for two excellent working solutions
> to my problem. The COALESCE function was interesting. Will it perform
> better than the "WHERE ((@.P1 = -1) OR (Field1 = @.P1)) " approach?

Permit me to modify Gert-Jan's enthusiasm a little. It may perform better,
but I have not always be successful with it. And if the columns is not
indexed then it not matter much anyway.

The only way to find out is to benchmark.

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

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||"Gert-Jan Strik" wrote
> Gunnar Liknes wrote:
> > Thank you both (Gert-Jan and Jrgen) for two excellent working solutions
to
> > my problem. The COALESCE function was interesting. Will it perform
better
> > than the "WHERE ((@.P1 = -1) OR (Field1 = @.P1)) "
> > approach?

> Yes, because if the column is indexed, index seeks can be used. The OR
> solution needs an index scan.

Does MS SQL perform complete boolean evaluations? If (@.P1=-1) it should
not have to check if (Field1 = @.P1) because the result of the statement is
already determined.

Gunnar|||Gunnar Liknes (g_liknes.Tabortunderscores@.g_lobal-satcom.com) writes:
> Does MS SQL perform complete boolean evaluations? If (@.P1=-1) it should
> not have to check if (Field1 = @.P1) because the result of the statement is
> already determined.

The answer is that, yes, SQL Server is able to make logical shortcuts,
but that is not applicable here.

When SQL Server builds a query plan for a stored procedure, it builds
the plan for the entire procedure at once, and is thus blind to what
the actual values of variables and parameters at the time of the statement.
It does take in regard the values of parameter to build the plan, but
since it don't know whether parameter changes value in the procedure or
not, SQL Server can choose a plan which would yield the wrong result if
the parameter is changed. Moreover, since the plan is cached, the procedure
might be called with some other values the next time.

Thus if you have:

SELECT *
FROM tbl
WHERE (field1 = @.p1 OR @.p1 IS NULL)
AND (field2 = @.p2 OR @.p2 IS NULL)

It cannot look at @.p1 and say "Hey @.p1 is NULL, I don't have to test
Field1". So it must pick a plan where it accesses field1. No, once it
comes to the statement it could opt to not actually check field1, but
the cost is not the check - the cost is the access. In this case,
the optimizer will most like to scan the table from left to right.

Here is another example:

SELECT *
FROM tbl
WHERE @.p1 = 0 OR EXISTS (SELECT *
FROM tbl2
WHERE tbl.col = tbl2.col)

Here, if @.p1 is 0 we retrieve all rows from tbl, but if @.p1 is 1 only
rows which has a matching row in tbl2 are to be returned. In this example,
SQL Server is actually able to avoid accessing tbl2 if @.p1 is 0, since
once @.p1 is evaluated, the other branch can be pruned. Note here that
is not your C-style of shortcutting - you get the same result if you
have the condition on @.p1 last.

To read more about this topic, I have an article on my web site:
http://www.sommarskog.se/dyn-search.html.

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

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||"Erland Sommarskog" wrote.
> Gunnar Liknes writes:

> > Does MS SQL perform complete boolean evaluations? If (@.P1=-1) it should
> > not have to check if (Field1 = @.P1) because the result of the statement
is
> > already determined.

> The answer is that, yes, SQL Server is able to make logical shortcuts,
> but that is not applicable here.

<snip explanation
> To read more about this topic, I have an article on my web site:
> http://www.sommarskog.se/dyn-search.html.

Thank you Erland, your article was very helpful. I also found the topics of
your
other articles very interresting. I'll read the one about Arrays & Lists
when I have
some time.

Regarding search. I'll have to wait until we get more data in our database
before
I decide which search alternative to use. For now I stick to IF / OR.

Cheers
Gunnar

Disregard null parameter in WHERE clause

I have a problem optionally using a parameter to query a second key
column in an outer joined table:
DROP TABLE Sub;
DROP TABLE Main;
CREATE TABLE Main (
main_key_col INTEGER NOT NULL PRIMARY KEY,
main_data_col VARCHAR(15) NOT NULL
)'
CREATE TABLE Sub (
main_key_col INTEGER NOT NULL
REFERENCES Main (main_key_col),
sub_key_col INTEGER NOT NULL,
PRIMARY KEY (main_key_col, sub_key_col),
sub_data_col VARCHAR(15) NOT NULL
);
INSERT INTO Main VALUES (1,'Ford Model T');
INSERT INTO Main VALUES (2,'Ferrari GTB');
INSERT INTO Sub VALUES (2,1,'Red');
INSERT INTO Sub VALUES (2,2,'Yellow');
INSERT INTO Sub VALUES (2,3,'Silver');
To return the full 'denormalized' set:
SELECT Main.main_key_col, Main.main_data_col,
Sub.sub_key_col, Sub.sub_data_col
FROM Main LEFT JOIN Sub ON Main.main_key_col = Sub.main_key_col;
Now I want to use two parameters for the respective key columns with
the sub_key_col parameter 'optional', meaning if it's NULL it is not
used in the WHERE clause. In the past I've got away with a trick like:
Sub.sub_key_col = COALESCE(@.sub_key_col, Sub.sub_key_col)
but, because of the outer join, sub_key_col can be null and NULL = NULL
removes the row, of course.
I have a solution but it isn't very satisfactory:
DECLARE @.main_key_col INTEGER, @.sub_key_col INTEGER
SET @.main_key_col = 2
SET @.sub_key_col = NULL
SELECT Main.main_key_col, Main.main_data_col,
Sub.sub_key_col, Sub.sub_data_col
FROM Main LEFT JOIN Sub ON Main.main_key_col = Sub.main_key_col
WHERE Main.main_key_col = @.main_key_col
AND
CASE WHEN @.sub_key_col IS NULL THEN 1
WHEN Sub.sub_key_col = @.sub_key_col THEN 1
ELSE 0 END = 1
Is there a better way?
Thank you.See if this article on Dynamic Search Conditions by Erland helps:
http://www.sommarskog.se/dyn-search.html
--
HTH,
Vyas, MVP (SQL Server)
SQL Server Articles and Code Samples @. http://vyaskn.tripod.com/
<decland@.petml.com> wrote in message
news:1118313681.656069.190380@.g14g2000cwa.googlegroups.com...
I have a problem optionally using a parameter to query a second key
column in an outer joined table:
DROP TABLE Sub;
DROP TABLE Main;
CREATE TABLE Main (
main_key_col INTEGER NOT NULL PRIMARY KEY,
main_data_col VARCHAR(15) NOT NULL
)'
CREATE TABLE Sub (
main_key_col INTEGER NOT NULL
REFERENCES Main (main_key_col),
sub_key_col INTEGER NOT NULL,
PRIMARY KEY (main_key_col, sub_key_col),
sub_data_col VARCHAR(15) NOT NULL
);
INSERT INTO Main VALUES (1,'Ford Model T');
INSERT INTO Main VALUES (2,'Ferrari GTB');
INSERT INTO Sub VALUES (2,1,'Red');
INSERT INTO Sub VALUES (2,2,'Yellow');
INSERT INTO Sub VALUES (2,3,'Silver');
To return the full 'denormalized' set:
SELECT Main.main_key_col, Main.main_data_col,
Sub.sub_key_col, Sub.sub_data_col
FROM Main LEFT JOIN Sub ON Main.main_key_col = Sub.main_key_col;
Now I want to use two parameters for the respective key columns with
the sub_key_col parameter 'optional', meaning if it's NULL it is not
used in the WHERE clause. In the past I've got away with a trick like:
Sub.sub_key_col = COALESCE(@.sub_key_col, Sub.sub_key_col)
but, because of the outer join, sub_key_col can be null and NULL = NULL
removes the row, of course.
I have a solution but it isn't very satisfactory:
DECLARE @.main_key_col INTEGER, @.sub_key_col INTEGER
SET @.main_key_col = 2
SET @.sub_key_col = NULL
SELECT Main.main_key_col, Main.main_data_col,
Sub.sub_key_col, Sub.sub_data_col
FROM Main LEFT JOIN Sub ON Main.main_key_col = Sub.main_key_col
WHERE Main.main_key_col = @.main_key_col
AND
CASE WHEN @.sub_key_col IS NULL THEN 1
WHEN Sub.sub_key_col = @.sub_key_col THEN 1
ELSE 0 END = 1
Is there a better way?
Thank you.|||DECLARE @.main_key_col INTEGER, @.sub_key_col INTEGER
SET @.main_key_col = 2
SET @.sub_key_col = NULL
SELECT Main.main_key_col, Main.main_data_col,
Sub.sub_key_col, Sub.sub_data_col
FROM Main
LEFT JOIN Sub ON Main.main_key_col = Sub.main_key_col
AND (Sub.sub_key_col = @.sub_key_col OR @.sub_key_col IS NULL)
WHERE Main.main_key_col = @.main_key_col
Jacco Schalkwijk
SQL Server MVP
<decland@.petml.com> wrote in message
news:1118313681.656069.190380@.g14g2000cwa.googlegroups.com...
>I have a problem optionally using a parameter to query a second key
> column in an outer joined table:
> DROP TABLE Sub;
> DROP TABLE Main;
> CREATE TABLE Main (
> main_key_col INTEGER NOT NULL PRIMARY KEY,
> main_data_col VARCHAR(15) NOT NULL
> )'
> CREATE TABLE Sub (
> main_key_col INTEGER NOT NULL
> REFERENCES Main (main_key_col),
> sub_key_col INTEGER NOT NULL,
> PRIMARY KEY (main_key_col, sub_key_col),
> sub_data_col VARCHAR(15) NOT NULL
> );
> INSERT INTO Main VALUES (1,'Ford Model T');
> INSERT INTO Main VALUES (2,'Ferrari GTB');
> INSERT INTO Sub VALUES (2,1,'Red');
> INSERT INTO Sub VALUES (2,2,'Yellow');
> INSERT INTO Sub VALUES (2,3,'Silver');
> To return the full 'denormalized' set:
> SELECT Main.main_key_col, Main.main_data_col,
> Sub.sub_key_col, Sub.sub_data_col
> FROM Main LEFT JOIN Sub ON Main.main_key_col = Sub.main_key_col;
> Now I want to use two parameters for the respective key columns with
> the sub_key_col parameter 'optional', meaning if it's NULL it is not
> used in the WHERE clause. In the past I've got away with a trick like:
> Sub.sub_key_col = COALESCE(@.sub_key_col, Sub.sub_key_col)
> but, because of the outer join, sub_key_col can be null and NULL = NULL
> removes the row, of course.
> I have a solution but it isn't very satisfactory:
> DECLARE @.main_key_col INTEGER, @.sub_key_col INTEGER
> SET @.main_key_col = 2
> SET @.sub_key_col = NULL
> SELECT Main.main_key_col, Main.main_data_col,
> Sub.sub_key_col, Sub.sub_data_col
> FROM Main LEFT JOIN Sub ON Main.main_key_col = Sub.main_key_col
> WHERE Main.main_key_col = @.main_key_col
> AND
> CASE WHEN @.sub_key_col IS NULL THEN 1
> WHEN Sub.sub_key_col = @.sub_key_col THEN 1
> ELSE 0 END = 1
> Is there a better way?
> Thank you.
>|||COALESCE (Sub.sub_key_col, '?') = COALESCE(@.sub_key_col,
Sub.sub_key_col, '?')|||--CELKO-- wrote:
> COALESCE (Sub.sub_key_col, '?') = COALESCE(@.sub_key_col,
> Sub.sub_key_col, '?')
Now this I like because I get to use COALESCE after all! I'm now off to
order 'SQL Programming Style' <g>
Thanks everyone.