Showing posts with label standard. Show all posts
Showing posts with label standard. Show all posts

Friday, March 30, 2012

Is it possible to perform Sql 7 Enterprise upgrade to Sql 200o Standard Editions

Hi all,

I was curious if there any issues that I need to be aware off in attempting to upgrade an existing client database (Sql Server 7 Enterprise Edition) to Sql 2000 Standard edition. During upgrades are we forced to stay with the same editions or can the upgrade to lower level editions.

Thanks
ZeidNot possible, you need to uninstall and re-install SE.
EE is far superior than SE by any means.

Wednesday, March 28, 2012

Is it possible to install SQL Express with SQL standard Edition

Hi,

I have installed SQL standard Edition in my computer for one project. We want to kick off a new project, and intend to use SQL Express, Will anybody advise me whether I can install SQL express when SQL Standard Edition is there? or I need to remove SQL standard Edition first and install SQL express?

Thanks a lot

Haihong

Yes absolutely you can install them side-by-side. You are limited in the number and flavors of SQL Server installs really only by your hardware capabilities. The one caveat is that each beyond the first will have to be named uniquely as you can only have one default instance running. I have SQL Server 2000, SQL Server 2005 Express, and SQL Server 2005 Developer on the same machine and haven't had any problems.|||


Hi,

yes you sure can do this. The new SQL Express instance will have a different port number′, so if you want to connect to this instance you either have to name the port number after the instance name by using the syntax Machinename\InstanceName,Portnumber or start the SQL Browser service which wil redirect the client automatically to the appropiate port number during connection time.

HTH, Jens Suessmeyer.


http://www.sqlserver2005.de

Monday, March 26, 2012

Is it possible to install Enterprise from a Standard Edition CD?

There is only on one CD in my environment and it contains SQL Svr Standard;
however, some installs show as Enterprise Editions - is this possible?No, someone had another CD at some point.
--
Please post DDL, sample data and desired results.
See http://www.aspfaq.com/5006 for info.
"NeverQuit" <NeverQuit@.discussions.microsoft.com> wrote in message
news:BBBDBE3A-0DB9-4F9D-8D4F-582F69EEA963@.microsoft.com...
> There is only on one CD in my environment and it contains SQL Svr
Standard;
> however, some installs show as Enterprise Editions - is this possible?

Is it possible to install Enterprise from a Standard Edition CD?

There is only on one CD in my environment and it contains SQL Svr Standard;
however, some installs show as Enterprise Editions - is this possible?
No, someone had another CD at some point.
Please post DDL, sample data and desired results.
See http://www.aspfaq.com/5006 for info.
"NeverQuit" <NeverQuit@.discussions.microsoft.com> wrote in message
news:BBBDBE3A-0DB9-4F9D-8D4F-582F69EEA963@.microsoft.com...
> There is only on one CD in my environment and it contains SQL Svr
Standard;
> however, some installs show as Enterprise Editions - is this possible?
sql

Is it possible to install Enterprise from a Standard Edition CD?

There is only on one CD in my environment and it contains SQL Svr Standard;
however, some installs show as Enterprise Editions - is this possible?No, someone had another CD at some point.
Please post DDL, sample data and desired results.
See http://www.aspfaq.com/5006 for info.
"NeverQuit" <NeverQuit@.discussions.microsoft.com> wrote in message
news:BBBDBE3A-0DB9-4F9D-8D4F-582F69EEA963@.microsoft.com...
> There is only on one CD in my environment and it contains SQL Svr
Standard;
> however, some installs show as Enterprise Editions - is this possible?

Is it possible to have a matrix row footer?

I have a fairly standard matrix on my report, that looks like this when it
renders (I'm simplifying somewhat to get the idea across):
Account Jan Feb Mar Apr May ..... Dec
Total
Office Supplies 100 150 200 50 100 100
1900
...
Obviously "Account" the the row group, and "Month" is the column group.
This works just fine.
What I'd like to have is have a column AFTER the Total column, that lists
some comments about the account (tied to the Account row group). For
example:
Account Jan Feb Mar Apr May ..... Dec
Total Account comments
Office Supplies 100 150 200 50 100 100
1900 Increased by 5% due to switch to new supplier
I can't figure out how to do this...can someone help?
Thanks,
C17Hi C17,
I understand that you would like to know if you can have a row footer in
the matrix of your report.
If I have misunderstood, please let me know.
I do not think that you can do this in a matrix report. You can only add
row group or column group in the existing matrix. Instead I recommend that
you modify your DataSet query text so that you can use a table for
implementing your requirements. You may refer to PIVOT statement so that
you can rotate the month values from one column to multiple columns.
You may refer to:
Using PIVOT and UNPIVOT
http://msdn2.microsoft.com/en-us/library/ms177410.aspx
Hope this helps. If you have any other questions or concerns, please feel
free to let me know.
Best regards,
Charles Wang
Microsoft Online Community Support
===========================================================Delighting our customers is our #1 priority. We welcome your
comments and suggestions about how we can improve the
support we provide to you. Please feel free to let my manager
know what you think of the level of service provided. You can
send feedback directly to my manager at: msdnmg@.microsoft.com.
===========================================================Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.
Note: The MSDN Managed Newsgroup support offering is for
non-urgent issues where an initial response from the community
or a Microsoft Support Engineer within 1 business day is acceptable.
Please note that each follow up response may take approximately
2 business days as the support professional working with you may
need further investigation to reach the most efficient resolution.
The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by
contacting Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
============================================================This posting is provided "AS IS" with no warranties, and confers no rights.
=========================================================|||On Mar 21, 3:31=A0pm, "C17" <c...@.community.nospam> wrote:
> I have a fairly standard matrix on my report, that looks like this when it=
> renders (I'm simplifying somewhat to get the idea across):
> =A0 =A0 Account =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Jan =A0 =A0 =A0Feb =A0 =A0 ==A0Mar =A0 =A0 Apr =A0 =A0 May ..... Dec
> Total
> =A0 =A0 Office Supplies =A0 =A0 =A0100 =A0 =A0 150 =A0 =A0 =A0200 =A0 =A0 ==A0 50 =A0 =A0 =A0100 =A0 =A0 =A0 =A0100
> 1900
> =A0 =A0 ...
> Obviously "Account" the the row group, and "Month" is the column group.
> This works just fine.
> What I'd like to have is have a column AFTER the Total column, that lists
> some comments about the account (tied to the Account row group). =A0For
> example:
> =A0 =A0 Account =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Jan =A0 =A0 =A0Feb =A0 =A0 ==A0Mar =A0 =A0 Apr =A0 =A0 May ..... Dec
> Total =A0 =A0 =A0Account comments
> =A0 =A0 Office Supplies =A0 =A0 =A0100 =A0 =A0 150 =A0 =A0 =A0200 =A0 =A0 ==A0 50 =A0 =A0 =A0100 =A0 =A0 =A0 =A0100
> 1900 =A0 =A0 Increased by 5% due to switch to new supplier
> I can't figure out how to do this...can someone help?
> Thanks,
> C17
What I would do is take create a dataset that is a Union of your Data
+ Comments, differentiated by a Group field, then create a Matrix with
the Group field as a Column group, then conditionally hide the
SubTotal on the Comment group.
In english, make a data set that is:
DataType, Account, Month, Amount, Comment
'Amount', 'Office Supplies', #1/1/2007#, 100, Nothing
'Amount', 'Office Supplies', #2/1/2007#, 150, Nothing
'Comment', 'Office Supplies', #1/1/2007#, Nothing, 'Increased by 5%
due to switch to new supplier'
=2E..
The Matrix would be
Column Group1: =3DFields!DataType.Value, Sort Ascending
Column Group2: =3DFields!Month.Value, Sort Ascending
Turn on Column Subtotal2
Maybe add a conditional Hide if InScope(Group2) And Fields!
Group1.Value =3D 'Comment'
Row Group: Account
Details Expression: =3DIIF( First(Fields!DataType.Value) =3D 'Amount',
Sum( Fields!Amount.Value ), First( Fields!Comment.Value ) )
Since I'm not in a Dev environment at the moment, I can't test this,
but you may have to play with the data types to get things to work.
-- Scott

Monday, March 12, 2012

Is it possible run C# .net Standard against SQL Server 2000?

Hi all!

I keep getting an error when I try and create a new data connection. This is the error I'm getting:

Unable to connect to database.
It is only possible to connect to SQL Server Desktop Engine databases and Microsoft Access with this version of Visual Studio.

I can connect to Access without any problems. Is there anyway around this?
I'm using C# .net Standard with SQL Server 2000.

Thanks for any help.>>It is only possible to connect to SQL Server Desktop Engine databases and Microsoft Access with this version of Visual Studio.

What version?? "C#.net standard" ??

What version of the .NET framework are you using? What IDE are you using?|||Thanks ehorn for reply

I'd like to runVisual C#.net 2003 Standard IDE against SQL Server 2000

I'm using Framework 1.1|||Given that you say this is the error:

Unable to connect to database.
It is only possible to connect to SQL Server Desktop Engine databases and Microsoft Access with this version of Visual Studio.

I imagine that the problem is exactly what it says. That is, the version you are using will NOT allow you to access SQL Server. However, if you install the MSDE on your machine (which is binary compatible with SQL Server) you will be able to access that.|||Thanks Douglas for reply!

It was exactly what I did but now trying to install MSDE I'm getting the error:
'The instance name specified is invalid.'

Will I have to remove SQL Server first then try again?|||I expect so, or alternately, specify an instance name while installing MSDE.

Wednesday, March 7, 2012

Is it a Compatible bug in SQL Server 2005 ?

Hi, all here,

I use SQL Server 2005 standard edition ,

I choose to use table(table stored in Oracle9i) as source for mining structure, and I use

Oracle Provider for OLE DB(or Microsoft OLE DB Provider for Oracle).I set one column as logic key and this column stored chinese data.Deployment was successful. When I processed the mining structure,

an error happened:

Warning 0x80202066:Data Flow Task :Connot retieve the column code page info from OLE DB provider.If the comopenent supports the "DefaultCodePage" property,the code page from that property will be used .Change the value of the property if the current string code page values are incorrect. If the component does not support the property, the code page from the component's locale ID will be used.

But I created the same mining stucture and processed it successfully in SQL Server 2000. Is it a Compatible bug in SQL Server 2005?

It looks like the OLE DB provider for Oracle requires a code page to be specified because there is locale-specific (Chinese) data in the column.

There is a similar posting on the SSIS forum which you may find useful:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PageIndex=2&SiteID=1&PostID=107027

HTH,

Akshai

|||

hi,Akshai,

thanks!

I had modified the Propertie:CheckDistinctRecordSortOrder in my SSAS,

and the mining model had been processed successfully!

is it a bug ? (relationships in report builder)

Hi friends
am having some weird problem.am using sql server 2005 standard edition.

i've a report model with tables (tab1,tab2,tab3). tab1 and tab2 (actually these are views) relate to same table but each has different columns from same table.
the third table i.e. tab3 is child of tab1.

in my report model project,i set cardinality of this role in tab3 as "one" and in tab1 as "Optionalmany".

when creating a report in reportbuilder.if select columns from either tab1 and/or tab2 i get to see 100 records which is correct.if add any column from tab3 i get to see only 1 record which also correct as i've only 1 row tab3 at the moment.

now ,fun begins , what should happen if i delete column(s) of tab3 from report designer ? i should see all 100 records ,right ? bcoz all my columns coming from either tab1 or tab3 but when i run report i get see only 1 record !!! why ? is it a bug or am i missing something.
Thanks for your help.no one ever faced this situation ?
any ideas on this one much appreciated.|||

The difference between the first report that returned 100 rows and the third report that returned 1 row is the primary entity, which changed when you added a column from tab3, but did not revert when you deleted that column.

The primary entity of the first report is tab1, which means that report is fundamentally about tab1 and the data related to it.

The primary entity of the third report is tab3, which means that report is fundamentally about tab3 and the data related to it. Basically, the third report is a summary report for the data in tab3, grouped by tab1, which explains why there is only one row.

|||Thanks for the reply Bob.
does it mean that even if some one adds a field from tab3 accidentally ,he has to create the whole report from scratch so that he can see data that matches its criteria ?|||Bob
I think ,i kind of achieved what i want. please advise if i go into any problems in future.

what i did was i set cardinality for the roles on parent table side as "optionalone" and child entity side as "Optionalmany". (normally its other way round ,right?)
now my reports work just fine. i mean i get data am expecting and top of it if i remove the field from tab3 still my report worked displaying all records from tab1,tab2.

BTW when i deploy (using BI) i get a warning like below

"The Relation property of the Role 'tab3 detail' refers to the Target end of the Relation 'dd_tab1-dd_tab3', which is not bound to a set of uniquely constrained columns for the Table 'dbo.dd__tab3'. Roles with Cardinality of One or OptionalOne require relations bound to uniquely constrained columns of the table."

is it a problem ?
i checked sql the report builder making (in sql profiler) and they look fine as its placing joins correctly on both parent and child tables.
any suggestions on this much appreciated.
Thank you very much|||

No, you should not swap the cardinality of your report model roles to get different joins. RB relies on this information in many ways to provide a consistent and appropriately constrained query design experience to the user.

You are right that there is currently no way to revert the primary entity other than rebuilding your report. This feature was slated for SQL 2005 at one point, but unfortunately did not make it into this release.

Friday, February 24, 2012

Is Forms Authentication available on Standard

I have been looking at the forms authentication sample that creates a custom login page. After looking at the licencing am I right in saying that this can only be implemented using SQL server enterprise edition as standard edition does not have the security extension API. If this is the case is there any way to custom authenticate a user when using URL calls that is not windows Authentication?I have found the answer which is simply no. Back to Crystal Reports then. Good luck getting this off the ground when you have to buy Enterprise Edition just to securely provide reports over the web that have some kind of functionality.
"Ryan Smith" wrote:
> I have been looking at the forms authentication sample that creates a custom login page. After looking at the licencing am I right in saying that this can only be implemented using SQL server enterprise edition as standard edition does not have the security extension API. If this is the case is there any way to custom authenticate a user when using URL calls that is not windows Authentication?|||Web services does not support everything as it only provides a snapshot of
the report and does not have drill down functionality. If you have a report
that has drill downs (95% of my reports) in it and you run a webservice for
it, when the user clicks on the drill down they get an error.
"Richard" wrote:
> You can still build your own web app (report manager) and use the web service
> to communitate with it. I have gone over the api for the ws and it supports
> everyting you need. Yes it's a bit of work up front but there are no
> licensing issues at all
> "Ryan Smith" wrote:
> > I have found the answer which is simply no. Back to Crystal Reports then. Good luck getting this off the ground when you have to buy Enterprise Edition just to securely provide reports over the web that have some kind of functionality.
> >
> > "Ryan Smith" wrote:
> >
> > > I have been looking at the forms authentication sample that creates a custom login page. After looking at the licencing am I right in saying that this can only be implemented using SQL server enterprise edition as standard edition does not have the security extension API. If this is the case is there any way to custom authenticate a user when using URL calls that is not windows Authentication?

is Exists faster than a Join

From http://www.sql-server-performance.co...sis_tuning.asp
B) Can standard JOIN's be replaced with EXISTS statements?
If you need to join tables to ensure XYZ value exists or a specific set of
rows exists, then considering porting to EXISTS or NOT EXISTS statements.
At the same time is may also alleviate the need for DISTINCT clauses.
So is a Join really potentiall slower?
The Exists clause can be faster than a join because it just searches long
enough to find the first "Hit" as opposed to returning all rows that meet
the join criteria.
Greg Jackson
PDX, Oregon
|||Could you please elaborate? An Exists will meet all the rows that meet the
query criteria. Given that the criteria should return the same data as a
join, how could it be faster?
"pdxJaxon" <GregoryAJackson@.Hotmail.com> wrote in message
news:eZWWYB7aFHA.3848@.TK2MSFTNGP10.phx.gbl...
> The Exists clause can be faster than a join because it just searches long
> enough to find the first "Hit" as opposed to returning all rows that meet
> the join criteria.
>
> Greg Jackson
> PDX, Oregon
>
|||I say
SELECT * FROM Main
WHERE Exists(SELECT 1 FROM MyJoinTable a WHERE a.foo = main.foo)
then it will only check for the first hit.
still probably not making sense.
show us YOUR query and I can probably explain a bit better
GAJ
|||create table #Table1(T1C1 int identity (1,1), T1C2 char(10))
create table #Table2(T2C1 int, T2C2 char(10))
insert into #Table1 (T1C2) values ('T1C2')
insert into #Table1 (T1C2) values ('T1C2-2')
insert into #Table2 (T2C1,T2C2) values (1,'T1C2')
select t1.T1C1,T1C2
from #Table1 t1
inner join #Table2 t2 on t1.t1c1 = t2.t2c1
or
select t1.T1C1,T1C2
from #table1 t1
where exists
(select * from #Table2 t2
where t2.T2C1 = T1.T1C1)
"pdxJaxon" <GregoryAJackson@.Hotmail.com> wrote in message
news:%23fZBCd7aFHA.464@.TK2MSFTNGP15.phx.gbl...
>I say
> SELECT * FROM Main
> WHERE Exists(SELECT 1 FROM MyJoinTable a WHERE a.foo = main.foo)
> then it will only check for the first hit.
> still probably not making sense.
> show us YOUR query and I can probably explain a bit better
>
> GAJ
>
|||that's faster than a Join.
the where clause will return TRUE as soon as it finds a SINGLE record in
TABLE 2 that mathces Table1 (It will not bother returning more than 1 record
that matches to table 1)
A join will return ALL Records in T2 that match T1. IF there are millions of
records in each table, this would be exponentially faster.
Greg Jackson
PDX, Oregon
|||On Tue, 7 Jun 2005 15:11:21 -0700, ChrisR wrote:

>From http://www.sql-server-performance.co...sis_tuning.asp
>B) Can standard JOIN's be replaced with EXISTS statements?
>If you need to join tables to ensure XYZ value exists or a specific set of
>rows exists, then considering porting to EXISTS or NOT EXISTS statements.
>At the same time is may also alleviate the need for DISTINCT clauses.
>
>So is a Join really potentiall slower?
Hi Chris,
The question is actually irrelevant. A join is different: a query such
as
SELECT a.*
FROM a
WHERE EXISTS (SELECT * FROM b WHERE b.xx = a.xx)
will never return more than one copy of each row in a. Using a join
instead, such as this:
SELECT a.*
FROM a
JOIN b ON b.xx = a.xx
might return multiple copies of rows in a for values of xx that are not
unique in table b.
If no value of xx is ever duplicated in b, then the results will be the
same, but the EXISTS version might still be faster. Since SQL Server
doesn't know that there is only one row in b with a particular value of
xx, it still has to search the rest of the table after encoutering one;
if EXISTS is used, the search is aborted after the first match.
If SQL Server knows that values of b.xx are unique (because there is a
PRIMARY KEY or UNIQUE constraint on b.xx), then the performance MIGHT be
the same - the optimizer MIGHT decide to use the knowledge of this
constraint and createt the same execution plan it'll also use for the
EXISTS version.
I have never seen or heard of any situation where the JOIN would be
fafster than the "equivalent" EXISTS version. And I don't think I ever
will.
Best, Hugo
(Remove _NO_ and _SPAM_ to get my e-mail address)
|||Hi Hugo and Chris,
"Hugo Kornelis" wrote:
> On Tue, 7 Jun 2005 15:11:21 -0700, ChrisR wrote:
>
> Hi Chris,
> The question is actually irrelevant. A join is different: a query such
> as
> SELECT a.*
> FROM a
> WHERE EXISTS (SELECT * FROM b WHERE b.xx = a.xx)
> will never return more than one copy of each row in a. Using a join
> instead, such as this:
> SELECT a.*
> FROM a
> JOIN b ON b.xx = a.xx
> might return multiple copies of rows in a for values of xx that are not
> unique in table b.
> If no value of xx is ever duplicated in b, then the results will be the
> same, but the EXISTS version might still be faster. Since SQL Server
> doesn't know that there is only one row in b with a particular value of
> xx, it still has to search the rest of the table after encoutering one;
> if EXISTS is used, the search is aborted after the first match.
> If SQL Server knows that values of b.xx are unique (because there is a
> PRIMARY KEY or UNIQUE constraint on b.xx), then the performance MIGHT be
> the same - the optimizer MIGHT decide to use the knowledge of this
> constraint and createt the same execution plan it'll also use for the
> EXISTS version.
> I have never seen or heard of any situation where the JOIN would be
> fafster than the "equivalent" EXISTS version. And I don't think I ever
> will.
>
I think you have to try the statement both ways.
I'm not sure about EXISTS, but I have a fairly complex multi-way join that
is much faster with
a LEFT JOIN b on a.id = b.id ... WHERE b.id is null
than with
WHERE NOT EXISTS (select 1 from b where a.id = b.id)
Regards,
Jonathan
|||On Thu, 9 Jun 2005 12:52:03 -0700, Jonathan Levine wrote:
(snip)
>I'm not sure about EXISTS, but I have a fairly complex multi-way join that
>is much faster with
>a LEFT JOIN b on a.id = b.id ... WHERE b.id is null
>than with
>WHERE NOT EXISTS (select 1 from b where a.id = b.id)
Hi Jonathan,
Thanks for adding this. This is not the first time I witness or hear
reports of this either. It seems that the SQL Server development team
put most effort in the optimization of join strategies, since they are
used most often in typical queries.
Best, Hugo
(Remove _NO_ and _SPAM_ to get my e-mail address)
|||Also, be careful of the Optimizer Estimated Execution Plans. I especially
see this in comparisons between LEFT OUTER JOINS versus the use of EXISTS or
NOT EXISTS.
Even though the JOIN may produce a better ESTIMATED execution cost, it will
often create a HASH table for the JOIN, where the EXISTS solution will often
use a Nested Loop JOIN. The HASH will ALWAYS create temporary object, which
will have physical impact that the Optimizer does not take into account.
You're best bet would be to SET STATISTICS time and I/O on and run them both
ways, making sure to flush the Buffer Pool before each execution. This will
give you ACTUAL run information, not just ESTIMATED.
Sincerely,
Anthony Thomas

"Hugo Kornelis" <hugo@.pe_NO_rFact.in_SPAM_fo> wrote in message
news:mnfha11l8fukurbcocmi9rg30s47q0lj6j@.4ax.com...
On Thu, 9 Jun 2005 12:52:03 -0700, Jonathan Levine wrote:
(snip)
>I'm not sure about EXISTS, but I have a fairly complex multi-way join that
>is much faster with
>a LEFT JOIN b on a.id = b.id ... WHERE b.id is null
>than with
>WHERE NOT EXISTS (select 1 from b where a.id = b.id)
Hi Jonathan,
Thanks for adding this. This is not the first time I witness or hear
reports of this either. It seems that the SQL Server development team
put most effort in the optimization of join strategies, since they are
used most often in typical queries.
Best, Hugo
(Remove _NO_ and _SPAM_ to get my e-mail address)

is Exists faster than a Join

From http://www.sql-server-performance.c...ysis_tuning.asp
B) Can standard JOIN's be replaced with EXISTS statements?
If you need to join tables to ensure XYZ value exists or a specific set of
rows exists, then considering porting to EXISTS or NOT EXISTS statements.
At the same time is may also alleviate the need for DISTINCT clauses.
So is a Join really potentiall slower?The Exists clause can be faster than a join because it just searches long
enough to find the first "Hit" as opposed to returning all rows that meet
the join criteria.
Greg Jackson
PDX, Oregon|||Could you please elaborate? An Exists will meet all the rows that meet the
query criteria. Given that the criteria should return the same data as a
join, how could it be faster?
"pdxJaxon" <GregoryAJackson@.Hotmail.com> wrote in message
news:eZWWYB7aFHA.3848@.TK2MSFTNGP10.phx.gbl...
> The Exists clause can be faster than a join because it just searches long
> enough to find the first "Hit" as opposed to returning all rows that meet
> the join criteria.
>
> Greg Jackson
> PDX, Oregon
>|||I say
SELECT * FROM Main
WHERE Exists(SELECT 1 FROM MyJoinTable a WHERE a.foo = main.foo)
then it will only check for the first hit.
still probably not making sense.
show us YOUR query and I can probably explain a bit better
GAJ|||create table #Table1(T1C1 int identity (1,1), T1C2 char(10))
create table #Table2(T2C1 int, T2C2 char(10))
insert into #Table1 (T1C2) values ('T1C2')
insert into #Table1 (T1C2) values ('T1C2-2')
insert into #Table2 (T2C1,T2C2) values (1,'T1C2')
select t1.T1C1,T1C2
from #Table1 t1
inner join #Table2 t2 on t1.t1c1 = t2.t2c1
or
select t1.T1C1,T1C2
from #table1 t1
where exists
(select * from #Table2 t2
where t2.T2C1 = T1.T1C1)
"pdxJaxon" <GregoryAJackson@.Hotmail.com> wrote in message
news:%23fZBCd7aFHA.464@.TK2MSFTNGP15.phx.gbl...
>I say
> SELECT * FROM Main
> WHERE Exists(SELECT 1 FROM MyJoinTable a WHERE a.foo = main.foo)
> then it will only check for the first hit.
> still probably not making sense.
> show us YOUR query and I can probably explain a bit better
>
> GAJ
>|||that's faster than a Join.
the where clause will return TRUE as soon as it finds a SINGLE record in
TABLE 2 that mathces Table1 (It will not bother returning more than 1 record
that matches to table 1)
A join will return ALL Records in T2 that match T1. IF there are millions of
records in each table, this would be exponentially faster.
Greg Jackson
PDX, Oregon|||On Tue, 7 Jun 2005 15:11:21 -0700, ChrisR wrote:

>From http://www.sql-server-performance.c...ysis_tuning.asp
>B) Can standard JOIN's be replaced with EXISTS statements?
>If you need to join tables to ensure XYZ value exists or a specific set of
>rows exists, then considering porting to EXISTS or NOT EXISTS statements.
>At the same time is may also alleviate the need for DISTINCT clauses.
>
>So is a Join really potentiall slower?
Hi Chris,
The question is actually irrelevant. A join is different: a query such
as
SELECT a.*
FROM a
WHERE EXISTS (SELECT * FROM b WHERE b.xx = a.xx)
will never return more than one copy of each row in a. Using a join
instead, such as this:
SELECT a.*
FROM a
JOIN b ON b.xx = a.xx
might return multiple copies of rows in a for values of xx that are not
unique in table b.
If no value of xx is ever duplicated in b, then the results will be the
same, but the EXISTS version might still be faster. Since SQL Server
doesn't know that there is only one row in b with a particular value of
xx, it still has to search the rest of the table after encoutering one;
if EXISTS is used, the search is aborted after the first match.
If SQL Server knows that values of b.xx are unique (because there is a
PRIMARY KEY or UNIQUE constraint on b.xx), then the performance MIGHT be
the same - the optimizer MIGHT decide to use the knowledge of this
constraint and createt the same execution plan it'll also use for the
EXISTS version.
I have never seen or heard of any situation where the JOIN would be
fafster than the "equivalent" EXISTS version. And I don't think I ever
will.
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)|||Hi Hugo and Chris,
"Hugo Kornelis" wrote:
> On Tue, 7 Jun 2005 15:11:21 -0700, ChrisR wrote:
>
> Hi Chris,
> The question is actually irrelevant. A join is different: a query such
> as
> SELECT a.*
> FROM a
> WHERE EXISTS (SELECT * FROM b WHERE b.xx = a.xx)
> will never return more than one copy of each row in a. Using a join
> instead, such as this:
> SELECT a.*
> FROM a
> JOIN b ON b.xx = a.xx
> might return multiple copies of rows in a for values of xx that are not
> unique in table b.
> If no value of xx is ever duplicated in b, then the results will be the
> same, but the EXISTS version might still be faster. Since SQL Server
> doesn't know that there is only one row in b with a particular value of
> xx, it still has to search the rest of the table after encoutering one;
> if EXISTS is used, the search is aborted after the first match.
> If SQL Server knows that values of b.xx are unique (because there is a
> PRIMARY KEY or UNIQUE constraint on b.xx), then the performance MIGHT be
> the same - the optimizer MIGHT decide to use the knowledge of this
> constraint and createt the same execution plan it'll also use for the
> EXISTS version.
> I have never seen or heard of any situation where the JOIN would be
> fafster than the "equivalent" EXISTS version. And I don't think I ever
> will.
>
I think you have to try the statement both ways.
I'm not sure about EXISTS, but I have a fairly complex multi-way join that
is much faster with
a LEFT JOIN b on a.id = b.id ... WHERE b.id is null
than with
WHERE NOT EXISTS (select 1 from b where a.id = b.id)
Regards,
Jonathan|||On Thu, 9 Jun 2005 12:52:03 -0700, Jonathan Levine wrote:
(snip)
>I'm not sure about EXISTS, but I have a fairly complex multi-way join that
>is much faster with
>a LEFT JOIN b on a.id = b.id ... WHERE b.id is null
>than with
>WHERE NOT EXISTS (select 1 from b where a.id = b.id)
Hi Jonathan,
Thanks for adding this. This is not the first time I witness or hear
reports of this either. It seems that the SQL Server development team
put most effort in the optimization of join strategies, since they are
used most often in typical queries.
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)|||Also, be careful of the Optimizer Estimated Execution Plans. I especially
see this in comparisons between LEFT OUTER JOINS versus the use of EXISTS or
NOT EXISTS.
Even though the JOIN may produce a better ESTIMATED execution cost, it will
often create a HASH table for the JOIN, where the EXISTS solution will often
use a Nested Loop JOIN. The HASH will ALWAYS create temporary object, which
will have physical impact that the Optimizer does not take into account.
You're best bet would be to SET STATISTICS time and I/O on and run them both
ways, making sure to flush the Buffer Pool before each execution. This will
give you ACTUAL run information, not just ESTIMATED.
Sincerely,
Anthony Thomas
"Hugo Kornelis" <hugo@.pe_NO_rFact.in_SPAM_fo> wrote in message
news:mnfha11l8fukurbcocmi9rg30s47q0lj6j@.
4ax.com...
On Thu, 9 Jun 2005 12:52:03 -0700, Jonathan Levine wrote:
(snip)
>I'm not sure about EXISTS, but I have a fairly complex multi-way join that
>is much faster with
>a LEFT JOIN b on a.id = b.id ... WHERE b.id is null
>than with
>WHERE NOT EXISTS (select 1 from b where a.id = b.id)
Hi Jonathan,
Thanks for adding this. This is not the first time I witness or hear
reports of this either. It seems that the SQL Server development team
put most effort in the optimization of join strategies, since they are
used most often in typical queries.
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)

is Exists faster than a Join

From http://www.sql-server-performance.com/query_analysis_tuning.asp
B) Can standard JOIN's be replaced with EXISTS statements?
If you need to join tables to ensure XYZ value exists or a specific set of
rows exists, then considering porting to EXISTS or NOT EXISTS statements.
At the same time is may also alleviate the need for DISTINCT clauses.
So is a Join really potentiall slower?The Exists clause can be faster than a join because it just searches long
enough to find the first "Hit" as opposed to returning all rows that meet
the join criteria.
Greg Jackson
PDX, Oregon|||Could you please elaborate? An Exists will meet all the rows that meet the
query criteria. Given that the criteria should return the same data as a
join, how could it be faster?
"pdxJaxon" <GregoryAJackson@.Hotmail.com> wrote in message
news:eZWWYB7aFHA.3848@.TK2MSFTNGP10.phx.gbl...
> The Exists clause can be faster than a join because it just searches long
> enough to find the first "Hit" as opposed to returning all rows that meet
> the join criteria.
>
> Greg Jackson
> PDX, Oregon
>|||I say
SELECT * FROM Main
WHERE Exists(SELECT 1 FROM MyJoinTable a WHERE a.foo = main.foo)
then it will only check for the first hit.
still probably not making sense.
show us YOUR query and I can probably explain a bit better
GAJ|||create table #Table1(T1C1 int identity (1,1), T1C2 char(10))
create table #Table2(T2C1 int, T2C2 char(10))
insert into #Table1 (T1C2) values ('T1C2')
insert into #Table1 (T1C2) values ('T1C2-2')
insert into #Table2 (T2C1,T2C2) values (1,'T1C2')
select t1.T1C1,T1C2
from #Table1 t1
inner join #Table2 t2 on t1.t1c1 = t2.t2c1
or
select t1.T1C1,T1C2
from #table1 t1
where exists
(select * from #Table2 t2
where t2.T2C1 = T1.T1C1)
"pdxJaxon" <GregoryAJackson@.Hotmail.com> wrote in message
news:%23fZBCd7aFHA.464@.TK2MSFTNGP15.phx.gbl...
>I say
> SELECT * FROM Main
> WHERE Exists(SELECT 1 FROM MyJoinTable a WHERE a.foo = main.foo)
> then it will only check for the first hit.
> still probably not making sense.
> show us YOUR query and I can probably explain a bit better
>
> GAJ
>|||that's faster than a Join.
the where clause will return TRUE as soon as it finds a SINGLE record in
TABLE 2 that mathces Table1 (It will not bother returning more than 1 record
that matches to table 1)
A join will return ALL Records in T2 that match T1. IF there are millions of
records in each table, this would be exponentially faster.
Greg Jackson
PDX, Oregon|||On Tue, 7 Jun 2005 15:11:21 -0700, ChrisR wrote:
>From http://www.sql-server-performance.com/query_analysis_tuning.asp
>B) Can standard JOIN's be replaced with EXISTS statements?
>If you need to join tables to ensure XYZ value exists or a specific set of
>rows exists, then considering porting to EXISTS or NOT EXISTS statements.
>At the same time is may also alleviate the need for DISTINCT clauses.
>
>So is a Join really potentiall slower?
Hi Chris,
The question is actually irrelevant. A join is different: a query such
as
SELECT a.*
FROM a
WHERE EXISTS (SELECT * FROM b WHERE b.xx = a.xx)
will never return more than one copy of each row in a. Using a join
instead, such as this:
SELECT a.*
FROM a
JOIN b ON b.xx = a.xx
might return multiple copies of rows in a for values of xx that are not
unique in table b.
If no value of xx is ever duplicated in b, then the results will be the
same, but the EXISTS version might still be faster. Since SQL Server
doesn't know that there is only one row in b with a particular value of
xx, it still has to search the rest of the table after encoutering one;
if EXISTS is used, the search is aborted after the first match.
If SQL Server knows that values of b.xx are unique (because there is a
PRIMARY KEY or UNIQUE constraint on b.xx), then the performance MIGHT be
the same - the optimizer MIGHT decide to use the knowledge of this
constraint and createt the same execution plan it'll also use for the
EXISTS version.
I have never seen or heard of any situation where the JOIN would be
fafster than the "equivalent" EXISTS version. And I don't think I ever
will.
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)|||Hi Hugo and Chris,
"Hugo Kornelis" wrote:
> On Tue, 7 Jun 2005 15:11:21 -0700, ChrisR wrote:
> >From http://www.sql-server-performance.com/query_analysis_tuning.asp
> >
> >B) Can standard JOIN's be replaced with EXISTS statements?
> >If you need to join tables to ensure XYZ value exists or a specific set of
> >rows exists, then considering porting to EXISTS or NOT EXISTS statements.
> >At the same time is may also alleviate the need for DISTINCT clauses.
> >
> >So is a Join really potentiall slower?
> Hi Chris,
> The question is actually irrelevant. A join is different: a query such
> as
> SELECT a.*
> FROM a
> WHERE EXISTS (SELECT * FROM b WHERE b.xx = a.xx)
> will never return more than one copy of each row in a. Using a join
> instead, such as this:
> SELECT a.*
> FROM a
> JOIN b ON b.xx = a.xx
> might return multiple copies of rows in a for values of xx that are not
> unique in table b.
> If no value of xx is ever duplicated in b, then the results will be the
> same, but the EXISTS version might still be faster. Since SQL Server
> doesn't know that there is only one row in b with a particular value of
> xx, it still has to search the rest of the table after encoutering one;
> if EXISTS is used, the search is aborted after the first match.
> If SQL Server knows that values of b.xx are unique (because there is a
> PRIMARY KEY or UNIQUE constraint on b.xx), then the performance MIGHT be
> the same - the optimizer MIGHT decide to use the knowledge of this
> constraint and createt the same execution plan it'll also use for the
> EXISTS version.
> I have never seen or heard of any situation where the JOIN would be
> fafster than the "equivalent" EXISTS version. And I don't think I ever
> will.
>
I think you have to try the statement both ways.
I'm not sure about EXISTS, but I have a fairly complex multi-way join that
is much faster with
a LEFT JOIN b on a.id = b.id ... WHERE b.id is null
than with
WHERE NOT EXISTS (select 1 from b where a.id = b.id)
Regards,
Jonathan|||On Thu, 9 Jun 2005 12:52:03 -0700, Jonathan Levine wrote:
(snip)
>I'm not sure about EXISTS, but I have a fairly complex multi-way join that
>is much faster with
>a LEFT JOIN b on a.id = b.id ... WHERE b.id is null
>than with
>WHERE NOT EXISTS (select 1 from b where a.id = b.id)
Hi Jonathan,
Thanks for adding this. This is not the first time I witness or hear
reports of this either. It seems that the SQL Server development team
put most effort in the optimization of join strategies, since they are
used most often in typical queries.
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)|||Also, be careful of the Optimizer Estimated Execution Plans. I especially
see this in comparisons between LEFT OUTER JOINS versus the use of EXISTS or
NOT EXISTS.
Even though the JOIN may produce a better ESTIMATED execution cost, it will
often create a HASH table for the JOIN, where the EXISTS solution will often
use a Nested Loop JOIN. The HASH will ALWAYS create temporary object, which
will have physical impact that the Optimizer does not take into account.
You're best bet would be to SET STATISTICS time and I/O on and run them both
ways, making sure to flush the Buffer Pool before each execution. This will
give you ACTUAL run information, not just ESTIMATED.
Sincerely,
Anthony Thomas
"Hugo Kornelis" <hugo@.pe_NO_rFact.in_SPAM_fo> wrote in message
news:mnfha11l8fukurbcocmi9rg30s47q0lj6j@.4ax.com...
On Thu, 9 Jun 2005 12:52:03 -0700, Jonathan Levine wrote:
(snip)
>I'm not sure about EXISTS, but I have a fairly complex multi-way join that
>is much faster with
>a LEFT JOIN b on a.id = b.id ... WHERE b.id is null
>than with
>WHERE NOT EXISTS (select 1 from b where a.id = b.id)
Hi Jonathan,
Thanks for adding this. This is not the first time I witness or hear
reports of this either. It seems that the SQL Server development team
put most effort in the optimization of join strategies, since they are
used most often in typical queries.
Best, Hugo
--
(Remove _NO_ and _SPAM_ to get my e-mail address)