From fuller.artful at gmail.com  Tue Jul  1 06:36:18 2008
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Tue, 1 Jul 2008 08:36:18 -0300
Subject: [dba-SQLServer] dba-SQLServer Digest, Vol 64, Issue 23
In-Reply-To: <200806302302.m5UN2IIt010799@databaseadvisors.com>
References: <mailman.33818.1214654995.3000.dba-sqlserver@databaseadvisors.com>
	<200806302302.m5UN2IIt010799@databaseadvisors.com>
Message-ID: <29f585dd0807010436n4bcd2352q1accad4df13ca43b@mail.gmail.com>

That's what I thought, but now I have another question. On which of my
numerous MS CDs will I find VSS? I've installed VS 2005 and SQL 2005 and no
sign of VSS, so do I have to reach back further to something like Office
Developer? So many CDs, so little time :)

Arthur

On Mon, Jun 30, 2008 at 7:59 PM, Robert L. Stewart <robert at webedb.com>
wrote:

> Arthur,
>
> VSS integrates with SQL Management Studio. This makes
> it easy to use it for version control for SQL. It
> also integrates with VS 2005, so using it for the front
> end is also easy.
>
> Subversion, as far as I know, does not integrate with
> either one. There is an integration for Eclipse.
>


From ssharkins at gmail.com  Tue Jul  1 11:20:54 2008
From: ssharkins at gmail.com (Susan Harkins)
Date: Tue, 1 Jul 2008 12:20:54 -0400
Subject: [dba-SQLServer] RESEED deletes records
Message-ID: <050d01c8db96$71fd4460$2f8601c7@SusanOne>

I'm running some tests on DBCC CHECKIDENT and only one surprise:

DBCC CHECKIDENT (tablename, RESEED)

deletes the table's records. Now, I wasn't expecting that, since the 
documentation says it corrects the seed value -- in truth, I wasn't sure 
what that meant, hence the testing.

I'm going to do a little research, but if someone already has an explanation 
and doesn't mind sharing, please do.

Susan H. 



From ssharkins at gmail.com  Tue Jul  1 11:34:35 2008
From: ssharkins at gmail.com (Susan Harkins)
Date: Tue, 1 Jul 2008 12:34:35 -0400
Subject: [dba-SQLServer] Fw: RESEED deletes records
Message-ID: <054001c8db98$5b50c0f0$2f8601c7@SusanOne>

I forgot to mention that I'm using SQL Server 2005 Express -- not sure why 
that would matter, but it might.

Susan H.


> I'm running some tests on DBCC CHECKIDENT and only one surprise:
>
> DBCC CHECKIDENT (tablename, RESEED)
>
> deletes the table's records. Now, I wasn't expecting that, since the 
> documentation says it corrects the seed value -- in truth, I wasn't sure 
> what that meant, hence the testing.
>
> I'm going to do a little research, but if someone already has an 
> explanation and doesn't mind sharing, please do.
>
> Susan H. 



From fhtapia at gmail.com  Tue Jul  1 15:04:40 2008
From: fhtapia at gmail.com (Francisco Tapia)
Date: Tue, 1 Jul 2008 13:04:40 -0700
Subject: [dba-SQLServer] Fw: RESEED deletes records
In-Reply-To: <054001c8db98$5b50c0f0$2f8601c7@SusanOne>
References: <054001c8db98$5b50c0f0$2f8601c7@SusanOne>
Message-ID: <b874372a0807011304s26b1214eyb1105b122ed8cc35@mail.gmail.com>

I am having a hard time re-producing your results, here is what I tried from
the article on SqlServerCentral
http://www.sqlservercentral.com/articles/RESEED/62847/

--Create table
CREATE TABLE dbo.reseedtest (reseedtestId INT IDENTITY(1,1), column2
NVARCHAR(50));
--Insert a few rows
INSERT dbo.reseedtest (column2) VALUES ('One')
INSERT dbo.reseedtest (column2) VALUES ('Two')
--RESEED on a non-virgin table and insert a few rows
DBCC CHECKIDENT('dbo.reseedtest',RESEED,3);

INSERT dbo.reseedtest (column2) VALUES ('Three')
INSERT dbo.reseedtest (column2) VALUES ('Four')

select * from reseedtest

The only thing

On Tue, Jul 1, 2008 at 9:34 AM, Susan Harkins <ssharkins at gmail.com> wrote:

> I forgot to mention that I'm using SQL Server 2005 Express -- not sure why
> that would matter, but it might.
>
> Susan H.
>
>
> > I'm running some tests on DBCC CHECKIDENT and only one surprise:
> >
> > DBCC CHECKIDENT (tablename, RESEED)
> >
> > deletes the table's records. Now, I wasn't expecting that, since the
> > documentation says it corrects the seed value -- in truth, I wasn't sure
> > what that meant, hence the testing.
> >
> > I'm going to do a little research, but if someone already has an
> > explanation and doesn't mind sharing, please do.
> >
> > Susan H.
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>


-- 
-Francisco
http://sqlthis.blogspot.com | Tsql and More...


From ssharkins at gmail.com  Tue Jul  1 16:10:46 2008
From: ssharkins at gmail.com (Susan Harkins)
Date: Tue, 1 Jul 2008 17:10:46 -0400
Subject: [dba-SQLServer] Fw: RESEED deletes records
References: <054001c8db98$5b50c0f0$2f8601c7@SusanOne>
	<b874372a0807011304s26b1214eyb1105b122ed8cc35@mail.gmail.com>
Message-ID: <06dc01c8dbbe$ef81ceb0$2f8601c7@SusanOne>

RESEED deleted all the rows -- I have no explanation whatsoever other than 
it may be a bug in Express, but I've not found anything on it yet.

Susan H.

>I am having a hard time re-producing your results, here is what I tried 
>from
> the article on SqlServerCentral
> http://www.sqlservercentral.com/articles/RESEED/62847/



From fhtapia at gmail.com  Tue Jul  1 16:25:28 2008
From: fhtapia at gmail.com (Francisco Tapia)
Date: Tue, 1 Jul 2008 14:25:28 -0700
Subject: [dba-SQLServer] Fw: RESEED deletes records
In-Reply-To: <06dc01c8dbbe$ef81ceb0$2f8601c7@SusanOne>
References: <054001c8db98$5b50c0f0$2f8601c7@SusanOne>
	<b874372a0807011304s26b1214eyb1105b122ed8cc35@mail.gmail.com>
	<06dc01c8dbbe$ef81ceb0$2f8601c7@SusanOne>
Message-ID: <b874372a0807011425g287e9c17u1531495bdba67f0f@mail.gmail.com>

What SP are you on with your Express engine?

On Tue, Jul 1, 2008 at 2:10 PM, Susan Harkins <ssharkins at gmail.com> wrote:

> RESEED deleted all the rows -- I have no explanation whatsoever other than
> it may be a bug in Express, but I've not found anything on it yet.
>
> Susan H.
>
> >I am having a hard time re-producing your results, here is what I tried
> >from
> > the article on SqlServerCentral
> > http://www.sqlservercentral.com/articles/RESEED/62847/
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>


-- 
-Francisco
http://sqlthis.blogspot.com | Tsql and More...


From ssharkins at gmail.com  Wed Jul  2 17:04:47 2008
From: ssharkins at gmail.com (Susan Harkins)
Date: Wed, 2 Jul 2008 18:04:47 -0400
Subject: [dba-SQLServer] free training
Message-ID: <0d2301c8dc8f$a67d1b30$2f8601c7@SusanOne>

<http://www.sqlservercentral.com/articles/Training/63567/>

Susan H. 


From ab-mi at post3.tele.dk  Thu Jul  3 17:46:34 2008
From: ab-mi at post3.tele.dk (Asger Blond)
Date: Fri, 4 Jul 2008 00:46:34 +0200
Subject: [dba-SQLServer] Free Microsoft Press E-Book Offer
In-Reply-To: <0d2301c8dc8f$a67d1b30$2f8601c7@SusanOne>
Message-ID: <000001c8dd5e$a5433a90$2101a8c0@AB>

Anyone tried this link?
http://csna01.libredigital.com/?urss1q2we6
It's a free version of Peter DeBetta's book "Introducing SQL Server 2008".
When entering the page you can get a preview of chapter 1 and 11, or as
stated on the page:
"The entire contents of this book will be made available from this site in
late Q1 2008."
However, when clicking the button to download the entire book I only get
chapter 1 and 11.
Has Peter DeBetta not finish his book yet, or do I have to use a different
link?
TIA
Asger




































































































































































From Darryl.Collins at coles.com.au  Thu Jul  3 19:09:23 2008
From: Darryl.Collins at coles.com.au (Darryl Collins)
Date: Fri, 4 Jul 2008 10:09:23 +1000
Subject: [dba-SQLServer] Data Transformation Question.
In-Reply-To: <000001c8dd5e$a5433a90$2101a8c0@AB>
Message-ID: <57E6E6CA42105A48B977303A2CDC2720076BF12CC1@WPEXCH22.retail.ad.cmltd.net.au>


Hi Guys and Gals,

I have create some local packages using the Data Transformation wizard so I can pull data in from an Access Database into SQL Server.  This process works great and I have ask for it to be run once a day ra ra ra.

Problem is when it runs it just keeps appending data to the table, rather than replacing the existing data.

How can I get the package to remove all the existing data in the table first, and then import the updated data from the external database.

AirCodeish.

DELETE * FROM tbl_MyTable
Then Run the local package.

This cannot be hard to do, but I just cannot see how it make it work.

Regard
Darryl

This email and any attachments may contain privileged and confidential information and are intended for the named addressee only. If you have received this e-mail in error, please notify the sender and delete this e-mail immediately. Any confidentiality, privilege or copyright is not waived or lost because this e-mail has been sent to you in error. It is your responsibility to check this e-mail and any attachments for viruses.  No warranty is made that this material is free from computer virus or any other defect or error.  Any loss/damage incurred by using this material is not the sender's responsibility.  The sender's entire liability will be limited to resupplying the material.



From fuller.artful at gmail.com  Fri Jul  4 06:28:11 2008
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Fri, 4 Jul 2008 08:28:11 -0300
Subject: [dba-SQLServer] AdventureWorks->AdventureWorksDW
Message-ID: <29f585dd0807040428t26f840d1g8840ce16ab36ac11@mail.gmail.com>

I have failed to discover in the docs exactly how AdventureWorksDW was
created from the original source AdventureWorks, such as how and why various
decisions were made. For example, DimCustomer. Should one create a view to
denormalize all the attendant lookups and then use that as one of the data
sources? And even more basically, given your basic OLTP db (call it a), what
steps do you execute to create your OLAP db (call it b)? I understand some
of what to do once I get from a to b, I'm just unsteady on how to get from a
to b.

TIA,
Arthur


From robert at webedb.com  Sun Jul  6 10:01:40 2008
From: robert at webedb.com (Robert L. Stewart)
Date: Sun, 06 Jul 2008 10:01:40 -0500
Subject: [dba-SQLServer] AdventureWorks->AdventureWorksDW
In-Reply-To: <mailman.5.1215190803.11436.dba-sqlserver@databaseadvisors. com>
References: <mailman.5.1215190803.11436.dba-sqlserver@databaseadvisors.com>
Message-ID: <200807061505.m66F4wnQ008060@databaseadvisors.com>

Arthur,

dimCustomer is a dimension table which is highly denormalized, or should be.
The idea is to keep it to what is called a star schema. This means that there
should be on a single kep to link the different aspects to the fact table. The
fact table is what holds the additive data, data which can 99% of the time
be added, subtracted, multiplied or divided. If you, for instance, do not
store the address information in the customer dimension, and then link to
the customer address table to get it, it is called snowflaking. Snowflaking
will significantly reduce the performance on a data warehouse.

I have not dealt with the cube type data mart (MOLAP). I have only dealt
with star schema type (ROLAP).

At 12:00 PM 7/4/2008, you wrote:
>Date: Fri, 4 Jul 2008 08:28:11 -0300
>From: "Arthur Fuller" <fuller.artful at gmail.com>
>Subject: [dba-SQLServer] AdventureWorks->AdventureWorksDW
>To: "Discussion concerning MS SQL Server"
>         <dba-sqlserver at databaseadvisors.com>
>Message-ID:
>         <29f585dd0807040428t26f840d1g8840ce16ab36ac11 at mail.gmail.com>
>Content-Type: text/plain; charset=ISO-8859-1
>
>I have failed to discover in the docs exactly how AdventureWorksDW was
>created from the original source AdventureWorks, such as how and why various
>decisions were made. For example, DimCustomer. Should one create a view to
>denormalize all the attendant lookups and then use that as one of the data
>sources? And even more basically, given your basic OLTP db (call it a), what
>steps do you execute to create your OLAP db (call it b)? I understand some
>of what to do once I get from a to b, I'm just unsteady on how to get from a
>to b.
>
>TIA,
>Arthur




From robert at webedb.com  Sun Jul  6 10:05:12 2008
From: robert at webedb.com (Robert L. Stewart)
Date: Sun, 06 Jul 2008 10:05:12 -0500
Subject: [dba-SQLServer] Data Transformation Question
In-Reply-To: <mailman.5.1215190803.11436.dba-sqlserver@databaseadvisors. com>
References: <mailman.5.1215190803.11436.dba-sqlserver@databaseadvisors.com>
Message-ID: <200807061507.m66F7kj0010143@databaseadvisors.com>

Darryl,

Unless you want the deletions to take longer and be recorded in the log,
you would do a TRUNCATE TABLE MyTable in an Execute SQL task. Then, you
would link it to the other one with an On Success join line (the green one
changed to blue).

Robert

At 12:00 PM 7/4/2008, you wrote:
>Date: Fri, 4 Jul 2008 10:09:23 +1000
>From: Darryl Collins <Darryl.Collins at coles.com.au>
>Subject: [dba-SQLServer] Data Transformation Question.
>To: "'Discussion concerning MS SQL Server'"
>         <dba-sqlserver at databaseadvisors.com>
>Message-ID:
> 
><57E6E6CA42105A48B977303A2CDC2720076BF12CC1 at WPEXCH22.retail.ad.cmltd.net.au>
>
>Content-Type: text/plain; charset="us-ascii"
>
>
>Hi Guys and Gals,
>
>I have create some local packages using the Data Transformation 
>wizard so I can pull data in from an Access Database into SQL 
>Server.  This process works great and I have ask for it to be run 
>once a day ra ra ra.
>
>Problem is when it runs it just keeps appending data to the table, 
>rather than replacing the existing data.
>
>How can I get the package to remove all the existing data in the 
>table first, and then import the updated data from the external database.
>
>AirCodeish.
>
>DELETE * FROM tbl_MyTable
>Then Run the local package.
>
>This cannot be hard to do, but I just cannot see how it make it work.
>
>Regard
>Darryl




From Darryl.Collins at coles.com.au  Mon Jul  7 00:26:28 2008
From: Darryl.Collins at coles.com.au (Darryl Collins)
Date: Mon, 7 Jul 2008 15:26:28 +1000
Subject: [dba-SQLServer] Data Transformation Question
In-Reply-To: <200807061507.m66F7kj0010143@databaseadvisors.com>
Message-ID: <57E6E6CA42105A48B977303A2CDC2720076BF12CDB@WPEXCH22.retail.ad.cmltd.net.au>


ok....  I cannot find anything about TRUNCATE in the help - I am using SQL Server 2000 so maybe this method is a later addition to SQL Server.

Sorry if this is a dumb question, I am pretty green at this SQL businesss.

cheers
Darryl


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of Robert
L. Stewart
Sent: Monday, 7 July 2008 1:05 AM
To: dba-sqlserver at databaseadvisors.com
Cc: Darryl Collins
Subject: Re: [dba-SQLServer] Data Transformation Question


Darryl,

Unless you want the deletions to take longer and be recorded in the log,
you would do a TRUNCATE TABLE MyTable in an Execute SQL task. Then, you
would link it to the other one with an On Success join line (the green one
changed to blue).

Robert

At 12:00 PM 7/4/2008, you wrote:
>Date: Fri, 4 Jul 2008 10:09:23 +1000
>From: Darryl Collins <Darryl.Collins at coles.com.au>
>Subject: [dba-SQLServer] Data Transformation Question.
>To: "'Discussion concerning MS SQL Server'"
>         <dba-sqlserver at databaseadvisors.com>
>Message-ID:
>
><57E6E6CA42105A48B977303A2CDC2720076BF12CC1 at WPEXCH22.retail.ad.cmltd.net.au>
>
>Content-Type: text/plain; charset="us-ascii"
>
>
>Hi Guys and Gals,
>
>I have create some local packages using the Data Transformation
>wizard so I can pull data in from an Access Database into SQL
>Server.  This process works great and I have ask for it to be run
>once a day ra ra ra.
>
>Problem is when it runs it just keeps appending data to the table,
>rather than replacing the existing data.
>
>How can I get the package to remove all the existing data in the
>table first, and then import the updated data from the external database.
>
>AirCodeish.
>
>DELETE * FROM tbl_MyTable
>Then Run the local package.
>
>This cannot be hard to do, but I just cannot see how it make it work.
>
>Regard
>Darryl


_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com


This email and any attachments may contain privileged and confidential information and are intended for the named addressee only. If you have received this e-mail in error, please notify the sender and delete this e-mail immediately. Any confidentiality, privilege or copyright is not waived or lost because this e-mail has been sent to you in error. It is your responsibility to check this e-mail and any attachments for viruses.  No warranty is made that this material is free from computer virus or any other defect or error.  Any loss/damage incurred by using this material is not the sender's responsibility.  The sender's entire liability will be limited to resupplying the material.



From Darryl.Collins at coles.com.au  Mon Jul  7 00:43:35 2008
From: Darryl.Collins at coles.com.au (Darryl Collins)
Date: Mon, 7 Jul 2008 15:43:35 +1000
Subject: [dba-SQLServer] Data Transformation Question
In-Reply-To: <57E6E6CA42105A48B977303A2CDC2720076BF12CDB@WPEXCH22.retail.ad.cmltd.net.au>
Message-ID: <57E6E6CA42105A48B977303A2CDC2720076BF12CDC@WPEXCH22.retail.ad.cmltd.net.au>



hmmm... speaking of dumb...  I do a bit more research into this (outside of SQL help) and found it why it works, why it is different from delete and tested it a few times in a sproc.

So far so good.  Although I am suprised that I still cannot find it in MS help.

cheers
Darryl.

-----Original Message-----
From: Darryl Collins
Sent: Monday, 7 July 2008 3:26 PM
To: 'Discussion concerning MS SQL Server'
Subject: RE: [dba-SQLServer] Data Transformation Question



ok....  I cannot find anything about TRUNCATE in the help - I am using SQL Server 2000 so maybe this method is a later addition to SQL Server.

Sorry if this is a dumb question, I am pretty green at this SQL businesss.

cheers
Darryl


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of Robert
L. Stewart
Sent: Monday, 7 July 2008 1:05 AM
To: dba-sqlserver at databaseadvisors.com
Cc: Darryl Collins
Subject: Re: [dba-SQLServer] Data Transformation Question


Darryl,

Unless you want the deletions to take longer and be recorded in the log,
you would do a TRUNCATE TABLE MyTable in an Execute SQL task. Then, you
would link it to the other one with an On Success join line (the green one
changed to blue).

Robert

At 12:00 PM 7/4/2008, you wrote:
>Date: Fri, 4 Jul 2008 10:09:23 +1000
>From: Darryl Collins <Darryl.Collins at coles.com.au>
>Subject: [dba-SQLServer] Data Transformation Question.
>To: "'Discussion concerning MS SQL Server'"
>         <dba-sqlserver at databaseadvisors.com>
>Message-ID:
>
><57E6E6CA42105A48B977303A2CDC2720076BF12CC1 at WPEXCH22.retail.ad.cmltd.net.au>
>
>Content-Type: text/plain; charset="us-ascii"
>
>
>Hi Guys and Gals,
>
>I have create some local packages using the Data Transformation
>wizard so I can pull data in from an Access Database into SQL
>Server.  This process works great and I have ask for it to be run
>once a day ra ra ra.
>
>Problem is when it runs it just keeps appending data to the table,
>rather than replacing the existing data.
>
>How can I get the package to remove all the existing data in the
>table first, and then import the updated data from the external database.
>
>AirCodeish.
>
>DELETE * FROM tbl_MyTable
>Then Run the local package.
>
>This cannot be hard to do, but I just cannot see how it make it work.
>
>Regard
>Darryl


_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com


This email and any attachments may contain privileged and confidential information and are intended for the named addressee only. If you have received this e-mail in error, please notify the sender and delete this e-mail immediately. Any confidentiality, privilege or copyright is not waived or lost because this e-mail has been sent to you in error. It is your responsibility to check this e-mail and any attachments for viruses.  No warranty is made that this material is free from computer virus or any other defect or error.  Any loss/damage incurred by using this material is not the sender's responsibility.  The sender's entire liability will be limited to resupplying the material.



From fuller.artful at gmail.com  Mon Jul  7 11:37:24 2008
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Mon, 7 Jul 2008 13:37:24 -0300
Subject: [dba-SQLServer] Data Transformation Question
In-Reply-To: <57E6E6CA42105A48B977303A2CDC2720076BF12CDC@WPEXCH22.retail.ad.cmltd.net.au>
References: <57E6E6CA42105A48B977303A2CDC2720076BF12CDB@WPEXCH22.retail.ad.cmltd.net.au>
	<57E6E6CA42105A48B977303A2CDC2720076BF12CDC@WPEXCH22.retail.ad.cmltd.net.au>
Message-ID: <29f585dd0807070937q4bed6868w12c1d3e7bdf0b967@mail.gmail.com>

One thing that you should know about TRUNCATE is that it does not return the
space to the OS. In many cases that's no big deal, but if you're trying to
recover disk space then look into DBCC SHRINKFILE.

Arthur

On 7/7/08, Darryl Collins <Darryl.Collins at coles.com.au> wrote:
>
>
>
> hmmm... speaking of dumb...  I do a bit more research into this (outside of
> SQL help) and found it why it works, why it is different from delete and
> tested it a few times in a sproc.
>
> So far so good.  Although I am suprised that I still cannot find it in MS
> help.
>
> cheers
>
> Darryl.
>


From Darryl.Collins at coles.com.au  Mon Jul  7 18:43:23 2008
From: Darryl.Collins at coles.com.au (Darryl Collins)
Date: Tue, 8 Jul 2008 09:43:23 +1000
Subject: [dba-SQLServer] Data Transformation Question
In-Reply-To: <29f585dd0807070937q4bed6868w12c1d3e7bdf0b967@mail.gmail.com>
Message-ID: <57E6E6CA42105A48B977303A2CDC2720076BF12CE1@WPEXCH22.retail.ad.cmltd.net.au>

Thanks Arthur,

In this case I suspect it wont matter, however this tidbit of information is good to know and I will file for future reference.

Cheers
Darryl

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of Arthur
Fuller
Sent: Tuesday, 8 July 2008 2:37 AM
To: Discussion concerning MS SQL Server
Subject: Re: [dba-SQLServer] Data Transformation Question


One thing that you should know about TRUNCATE is that it does not return the
space to the OS. In many cases that's no big deal, but if you're trying to
recover disk space then look into DBCC SHRINKFILE.

Arthur

On 7/7/08, Darryl Collins <Darryl.Collins at coles.com.au> wrote:
>
>
>
> hmmm... speaking of dumb...  I do a bit more research into this (outside of
> SQL help) and found it why it works, why it is different from delete and
> tested it a few times in a sproc.
>
> So far so good.  Although I am suprised that I still cannot find it in MS
> help.
>
> cheers
>
> Darryl.
>
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com


This email and any attachments may contain privileged and confidential information and are intended for the named addressee only. If you have received this e-mail in error, please notify the sender and delete this e-mail immediately. Any confidentiality, privilege or copyright is not waived or lost because this e-mail has been sent to you in error. It is your responsibility to check this e-mail and any attachments for viruses.  No warranty is made that this material is free from computer virus or any other defect or error.  Any loss/damage incurred by using this material is not the sender's responsibility.  The sender's entire liability will be limited to resupplying the material.



From ab-mi at post3.tele.dk  Mon Jul  7 18:53:01 2008
From: ab-mi at post3.tele.dk (Asger Blond)
Date: Tue, 8 Jul 2008 01:53:01 +0200
Subject: [dba-SQLServer] Data Transformation Question
In-Reply-To: <57E6E6CA42105A48B977303A2CDC2720076BF12CDB@WPEXCH22.retail.ad.cmltd.net.au>
Message-ID: <000001c8e08c$97a40050$2101a8c0@AB>

Darryl,

DTS Import/Export Wizard in SQL Server 2000:
On the step-page "Select Source Tables and Views" you have a button (with
tree dots) in the column "Transform", click this button and you will reach
the page "Column Mappings and Transformations". On this page select the
checkbox "Drop and recreate destination table".

HTH
Asger

-----Oprindelig meddelelse-----
Fra: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] P? vegne af Darryl
Collins
Sendt: 7. juli 2008 07:26
Til: 'Discussion concerning MS SQL Server'
Emne: Re: [dba-SQLServer] Data Transformation Question


ok....  I cannot find anything about TRUNCATE in the help - I am using SQL
Server 2000 so maybe this method is a later addition to SQL Server.

Sorry if this is a dumb question, I am pretty green at this SQL businesss.

cheers
Darryl


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of Robert
L. Stewart
Sent: Monday, 7 July 2008 1:05 AM
To: dba-sqlserver at databaseadvisors.com
Cc: Darryl Collins
Subject: Re: [dba-SQLServer] Data Transformation Question


Darryl,

Unless you want the deletions to take longer and be recorded in the log,
you would do a TRUNCATE TABLE MyTable in an Execute SQL task. Then, you
would link it to the other one with an On Success join line (the green one
changed to blue).

Robert

At 12:00 PM 7/4/2008, you wrote:
>Date: Fri, 4 Jul 2008 10:09:23 +1000
>From: Darryl Collins <Darryl.Collins at coles.com.au>
>Subject: [dba-SQLServer] Data Transformation Question.
>To: "'Discussion concerning MS SQL Server'"
>         <dba-sqlserver at databaseadvisors.com>
>Message-ID:
>
><57E6E6CA42105A48B977303A2CDC2720076BF12CC1 at WPEXCH22.retail.ad.cmltd.net..au
>
>
>Content-Type: text/plain; charset="us-ascii"
>
>
>Hi Guys and Gals,
>
>I have create some local packages using the Data Transformation
>wizard so I can pull data in from an Access Database into SQL
>Server.  This process works great and I have ask for it to be run
>once a day ra ra ra.
>
>Problem is when it runs it just keeps appending data to the table,
>rather than replacing the existing data.
>
>How can I get the package to remove all the existing data in the
>table first, and then import the updated data from the external database.
>
>AirCodeish.
>
>DELETE * FROM tbl_MyTable
>Then Run the local package.
>
>This cannot be hard to do, but I just cannot see how it make it work.
>
>Regard
>Darryl


_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com


This email and any attachments may contain privileged and confidential
information and are intended for the named addressee only. If you have
received this e-mail in error, please notify the sender and delete this
e-mail immediately. Any confidentiality, privilege or copyright is not
waived or lost because this e-mail has been sent to you in error. It is your
responsibility to check this e-mail and any attachments for viruses.  No
warranty is made that this material is free from computer virus or any other
defect or error.  Any loss/damage incurred by using this material is not the
sender's responsibility.  The sender's entire liability will be limited to
resupplying the material.

_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com






























































































































































































From stuart at lexacorp.com.pg  Mon Jul  7 18:15:41 2008
From: stuart at lexacorp.com.pg (Stuart McLachlan)
Date: Tue, 08 Jul 2008 09:15:41 +1000
Subject: [dba-SQLServer] Data Transformation Question
In-Reply-To: <57E6E6CA42105A48B977303A2CDC2720076BF12CDC@WPEXCH22.retail.ad.cmltd.net.au>
References: <57E6E6CA42105A48B977303A2CDC2720076BF12CDB@WPEXCH22.retail.ad.cmltd.net.au>
Message-ID: <4873303D.29958.614BFC27@stuart.lexacorp.com.pg>

Strange, in my 2000 BOL, Transact SQL - there is an index entry for "TRUNCATE TABLE".

<quote>
TRUNCATE TABLE
Removes all rows from a table without logging the individual row deletes. 
Syntax
TRUNCATE TABLE name
Arguments
name
Is the name of the table to truncate or from which all rows are removed.
Remarks
TRUNCATE TABLE is functionally identical to DELETE statement with no 
WHERE clause: both remove all rows in the table. But TRUNCATE TABLE is faster 
and uses fewer system and transaction log resources than DELETE. 
The DELETE statement removes rows one at a time and records an entry in the 
transaction log for each deleted row. TRUNCATE TABLE removes the data by 
deallocating the data pages used to store the table's data, and only the page 
deallocations are recorded in the transaction log.
TRUNCATE TABLE removes all rows from a table, but the table structure and its 
columns, constraints, indexes and so on remain. The counter used by an identity for 
new rows is reset to the seed for the column. If you want to retain the identity 
counter, use DELETE instead. If you want to remove table definition and its data, use 
the DROP TABLE statement.
You cannot use TRUNCATE TABLE on a table referenced by a FOREIGN KEY 
constraint; instead, use DELETE statement without a WHERE clause. Because 
TRUNCATE TABLE is not logged, it cannot activate a trigger. 
TRUNCATE TABLE may not be used on tables participating in an indexed view.
Examples
This example removes all data from the authors table.
TRUNCATE TABLE authors
Permissions
TRUNCATE TABLE permissions default to the table owner, members of the 
sysadmin fixed server role, and the db_owner and db_ddladmin fixed database 
roles, and are not transferable.
See Also
DELETE
DROP TABLE
       ?1988-2000 Microsoft Corporation. All Rights Reserved.

</quote>

On 7 Jul 2008 at 15:43, Darryl Collins wrote:

> 
> 
> hmmm... speaking of dumb... I do a bit more research into this (outside of SQL help) and found it why it works, why it is different from delete and tested it a few times in a sproc.
> 
> So far so good. Although I am suprised that I still cannot find it in MS help.
> 
> cheers
> Darryl.
> 
> -----Original Message-----
> From: Darryl Collins
> Sent: Monday, 7 July 2008 3:26 PM
> To: 'Discussion concerning MS SQL Server'
> Subject: RE: [dba-SQLServer] Data Transformation Question
> 
> 
> 
> ok.... I cannot find anything about TRUNCATE in the help - I am using SQL Server 2000 so maybe this method is a later addition to SQL Server.
> 
> Sorry if this is a dumb question, I am pretty green at this SQL businesss.
> 




From pcs.accessd at gmail.com  Mon Jul  7 19:03:31 2008
From: pcs.accessd at gmail.com (Borge Hansen)
Date: Tue, 8 Jul 2008 10:03:31 +1000
Subject: [dba-SQLServer] concatenating strings where one or more string is
	null
Message-ID: <f0981fe30807071703l7e846fa4i99c64dd514064a@mail.gmail.com>

Hi,

A very simple one:

What is 'best practise way' of handling something like the following in a
select sp or view:


t.StreetNrPOBox + ', . . . ' + t.StreetName + ', . . . ' + t.Suburb + ', . .
.' as xyz

where one of the column values may be null ??

MS Help in BOL is again not very helpful ... (topic: concatenation [SQL
Server] )

They talk about

..Just like arithmetic operations that are performed on null values, when a
null value is added to a known value the result is typically an unknown
value, a string concatenation operation that is performed with a null value
should also produce a null result. However, you can change this behavior by
changing the setting of CONCAT_NULL_YIELDS_NULL for the current session. For
more information, see SET CONCAT_NULL_YIELDS_NULL (Transact-SQL).

Then for SET CONCAT_NULL_YIELDS_NULL { ON|OFF } the first thing you read is:

  Important:  This feature will be removed in a future version of Microsoft
SQL Server. Avoid using this feature in new development work, and plan to
modify applications that currently use this feature.

So, what's best practise here:

a) Don't allow null in any text fields in your table definitions?

b) use a case statement to test for null

c) ?


From Darryl.Collins at coles.com.au  Mon Jul  7 20:34:23 2008
From: Darryl.Collins at coles.com.au (Darryl Collins)
Date: Tue, 8 Jul 2008 11:34:23 +1000
Subject: [dba-SQLServer] Data Transformation Question
In-Reply-To: <000001c8e08c$97a40050$2101a8c0@AB>
Message-ID: <57E6E6CA42105A48B977303A2CDC2720076BF12CEB@WPEXCH22.retail.ad.cmltd.net.au>


This look perfect.  Thanks Asger.



-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of Asger
Blond
Sent: Tuesday, 8 July 2008 9:53 AM
To: 'Discussion concerning MS SQL Server'
Subject: Re: [dba-SQLServer] Data Transformation Question


Darryl,

DTS Import/Export Wizard in SQL Server 2000:
On the step-page "Select Source Tables and Views" you have a button (with
tree dots) in the column "Transform", click this button and you will reach
the page "Column Mappings and Transformations". On this page select the
checkbox "Drop and recreate destination table".

HTH
Asger

-----Oprindelig meddelelse-----
Fra: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] P? vegne af Darryl
Collins
Sendt: 7. juli 2008 07:26
Til: 'Discussion concerning MS SQL Server'
Emne: Re: [dba-SQLServer] Data Transformation Question


ok....  I cannot find anything about TRUNCATE in the help - I am using SQL
Server 2000 so maybe this method is a later addition to SQL Server.

Sorry if this is a dumb question, I am pretty green at this SQL businesss.

cheers
Darryl


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of Robert
L. Stewart
Sent: Monday, 7 July 2008 1:05 AM
To: dba-sqlserver at databaseadvisors.com
Cc: Darryl Collins
Subject: Re: [dba-SQLServer] Data Transformation Question


Darryl,

Unless you want the deletions to take longer and be recorded in the log,
you would do a TRUNCATE TABLE MyTable in an Execute SQL task. Then, you
would link it to the other one with an On Success join line (the green one
changed to blue).

Robert

At 12:00 PM 7/4/2008, you wrote:
>Date: Fri, 4 Jul 2008 10:09:23 +1000
>From: Darryl Collins <Darryl.Collins at coles.com.au>
>Subject: [dba-SQLServer] Data Transformation Question.
>To: "'Discussion concerning MS SQL Server'"
>         <dba-sqlserver at databaseadvisors.com>
>Message-ID:
>
><57E6E6CA42105A48B977303A2CDC2720076BF12CC1 at WPEXCH22.retail.ad.cmltd.net..au
>
>
>Content-Type: text/plain; charset="us-ascii"
>
>
>Hi Guys and Gals,
>
>I have create some local packages using the Data Transformation
>wizard so I can pull data in from an Access Database into SQL
>Server.  This process works great and I have ask for it to be run
>once a day ra ra ra.
>
>Problem is when it runs it just keeps appending data to the table,
>rather than replacing the existing data.
>
>How can I get the package to remove all the existing data in the
>table first, and then import the updated data from the external database.
>
>AirCodeish.
>
>DELETE * FROM tbl_MyTable
>Then Run the local package.
>
>This cannot be hard to do, but I just cannot see how it make it work.
>
>Regard
>Darryl


_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com


This email and any attachments may contain privileged and confidential
information and are intended for the named addressee only. If you have
received this e-mail in error, please notify the sender and delete this
e-mail immediately. Any confidentiality, privilege or copyright is not
waived or lost because this e-mail has been sent to you in error. It is your
responsibility to check this e-mail and any attachments for viruses.  No
warranty is made that this material is free from computer virus or any other
defect or error.  Any loss/damage incurred by using this material is not the
sender's responsibility.  The sender's entire liability will be limited to
resupplying the material.

_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com




























































































































































































_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com


This email and any attachments may contain privileged and confidential information and are intended for the named addressee only. If you have received this e-mail in error, please notify the sender and delete this e-mail immediately. Any confidentiality, privilege or copyright is not waived or lost because this e-mail has been sent to you in error. It is your responsibility to check this e-mail and any attachments for viruses.  No warranty is made that this material is free from computer virus or any other defect or error.  Any loss/damage incurred by using this material is not the sender's responsibility.  The sender's entire liability will be limited to resupplying the material.



From stuart at lexacorp.com.pg  Mon Jul  7 22:22:29 2008
From: stuart at lexacorp.com.pg (Stuart McLachlan)
Date: Tue, 08 Jul 2008 13:22:29 +1000
Subject: [dba-SQLServer] concatenating strings where one or more string
	is null
In-Reply-To: <f0981fe30807071703l7e846fa4i99c64dd514064a@mail.gmail.com>
Message-ID: <48736A15.30217.622DF20A@stuart.lexacorp.com.pg>

c) Use the ISNULL() function


ISNULL(t.StreetNrPOBox + ', . . . ','') + ISNULL(t.StreetName + ', . . . ','') + 
ISNULL(t.Suburb + ', .. .','') as xyz

Note that I've included  the  field and string in the ISNULL() so that if the 
field is null, you don't get two sets of ', . . . .' 


On 8 Jul 2008 at 10:03, Borge Hansen wrote:

> Hi,
> 
> A very simple one:
> 
> What is 'best practise way' of handling something like the following in a
> select sp or view:
> 
> 
> t.StreetNrPOBox + ', . . . ' + t.StreetName + ', . . . ' + t.Suburb + ', . .
> .' as xyz
> 
> where one of the column values may be null ??
> 
> MS Help in BOL is again not very helpful ... (topic: concatenation [SQL
> Server] )
> 
> They talk about
> 
> ..Just like arithmetic operations that are performed on null values, when a
> null value is added to a known value the result is typically an unknown
> value, a string concatenation operation that is performed with a null value
> should also produce a null result. However, you can change this behavior by
> changing the setting of CONCAT_NULL_YIELDS_NULL for the current session. For
> more information, see SET CONCAT_NULL_YIELDS_NULL (Transact-SQL).
> 
> Then for SET CONCAT_NULL_YIELDS_NULL { ON|OFF } the first thing you read is:
> 
>   Important:  This feature will be removed in a future version of Microsoft
> SQL Server. Avoid using this feature in new development work, and plan to
> modify applications that currently use this feature.
> 
> So, what's best practise here:
> 
> a) Don't allow null in any text fields in your table definitions?
> 
> b) use a case statement to test for null
> 
> c) ?
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
> 




From newsgrps at dalyn.co.nz  Tue Jul  8 12:55:49 2008
From: newsgrps at dalyn.co.nz (David Emerson)
Date: Wed, 09 Jul 2008 05:55:49 +1200
Subject: [dba-SQLServer] Truncating Temporary Tables
Message-ID: <20080708175556.LMCK27627.mta06.xtra.co.nz@Dalyn.dalyn.co.nz>

Is it possible to truncate a temporary table in SQL2000?

I have a table defines as follows:

DECLARE @ttmpGoalIns TABLE (RowID int IDENTITY (1, 1) NOT NULL, 
GoalID int, Description varchar(100), GoalAmt money DEFAULT (0) )

During my code I want to delete the rows and reset the identity back 
to 1.  Truncate is supposed to do this but I get an Incorrect Syntax 
error on the line:

TRUNCATE TABLE @ttmpGoalIns


Regards

David Emerson
Dalyn Software Ltd
Wellington, New Zealand 

From ab-mi at post3.tele.dk  Tue Jul  8 14:13:26 2008
From: ab-mi at post3.tele.dk (Asger Blond)
Date: Tue, 8 Jul 2008 21:13:26 +0200
Subject: [dba-SQLServer] Truncating Temporary Tables
In-Reply-To: <20080708175556.LMCK27627.mta06.xtra.co.nz@Dalyn.dalyn.co.nz>
Message-ID: <000001c8e12e$b30084c0$2101a8c0@AB>

David,

Yes, it's possible to truncate a TEMPORARY TABLE, but it is not possible to
truncate a TABLE VARIABLE which is what you are using...
I don't think you can reseed the identity value of a column in a table
variable.
Using a temporary table instead you can try this reseeding:

CREATE TABLE #ttmpGoalIns (RowID int IDENTITY (1, 1) NOT NULL, GoalID int,
Description varchar(100), GoalAmt money DEFAULT (0) )
INSERT #ttmpGoalIns (GoalID,Description) values(10,'a')
INSERT #ttmpGoalIns (GoalID,Description) values(20,'b')
SELECT * FROM #ttmpGoalIns
TRUNCATE TABLE #ttmpGoalIns
INSERT #ttmpGoalIns (GoalID,Description) values(30,'c')
SELECT * FROM #ttmpGoalIns --> RowID reseeded to 1
DROP TABLE #ttmpGoalIns

Asger



-----Oprindelig meddelelse-----
Fra: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] P? vegne af David
Emerson
Sendt: 8. juli 2008 19:56
Til: dba-SQLServer at databaseadvisors.com
Emne: [dba-SQLServer] Truncating Temporary Tables

Is it possible to truncate a temporary table in SQL2000?

I have a table defines as follows:

DECLARE @ttmpGoalIns TABLE (RowID int IDENTITY (1, 1) NOT NULL, 
GoalID int, Description varchar(100), GoalAmt money DEFAULT (0) )

During my code I want to delete the rows and reset the identity back 
to 1.  Truncate is supposed to do this but I get an Incorrect Syntax 
error on the line:

TRUNCATE TABLE @ttmpGoalIns


Regards

David Emerson
Dalyn Software Ltd
Wellington, New Zealand 
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com

 










































































































































































From newsgrps at dalyn.co.nz  Tue Jul  8 14:25:13 2008
From: newsgrps at dalyn.co.nz (David Emerson)
Date: Wed, 09 Jul 2008 07:25:13 +1200
Subject: [dba-SQLServer] Truncating Temporary Tables
In-Reply-To: <000001c8e12e$b30084c0$2101a8c0@AB>
References: <20080708175556.LMCK27627.mta06.xtra.co.nz@Dalyn.dalyn.co.nz>
	<000001c8e12e$b30084c0$2101a8c0@AB>
Message-ID: <20080708192515.OYOG7588.mta03.xtra.co.nz@Dalyn.dalyn.co.nz>

Thanks - Yes you are correct about the wrong terminology I used.

I have read that table variables are more 
efficient than temporary tables.  I have go 
around the problem of not being able to truncate 
by using variables to track the first and last values of the RowID.

David

At 07/9/2008, you wrote:
>David,
>
>Yes, it's possible to truncate a TEMPORARY TABLE, but it is not possible to
>truncate a TABLE VARIABLE which is what you are using...
>I don't think you can reseed the identity value of a column in a table
>variable.
>Using a temporary table instead you can try this reseeding:
>
>CREATE TABLE #ttmpGoalIns (RowID int IDENTITY (1, 1) NOT NULL, GoalID int,
>Description varchar(100), GoalAmt money DEFAULT (0) )
>INSERT #ttmpGoalIns (GoalID,Description) values(10,'a')
>INSERT #ttmpGoalIns (GoalID,Description) values(20,'b')
>SELECT * FROM #ttmpGoalIns
>TRUNCATE TABLE #ttmpGoalIns
>INSERT #ttmpGoalIns (GoalID,Description) values(30,'c')
>SELECT * FROM #ttmpGoalIns --> RowID reseeded to 1
>DROP TABLE #ttmpGoalIns
>
>Asger
>
>
>
>-----Oprindelig meddelelse-----
>Fra: dba-sqlserver-bounces at databaseadvisors.com
>[mailto:dba-sqlserver-bounces at databaseadvisors.com] P? vegne af David
>Emerson
>Sendt: 8. juli 2008 19:56
>Til: dba-SQLServer at databaseadvisors.com
>Emne: [dba-SQLServer] Truncating Temporary Tables
>
>Is it possible to truncate a temporary table in SQL2000?
>
>I have a table defines as follows:
>
>DECLARE @ttmpGoalIns TABLE (RowID int IDENTITY (1, 1) NOT NULL,
>GoalID int, Description varchar(100), GoalAmt money DEFAULT (0) )
>
>During my code I want to delete the rows and reset the identity back
>to 1.  Truncate is supposed to do this but I get an Incorrect Syntax
>error on the line:
>
>TRUNCATE TABLE @ttmpGoalIns
>
>
>Regards
>
>David Emerson
>Dalyn Software Ltd
>Wellington, New Zealand
>_______________________________________________
>dba-SQLServer mailing list
>dba-SQLServer at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>http://www.databaseadvisors.com
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>_______________________________________________
>dba-SQLServer mailing list
>dba-SQLServer at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>http://www.databaseadvisors.com




From fuller.artful at gmail.com  Wed Jul  9 08:01:47 2008
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Wed, 9 Jul 2008 10:01:47 -0300
Subject: [dba-SQLServer] SQL Agent Jobs
Message-ID: <29f585dd0807090601l22ffa781j334225e4fae91f17@mail.gmail.com>

Where do SQL Agent jobs live? In master? In msdb? Somewhere else? I have a
pretty smart restore script set up now that does a restore and then
recreates some users etc. but it is unaware of jobs, and I want to figure
out how to automate that part as well. Any ideas?

TIA,
Arthur


From ab-mi at post3.tele.dk  Wed Jul  9 08:43:29 2008
From: ab-mi at post3.tele.dk (Asger Blond)
Date: Wed, 9 Jul 2008 15:43:29 +0200
Subject: [dba-SQLServer] SQL Agent Jobs
In-Reply-To: <29f585dd0807090601l22ffa781j334225e4fae91f17@mail.gmail.com>
Message-ID: <000301c8e1c9$c5a462e0$2101a8c0@AB>

msdb

Asger

-----Oprindelig meddelelse-----
Fra: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] P? vegne af Arthur
Fuller
Sendt: 9. juli 2008 15:02
Til: Discussion concerning MS SQL Server
Emne: [dba-SQLServer] SQL Agent Jobs

Where do SQL Agent jobs live? In master? In msdb? Somewhere else? I have a
pretty smart restore script set up now that does a restore and then
recreates some users etc. but it is unaware of jobs, and I want to figure
out how to automate that part as well. Any ideas?

TIA,
Arthur
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com










































































































































































From fuller.artful at gmail.com  Wed Jul  9 08:49:16 2008
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Wed, 9 Jul 2008 10:49:16 -0300
Subject: [dba-SQLServer] SQL Agent Jobs
In-Reply-To: <000301c8e1c9$c5a462e0$2101a8c0@AB>
References: <29f585dd0807090601l22ffa781j334225e4fae91f17@mail.gmail.com>
	<000301c8e1c9$c5a462e0$2101a8c0@AB>
Message-ID: <29f585dd0807090649p16bd0171t4b2447d8c4ae9c5c@mail.gmail.com>

Thanks, Asger.

On a related subject, what are the pros and cons between storing SSIS
packages inside the database vs. externally? Any thoughts on that subject?

Arthur

On 7/9/08, Asger Blond <ab-mi at post3.tele.dk> wrote:
>
> msdb
>
> Asger
>


From ab-mi at post3.tele.dk  Wed Jul  9 10:06:38 2008
From: ab-mi at post3.tele.dk (Asger Blond)
Date: Wed, 9 Jul 2008 17:06:38 +0200
Subject: [dba-SQLServer] SQL Agent Jobs
In-Reply-To: <29f585dd0807090649p16bd0171t4b2447d8c4ae9c5c@mail.gmail.com>
Message-ID: <000101c8e1d5$633991a0$2101a8c0@AB>

When stored inside the database SSIS packages will reside in
msdb.dbo.sysdtspackages90 in the column Packagedata.
You can run SSIS packages in a SQL Server Agent Job whether the packages
resides externally or in the msdb database.
I think the main advantage storing in msdb is backup. If you make regular
backups of msdb you can recover all your SSIS packages.
The main con for storing in msdb could be when you update/make changes to
the packages - then you have to redeploy the packages to msdb, but that's
not a big issue I think.

Asger

-----Oprindelig meddelelse-----
Fra: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] P? vegne af Arthur
Fuller
Sendt: 9. juli 2008 15:49
Til: Discussion concerning MS SQL Server
Emne: Re: [dba-SQLServer] SQL Agent Jobs

Thanks, Asger.

On a related subject, what are the pros and cons between storing SSIS
packages inside the database vs. externally? Any thoughts on that subject?

Arthur

On 7/9/08, Asger Blond <ab-mi at post3.tele.dk> wrote:
>
> msdb
>
> Asger
>
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com

 








































































































































































From fuller.artful at gmail.com  Thu Jul 10 08:10:10 2008
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Thu, 10 Jul 2008 10:10:10 -0300
Subject: [dba-SQLServer] Trace kills performance?
Message-ID: <29f585dd0807100610m4de1b0cepe0e3454cc7b996f2@mail.gmail.com>

I was running a relatively simple trace using the locking issues template
and I can't believe how much it killed the server performance. I'm new to
tracing so maybe this is just how things are. I'm going to do another one
soon, and narrow the focus just to deadlocks. Hopefully that won't cripple
performance.

Anyone got some insights about this?

TIA,
Arthur


From fhtapia at gmail.com  Thu Jul 10 09:31:51 2008
From: fhtapia at gmail.com (Francisco Tapia)
Date: Thu, 10 Jul 2008 07:31:51 -0700
Subject: [dba-SQLServer] Trace kills performance?
In-Reply-To: <29f585dd0807100610m4de1b0cepe0e3454cc7b996f2@mail.gmail.com>
References: <29f585dd0807100610m4de1b0cepe0e3454cc7b996f2@mail.gmail.com>
Message-ID: <b874372a0807100731n35dab952qd249d7bb2ed3bbdc@mail.gmail.com>

Traces are generally expensive, performance exercises of patience, you
should run them while you are troubleshooting an issue in this case the
deadlock issue, but they will cause a performance drain on your system, how
much generally depends on where you are writing the trace file to, in
general you can get the slightly better performance by running the trace
from a remote client where you write the file to local storage.



On Thu, Jul 10, 2008 at 6:10 AM, Arthur Fuller <fuller.artful at gmail.com>
wrote:

> I was running a relatively simple trace using the locking issues template
> and I can't believe how much it killed the server performance. I'm new to
> tracing so maybe this is just how things are. I'm going to do another one
> soon, and narrow the focus just to deadlocks. Hopefully that won't cripple
> performance.
>
> Anyone got some insights about this?
>
> TIA,
> Arthur
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>


-- 
-Francisco
http://sqlthis.blogspot.com | Tsql and More...


From fuller.artful at gmail.com  Thu Jul 10 11:03:44 2008
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Thu, 10 Jul 2008 13:03:44 -0300
Subject: [dba-SQLServer] Trace kills performance?
In-Reply-To: <b874372a0807100731n35dab952qd249d7bb2ed3bbdc@mail.gmail.com>
References: <29f585dd0807100610m4de1b0cepe0e3454cc7b996f2@mail.gmail.com>
	<b874372a0807100731n35dab952qd249d7bb2ed3bbdc@mail.gmail.com>
Message-ID: <29f585dd0807100903o2a9b2bdavd684d8c3239351ec@mail.gmail.com>

Yes, that is what I assumed, and how I set it up. One detail, however: I
directed the trace results to a table rather than a file. Was that a bad
idea?

Thanks,
Arthur

On 7/10/08, Francisco Tapia <fhtapia at gmail.com> wrote:
>
> Traces are generally expensive, performance exercises of patience, you
> should run them while you are troubleshooting an issue in this case the
> deadlock issue, but they will cause a performance drain on your system, how
> much generally depends on where you are writing the trace file to, in
> general you can get the slightly better performance by running the trace
> from a remote client where you write the file to local storage.
>


From fhtapia at gmail.com  Thu Jul 10 11:07:37 2008
From: fhtapia at gmail.com (Francisco Tapia)
Date: Thu, 10 Jul 2008 09:07:37 -0700
Subject: [dba-SQLServer] Trace kills performance?
In-Reply-To: <29f585dd0807100903o2a9b2bdavd684d8c3239351ec@mail.gmail.com>
References: <29f585dd0807100610m4de1b0cepe0e3454cc7b996f2@mail.gmail.com>
	<b874372a0807100731n35dab952qd249d7bb2ed3bbdc@mail.gmail.com>
	<29f585dd0807100903o2a9b2bdavd684d8c3239351ec@mail.gmail.com>
Message-ID: <b874372a0807100907k7eede38h7c4642cbb5f542b6@mail.gmail.com>

IME it is often better to dump the results to a file especially on big and
busy servers.

On Thu, Jul 10, 2008 at 9:03 AM, Arthur Fuller <fuller.artful at gmail.com>
wrote:

> Yes, that is what I assumed, and how I set it up. One detail, however: I
> directed the trace results to a table rather than a file. Was that a bad
> idea?
>
> Thanks,
> Arthur
>
> On 7/10/08, Francisco Tapia <fhtapia at gmail.com> wrote:
> >
> > Traces are generally expensive, performance exercises of patience, you
> > should run them while you are troubleshooting an issue in this case the
> > deadlock issue, but they will cause a performance drain on your system,
> how
> > much generally depends on where you are writing the trace file to, in
> > general you can get the slightly better performance by running the trace
> > from a remote client where you write the file to local storage.
> >
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>


-- 
-Francisco
http://sqlthis.blogspot.com | Tsql and More...


From fuller.artful at gmail.com  Thu Jul 10 11:44:39 2008
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Thu, 10 Jul 2008 13:44:39 -0300
Subject: [dba-SQLServer] Trace kills performance?
In-Reply-To: <b874372a0807100907k7eede38h7c4642cbb5f542b6@mail.gmail.com>
References: <29f585dd0807100610m4de1b0cepe0e3454cc7b996f2@mail.gmail.com>
	<b874372a0807100731n35dab952qd249d7bb2ed3bbdc@mail.gmail.com>
	<29f585dd0807100903o2a9b2bdavd684d8c3239351ec@mail.gmail.com>
	<b874372a0807100907k7eede38h7c4642cbb5f542b6@mail.gmail.com>
Message-ID: <29f585dd0807100944k457aa1fcs2405da3016e861c7@mail.gmail.com>

Ok I will do that next run.0

On 7/10/08, Francisco Tapia <fhtapia at gmail.com> wrote:
>
> IME it is often better to dump the results to a file especially on big and
> busy servers.
>


From pcs.accessd at gmail.com  Thu Jul 10 20:35:28 2008
From: pcs.accessd at gmail.com (Borge Hansen)
Date: Fri, 11 Jul 2008 11:35:28 +1000
Subject: [dba-SQLServer] [dba-sqlserver] FncStrDateSQL
Message-ID: <f0981fe30807101835o68ce357ct6931d05545e7ec19@mail.gmail.com>

Hi,
I was thinking: ... shall I search the archives ... or .... shall I shoot a
quick message ...

What's the equivalent to Gustav's very helpful function (see below) of
formatting dates for use in queries when you are working with views / sp in
SQL2005 ??

Public Function FncStrDateSQL(ByVal dat As Date) As String
' Formats full string of date/time in US format for SQL.
' Overrides local (non US) settings for date/time separators.
' Example output:    #08/16/1998 04:03:36 PM#
' 1999-10-21. Cactus Data ApS, CPH.
      FncStrDateSQL = Format(dat, "\#mm\/dd\/yyyy hh\:nn\:ss AM/PM\#")
End Function

I need to be able to do > ; >=; <; <= comparisons being secure in my sleep
that a '7-Mar-2008' doesn't get interpreted as a '3-Jul-2008'

Gustav?

regards
Borge


From ab-mi at post3.tele.dk  Fri Jul 11 08:44:45 2008
From: ab-mi at post3.tele.dk (Asger Blond)
Date: Fri, 11 Jul 2008 15:44:45 +0200
Subject: [dba-SQLServer] [dba-sqlserver] FncStrDateSQL
In-Reply-To: <f0981fe30807101835o68ce357ct6931d05545e7ec19@mail.gmail.com>
Message-ID: <000b01c8e35c$479e6b40$2101a8c0@AB>

Borge,

Haven't tried Gustav's function.
But in SQL Server you can use the session level option:
set dateformat mdy

Or you can use conversion:
convert(varchar(11),'your date',103) --> dd/mm/yyyy
convert(varchar(11),'your date',104) --> dd.mm.yyyy
convert(varchar(11),'your date',105) --> dd-mm-yyyy
convert(varchar(24),'your date',113) --> dd mon yyyy hh:mm:ss:mmm

Asger

-----Oprindelig meddelelse-----
Fra: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] P? vegne af Borge Hansen
Sendt: 11. juli 2008 03:35
Til: Discussion concerning MS SQL Server
Emne: [dba-SQLServer] [dba-sqlserver] FncStrDateSQL

Hi,
I was thinking: ... shall I search the archives ... or .... shall I shoot a
quick message ...

What's the equivalent to Gustav's very helpful function (see below) of
formatting dates for use in queries when you are working with views / sp in
SQL2005 ??

Public Function FncStrDateSQL(ByVal dat As Date) As String
' Formats full string of date/time in US format for SQL.
' Overrides local (non US) settings for date/time separators.
' Example output:    #08/16/1998 04:03:36 PM#
' 1999-10-21. Cactus Data ApS, CPH.
      FncStrDateSQL = Format(dat, "\#mm\/dd\/yyyy hh\:nn\:ss AM/PM\#")
End Function

I need to be able to do > ; >=; <; <= comparisons being secure in my sleep
that a '7-Mar-2008' doesn't get interpreted as a '3-Jul-2008'

Gustav?

regards
Borge
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com

 










































































































































































From ab-mi at post3.tele.dk  Fri Jul 11 08:56:05 2008
From: ab-mi at post3.tele.dk (Asger Blond)
Date: Fri, 11 Jul 2008 15:56:05 +0200
Subject: [dba-SQLServer] [dba-sqlserver] FncStrDateSQL
In-Reply-To: <000b01c8e35c$479e6b40$2101a8c0@AB>
Message-ID: <000c01c8e35d$dcb9b1c0$2101a8c0@AB>

Sorry, your session level option should of course be:
set dateformat dmy

Asger

-----Oprindelig meddelelse-----
Fra: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] P? vegne af Asger Blond
Sendt: 11. juli 2008 15:45
Til: 'Discussion concerning MS SQL Server'
Emne: Re: [dba-SQLServer] [dba-sqlserver] FncStrDateSQL

Borge,

Haven't tried Gustav's function.
But in SQL Server you can use the session level option:
set dateformat mdy

Or you can use conversion:
convert(varchar(11),'your date',103) --> dd/mm/yyyy
convert(varchar(11),'your date',104) --> dd.mm.yyyy
convert(varchar(11),'your date',105) --> dd-mm-yyyy
convert(varchar(24),'your date',113) --> dd mon yyyy hh:mm:ss:mmm

Asger

-----Oprindelig meddelelse-----
Fra: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] P? vegne af Borge Hansen
Sendt: 11. juli 2008 03:35
Til: Discussion concerning MS SQL Server
Emne: [dba-SQLServer] [dba-sqlserver] FncStrDateSQL

Hi,
I was thinking: ... shall I search the archives ... or .... shall I shoot a
quick message ...

What's the equivalent to Gustav's very helpful function (see below) of
formatting dates for use in queries when you are working with views / sp in
SQL2005 ??

Public Function FncStrDateSQL(ByVal dat As Date) As String
' Formats full string of date/time in US format for SQL.
' Overrides local (non US) settings for date/time separators.
' Example output:    #08/16/1998 04:03:36 PM#
' 1999-10-21. Cactus Data ApS, CPH.
      FncStrDateSQL = Format(dat, "\#mm\/dd\/yyyy hh\:nn\:ss AM/PM\#")
End Function

I need to be able to do > ; >=; <; <= comparisons being secure in my sleep
that a '7-Mar-2008' doesn't get interpreted as a '3-Jul-2008'

Gustav?

regards
Borge
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com

 








































































































































































_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com

 

















































































































































































From Gustav at cactus.dk  Fri Jul 11 09:18:46 2008
From: Gustav at cactus.dk (Gustav Brock)
Date: Fri, 11 Jul 2008 16:18:46 +0200
Subject: [dba-SQLServer] FncStrDateSQL
Message-ID: <s87787f8.003@cactus.dk>

Hi Asger and Borge

But none of these returns what Borge requests.

The YYYY-MM-DD HH:MI:SS(24h) ODBC Canonical is closer: 

  SELECT CONVERT(VARCHAR(19), GETDATE(), 120) 

Returns:

  1972-01-01 13:42:24 

If you insist on "/" as the date separator, you could wrap this in a
replace expression.

A list of other date formats:

  http://www.sql-server-helper.com/tips/date-formats.aspx 

/gustav


>>> ab-mi at post3.tele.dk 11-07-2008 15:44 >>>
Borge,

Haven't tried Gustav's function.
But in SQL Server you can use the session level option:
set dateformat mdy

Or you can use conversion:
convert(varchar(11),'your date',103) --> dd/mm/yyyy
convert(varchar(11),'your date',104) --> dd.mm.yyyy
convert(varchar(11),'your date',105) --> dd-mm-yyyy
convert(varchar(24),'your date',113) --> dd mon yyyy hh:mm:ss:mmm

Asger

-----Oprindelig meddelelse-----
Fra: dba-sqlserver-bounces at databaseadvisors.com 
[mailto:dba-sqlserver-bounces at databaseadvisors.com] P? vegne af Borge
Hansen
Sendt: 11. juli 2008 03:35
Til: Discussion concerning MS SQL Server
Emne: [dba-SQLServer] [dba-sqlserver] FncStrDateSQL

Hi,
I was thinking: ... shall I search the archives ... or .... shall I
shoot a
quick message ...

What's the equivalent to Gustav's very helpful function (see below) of
formatting dates for use in queries when you are working with views /
sp in
SQL2005 ??

Public Function FncStrDateSQL(ByVal dat As Date) As String
' Formats full string of date/time in US format for SQL.
' Overrides local (non US) settings for date/time separators.
' Example output:    #08/16/1998 04:03:36 PM#
' 1999-10-21. Cactus Data ApS, CPH.
      FncStrDateSQL = Format(dat, "\#mm\/dd\/yyyy hh\:nn\:ss AM/PM\#")
End Function

I need to be able to do > ; >=; <; <= comparisons being secure in my
sleep
that a '7-Mar-2008' doesn't get interpreted as a '3-Jul-2008'

Gustav?

regards
Borge


From dwaters at usinternet.com  Sun Jul 13 11:26:20 2008
From: dwaters at usinternet.com (Dan Waters)
Date: Sun, 13 Jul 2008 11:26:20 -0500
Subject: [dba-SQLServer] Locking Discussion
Message-ID: <AE90DB4C46F84097BA28AE09B4470EF3@danwaters>

To everyone:

Several weeks ago there was a protracted 'discussion' about this issue.
While I skimmed the discussion I never did see anyone provide an answer to
the question, "How can I prevent data conflicts in SQL Server?"

Today I started reading my copy of Mastering SQL Server 2005 Express
Edition, coauthored by Susan Harkins and Mike Gunderloy.  News to me was
that SQL Server has it's own quite sophisticated and flexible locking
mechanism (see Chapter 21 - Locking).  From page 477: "What this means to
you as an application developer is that you almost never have to worry about
locking."

I'm just getting started upsizing an Access app, and would like to hear some
discussion on this and on how this locking mechanism impacts your
development of 'unbound' or 'bound' Access FE applications.

Thanks!
Dan



From ssharkins at gmail.com  Sun Jul 13 11:34:12 2008
From: ssharkins at gmail.com (Susan Harkins)
Date: Sun, 13 Jul 2008 12:34:12 -0400
Subject: [dba-SQLServer] Locking Discussion
References: <AE90DB4C46F84097BA28AE09B4470EF3@danwaters>
Message-ID: <013601c8e506$49b74090$2f8601c7@SusanOne>

Dan, the very realistic truth is this -- you can't prevent data conflicts. 
What you can do is minimize them. You do that best by letting SQL Server do 
the work for you. Of course, you need to understand how SQL Server works in 
this regard. SQL Server has a set of internal rules that it follows and 
almost always, it will make the right choice. If it doesn't, it's probably 
your strategy and not SQL Server's that's really the problem.

Susan H.


> To everyone:
>
> Several weeks ago there was a protracted 'discussion' about this issue.
> While I skimmed the discussion I never did see anyone provide an answer to
> the question, "How can I prevent data conflicts in SQL Server?"
>
> Today I started reading my copy of Mastering SQL Server 2005 Express
> Edition, coauthored by Susan Harkins and Mike Gunderloy.  News to me was
> that SQL Server has it's own quite sophisticated and flexible locking
> mechanism (see Chapter 21 - Locking).  From page 477: "What this means to
> you as an application developer is that you almost never have to worry 
> about
> locking."
>
> I'm just getting started upsizing an Access app, and would like to hear 
> some
> discussion on this and on how this locking mechanism impacts your
> development of 'unbound' or 'bound' Access FE applications.
>
> Thanks!
> Dan
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
> 



From accessd at shaw.ca  Sun Jul 13 12:49:51 2008
From: accessd at shaw.ca (Jim Lawrence)
Date: Sun, 13 Jul 2008 10:49:51 -0700
Subject: [dba-SQLServer] Locking Discussion
In-Reply-To: <AE90DB4C46F84097BA28AE09B4470EF3@danwaters>
References: <AE90DB4C46F84097BA28AE09B4470EF3@danwaters>
Message-ID: <D1FC73D587D9403792B4E4978709B6DE@creativesystemdesigns.com>

Hi Dan:

Listen to Susan she knows what she is talking about.

When using MS SQL Express/MS SQL/MySQL/Oracle or any of the other stand
alone databases the whole concepts of tight binding that you have learned
using the Access MDB are gone. Some built-in Access emulations can be rigged
that give the appearance of bound fields but in some circumstances you will
pay a heavy performance price.

It is best to just let the DB do what it does best... manage data. Built
within it are many methods for handling data conflict resolutions so you do
not have to worry about it. (Note: there are situations in which what is
called a 'deadly-embrace' or 'a locked record due to use conflict' can be
created but it generally takes real effort and all professional DBs have
unlocking tools and time-out solutions.)

When you move 'up' it is time to drop the 'bound' forms and fields and this
can take a bit more programming but it is not difficult and there are many
here amongst the Access and SQL groups that can answer any particular
questions you may have.... and the performance gains are stellar.

Jim  

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Dan Waters
Sent: Sunday, July 13, 2008 9:26 AM
To: SQL Server List
Subject: [dba-SQLServer] Locking Discussion

To everyone:

Several weeks ago there was a protracted 'discussion' about this issue.
While I skimmed the discussion I never did see anyone provide an answer to
the question, "How can I prevent data conflicts in SQL Server?"

Today I started reading my copy of Mastering SQL Server 2005 Express
Edition, coauthored by Susan Harkins and Mike Gunderloy.  News to me was
that SQL Server has it's own quite sophisticated and flexible locking
mechanism (see Chapter 21 - Locking).  From page 477: "What this means to
you as an application developer is that you almost never have to worry about
locking."

I'm just getting started upsizing an Access app, and would like to hear some
discussion on this and on how this locking mechanism impacts your
development of 'unbound' or 'bound' Access FE applications.

Thanks!
Dan

_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com



From dwaters at usinternet.com  Sun Jul 13 14:12:36 2008
From: dwaters at usinternet.com (Dan Waters)
Date: Sun, 13 Jul 2008 14:12:36 -0500
Subject: [dba-SQLServer] Locking Discussion
In-Reply-To: <D1FC73D587D9403792B4E4978709B6DE@creativesystemdesigns.com>
References: <AE90DB4C46F84097BA28AE09B4470EF3@danwaters>
	<D1FC73D587D9403792B4E4978709B6DE@creativesystemdesigns.com>
Message-ID: <48591A5A2C034155B6BB8F1B98B8403A@danwaters>

Jim - I am NOT arguing for bound/unbound forms.  Let that go.

What I had never heard of before was that SQL Server has its own mechanism
to prevent data conflicts.  The past discussions had never mentioned that.
And the whole central point of all those discussions was how to prevent data
conflicts with unbound forms - no one even mentioned that SQL Server already
does this.  Read chapter 21 - then you'll see what I just learned is already
done and can be done.

What I was hoping to get a discussion on was if anyone was actively using
the different isolation levels that can be managed by a FE application, and
how people where doing that, what their results were, etc, etc.

Thanks,
Dan

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Jim
Lawrence
Sent: Sunday, July 13, 2008 12:50 PM
To: 'Discussion concerning MS SQL Server'
Subject: Re: [dba-SQLServer] Locking Discussion

Hi Dan:

Listen to Susan she knows what she is talking about.

When using MS SQL Express/MS SQL/MySQL/Oracle or any of the other stand
alone databases the whole concepts of tight binding that you have learned
using the Access MDB are gone. Some built-in Access emulations can be rigged
that give the appearance of bound fields but in some circumstances you will
pay a heavy performance price.

It is best to just let the DB do what it does best... manage data. Built
within it are many methods for handling data conflict resolutions so you do
not have to worry about it. (Note: there are situations in which what is
called a 'deadly-embrace' or 'a locked record due to use conflict' can be
created but it generally takes real effort and all professional DBs have
unlocking tools and time-out solutions.)

When you move 'up' it is time to drop the 'bound' forms and fields and this
can take a bit more programming but it is not difficult and there are many
here amongst the Access and SQL groups that can answer any particular
questions you may have.... and the performance gains are stellar.

Jim  

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Dan Waters
Sent: Sunday, July 13, 2008 9:26 AM
To: SQL Server List
Subject: [dba-SQLServer] Locking Discussion

To everyone:

Several weeks ago there was a protracted 'discussion' about this issue.
While I skimmed the discussion I never did see anyone provide an answer to
the question, "How can I prevent data conflicts in SQL Server?"

Today I started reading my copy of Mastering SQL Server 2005 Express
Edition, coauthored by Susan Harkins and Mike Gunderloy.  News to me was
that SQL Server has it's own quite sophisticated and flexible locking
mechanism (see Chapter 21 - Locking).  From page 477: "What this means to
you as an application developer is that you almost never have to worry about
locking."

I'm just getting started upsizing an Access app, and would like to hear some
discussion on this and on how this locking mechanism impacts your
development of 'unbound' or 'bound' Access FE applications.

Thanks!
Dan

_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com

_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com



From accessd at shaw.ca  Sun Jul 13 14:43:25 2008
From: accessd at shaw.ca (Jim Lawrence)
Date: Sun, 13 Jul 2008 12:43:25 -0700
Subject: [dba-SQLServer] Locking Discussion
In-Reply-To: <48591A5A2C034155B6BB8F1B98B8403A@danwaters>
References: <AE90DB4C46F84097BA28AE09B4470EF3@danwaters>
	<D1FC73D587D9403792B4E4978709B6DE@creativesystemdesigns.com>
	<48591A5A2C034155B6BB8F1B98B8403A@danwaters>
Message-ID: <E734CD8CEABA4EF69F355499791FCC63@creativesystemdesigns.com>

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Dan Waters
Sent: Sunday, July 13, 2008 12:13 PM
To: 'Discussion concerning MS SQL Server'
Subject: Re: [dba-SQLServer] Locking Discussion

Jim - I am NOT arguing for bound/unbound forms.  Let that go.

> That was not my intention... just a heads up.

What I had never heard of before was that SQL Server has its own mechanism
to prevent data conflicts.  The past discussions had never mentioned that.
And the whole central point of all those discussions was how to prevent data
conflicts with unbound forms - no one even mentioned that SQL Server already
does this.  Read chapter 21 - then you'll see what I just learned is already
done and can be done.

> That is the way all DBs work today. In over 10 years of working with MS
SQL and Oracle, I have never had an unresolved data issue... but I have
heard, in very special circumstances they can happen... But I have no
personal experience with that.  

What I was hoping to get a discussion on was if anyone was actively using
the different isolation levels that can be managed by a FE application, and
how people where doing that, what their results were, etc, etc.

> I have been mostly working with web-based applications lately but there
are a host documentation out there. The only item that I know of is a
article I wrote a few yeasr back on using an Access FE and MS SQL BE. See
article:
http://www.databaseadvisors.com/newsletters/newsletter112003/0311UnboundRepo
rts.asp

I hope this sheds some light on the subject at hand. 

Thanks,
Dan

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Jim
Lawrence
Sent: Sunday, July 13, 2008 12:50 PM
To: 'Discussion concerning MS SQL Server'
Subject: Re: [dba-SQLServer] Locking Discussion

Hi Dan:

Listen to Susan she knows what she is talking about.

When using MS SQL Express/MS SQL/MySQL/Oracle or any of the other stand
alone databases the whole concepts of tight binding that you have learned
using the Access MDB are gone. Some built-in Access emulations can be rigged
that give the appearance of bound fields but in some circumstances you will
pay a heavy performance price.

It is best to just let the DB do what it does best... manage data. Built
within it are many methods for handling data conflict resolutions so you do
not have to worry about it. (Note: there are situations in which what is
called a 'deadly-embrace' or 'a locked record due to use conflict' can be
created but it generally takes real effort and all professional DBs have
unlocking tools and time-out solutions.)

When you move 'up' it is time to drop the 'bound' forms and fields and this
can take a bit more programming but it is not difficult and there are many
here amongst the Access and SQL groups that can answer any particular
questions you may have.... and the performance gains are stellar.

Jim  

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Dan Waters
Sent: Sunday, July 13, 2008 9:26 AM
To: SQL Server List
Subject: [dba-SQLServer] Locking Discussion

To everyone:

Several weeks ago there was a protracted 'discussion' about this issue.
While I skimmed the discussion I never did see anyone provide an answer to
the question, "How can I prevent data conflicts in SQL Server?"

Today I started reading my copy of Mastering SQL Server 2005 Express
Edition, coauthored by Susan Harkins and Mike Gunderloy.  News to me was
that SQL Server has it's own quite sophisticated and flexible locking
mechanism (see Chapter 21 - Locking).  From page 477: "What this means to
you as an application developer is that you almost never have to worry about
locking."

I'm just getting started upsizing an Access app, and would like to hear some
discussion on this and on how this locking mechanism impacts your
development of 'unbound' or 'bound' Access FE applications.

Thanks!
Dan



From dwaters at usinternet.com  Sun Jul 13 15:58:51 2008
From: dwaters at usinternet.com (Dan Waters)
Date: Sun, 13 Jul 2008 15:58:51 -0500
Subject: [dba-SQLServer] Locking Discussion
In-Reply-To: <E734CD8CEABA4EF69F355499791FCC63@creativesystemdesigns.com>
References: <AE90DB4C46F84097BA28AE09B4470EF3@danwaters><D1FC73D587D9403792B4E4978709B6DE@creativesystemdesigns.com><48591A5A2C034155B6BB8F1B98B8403A@danwaters>
	<E734CD8CEABA4EF69F355499791FCC63@creativesystemdesigns.com>
Message-ID: <AFB2A03077DA48DBA5A3380FE7394B73@danwaters>

Jim - thanks for the copy of your article.  It looks like a good
introduction that will be a good help!

Dan

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Jim
Lawrence
Sent: Sunday, July 13, 2008 2:43 PM
To: 'Discussion concerning MS SQL Server'
Subject: Re: [dba-SQLServer] Locking Discussion

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Dan Waters
Sent: Sunday, July 13, 2008 12:13 PM
To: 'Discussion concerning MS SQL Server'
Subject: Re: [dba-SQLServer] Locking Discussion

Jim - I am NOT arguing for bound/unbound forms.  Let that go.

> That was not my intention... just a heads up.

What I had never heard of before was that SQL Server has its own mechanism
to prevent data conflicts.  The past discussions had never mentioned that.
And the whole central point of all those discussions was how to prevent data
conflicts with unbound forms - no one even mentioned that SQL Server already
does this.  Read chapter 21 - then you'll see what I just learned is already
done and can be done.

> That is the way all DBs work today. In over 10 years of working with MS
SQL and Oracle, I have never had an unresolved data issue... but I have
heard, in very special circumstances they can happen... But I have no
personal experience with that.  

What I was hoping to get a discussion on was if anyone was actively using
the different isolation levels that can be managed by a FE application, and
how people where doing that, what their results were, etc, etc.

> I have been mostly working with web-based applications lately but there
are a host documentation out there. The only item that I know of is a
article I wrote a few yeasr back on using an Access FE and MS SQL BE. See
article:
http://www.databaseadvisors.com/newsletters/newsletter112003/0311UnboundRepo
rts.asp

I hope this sheds some light on the subject at hand. 

Thanks,
Dan

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Jim
Lawrence
Sent: Sunday, July 13, 2008 12:50 PM
To: 'Discussion concerning MS SQL Server'
Subject: Re: [dba-SQLServer] Locking Discussion

Hi Dan:

Listen to Susan she knows what she is talking about.

When using MS SQL Express/MS SQL/MySQL/Oracle or any of the other stand
alone databases the whole concepts of tight binding that you have learned
using the Access MDB are gone. Some built-in Access emulations can be rigged
that give the appearance of bound fields but in some circumstances you will
pay a heavy performance price.

It is best to just let the DB do what it does best... manage data. Built
within it are many methods for handling data conflict resolutions so you do
not have to worry about it. (Note: there are situations in which what is
called a 'deadly-embrace' or 'a locked record due to use conflict' can be
created but it generally takes real effort and all professional DBs have
unlocking tools and time-out solutions.)

When you move 'up' it is time to drop the 'bound' forms and fields and this
can take a bit more programming but it is not difficult and there are many
here amongst the Access and SQL groups that can answer any particular
questions you may have.... and the performance gains are stellar.

Jim  

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Dan Waters
Sent: Sunday, July 13, 2008 9:26 AM
To: SQL Server List
Subject: [dba-SQLServer] Locking Discussion

To everyone:

Several weeks ago there was a protracted 'discussion' about this issue.
While I skimmed the discussion I never did see anyone provide an answer to
the question, "How can I prevent data conflicts in SQL Server?"

Today I started reading my copy of Mastering SQL Server 2005 Express
Edition, coauthored by Susan Harkins and Mike Gunderloy.  News to me was
that SQL Server has it's own quite sophisticated and flexible locking
mechanism (see Chapter 21 - Locking).  From page 477: "What this means to
you as an application developer is that you almost never have to worry about
locking."

I'm just getting started upsizing an Access app, and would like to hear some
discussion on this and on how this locking mechanism impacts your
development of 'unbound' or 'bound' Access FE applications.

Thanks!
Dan

_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com



From Darryl.Collins at coles.com.au  Mon Jul 14 00:16:26 2008
From: Darryl.Collins at coles.com.au (Darryl Collins)
Date: Mon, 14 Jul 2008 15:16:26 +1000
Subject: [dba-SQLServer] Calculated Column Field in a table...
In-Reply-To: <AFB2A03077DA48DBA5A3380FE7394B73@danwaters>
Message-ID: <57E6E6CA42105A48B977303A2CDC2720076BF12D33@WPEXCH22.retail.ad.cmltd.net.au>


Hi there,

I would have thought this was pretty simple, but I have a great ability to complicate these things it seems - heh, early days for me SQL server.
I have three fields in the table that I want to use for a calculated result in a couple of other fields in the table.

"AccTreatmentID"
1: Opex
2: Capex

"AccountingSplit"
0%-100%

"Dollars"
Manually entered dollar value


Then I have two other fields (Capex and Opex) and I (think I) want to do this.

"=iif([AccTreamtentID]=1,([Dollars]*[AccountingSplit]),0)" to get the Opex Value
"=iif([AccTreamtentID]=2,([Dollars]*[AccountingSplit]),0)" to get the Capex Value

or If AccTreatment is Capex, then get the Capex Percentage and multiply by the dollar value to get the capex amount.
The actual formula is more complex as I need to determine the balance of the percentage and then apply that to the remainder of the value (opex in this case). anyway I am trying to keep it simple to start with.  (plus I will probably need some sort of error test to return zero if part of the data is missing - Am not sure if I need this or not in SQL server.)

The syntax in these formulae are not valid so I would like some help with that.  And I guess my other question is do I actually need this at all?

Maybe I should do all the hack work in a query to report of Opex / Capex splits.  Part of me suspect I dont need to store the calculated data at all in the table at all and this is bad practise as it takes up time and space for no real reason.

Anyone got any thoughts on this.

Cheers
Darryll

This email and any attachments may contain privileged and confidential information and are intended for the named addressee only. If you have received this e-mail in error, please notify the sender and delete this e-mail immediately. Any confidentiality, privilege or copyright is not waived or lost because this e-mail has been sent to you in error. It is your responsibility to check this e-mail and any attachments for viruses.  No warranty is made that this material is free from computer virus or any other defect or error.  Any loss/damage incurred by using this material is not the sender's responsibility.  The sender's entire liability will be limited to resupplying the material.



From stuart at lexacorp.com.pg  Mon Jul 14 01:35:52 2008
From: stuart at lexacorp.com.pg (Stuart McLachlan)
Date: Mon, 14 Jul 2008 16:35:52 +1000
Subject: [dba-SQLServer] Calculated Column Field in a table...
In-Reply-To: <57E6E6CA42105A48B977303A2CDC2720076BF12D33@WPEXCH22.retail.ad.cmltd.net.au>
References: <AFB2A03077DA48DBA5A3380FE7394B73@danwaters>
Message-ID: <487B8068.9695.81C5246D@stuart.lexacorp.com.pg>

Your last comment is right on the nail. You don't want to store calcuated results in the table 
unless you have VERY good reasons to do so.

You can create either a View or a Stored Procedure to return Capex and Opex.

In a Stored Procedure it would be 

Select  
.....,
Case AccTreatmentId
	When 1 Then Dollars*AccountingSplit
	Else Dollars * (1-AccountingSplit)
End As Capex,
Case AccTreatmentId
	When 2 Then Dollars*AccountingSplit
	Else  Dollars * (1-AccountingSplit)
End As Opex,
.....


In the Design grid in a View, put

"CASE AccTreatmentId WHEN 1 THEN Dollars * AccountingSplit ELSE Dollars * (1 - 
AccountingSplit) END"  
as the Column value and "Capex" as the Alias and similarly for Opex.


Cheers,
Stuart


On 14 Jul 2008 at 15:16, Darryl Collins wrote:

> 
> Hi there,
> 
> I would have thought this was pretty simple, but I have a great ability to complicate these things it seems - heh, early days for me SQL server.
> I have three fields in the table that I want to use for a calculated result in a couple of other fields in the table.
> 
> "AccTreatmentID"
> 1: Opex
> 2: Capex
> 
> "AccountingSplit"
> 0%-100%
> 
> "Dollars"
> Manually entered dollar value
> 
> 
> Then I have two other fields (Capex and Opex) and I (think I) want to do this.
> 
> "=iif([AccTreamtentID]=1,([Dollars]*[AccountingSplit]),0)" to get the Opex Value
> "=iif([AccTreamtentID]=2,([Dollars]*[AccountingSplit]),0)" to get the Capex Value
> 
> or If AccTreatment is Capex, then get the Capex Percentage and multiply by the dollar value to get the capex amount.
> The actual formula is more complex as I need to determine the balance of the percentage and then apply that to the remainder of the value (opex in this case). anyway I am trying to keep it simple to start with.  (plus I will probably need some sort of error test to return zero if part of the data is missing - Am not sure if I need this or not in SQL server.)
> 
> The syntax in these formulae are not valid so I would like some help with that.  And I guess my other question is do I actually need this at all?
> 
> Maybe I should do all the hack work in a query to report of Opex / Capex splits.  Part of me suspect I dont need to store the calculated data at all in the table at all and this is bad practise as it takes up time and space for no real reason.
> 
> Anyone got any thoughts on this.
> 
> Cheers
> Darryll
> 
> This email and any attachments may contain privileged and confidential information and are intended for the named addressee only. If you have received this e-mail in error, please notify the sender and delete this e-mail immediately. Any confidentiality, privilege or copyright is not waived or lost because this e-mail has been sent to you in error. It is your responsibility to check this e-mail and any attachments for viruses.  No warranty is made that this material is free from computer virus or any other defect or error.  Any loss/damage incurred by using this material is not the sender's responsibility.  The sender's entire liability will be limited to resupplying the material.
> 
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
> 




From Darryl.Collins at coles.com.au  Mon Jul 14 01:45:23 2008
From: Darryl.Collins at coles.com.au (Darryl Collins)
Date: Mon, 14 Jul 2008 16:45:23 +1000
Subject: [dba-SQLServer] Calculated Column Field in a table...
In-Reply-To: <487B8068.9695.81C5246D@stuart.lexacorp.com.pg>
Message-ID: <57E6E6CA42105A48B977303A2CDC2720076BF12D35@WPEXCH22.retail.ad.cmltd.net.au>


Hi Stuart;

Most Excellent.  I will definately take this approach then and forget about using the table.  I am glad, because it was starting to make a lot of sense to me to do the calc outside of the table structure.  Too often I see a problem and I think about it with my MS Excel hat on first, often later in database land I go "oh.. hang on...."

Many thanks for clarifying this for me.

Cheers
Darryl.

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of Stuart
McLachlan
Sent: Monday, 14 July 2008 4:36 PM
To: Discussion concerning MS SQL Server
Subject: Re: [dba-SQLServer] Calculated Column Field in a table...


Your last comment is right on the nail. You don't want to store calcuated results in the table
unless you have VERY good reasons to do so.

You can create either a View or a Stored Procedure to return Capex and Opex.

In a Stored Procedure it would be

Select
.....,
Case AccTreatmentId
        When 1 Then Dollars*AccountingSplit
        Else Dollars * (1-AccountingSplit)
End As Capex,
Case AccTreatmentId
        When 2 Then Dollars*AccountingSplit
        Else  Dollars * (1-AccountingSplit)
End As Opex,
.....


In the Design grid in a View, put

"CASE AccTreatmentId WHEN 1 THEN Dollars * AccountingSplit ELSE Dollars * (1 -
AccountingSplit) END"
as the Column value and "Capex" as the Alias and similarly for Opex.


Cheers,
Stuart


On 14 Jul 2008 at 15:16, Darryl Collins wrote:

>
> Hi there,
>
> I would have thought this was pretty simple, but I have a great ability to complicate these things it seems - heh, early days for me SQL server.
> I have three fields in the table that I want to use for a calculated result in a couple of other fields in the table.
>
> "AccTreatmentID"
> 1: Opex
> 2: Capex
>
> "AccountingSplit"
> 0%-100%
>
> "Dollars"
> Manually entered dollar value
>
>
> Then I have two other fields (Capex and Opex) and I (think I) want to do this.
>
> "=iif([AccTreamtentID]=1,([Dollars]*[AccountingSplit]),0)" to get the Opex Value
> "=iif([AccTreamtentID]=2,([Dollars]*[AccountingSplit]),0)" to get the Capex Value
>
> or If AccTreatment is Capex, then get the Capex Percentage and multiply by the dollar value to get the capex amount.
> The actual formula is more complex as I need to determine the balance of the percentage and then apply that to the remainder of the value (opex in this case). anyway I am trying to keep it simple to start with.  (plus I will probably need some sort of error test to return zero if part of the data is missing - Am not sure if I need this or not in SQL server.)
>
> The syntax in these formulae are not valid so I would like some help with that.  And I guess my other question is do I actually need this at all?
>
> Maybe I should do all the hack work in a query to report of Opex / Capex splits.  Part of me suspect I dont need to store the calculated data at all in the table at all and this is bad practise as it takes up time and space for no real reason.
>
> Anyone got any thoughts on this.
>
> Cheers
> Darryll
>
> This email and any attachments may contain privileged and confidential information and are intended for the named addressee only. If you have received this e-mail in error, please notify the sender and delete this e-mail immediately. Any confidentiality, privilege or copyright is not waived or lost because this e-mail has been sent to you in error. It is your responsibility to check this e-mail and any attachments for viruses.  No warranty is made that this material is free from computer virus or any other defect or error.  Any loss/damage incurred by using this material is not the sender's responsibility.  The sender's entire liability will be limited to resupplying the material.
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>


_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com


This email and any attachments may contain privileged and confidential information and are intended for the named addressee only. If you have received this e-mail in error, please notify the sender and delete this e-mail immediately. Any confidentiality, privilege or copyright is not waived or lost because this e-mail has been sent to you in error. It is your responsibility to check this e-mail and any attachments for viruses.  No warranty is made that this material is free from computer virus or any other defect or error.  Any loss/damage incurred by using this material is not the sender's responsibility.  The sender's entire liability will be limited to resupplying the material.



From ab-mi at post3.tele.dk  Mon Jul 14 06:31:59 2008
From: ab-mi at post3.tele.dk (Asger Blond)
Date: Mon, 14 Jul 2008 13:31:59 +0200
Subject: [dba-SQLServer] Calculated Column Field in a table...
In-Reply-To: <487B8068.9695.81C5246D@stuart.lexacorp.com.pg>
Message-ID: <000d01c8e5a5$4f723b30$2101a8c0@AB>

Stuart and Darryl,

Calculated columns are calculated on the fly when querying the table. They
are NOT stored in the table unless you make an index on the calculated
column.
Non-indexed calculated columns are just a convenient way of having often
used calculations ready for table querying. If on the other hand you make an
index on a calculated column you actually persist the calculated results
which will speed up query performance compared to calculations in stored
procedures or views, but at the same time it will degrade performance of
insert and update operations against the table.

Asger


-----Oprindelig meddelelse-----
Fra: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] P? vegne af Stuart
McLachlan
Sendt: 14. juli 2008 08:36
Til: Discussion concerning MS SQL Server
Emne: Re: [dba-SQLServer] Calculated Column Field in a table...

Your last comment is right on the nail. You don't want to store calcuated
results in the table 
unless you have VERY good reasons to do so.

You can create either a View or a Stored Procedure to return Capex and Opex.

In a Stored Procedure it would be 

Select  
.....,
Case AccTreatmentId
	When 1 Then Dollars*AccountingSplit
	Else Dollars * (1-AccountingSplit)
End As Capex,
Case AccTreatmentId
	When 2 Then Dollars*AccountingSplit
	Else  Dollars * (1-AccountingSplit)
End As Opex,
.....


In the Design grid in a View, put

"CASE AccTreatmentId WHEN 1 THEN Dollars * AccountingSplit ELSE Dollars * (1
- 
AccountingSplit) END"  
as the Column value and "Capex" as the Alias and similarly for Opex.


Cheers,
Stuart


On 14 Jul 2008 at 15:16, Darryl Collins wrote:

> 
> Hi there,
> 
> I would have thought this was pretty simple, but I have a great ability to
complicate these things it seems - heh, early days for me SQL server.
> I have three fields in the table that I want to use for a calculated
result in a couple of other fields in the table.
> 
> "AccTreatmentID"
> 1: Opex
> 2: Capex
> 
> "AccountingSplit"
> 0%-100%
> 
> "Dollars"
> Manually entered dollar value
> 
> 
> Then I have two other fields (Capex and Opex) and I (think I) want to do
this.
> 
> "=iif([AccTreamtentID]=1,([Dollars]*[AccountingSplit]),0)" to get the Opex
Value
> "=iif([AccTreamtentID]=2,([Dollars]*[AccountingSplit]),0)" to get the
Capex Value
> 
> or If AccTreatment is Capex, then get the Capex Percentage and multiply by
the dollar value to get the capex amount.
> The actual formula is more complex as I need to determine the balance of
the percentage and then apply that to the remainder of the value (opex in
this case). anyway I am trying to keep it simple to start with.  (plus I
will probably need some sort of error test to return zero if part of the
data is missing - Am not sure if I need this or not in SQL server.)
> 
> The syntax in these formulae are not valid so I would like some help with
that.  And I guess my other question is do I actually need this at all?
> 
> Maybe I should do all the hack work in a query to report of Opex / Capex
splits.  Part of me suspect I dont need to store the calculated data at all
in the table at all and this is bad practise as it takes up time and space
for no real reason.
> 
> Anyone got any thoughts on this.
> 
> Cheers
> Darryll
> 
> This email and any attachments may contain privileged and confidential
information and are intended for the named addressee only. If you have
received this e-mail in error, please notify the sender and delete this
e-mail immediately. Any confidentiality, privilege or copyright is not
waived or lost because this e-mail has been sent to you in error. It is your
responsibility to check this e-mail and any attachments for viruses.  No
warranty is made that this material is free from computer virus or any other
defect or error.  Any loss/damage incurred by using this material is not the
sender's responsibility.  The sender's entire liability will be limited to
resupplying the material.
> 
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
> 


_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com


























































































































































































From fuller.artful at gmail.com  Mon Jul 14 17:57:16 2008
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Mon, 14 Jul 2008 19:57:16 -0300
Subject: [dba-SQLServer] About Time!
Message-ID: <29f585dd0807141557h69fd9d21ma440a8dcb44f3875@mail.gmail.com>

>From Values

Row Constructors are new to SQL Server 2008 - they add the ability to insert
multiple rows using a single INSERT statements.

Row Constructors may also be used in the FROM clause to select hard-coded
values. Check out this syntax - cool huh?

SELECT *
  FROM
    (VALUES
       ('Paul', 123),
       ('David', 456),
       ('Edie', 789))
      AS RowConstructor
       (name, amount)



The Values clause must have parens, an alias, and named columns following
the alias.

Why did this take so long? MySQL led the way a long time ago.

A.


From stuart at lexacorp.com.pg  Mon Jul 14 18:22:25 2008
From: stuart at lexacorp.com.pg (Stuart McLachlan)
Date: Tue, 15 Jul 2008 09:22:25 +1000
Subject: [dba-SQLServer] Calculated Column Field in a table...
In-Reply-To: <000d01c8e5a5$4f723b30$2101a8c0@AB>
References: <487B8068.9695.81C5246D@stuart.lexacorp.com.pg>
Message-ID: <487C6C51.14542.156F9D1@stuart.lexacorp.com.pg>

You're right.  

I  don't  use "computed columns"  in tables generally and didn't think of doing so in this 
instance.    When Darryl talked about "calculated columns", I was thinking in Access mode 
and assumed that he was intending to store the *results* of the calculation in ordinary data 
fields in the table.  

I really have to get over the mindset that tables are just data stores - in SQL Server, you 
can embed much of your business logic at the table level.

Stuart

On 14 Jul 2008 at 13:31, Asger Blond wrote:

> Stuart and Darryl,
> 
> Calculated columns are calculated on the fly when querying the table. They
> are NOT stored in the table unless you make an index on the calculated
> column.
> Non-indexed calculated columns are just a convenient way of having often
> used calculations ready for table querying. If on the other hand you make an
> index on a calculated column you actually persist the calculated results
> which will speed up query performance compared to calculations in stored
> procedures or views, but at the same time it will degrade performance of
> insert and update operations against the table.
> 
> Asger
> 
> 
> -----Oprindelig meddelelse-----
> Fra: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] P? vegne af Stuart
> McLachlan
> Sendt: 14. juli 2008 08:36
> Til: Discussion concerning MS SQL Server
> Emne: Re: [dba-SQLServer] Calculated Column Field in a table...
> 
> Your last comment is right on the nail. You don't want to store calcuated
> results in the table 
> unless you have VERY good reasons to do so.
> 
> You can create either a View or a Stored Procedure to return Capex and Opex.
> 
> In a Stored Procedure it would be 
> 
> Select  
> .....,
> Case AccTreatmentId
> 	When 1 Then Dollars*AccountingSplit
> 	Else Dollars * (1-AccountingSplit)
> End As Capex,
> Case AccTreatmentId
> 	When 2 Then Dollars*AccountingSplit
> 	Else  Dollars * (1-AccountingSplit)
> End As Opex,
> .....
> 
> 
> In the Design grid in a View, put
> 
> "CASE AccTreatmentId WHEN 1 THEN Dollars * AccountingSplit ELSE Dollars * (1
> - 
> AccountingSplit) END"  
> as the Column value and "Capex" as the Alias and similarly for Opex.
> 
> 
> Cheers,
> Stuart
> 
> 
> On 14 Jul 2008 at 15:16, Darryl Collins wrote:
> 
> > 
> > Hi there,
> > 
> > I would have thought this was pretty simple, but I have a great ability to
> complicate these things it seems - heh, early days for me SQL server.
> > I have three fields in the table that I want to use for a calculated
> result in a couple of other fields in the table.
> > 
> > "AccTreatmentID"
> > 1: Opex
> > 2: Capex
> > 
> > "AccountingSplit"
> > 0%-100%
> > 
> > "Dollars"
> > Manually entered dollar value
> > 
> > 
> > Then I have two other fields (Capex and Opex) and I (think I) want to do
> this.
> > 
> > "=iif([AccTreamtentID]=1,([Dollars]*[AccountingSplit]),0)" to get the Opex
> Value
> > "=iif([AccTreamtentID]=2,([Dollars]*[AccountingSplit]),0)" to get the
> Capex Value
> > 
> > or If AccTreatment is Capex, then get the Capex Percentage and multiply by
> the dollar value to get the capex amount.
> > The actual formula is more complex as I need to determine the balance of
> the percentage and then apply that to the remainder of the value (opex in
> this case). anyway I am trying to keep it simple to start with.  (plus I
> will probably need some sort of error test to return zero if part of the
> data is missing - Am not sure if I need this or not in SQL server.)
> > 
> > The syntax in these formulae are not valid so I would like some help with
> that.  And I guess my other question is do I actually need this at all?
> > 
> > Maybe I should do all the hack work in a query to report of Opex / Capex
> splits.  Part of me suspect I dont need to store the calculated data at all
> in the table at all and this is bad practise as it takes up time and space
> for no real reason.
> > 
> > Anyone got any thoughts on this.
> > 
> > Cheers
> > Darryll
> > 
> > This email and any attachments may contain privileged and confidential
> information and are intended for the named addressee only. If you have
> received this e-mail in error, please notify the sender and delete this
> e-mail immediately. Any confidentiality, privilege or copyright is not
> waived or lost because this e-mail has been sent to you in error. It is your
> responsibility to check this e-mail and any attachments for viruses.  No
> warranty is made that this material is free from computer virus or any other
> defect or error.  Any loss/damage incurred by using this material is not the
> sender's responsibility.  The sender's entire liability will be limited to
> resupplying the material.
> > 
> > _______________________________________________
> > dba-SQLServer mailing list
> > dba-SQLServer at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> > http://www.databaseadvisors.com
> > 
> 
> 
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
> 
> 





From Darryl.Collins at coles.com.au  Mon Jul 14 19:27:57 2008
From: Darryl.Collins at coles.com.au (Darryl Collins)
Date: Tue, 15 Jul 2008 10:27:57 +1000
Subject: [dba-SQLServer] Calculated Column Field in a table...
In-Reply-To: <487C6C51.14542.156F9D1@stuart.lexacorp.com.pg>
Message-ID: <57E6E6CA42105A48B977303A2CDC2720076BF12D38@WPEXCH22.retail.ad.cmltd.net.au>



-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of Stuart
McLachlan
Sent: Tuesday, 15 July 2008 9:22 AM
To: Discussion concerning MS SQL Server
Subject: Re: [dba-SQLServer] Calculated Column Field in a table...


You're right.

I  don't  use "computed columns"  in tables generally and didn't think of doing so in this
instance.    When Darryl talked about "calculated columns", I was thinking in Access mode
and assumed that he was intending to store the *results* of the calculation in ordinary data
fields in the table.

I really have to get over the mindset that tables are just data stores - in SQL Server, you
can embed much of your business logic at the table level.

Stuart

On 14 Jul 2008 at 13:31, Asger Blond wrote:

> Stuart and Darryl,
>
> Calculated columns are calculated on the fly when querying the table. They
> are NOT stored in the table unless you make an index on the calculated
> column.
> Non-indexed calculated columns are just a convenient way of having often
> used calculations ready for table querying. If on the other hand you make an
> index on a calculated column you actually persist the calculated results
> which will speed up query performance compared to calculations in stored
> procedures or views, but at the same time it will degrade performance of
> insert and update operations against the table.
>
> Asger
>
>
> -----Oprindelig meddelelse-----
> Fra: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] P? vegne af Stuart
> McLachlan
> Sendt: 14. juli 2008 08:36
> Til: Discussion concerning MS SQL Server
> Emne: Re: [dba-SQLServer] Calculated Column Field in a table...
>
> Your last comment is right on the nail. You don't want to store calcuated
> results in the table
> unless you have VERY good reasons to do so.
>
> You can create either a View or a Stored Procedure to return Capex and Opex.
>
> In a Stored Procedure it would be
>
> Select
> .....,
> Case AccTreatmentId
>       When 1 Then Dollars*AccountingSplit
>       Else Dollars * (1-AccountingSplit)
> End As Capex,
> Case AccTreatmentId
>       When 2 Then Dollars*AccountingSplit
>       Else  Dollars * (1-AccountingSplit)
> End As Opex,
> .....
>
>
> In the Design grid in a View, put
>
> "CASE AccTreatmentId WHEN 1 THEN Dollars * AccountingSplit ELSE Dollars * (1
> -
> AccountingSplit) END"
> as the Column value and "Capex" as the Alias and similarly for Opex.
>
>
> Cheers,
> Stuart
>
>
> On 14 Jul 2008 at 15:16, Darryl Collins wrote:
>
> >
> > Hi there,
> >
> > I would have thought this was pretty simple, but I have a great ability to
> complicate these things it seems - heh, early days for me SQL server.
> > I have three fields in the table that I want to use for a calculated
> result in a couple of other fields in the table.
> >
> > "AccTreatmentID"
> > 1: Opex
> > 2: Capex
> >
> > "AccountingSplit"
> > 0%-100%
> >
> > "Dollars"
> > Manually entered dollar value
> >
> >
> > Then I have two other fields (Capex and Opex) and I (think I) want to do
> this.
> >
> > "=iif([AccTreamtentID]=1,([Dollars]*[AccountingSplit]),0)" to get the Opex
> Value
> > "=iif([AccTreamtentID]=2,([Dollars]*[AccountingSplit]),0)" to get the
> Capex Value
> >
> > or If AccTreatment is Capex, then get the Capex Percentage and multiply by
> the dollar value to get the capex amount.
> > The actual formula is more complex as I need to determine the balance of
> the percentage and then apply that to the remainder of the value (opex in
> this case). anyway I am trying to keep it simple to start with.  (plus I
> will probably need some sort of error test to return zero if part of the
> data is missing - Am not sure if I need this or not in SQL server.)
> >
> > The syntax in these formulae are not valid so I would like some help with
> that.  And I guess my other question is do I actually need this at all?
> >
> > Maybe I should do all the hack work in a query to report of Opex / Capex
> splits.  Part of me suspect I dont need to store the calculated data at all
> in the table at all and this is bad practise as it takes up time and space
> for no real reason.
> >
> > Anyone got any thoughts on this.
> >
> > Cheers
> > Darryll
> >
> > This email and any attachments may contain privileged and confidential
> information and are intended for the named addressee only. If you have
> received this e-mail in error, please notify the sender and delete this
> e-mail immediately. Any confidentiality, privilege or copyright is not
> waived or lost because this e-mail has been sent to you in error. It is your
> responsibility to check this e-mail and any attachments for viruses.  No
> warranty is made that this material is free from computer virus or any other
> defect or error.  Any loss/damage incurred by using this material is not the
> sender's responsibility.  The sender's entire liability will be limited to
> resupplying the material.
> >
> > _______________________________________________
> > dba-SQLServer mailing list
> > dba-SQLServer at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> > http://www.databaseadvisors.com
> >
>
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>



_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com


This email and any attachments may contain privileged and confidential information and are intended for the named addressee only. If you have received this e-mail in error, please notify the sender and delete this e-mail immediately. Any confidentiality, privilege or copyright is not waived or lost because this e-mail has been sent to you in error. It is your responsibility to check this e-mail and any attachments for viruses.  No warranty is made that this material is free from computer virus or any other defect or error.  Any loss/damage incurred by using this material is not the sender's responsibility.  The sender's entire liability will be limited to resupplying the material.



From Darryl.Collins at coles.com.au  Mon Jul 14 19:32:54 2008
From: Darryl.Collins at coles.com.au (Darryl Collins)
Date: Tue, 15 Jul 2008 10:32:54 +1000
Subject: [dba-SQLServer] Calculated Column Field in a table...
In-Reply-To: <487C6C51.14542.156F9D1@stuart.lexacorp.com.pg>
Message-ID: <57E6E6CA42105A48B977303A2CDC2720076BF12D39@WPEXCH22.retail.ad.cmltd.net.au>


bugger... I think Outlook sent this before I had a chance to write anything.  Sorry if you get a blank reply.,


"assumed that he was intending to store the *results* of the calculation in ordinary data fields in the table"

Stuart, you assumption was 100% correct, and my original thought process was two steps removed from SQL Server.  First I was thinking in Excel Mode - basically store a formula in the table that did the calculation, and then I was trying to think how I would do that in Access blah blah, before I started to see the light and think logically about it.  After reading what Asger had to say I now understand that my initial concept of what "Calculated columns" are and what they can be used for was flawed to begin with.  Grasshopper has learnt another valuable lesson from the masters this week.

Thanks. :)



-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of Stuart
McLachlan
Sent: Tuesday, 15 July 2008 9:22 AM
To: Discussion concerning MS SQL Server
Subject: Re: [dba-SQLServer] Calculated Column Field in a table...


You're right.

I  don't  use "computed columns"  in tables generally and didn't think of doing so in this
instance.    When Darryl talked about "calculated columns", I was thinking in Access mode
and assumed that he was intending to store the *results* of the calculation in ordinary data
fields in the table.

I really have to get over the mindset that tables are just data stores - in SQL Server, you
can embed much of your business logic at the table level.

Stuart

On 14 Jul 2008 at 13:31, Asger Blond wrote:

> Stuart and Darryl,
>
> Calculated columns are calculated on the fly when querying the table. They
> are NOT stored in the table unless you make an index on the calculated
> column.
> Non-indexed calculated columns are just a convenient way of having often
> used calculations ready for table querying. If on the other hand you make an
> index on a calculated column you actually persist the calculated results
> which will speed up query performance compared to calculations in stored
> procedures or views, but at the same time it will degrade performance of
> insert and update operations against the table.
>
> Asger
>
>
> -----Oprindelig meddelelse-----
> Fra: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] P? vegne af Stuart
> McLachlan
> Sendt: 14. juli 2008 08:36
> Til: Discussion concerning MS SQL Server
> Emne: Re: [dba-SQLServer] Calculated Column Field in a table...
>
> Your last comment is right on the nail. You don't want to store calcuated
> results in the table
> unless you have VERY good reasons to do so.
>
> You can create either a View or a Stored Procedure to return Capex and Opex.
>
> In a Stored Procedure it would be
>
> Select
> .....,
> Case AccTreatmentId
>       When 1 Then Dollars*AccountingSplit
>       Else Dollars * (1-AccountingSplit)
> End As Capex,
> Case AccTreatmentId
>       When 2 Then Dollars*AccountingSplit
>       Else  Dollars * (1-AccountingSplit)
> End As Opex,
> .....
>
>
> In the Design grid in a View, put
>
> "CASE AccTreatmentId WHEN 1 THEN Dollars * AccountingSplit ELSE Dollars * (1
> -
> AccountingSplit) END"
> as the Column value and "Capex" as the Alias and similarly for Opex.
>
>
> Cheers,
> Stuart
>
>
> On 14 Jul 2008 at 15:16, Darryl Collins wrote:
>
> >
> > Hi there,
> >
> > I would have thought this was pretty simple, but I have a great ability to
> complicate these things it seems - heh, early days for me SQL server.
> > I have three fields in the table that I want to use for a calculated
> result in a couple of other fields in the table.
> >
> > "AccTreatmentID"
> > 1: Opex
> > 2: Capex
> >
> > "AccountingSplit"
> > 0%-100%
> >
> > "Dollars"
> > Manually entered dollar value
> >
> >
> > Then I have two other fields (Capex and Opex) and I (think I) want to do
> this.
> >
> > "=iif([AccTreamtentID]=1,([Dollars]*[AccountingSplit]),0)" to get the Opex
> Value
> > "=iif([AccTreamtentID]=2,([Dollars]*[AccountingSplit]),0)" to get the
> Capex Value
> >
> > or If AccTreatment is Capex, then get the Capex Percentage and multiply by
> the dollar value to get the capex amount.
> > The actual formula is more complex as I need to determine the balance of
> the percentage and then apply that to the remainder of the value (opex in
> this case). anyway I am trying to keep it simple to start with.  (plus I
> will probably need some sort of error test to return zero if part of the
> data is missing - Am not sure if I need this or not in SQL server.)
> >
> > The syntax in these formulae are not valid so I would like some help with
> that.  And I guess my other question is do I actually need this at all?
> >
> > Maybe I should do all the hack work in a query to report of Opex / Capex
> splits.  Part of me suspect I dont need to store the calculated data at all
> in the table at all and this is bad practise as it takes up time and space
> for no real reason.
> >
> > Anyone got any thoughts on this.
> >
> > Cheers
> > Darryll
> >
> > This email and any attachments may contain privileged and confidential
> information and are intended for the named addressee only. If you have
> received this e-mail in error, please notify the sender and delete this
> e-mail immediately. Any confidentiality, privilege or copyright is not
> waived or lost because this e-mail has been sent to you in error. It is your
> responsibility to check this e-mail and any attachments for viruses.  No
> warranty is made that this material is free from computer virus or any other
> defect or error.  Any loss/damage incurred by using this material is not the
> sender's responsibility.  The sender's entire liability will be limited to
> resupplying the material.
> >
> > _______________________________________________
> > dba-SQLServer mailing list
> > dba-SQLServer at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> > http://www.databaseadvisors.com
> >
>
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>



_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com


This email and any attachments may contain privileged and confidential information and are intended for the named addressee only. If you have received this e-mail in error, please notify the sender and delete this e-mail immediately. Any confidentiality, privilege or copyright is not waived or lost because this e-mail has been sent to you in error. It is your responsibility to check this e-mail and any attachments for viruses.  No warranty is made that this material is free from computer virus or any other defect or error.  Any loss/damage incurred by using this material is not the sender's responsibility.  The sender's entire liability will be limited to resupplying the material.



From ssharkins at gmail.com  Tue Jul 15 11:49:12 2008
From: ssharkins at gmail.com (Susan Harkins)
Date: Tue, 15 Jul 2008 12:49:12 -0400
Subject: [dba-SQLServer] corruption
Message-ID: <009801c8e69a$b6f264b0$2f8601c7@SusanOne>

My experience with SQL Server is limited to training rather than actual 
development and administration. I have never run into a corruption problem 
with SQL Server -- how susceptible is SQL Server to corruption in the real 
world?

Susan H. 



From fuller.artful at gmail.com  Tue Jul 15 12:47:40 2008
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Tue, 15 Jul 2008 14:47:40 -0300
Subject: [dba-SQLServer] corruption
In-Reply-To: <009801c8e69a$b6f264b0$2f8601c7@SusanOne>
References: <009801c8e69a$b6f264b0$2f8601c7@SusanOne>
Message-ID: <29f585dd0807151047s5f874a04mbc97f99552a3309b@mail.gmail.com>

I don't know about the big picture Susan but I have been working non-stop
with SQL 2000+ since 1999 and I have never once experienced any data
corruption. I have brought the servers down a couple of times for hardware
reasons but never because of anything internal.

A.

On Tue, Jul 15, 2008 at 1:49 PM, Susan Harkins <ssharkins at gmail.com> wrote:

> My experience with SQL Server is limited to training rather than actual
> development and administration. I have never run into a corruption problem
> with SQL Server -- how susceptible is SQL Server to corruption in the real
> world?
>
> Susan H.
>


From ssharkins at gmail.com  Tue Jul 15 12:54:15 2008
From: ssharkins at gmail.com (Susan Harkins)
Date: Tue, 15 Jul 2008 13:54:15 -0400
Subject: [dba-SQLServer] corruption
References: <009801c8e69a$b6f264b0$2f8601c7@SusanOne>
	<29f585dd0807151047s5f874a04mbc97f99552a3309b@mail.gmail.com>
Message-ID: <00fb01c8e6a3$cfde28c0$2f8601c7@SusanOne>

Arthur, that does seem to be the case, but I thought I needed to ask, just 
to make sure.

Susan H.


>I don't know about the big picture Susan but I have been working non-stop
> with SQL 2000+ since 1999 and I have never once experienced any data
> corruption. I have brought the servers down a couple of times for hardware
> reasons but never because of anything internal.



From robert at webedb.com  Tue Jul 15 14:23:32 2008
From: robert at webedb.com (Robert L. Stewart)
Date: Tue, 15 Jul 2008 14:23:32 -0500
Subject: [dba-SQLServer] corruption
In-Reply-To: <mailman.5.1216141201.26753.dba-sqlserver@databaseadvisors. com>
References: <mailman.5.1216141201.26753.dba-sqlserver@databaseadvisors.com>
Message-ID: <200807151928.m6FJRuwo006808@databaseadvisors.com>

I have worked with it since 3.21. I have seen
it corrupt one time in all the time I have
worked with it.While it is possible, it is
very highly unlikely.

A friend of mine works for First American
Title. They use SQL Server for their data
warehouse, 3 tb of data. They have never had
a corruption.

Robert



>Date: Tue, 15 Jul 2008 12:49:12 -0400
>From: "Susan Harkins" <ssharkins at gmail.com>
>Subject: [dba-SQLServer] corruption
>To: "SQLList" <dba-SQLServer at databaseadvisors.com>
>Message-ID: <009801c8e69a$b6f264b0$2f8601c7 at SusanOne>
>Content-Type: text/plain; format=flowed; charset="iso-8859-1";
>         reply-type=original
>
>My experience with SQL Server is limited to training rather than actual
>development and administration. I have never run into a corruption problem
>with SQL Server -- how susceptible is SQL Server to corruption in the real
>world?
>
>Susan H.
>
>
>
>------------------------------
>
>_______________________________________________
>dba-SQLServer mailing list
>dba-SQLServer at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>
>
>End of dba-SQLServer Digest, Vol 65, Issue 15
>*********************************************




From fhtapia at gmail.com  Tue Jul 15 15:50:09 2008
From: fhtapia at gmail.com (Francisco Tapia)
Date: Tue, 15 Jul 2008 13:50:09 -0700
Subject: [dba-SQLServer] corruption
In-Reply-To: <009801c8e69a$b6f264b0$2f8601c7@SusanOne>
References: <009801c8e69a$b6f264b0$2f8601c7@SusanOne>
Message-ID: <2B4C87FD-B0A5-4CC2-990C-A4C87446D679@gmail.com>

I've never had any corelruption with data on SQL server, I've had  
databases as suspect because of hardware fauilure

Sent from my iPod

On Jul 15, 2008, at 9:49 AM, "Susan Harkins" <ssharkins at gmail.com>  
wrote:

> My experience with SQL Server is limited to training rather than  
> actual
> development and administration. I have never run into a corruption  
> problem
> with SQL Server -- how susceptible is SQL Server to corruption in  
> the real
> world?
>
> Susan H.
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>


From fhtapia at gmail.com  Tue Jul 15 15:50:09 2008
From: fhtapia at gmail.com (Francisco Tapia)
Date: Tue, 15 Jul 2008 13:50:09 -0700
Subject: [dba-SQLServer] corruption
In-Reply-To: <009801c8e69a$b6f264b0$2f8601c7@SusanOne>
References: <009801c8e69a$b6f264b0$2f8601c7@SusanOne>
Message-ID: <2B4C87FD-B0A5-4CC2-990C-A4C87446D679@gmail.com>

I've never had any corelruption with data on SQL server, I've had  
databases as suspect because of hardware fauilure

Sent from my iPod

On Jul 15, 2008, at 9:49 AM, "Susan Harkins" <ssharkins at gmail.com>  
wrote:

> My experience with SQL Server is limited to training rather than  
> actual
> development and administration. I have never run into a corruption  
> problem
> with SQL Server -- how susceptible is SQL Server to corruption in  
> the real
> world?
>
> Susan H.
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>


From ab-mi at post3.tele.dk  Tue Jul 15 16:31:16 2008
From: ab-mi at post3.tele.dk (Asger Blond)
Date: Tue, 15 Jul 2008 23:31:16 +0200
Subject: [dba-SQLServer] corruption
In-Reply-To: <2B4C87FD-B0A5-4CC2-990C-A4C87446D679@gmail.com>
Message-ID: <000001c8e6c2$1d1ad200$2101a8c0@AB>

So we can conclude: SQL Server is perfect, iPod a corelrupted fauilure ;-o

Asger

-----Oprindelig meddelelse-----
Fra: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] P? vegne af Francisco
Tapia
Sendt: 15. juli 2008 22:50
Til: Discussion concerning MS SQL Server
Cc: SQLList
Emne: Re: [dba-SQLServer] corruption

I've never had any corelruption with data on SQL server, I've had  
databases as suspect because of hardware fauilure

Sent from my iPod

On Jul 15, 2008, at 9:49 AM, "Susan Harkins" <ssharkins at gmail.com>  
wrote:

> My experience with SQL Server is limited to training rather than  
> actual
> development and administration. I have never run into a corruption  
> problem
> with SQL Server -- how susceptible is SQL Server to corruption in  
> the real
> world?
>
> Susan H.
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com

 











































































































































































From john at winhaven.net  Tue Jul 15 16:39:40 2008
From: john at winhaven.net (John Bartow)
Date: Tue, 15 Jul 2008 16:39:40 -0500
Subject: [dba-SQLServer] Paging Chris Mackin
Message-ID: <200807152139.m6FLdS9r022604@databaseadvisors.com>

Does anyone know Chris new email address?
 
John Bartow, President
Database Advisors, Inc.
Email: mailto:president at databaseadvisors.com
Website: http://www.databaseadvisors.com <http://www.databaseadvisors.com/> 




From fhtapia at gmail.com  Tue Jul 15 21:08:36 2008
From: fhtapia at gmail.com (Francisco Tapia)
Date: Tue, 15 Jul 2008 19:08:36 -0700
Subject: [dba-SQLServer] corruption
In-Reply-To: <000001c8e6c2$1d1ad200$2101a8c0@AB>
References: <2B4C87FD-B0A5-4CC2-990C-A4C87446D679@gmail.com>
	<000001c8e6c2$1d1ad200$2101a8c0@AB>
Message-ID: <b874372a0807151908s587ebcb3n3725e5d3821ab1ec@mail.gmail.com>

Hahaha!
yeah, I've been messing with my Ipod to for email in the last few days...
didn't catch that typo until after I hit the send button... :)

On Tue, Jul 15, 2008 at 2:31 PM, Asger Blond <ab-mi at post3.tele.dk> wrote:

> So we can conclude: SQL Server is perfect, iPod a corelrupted fauilure ;-o
>
> Asger
>
> -----Oprindelig meddelelse-----
> Fra: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] P? vegne af Francisco
> Tapia
> Sendt: 15. juli 2008 22:50
> Til: Discussion concerning MS SQL Server
> Cc: SQLList
> Emne: Re: [dba-SQLServer] corruption
>
> I've never had any corelruption with data on SQL server, I've had
> databases as suspect because of hardware fauilure
>
> Sent from my iPod
>
> On Jul 15, 2008, at 9:49 AM, "Susan Harkins" <ssharkins at gmail.com>
> wrote:
>
> > My experience with SQL Server is limited to training rather than
> > actual
> > development and administration. I have never run into a corruption
> > problem
> > with SQL Server -- how susceptible is SQL Server to corruption in
> > the real
> > world?
> >
> > Susan H.
> >
> > _______________________________________________
> > dba-SQLServer mailing list
> > dba-SQLServer at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> > http://www.databaseadvisors.com
> >
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>


-- 
-Francisco
http://sqlthis.blogspot.com | Tsql and More...


From accessd at shaw.ca  Tue Jul 15 22:10:34 2008
From: accessd at shaw.ca (Jim Lawrence)
Date: Tue, 15 Jul 2008 20:10:34 -0700
Subject: [dba-SQLServer] corruption
In-Reply-To: <2B4C87FD-B0A5-4CC2-990C-A4C87446D679@gmail.com>
References: <009801c8e69a$b6f264b0$2f8601c7@SusanOne>
	<2B4C87FD-B0A5-4CC2-990C-A4C87446D679@gmail.com>
Message-ID: <E10940AE24674A9788FC15D1F162E5C3@creativesystemdesigns.com>

Hi Susan:

I have worked with MS SQL since vesrion 6.5, 1996 and have never had any
data corruption... that can certainly not be said for any MDB app.

Jim
  
On Jul 15, 2008, at 9:49 AM, "Susan Harkins" <ssharkins at gmail.com>  
wrote:

> My experience with SQL Server is limited to training rather than  
> actual
> development and administration. I have never run into a corruption  
> problem
> with SQL Server -- how susceptible is SQL Server to corruption in  
> the real
> world?
>
> Susan H.
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com



From ssharkins at gmail.com  Wed Jul 16 19:14:42 2008
From: ssharkins at gmail.com (Susan Harkins)
Date: Wed, 16 Jul 2008 20:14:42 -0400
Subject: [dba-SQLServer] time issue
Message-ID: <00ed01c8e7a2$1dba5c90$2f8601c7@SusanOne>

A reader has a peculiar question -- at least, it is peculiar to me. They 
receive timestamped records from other time zones. When they receive them, 
SQL Server adjusts them to the current time zone! I'm aghast, but that seems 
to be what's happening.

They control both sides of the data, so they're in a position to adjust 
either end.

I just wouldn't have expected that to happen. Is this normal? Is there an 
easy way to tell SQL Server not to adjust time values?

Susan H. 



From stuart at lexacorp.com.pg  Wed Jul 16 20:20:02 2008
From: stuart at lexacorp.com.pg (Stuart McLachlan)
Date: Thu, 17 Jul 2008 11:20:02 +1000
Subject: [dba-SQLServer] time issue
In-Reply-To: <00ed01c8e7a2$1dba5c90$2f8601c7@SusanOne>
Message-ID: <487F2AE2.24472.C0F675D@stuart.lexacorp.com.pg>

I doubt very much that SQL Server is changing data.  

The problem is more likely to be in how it is created (whether they are storing UTC or Local 
time) and how it is displayed.

If they want to synchronize between time zones they need to store the times as UTC or 
store them as local time and also store the current UTC offset.




On 16 Jul 2008 at 20:14, Susan Harkins wrote:

> A reader has a peculiar question -- at least, it is peculiar to me. They 
> receive timestamped records from other time zones. When they receive them, 
> SQL Server adjusts them to the current time zone! I'm aghast, but that seems 
> to be what's happening.
> 
> They control both sides of the data, so they're in a position to adjust 
> either end.
> 
> I just wouldn't have expected that to happen. Is this normal? Is there an 
> easy way to tell SQL Server not to adjust time values?
> 
> Susan H. 
> 
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
> 




From ssharkins at gmail.com  Wed Jul 16 20:36:39 2008
From: ssharkins at gmail.com (Susan Harkins)
Date: Wed, 16 Jul 2008 21:36:39 -0400
Subject: [dba-SQLServer] time issue
References: <487F2AE2.24472.C0F675D@stuart.lexacorp.com.pg>
Message-ID: <017c01c8e7ad$937a3f80$2f8601c7@SusanOne>

That makes so much sense -- thank you Stuart.

Susan H.


>I doubt very much that SQL Server is changing data.
>
> The problem is more likely to be in how it is created (whether they are 
> storing UTC or Local
> time) and how it is displayed.
>
> If they want to synchronize between time zones they need to store the 
> times as UTC or
> store them as local time and also store the current UTC offset.
>
>
>
>
> On 16 Jul 2008 at 20:14, Susan Harkins wrote:
>
>> A reader has a peculiar question -- at least, it is peculiar to me. They
>> receive timestamped records from other time zones. When they receive 
>> them,
>> SQL Server adjusts them to the current time zone! I'm aghast, but that 
>> seems
>> to be what's happening.
>>
>> They control both sides of the data, so they're in a position to adjust
>> either end.
>>
>> I just wouldn't have expected that to happen. Is this normal? Is there an
>> easy way to tell SQL Server not to adjust time values?
>>
>> Susan H.
>>
>> _______________________________________________
>> dba-SQLServer mailing list
>> dba-SQLServer at databaseadvisors.com
>> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>> http://www.databaseadvisors.com
>>
>
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
> 



From ssharkins at gmail.com  Thu Jul 17 08:06:21 2008
From: ssharkins at gmail.com (Susan Harkins)
Date: Thu, 17 Jul 2008 09:06:21 -0400
Subject: [dba-SQLServer] more on that date problem
Message-ID: <020a01c8e80d$ea8eb8e0$2f8601c7@SusanOne>

How do you specify that a date-time value should be UTC? I'm familiar with 
UTC, but not how to specify it in SQL Server.

Susan h. 



From fuller.artful at gmail.com  Thu Jul 17 10:19:01 2008
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Thu, 17 Jul 2008 12:19:01 -0300
Subject: [dba-SQLServer] AdventureWorks --> AdventureWorksDW
Message-ID: <29f585dd0807170819x3dca8519s190b1aa7218eaabc@mail.gmail.com>

Does anyone have an URL or other info source on how the transition was made
from AW to AWDW? What underlies the decisions made, etc. I can play with
both but the deductions and the amalgamations and the aggregates baffle me.

Mostly unrelated question: given a bunch of data about stock prices at
moments in time, and quantities bought and sold, how might I build a cube
out of all this? At first blush, I would guess that trader, stock and date
are obvious dimensions. I want things out of this like moving averages and
position and so on, but I am totally unsure how to go about creating the
cube based on these dimensions. I'm reading Analysis Services Step by Step
but it is so literal (step by step) that I don't feel that I'm learning
anything about the larger picture.

My current app ignores cube technology completely and instead rolls up
everything since the beginning of time. My thought is that the past is the
past, and can be rolled up, and then we look at the past plus the present
(e.g. say the threshhold is beginning of last month, all the past data is in
the cube and all the current data is in the OLTP db; this requires an
amalgamation of the past with the present; I think this would be way faster
than our current "since the beginning of time" approach, but I am unsure how
to implement it.)

One small example is let's call it PersonOfInterest. That means a trader
whose details are normalized into a dozen tables. In the AS version, should
I denormalize all this detail and create a bunch of largely redundant rows
so that lookups are no longer required? On the other side of it, a stock
resides within a sub-industry which lives in an industry which lives in a
sector. Should all this be denormalized in the OLAP db? The aforementioned
"Step by Step" book touches not at all on this subject.

Currently my thought is that denormalization is the way to go: that I start
with the normalized Person data and create a view or something that grabs
all the data about said Person from let's say 12 tables and presents it as a
single table with all the FKs resolved already. This single table will then
be joined in the OLTP db to various items, but will avoid all the ancillary
lookups. Apply the same logic to Products, which have a ProductType and a
ManufacturerID and so on... so in the transition I denormalize all this and
end up with a dimProducts table. These tables will obviously be much larger
than the original source, but they will reduce the number of joins from 20
to say 3. Then we sum everything (bicycle sales by brand by customer by
salesperson by region etc.) and write a db which is considerably larger than
the OLTP version, but which has all the answers we want by visiting only one
or perhaps a few rows rather than doing all the legwork required in the OLTP
version of the db.

Do I have the picture right, or at least vaguely right?

Advice, URLs and other sources eagerly invited.

TIA,
Arthur


From stuart at lexacorp.com.pg  Thu Jul 17 17:58:35 2008
From: stuart at lexacorp.com.pg (Stuart McLachlan)
Date: Fri, 18 Jul 2008 08:58:35 +1000
Subject: [dba-SQLServer] more on that date problem
In-Reply-To: <020a01c8e80d$ea8eb8e0$2f8601c7@SusanOne>
Message-ID: <48805B3B.21773.10B44392@stuart.lexacorp.com.pg>

On 17 Jul 2008 at 9:06, Susan Harkins wrote:

> How do you specify that a date-time value should be UTC? I'm familiar with 
> UTC, but not how to specify it in SQL Server.

It's an implementation, not a design issue.

For instance, WHEN YOU CREATE A DATE ENTRY, instead of USING GETDATE(), you 
use GETUTCDATE().   Similarly you need another field to accompany each UTC 
DateTime field which stores the current local time offset from UTC.

You can get the current local time offset (in minutes) like this:
DECLARE @UTCOffset INT
 EXEC master..xp_regread
    'HKEY_LOCAL_MACHINE',
    'SYSTEM\CurrentControlSet\Control\TimeZoneInformation',
    'ActiveTimeBias',
    @UTCOffset OUTPUT
select @UTCOffset 


In SQL Server 2008, there are  new  time zone aware data types so this will become 
easier.






From ssharkins at gmail.com  Thu Jul 17 18:25:37 2008
From: ssharkins at gmail.com (Susan Harkins)
Date: Thu, 17 Jul 2008 19:25:37 -0400
Subject: [dba-SQLServer] more on that date problem
References: <48805B3B.21773.10B44392@stuart.lexacorp.com.pg>
Message-ID: <00c901c8e864$6cd23bf0$2f8601c7@SusanOne>

>
> For instance, WHEN YOU CREATE A DATE ENTRY, instead of USING GETDATE(), 
> you
> use GETUTCDATE().

======Thanks Stuart -- I didn't even know that existed.

Susan H. 



From ssharkins at gmail.com  Thu Jul 17 20:04:38 2008
From: ssharkins at gmail.com (Susan Harkins)
Date: Thu, 17 Jul 2008 21:04:38 -0400
Subject: [dba-SQLServer] Another one on checkident
Message-ID: <013f01c8e872$45a64720$2f8601c7@SusanOne>

If you delete the last identity value and run checkident, it says the 
current column value is actually the value you just deleted. Is it supposed 
to do that?

Susan H.



From Darryl.Collins at coles.com.au  Fri Jul 18 01:31:15 2008
From: Darryl.Collins at coles.com.au (Darryl Collins)
Date: Fri, 18 Jul 2008 16:31:15 +1000
Subject: [dba-SQLServer] Horizontally Partitioned Views - your thoughts?
In-Reply-To: <013f01c8e872$45a64720$2f8601c7@SusanOne>
Message-ID: <57E6E6CA42105A48B977303A2CDC2720076BF12D75@WPEXCH22.retail.ad.cmltd.net.au>

Hi everyone,

I have been reading about Horizontally Partitioned Views and their use in speeding up a query, especially if only working with a sub set of the orginal data.  This sort of thing seems to suit some of my requirement and the theory sounds good at least - although the text I am reading is a bit vauge on the actual parameters (for example, They state this is good for very large tables of data, just what is considered to be a "very large table" - 100,000 rows, 1,000,000 rows 10,000,000 rows, 5000 rows? is not clear).

Anyway.  Does any of you folks use this approach?  and in your real world experience at what point does it start to become worthwhile to use Horizontally Partitioned Views rather than a plain ol vanilla table?

Just curious.

Cheers
Darryl.

This email and any attachments may contain privileged and confidential information and are intended for the named addressee only. If you have received this e-mail in error, please notify the sender and delete this e-mail immediately. Any confidentiality, privilege or copyright is not waived or lost because this e-mail has been sent to you in error. It is your responsibility to check this e-mail and any attachments for viruses.  No warranty is made that this material is free from computer virus or any other defect or error.  Any loss/damage incurred by using this material is not the sender's responsibility.  The sender's entire liability will be limited to resupplying the material.



From fuller.artful at gmail.com  Fri Jul 18 08:12:59 2008
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Fri, 18 Jul 2008 10:12:59 -0300
Subject: [dba-SQLServer] SELECT INTO Versus CREATE #temp
Message-ID: <29f585dd0807180612k1c7e1b03q515eb143d88f4f41@mail.gmail.com>

>From a practical point of view, it would seem that these two commands are
equivalent:

SELECT * INTO #tempTable
FROM somewhere
WHERE someConditionHolds

CREATE #tempTable ( field list )
INSERT #tempTable ( field list ) SELECT * FROM somewhere WHERE
someConditionHolds

Are there performance differences or any other reason to choose one over the
other?

Arthur


From ab-mi at post3.tele.dk  Fri Jul 18 08:54:37 2008
From: ab-mi at post3.tele.dk (Asger Blond)
Date: Fri, 18 Jul 2008 15:54:37 +0200
Subject: [dba-SQLServer] SELECT INTO Versus CREATE #temp
In-Reply-To: <29f585dd0807180612k1c7e1b03q515eb143d88f4f41@mail.gmail.com>
Message-ID: <000101c8e8dd$d171c610$2101a8c0@AB>

With CREATE TABLE #tempTable you can specify constraints (and thereby unique
indexes if you specify a primary key or unique constraint) in the
create-table-statement.

A table created with SELECT INTO doesn't inherit any constraints or indexes
from the source table. But you can of course build these constraints and
indexes on the destination table after it has been created.

No other difference as far as I know.

Asger
-----Oprindelig meddelelse-----
Fra: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] P? vegne af Arthur
Fuller
Sendt: 18. juli 2008 15:13
Til: Discussion concerning MS SQL Server
Emne: [dba-SQLServer] SELECT INTO Versus CREATE #temp

>From a practical point of view, it would seem that these two commands are
equivalent:

SELECT * INTO #tempTable
FROM somewhere
WHERE someConditionHolds

CREATE #tempTable ( field list )
INSERT #tempTable ( field list ) SELECT * FROM somewhere WHERE
someConditionHolds

Are there performance differences or any other reason to choose one over the
other?

Arthur
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com

 








































































































































































From fuller.artful at gmail.com  Fri Jul 18 09:05:51 2008
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Fri, 18 Jul 2008 11:05:51 -0300
Subject: [dba-SQLServer] SELECT INTO Versus CREATE #temp
In-Reply-To: <000101c8e8dd$d171c610$2101a8c0@AB>
References: <29f585dd0807180612k1c7e1b03q515eb143d88f4f41@mail.gmail.com>
	<000101c8e8dd$d171c610$2101a8c0@AB>
Message-ID: <29f585dd0807180705g3985dda3y7a0cff77da73890b@mail.gmail.com>

I guess maybe I can only find out by writing a test case that inserts 1K or
10k rows. None of the instances of such code impose any constraints, so it
may be 6 of one and 1/2 dozen of the other. Maybe they both resolve to
identical code beneath the covers; maybe not. I'll write my test case and
report back with the results.

One other completely unrelated question: why is it that your messages (and
only yours) have about 100 blank lines between the end of the message and
the usual dba-SQL Server mailing list signature?

Thanks,
Arthur

On Fri, Jul 18, 2008 at 10:54 AM, Asger Blond <ab-mi at post3.tele.dk> wrote:

> With CREATE TABLE #tempTable you can specify constraints (and thereby
> unique
> indexes if you specify a primary key or unique constraint) in the
> create-table-statement.
>
> A table created with SELECT INTO doesn't inherit any constraints or indexes
> from the source table. But you can of course build these constraints and
> indexes on the destination table after it has been created.
>
> No other difference as far as I know.
>
> Asger


From ab-mi at post3.tele.dk  Fri Jul 18 09:35:20 2008
From: ab-mi at post3.tele.dk (Asger Blond)
Date: Fri, 18 Jul 2008 16:35:20 +0200
Subject: [dba-SQLServer] SELECT INTO Versus CREATE #temp
In-Reply-To: <29f585dd0807180705g3985dda3y7a0cff77da73890b@mail.gmail.com>
Message-ID: <000301c8e8e3$96560860$2101a8c0@AB>

> One other completely unrelated question: why is it that your messages (and
> only yours) have about 100 blank lines between the end of the message and
> the usual dba-SQL Server mailing list signature?

No idea, but now I notice that all mails I receive has these blank lines.
Maybe it's my Outlook, maybe it's my CA Anti-spam.
Anyway, the lines certainly add up, and I'll remember to delete them from my
postings in the future. Please tell me if this mail still contains blank
lines.

Thanks,
Asger

-----Oprindelig meddelelse-----
Fra: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] P? vegne af Arthur
Fuller
Sendt: 18. juli 2008 16:06
Til: Discussion concerning MS SQL Server
Emne: Re: [dba-SQLServer] SELECT INTO Versus CREATE #temp

I guess maybe I can only find out by writing a test case that inserts 1K or
10k rows. None of the instances of such code impose any constraints, so it
may be 6 of one and 1/2 dozen of the other. Maybe they both resolve to
identical code beneath the covers; maybe not. I'll write my test case and
report back with the results.

One other completely unrelated question: why is it that your messages (and
only yours) have about 100 blank lines between the end of the message and
the usual dba-SQL Server mailing list signature?

Thanks,
Arthur

On Fri, Jul 18, 2008 at 10:54 AM, Asger Blond <ab-mi at post3.tele.dk> wrote:

> With CREATE TABLE #tempTable you can specify constraints (and thereby
> unique
> indexes if you specify a primary key or unique constraint) in the
> create-table-statement.
>
> A table created with SELECT INTO doesn't inherit any constraints or
indexes
> from the source table. But you can of course build these constraints and
> indexes on the destination table after it has been created.
>
> No other difference as far as I know.
>
> Asger
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com




From fuller.artful at gmail.com  Fri Jul 18 09:39:21 2008
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Fri, 18 Jul 2008 11:39:21 -0300
Subject: [dba-SQLServer] SELECT INTO Versus CREATE #temp
In-Reply-To: <000301c8e8e3$96560860$2101a8c0@AB>
References: <29f585dd0807180705g3985dda3y7a0cff77da73890b@mail.gmail.com>
	<000301c8e8e3$96560860$2101a8c0@AB>
Message-ID: <29f585dd0807180739g3bec6ca2j6cfe37c5ccff09ad@mail.gmail.com>

Hey Asger,

This one doesn't. Interesting. I don't use Outlook but I used to and don't
think it is responsible. Anyway, I wasn't so much complaining about them as
curious about their existence.

Arthur

On Fri, Jul 18, 2008 at 11:35 AM, Asger Blond <ab-mi at post3.tele.dk> wrote:

> > One other completely unrelated question: why is it that your messages
> (and
> > only yours) have about 100 blank lines between the end of the message and
> > the usual dba-SQL Server mailing list signature?
>
> No idea, but now I notice that all mails I receive has these blank lines.
> Maybe it's my Outlook, maybe it's my CA Anti-spam.
> Anyway, the lines certainly add up, and I'll remember to delete them from
> my
> postings in the future. Please tell me if this mail still contains blank
> lines.
>
> Thanks,
> Asger
>


From ab-mi at post3.tele.dk  Fri Jul 18 10:08:26 2008
From: ab-mi at post3.tele.dk (Asger Blond)
Date: Fri, 18 Jul 2008 17:08:26 +0200
Subject: [dba-SQLServer] SELECT INTO Versus CREATE #temp
In-Reply-To: <29f585dd0807180739g3bec6ca2j6cfe37c5ccff09ad@mail.gmail.com>
Message-ID: <000401c8e8e8$216d5850$2101a8c0@AB>

Tanks, I couldn't verify this on my machine because the mail I received back
has the blank lines appended again.
Funny thing: All mails I receive with this blank lines has a message just
beneath the sender's mail address telling "Extra linebreaks in this message
has been removed" (sic!) - mails, that doesn't contain extra linebreaks
doesn't have this message.
That's why I think it's an Outlook feature. Kind of Microsoft reverse logic:
just like in Windows, if you want to Stop your computer then press the Start
button...

Asger

-----Oprindelig meddelelse-----
Fra: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] P? vegne af Arthur
Fuller
Sendt: 18. juli 2008 16:39
Til: Discussion concerning MS SQL Server
Emne: Re: [dba-SQLServer] SELECT INTO Versus CREATE #temp

Hey Asger,

This one doesn't. Interesting. I don't use Outlook but I used to and don't
think it is responsible. Anyway, I wasn't so much complaining about them as
curious about their existence.

Arthur

On Fri, Jul 18, 2008 at 11:35 AM, Asger Blond <ab-mi at post3.tele.dk> wrote:

> > One other completely unrelated question: why is it that your messages
> (and
> > only yours) have about 100 blank lines between the end of the message
and
> > the usual dba-SQL Server mailing list signature?
>
> No idea, but now I notice that all mails I receive has these blank lines.
> Maybe it's my Outlook, maybe it's my CA Anti-spam.
> Anyway, the lines certainly add up, and I'll remember to delete them from
> my
> postings in the future. Please tell me if this mail still contains blank
> lines.
>
> Thanks,
> Asger
>
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com





From fuller.artful at gmail.com  Fri Jul 18 10:14:06 2008
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Fri, 18 Jul 2008 12:14:06 -0300
Subject: [dba-SQLServer] SELECT INTO Versus CREATE #temp
In-Reply-To: <29f585dd0807180705g3985dda3y7a0cff77da73890b@mail.gmail.com>
References: <29f585dd0807180612k1c7e1b03q515eb143d88f4f41@mail.gmail.com>
	<000101c8e8dd$d171c610$2101a8c0@AB>
	<29f585dd0807180705g3985dda3y7a0cff77da73890b@mail.gmail.com>
Message-ID: <29f585dd0807180814l3da58336pa5bcd7ec018ca141@mail.gmail.com>

I just complete my test case and the difference on inserting 100 rows was
less than one second. Hardly worth a rewrite.

Arthur

On Fri, Jul 18, 2008 at 11:05 AM, Arthur Fuller <fuller.artful at gmail.com>
wrote:

> I guess maybe I can only find out by writing a test case that inserts 1K or
> 10k rows. None of the instances of such code impose any constraints, so it
> may be 6 of one and 1/2 dozen of the other. Maybe they both resolve to
> identical code beneath the covers; maybe not. I'll write my test case and
> report back with the results.
>
>


From fuller.artful at gmail.com  Fri Jul 18 13:27:07 2008
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Fri, 18 Jul 2008 15:27:07 -0300
Subject: [dba-SQLServer] Views on Views
Message-ID: <29f585dd0807181127v3c6b43e8x19e029d037126018@mail.gmail.com>

Does anyone have opinions on the merits or weaknesses of building a view
that uses a view, as opposed to the underlying table(s)? In my current
project I have found a couple of instances of views depending on other
views, and in one case I found a view that depends on three other views.

TIA,
Arthur


From fhtapia at gmail.com  Fri Jul 18 15:37:32 2008
From: fhtapia at gmail.com (Francisco Tapia)
Date: Fri, 18 Jul 2008 13:37:32 -0700
Subject: [dba-SQLServer] SELECT INTO Versus CREATE #temp
In-Reply-To: <29f585dd0807180814l3da58336pa5bcd7ec018ca141@mail.gmail.com>
References: <29f585dd0807180612k1c7e1b03q515eb143d88f4f41@mail.gmail.com>
	<000101c8e8dd$d171c610$2101a8c0@AB>
	<29f585dd0807180705g3985dda3y7a0cff77da73890b@mail.gmail.com>
	<29f585dd0807180814l3da58336pa5bcd7ec018ca141@mail.gmail.com>
Message-ID: <b874372a0807181337i61495850t1d6d407755397083@mail.gmail.com>

Arthur/Asger,
  IME, when you do a SELECT * INTO #Temp you hold a lock on the TEMP db.  I
have not tested this against Sql Server 2005, but in Sql Server 2000 SP4
this was very evident on our legacy application.  if your Select * Into
takes several seconds to return you will be locking the TempDb for that
duration, in contrast, if you create the Temp Table first you do not lock up
the database while you are inserting data into the temp table.

On Fri, Jul 18, 2008 at 8:14 AM, Arthur Fuller <fuller.artful at gmail.com>
wrote:

> I just complete my test case and the difference on inserting 100 rows was
> less than one second. Hardly worth a rewrite.
>
> Arthur
>
> On Fri, Jul 18, 2008 at 11:05 AM, Arthur Fuller <fuller.artful at gmail.com>
> wrote:
>
> > I guess maybe I can only find out by writing a test case that inserts 1K
> or
> > 10k rows. None of the instances of such code impose any constraints, so
> it
> > may be 6 of one and 1/2 dozen of the other. Maybe they both resolve to
> > identical code beneath the covers; maybe not. I'll write my test case and
> > report back with the results.
> >
> >
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>


-- 
-Francisco
http://sqlthis.blogspot.com | Tsql and More...


From fhtapia at gmail.com  Fri Jul 18 16:11:51 2008
From: fhtapia at gmail.com (Francisco Tapia)
Date: Fri, 18 Jul 2008 14:11:51 -0700
Subject: [dba-SQLServer] Another one on checkident
In-Reply-To: <013f01c8e872$45a64720$2f8601c7@SusanOne>
References: <013f01c8e872$45a64720$2f8601c7@SusanOne>
Message-ID: <b874372a0807181411g61e270d5u9c4cdf78165399be@mail.gmail.com>

CheckIndent only returns the last identity value, it does not tell you if
the value is still in the table, just the last one hence you can use
CheckIndent to reseed a table and start the seed at let's say 5mil
5,000,000. otherwise it's the current id value case in point... you have two
users who insert a record into your table, however let's say the 2nd insert
occurred before your program ran the checkIndent, then you'll end up with
the 2nd users' Identity value instead of the one you were really after,
yours.  To solve this issue I always use scope_identity, but even that will
not tell you that the record has been deleted.

On Thu, Jul 17, 2008 at 6:04 PM, Susan Harkins <ssharkins at gmail.com> wrote:

> If you delete the last identity value and run checkident, it says the
> current column value is actually the value you just deleted. Is it supposed
> to do that?
>
> Susan H.
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>


-- 
-Francisco
http://sqlthis.blogspot.com | Tsql and More...


From fuller.artful at gmail.com  Fri Jul 18 16:12:07 2008
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Fri, 18 Jul 2008 18:12:07 -0300
Subject: [dba-SQLServer] SELECT INTO Versus CREATE #temp
In-Reply-To: <b874372a0807181337i61495850t1d6d407755397083@mail.gmail.com>
References: <29f585dd0807180612k1c7e1b03q515eb143d88f4f41@mail.gmail.com>
	<000101c8e8dd$d171c610$2101a8c0@AB>
	<29f585dd0807180705g3985dda3y7a0cff77da73890b@mail.gmail.com>
	<29f585dd0807180814l3da58336pa5bcd7ec018ca141@mail.gmail.com>
	<b874372a0807181337i61495850t1d6d407755397083@mail.gmail.com>
Message-ID: <29f585dd0807181412m7ce74d35mad82e791510ea9e0@mail.gmail.com>

I accept that, but you beg another interesting question. Suppose:

User 1 invokes the sproc which says "CREATE TABLE #Asger" and then does some
inserts.
One second later,
User 2 invokes the sproc which says "CREATE TABLE #Asger" and then does some
inserts.

Process #1 has not finished. What happens? Are we in danger here? We have
occasionally noticed that User 1 ends up with data that belongs to user #2?
Could this be why?

Time to put on the white coat and go into the lab and find out.

Completely irrelevant comment: I'm so glad that I'm now devoted to these
problems only, without having to worry about the Access or .NET front ends.
They belong to Shahid not me. I like this division a lot. (His desk is only
about 10 feet from mine, but we can concentrate on different problems. I
think I won -- he is in DLL Hell currently. I've been there and done that
and don't want to go back.

It turns out after using Red Gate's tools that I can uncover no instances of
"SELECT INTO" but there are a disturbing number of temp tables and now I
have to figure out why. I've been reading about the performance hits of temp
tables and ways to do it smarter, so now I know what to do this weekend --
some comparisons.

Thanks, Francisco and Asger, your input is always appreciated,
Arthur


On Fri, Jul 18, 2008 at 5:37 PM, Francisco Tapia <fhtapia at gmail.com> wrote:

> Arthur/Asger,
>  IME, when you do a SELECT * INTO #Temp you hold a lock on the TEMP db.  I
> have not tested this against Sql Server 2005, but in Sql Server 2000 SP4
> this was very evident on our legacy application.  if your Select * Into
> takes several seconds to return you will be locking the TempDb for that
> duration, in contrast, if you create the Temp Table first you do not lock
> up
> the database while you are inserting data into the temp table.
>
>


From fhtapia at gmail.com  Fri Jul 18 16:17:12 2008
From: fhtapia at gmail.com (Francisco Tapia)
Date: Fri, 18 Jul 2008 14:17:12 -0700
Subject: [dba-SQLServer] SELECT INTO Versus CREATE #temp
In-Reply-To: <29f585dd0807181412m7ce74d35mad82e791510ea9e0@mail.gmail.com>
References: <29f585dd0807180612k1c7e1b03q515eb143d88f4f41@mail.gmail.com>
	<000101c8e8dd$d171c610$2101a8c0@AB>
	<29f585dd0807180705g3985dda3y7a0cff77da73890b@mail.gmail.com>
	<29f585dd0807180814l3da58336pa5bcd7ec018ca141@mail.gmail.com>
	<b874372a0807181337i61495850t1d6d407755397083@mail.gmail.com>
	<29f585dd0807181412m7ce74d35mad82e791510ea9e0@mail.gmail.com>
Message-ID: <b874372a0807181417o2f381633idaf597085b064d03@mail.gmail.com>

Not at all, each execution of a sproc should be in it's own session. thus
after the 2nd create table, you should be able to view the Temp Tables in
the TempDB and see that you have #Asger000000000000000001 and
#Asger000000000000000002 (or some such number).  I'm not sure why User 1
would have User2's data unless you were createing ## temporary tables which
expand beyond the current users' session.


On Fri, Jul 18, 2008 at 2:12 PM, Arthur Fuller <fuller.artful at gmail.com>
wrote:

> I accept that, but you beg another interesting question. Suppose:
>
> User 1 invokes the sproc which says "CREATE TABLE #Asger" and then does
> some
> inserts.
> One second later,
> User 2 invokes the sproc which says "CREATE TABLE #Asger" and then does
> some
> inserts.
>
> Process #1 has not finished. What happens? Are we in danger here? We have
> occasionally noticed that User 1 ends up with data that belongs to user #2?
> Could this be why?
>
> Time to put on the white coat and go into the lab and find out.
>
> Completely irrelevant comment: I'm so glad that I'm now devoted to these
> problems only, without having to worry about the Access or .NET front ends.
> They belong to Shahid not me. I like this division a lot. (His desk is only
> about 10 feet from mine, but we can concentrate on different problems. I
> think I won -- he is in DLL Hell currently. I've been there and done that
> and don't want to go back.
>
> It turns out after using Red Gate's tools that I can uncover no instances
> of
> "SELECT INTO" but there are a disturbing number of temp tables and now I
> have to figure out why. I've been reading about the performance hits of
> temp
> tables and ways to do it smarter, so now I know what to do this weekend --
> some comparisons.
>
> Thanks, Francisco and Asger, your input is always appreciated,
> Arthur
>
>
> On Fri, Jul 18, 2008 at 5:37 PM, Francisco Tapia <fhtapia at gmail.com>
> wrote:
>
> > Arthur/Asger,
> >  IME, when you do a SELECT * INTO #Temp you hold a lock on the TEMP db.
>  I
> > have not tested this against Sql Server 2005, but in Sql Server 2000 SP4
> > this was very evident on our legacy application.  if your Select * Into
> > takes several seconds to return you will be locking the TempDb for that
> > duration, in contrast, if you create the Temp Table first you do not lock
> > up
> > the database while you are inserting data into the temp table.
> >
> >
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>


-- 
-Francisco
http://sqlthis.blogspot.com | Tsql and More...


From fuller.artful at gmail.com  Fri Jul 18 16:30:50 2008
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Fri, 18 Jul 2008 18:30:50 -0300
Subject: [dba-SQLServer] SELECT INTO Versus CREATE #temp
In-Reply-To: <b874372a0807181417o2f381633idaf597085b064d03@mail.gmail.com>
References: <29f585dd0807180612k1c7e1b03q515eb143d88f4f41@mail.gmail.com>
	<000101c8e8dd$d171c610$2101a8c0@AB>
	<29f585dd0807180705g3985dda3y7a0cff77da73890b@mail.gmail.com>
	<29f585dd0807180814l3da58336pa5bcd7ec018ca141@mail.gmail.com>
	<b874372a0807181337i61495850t1d6d407755397083@mail.gmail.com>
	<29f585dd0807181412m7ce74d35mad82e791510ea9e0@mail.gmail.com>
	<b874372a0807181417o2f381633idaf597085b064d03@mail.gmail.com>
Message-ID: <29f585dd0807181430v5af2fd60n9b101a5d87cb648b@mail.gmail.com>

Something to consider. I'm still inspecting the previous code but I will
make sure to look for ## in the code.

We are still trying to figure out why U2 ended up with U1's data and it does
not happen consistently so this one is maybe going to take a while to
resolve.

Thanks,
Arthur

On Fri, Jul 18, 2008 at 6:17 PM, Francisco Tapia <fhtapia at gmail.com> wrote:

> Not at all, each execution of a sproc should be in it's own session. thus
> after the 2nd create table, you should be able to view the Temp Tables in
> the TempDB and see that you have #Asger000000000000000001 and
> #Asger000000000000000002 (or some such number).  I'm not sure why User 1
> would have User2's data unless you were createing ## temporary tables which
> expand beyond the current users' session.
>
>


From ab-mi at post3.tele.dk  Fri Jul 18 17:11:18 2008
From: ab-mi at post3.tele.dk (Asger Blond)
Date: Sat, 19 Jul 2008 00:11:18 +0200
Subject: [dba-SQLServer] SELECT INTO Versus CREATE #temp
In-Reply-To: <b874372a0807181417o2f381633idaf597085b064d03@mail.gmail.com>
Message-ID: <000001c8e923$492de1d0$2101a8c0@AB>

Agree, only a global temporary table created with the ##-prefix should make
this behaviour possible. A temp table with the #-prefix is private to the
session creating the table.

Asger
-----Oprindelig meddelelse-----
Fra: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] P? vegne af Francisco
Tapia
Sendt: 18. juli 2008 23:17
Til: Discussion concerning MS SQL Server
Emne: Re: [dba-SQLServer] SELECT INTO Versus CREATE #temp

Not at all, each execution of a sproc should be in it's own session. thus
after the 2nd create table, you should be able to view the Temp Tables in
the TempDB and see that you have #Asger000000000000000001 and
#Asger000000000000000002 (or some such number).  I'm not sure why User 1
would have User2's data unless you were createing ## temporary tables which
expand beyond the current users' session.


On Fri, Jul 18, 2008 at 2:12 PM, Arthur Fuller <fuller.artful at gmail.com>
wrote:

> I accept that, but you beg another interesting question. Suppose:
>
> User 1 invokes the sproc which says "CREATE TABLE #Asger" and then does
> some
> inserts.
> One second later,
> User 2 invokes the sproc which says "CREATE TABLE #Asger" and then does
> some
> inserts.
>
> Process #1 has not finished. What happens? Are we in danger here? We have
> occasionally noticed that User 1 ends up with data that belongs to user
#2?
> Could this be why?
>
> Time to put on the white coat and go into the lab and find out.
>
> Completely irrelevant comment: I'm so glad that I'm now devoted to these
> problems only, without having to worry about the Access or .NET front
ends.
> They belong to Shahid not me. I like this division a lot. (His desk is
only
> about 10 feet from mine, but we can concentrate on different problems. I
> think I won -- he is in DLL Hell currently. I've been there and done that
> and don't want to go back.
>
> It turns out after using Red Gate's tools that I can uncover no instances
> of
> "SELECT INTO" but there are a disturbing number of temp tables and now I
> have to figure out why. I've been reading about the performance hits of
> temp
> tables and ways to do it smarter, so now I know what to do this weekend --
> some comparisons.
>
> Thanks, Francisco and Asger, your input is always appreciated,
> Arthur
>
>
> On Fri, Jul 18, 2008 at 5:37 PM, Francisco Tapia <fhtapia at gmail.com>
> wrote:
>
> > Arthur/Asger,
> >  IME, when you do a SELECT * INTO #Temp you hold a lock on the TEMP db.
>  I
> > have not tested this against Sql Server 2005, but in Sql Server 2000 SP4
> > this was very evident on our legacy application.  if your Select * Into
> > takes several seconds to return you will be locking the TempDb for that
> > duration, in contrast, if you create the Temp Table first you do not
lock
> > up
> > the database while you are inserting data into the temp table.
> >
> >
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>


-- 
-Francisco
http://sqlthis.blogspot.com | Tsql and More...
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com





From ssharkins at gmail.com  Fri Jul 18 17:13:18 2008
From: ssharkins at gmail.com (Susan Harkins)
Date: Fri, 18 Jul 2008 18:13:18 -0400
Subject: [dba-SQLServer] Another one on checkident
References: <013f01c8e872$45a64720$2f8601c7@SusanOne>
	<b874372a0807181411g61e270d5u9c4cdf78165399be@mail.gmail.com>
Message-ID: <03cd01c8e923$7d234610$2f8601c7@SusanOne>

It makes sense and I thought as much, but found it curious that the Help 
documentation refers to that value as the "current" value -- just a bad 
explanation I think. Thank you!

Susan H.


> CheckIndent only returns the last identity value, it does not tell you if
> the value is still in the table, just the last one hence you can use
> CheckIndent to reseed a table and start the seed at let's say 5mil
> 5,000,000. otherwise it's the current id value case in point... you have 
> two
> users who insert a record into your table, however let's say the 2nd 
> insert
> occurred before your program ran the checkIndent, then you'll end up with
> the 2nd users' Identity value instead of the one you were really after,
> yours.  To solve this issue I always use scope_identity, but even that 
> will
> not tell you that the record has been deleted.



From fuller.artful at gmail.com  Fri Jul 18 17:40:47 2008
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Fri, 18 Jul 2008 19:40:47 -0300
Subject: [dba-SQLServer] SELECT INTO Versus CREATE #temp
In-Reply-To: <000001c8e923$492de1d0$2101a8c0@AB>
References: <b874372a0807181417o2f381633idaf597085b064d03@mail.gmail.com>
	<000001c8e923$492de1d0$2101a8c0@AB>
Message-ID: <29f585dd0807181540t79198b5bx81b572926a7d898b@mail.gmail.com>

Good to know. Thanks!
Arthur


From ab-mi at post3.tele.dk  Fri Jul 18 18:23:24 2008
From: ab-mi at post3.tele.dk (Asger Blond)
Date: Sat, 19 Jul 2008 01:23:24 +0200
Subject: [dba-SQLServer] SELECT INTO Versus CREATE #temp
In-Reply-To: <29f585dd0807181430v5af2fd60n9b101a5d87cb648b@mail.gmail.com>
Message-ID: <000101c8e92d$46843a10$2101a8c0@AB>

Another thing to consider:
SQL Server 2005 uses tempdb more heavily than pervious versions does, and it
appears that you do too.
To boost performance it's good practice to place the tempdb database and its
log file on fast disks (and not in the default folder created when
installing SQL Server).
Maybe you already know, but here are the steps to move the tempdb database:

ALTER DATABASE tempdb MODIFY FILE 
(name='tempdev', filename='X:\TempDBData\tempdb.mdf')
ALTER DATABASE tempdb MODIFY FILE 
(name='templog', filename='Y:\TempDBLog\templog.ldf')

To make use of the new file-placements, restart SQL Server.

Asger
-----Oprindelig meddelelse-----
Fra: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] P? vegne af Arthur
Fuller
Sendt: 18. juli 2008 23:31
Til: Discussion concerning MS SQL Server
Emne: Re: [dba-SQLServer] SELECT INTO Versus CREATE #temp

Something to consider. I'm still inspecting the previous code but I will
make sure to look for ## in the code.

We are still trying to figure out why U2 ended up with U1's data and it does
not happen consistently so this one is maybe going to take a while to
resolve.

Thanks,
Arthur

On Fri, Jul 18, 2008 at 6:17 PM, Francisco Tapia <fhtapia at gmail.com> wrote:

> Not at all, each execution of a sproc should be in it's own session. thus
> after the 2nd create table, you should be able to view the Temp Tables in
> the TempDB and see that you have #Asger000000000000000001 and
> #Asger000000000000000002 (or some such number).  I'm not sure why User 1
> would have User2's data unless you were createing ## temporary tables
which
> expand beyond the current users' session.
>
>
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com





From fuller.artful at gmail.com  Fri Jul 18 18:33:20 2008
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Fri, 18 Jul 2008 20:33:20 -0300
Subject: [dba-SQLServer] SELECT INTO Versus CREATE #temp
In-Reply-To: <000101c8e92d$46843a10$2101a8c0@AB>
References: <29f585dd0807181430v5af2fd60n9b101a5d87cb648b@mail.gmail.com>
	<000101c8e92d$46843a10$2101a8c0@AB>
Message-ID: <29f585dd0807181633y601e2610h51e419ca418d0f27@mail.gmail.com>

Thanks for this advice, I will go into the office tomorrow and attempt to do
this while no one's home and see what happens. Thanks for the tip.

A.


From jlawrenc1 at shaw.ca  Sat Jul 19 22:07:24 2008
From: jlawrenc1 at shaw.ca (Jim Lawrence)
Date: Sat, 19 Jul 2008 20:07:24 -0700
Subject: [dba-SQLServer] Views on Views
In-Reply-To: <29f585dd0807181127v3c6b43e8x19e029d037126018@mail.gmail.com>
References: <29f585dd0807181127v3c6b43e8x19e029d037126018@mail.gmail.com>
Message-ID: <8EA748066AA849B6BAB7887D1B101451@creativesystemdesigns.com>

Hi Arthur:

I would try and keep it as simple as possible as there can be tremendous
over-head with this direction as well as some very complex class-like
inheritance and reciprocal loops that can come back to bite.

I do not have much experience with MS SQL and Views but I am familiar with
apps such as Cognos and Discoverer, both Oracle products that are built on
top of views on top of views. 

These programs are created to make managers feel that they can easily
generate any reports but never have I seen products that can grind Oracle
Enterprise, with 'state-of-the-art' hardware, to its knees faster or
actually freeze a site all-together.

After all that is said, it should be safe in the hands of a good IT guy,
like yourself but definitely be judicious.

Jim       

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Arthur
Fuller
Sent: Friday, July 18, 2008 11:27 AM
To: Discussion concerning MS SQL Server
Subject: [dba-SQLServer] Views on Views

Does anyone have opinions on the merits or weaknesses of building a view
that uses a view, as opposed to the underlying table(s)? In my current
project I have found a couple of instances of views depending on other
views, and in one case I found a view that depends on three other views.

TIA,
Arthur
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com



From fuller.artful at gmail.com  Sun Jul 20 08:54:02 2008
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Sun, 20 Jul 2008 10:54:02 -0300
Subject: [dba-SQLServer] Views on Views
In-Reply-To: <8EA748066AA849B6BAB7887D1B101451@creativesystemdesigns.com>
References: <29f585dd0807181127v3c6b43e8x19e029d037126018@mail.gmail.com>
	<8EA748066AA849B6BAB7887D1B101451@creativesystemdesigns.com>
Message-ID: <29f585dd0807200654t6a8a6ee1s6697dd877694ace8@mail.gmail.com>

I have some more reading on views and learned something new. A view is
apparently nothing more than a  macro that is expanded at run time.

Arthur


From fuller.artful at gmail.com  Mon Jul 21 10:11:03 2008
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Mon, 21 Jul 2008 12:11:03 -0300
Subject: [dba-SQLServer] INSERT SELECT question
Message-ID: <29f585dd0807210811w26d0e8c2l814049f2b81cbb0a@mail.gmail.com>

If I INSERT a group of rows at once based on a SELECT from somewhere, and
the target table has an INSTEAD OF insert trigger, does that trigger fire
once for each row inserted or once for the batch of inserts?

Thanks,
Arthur


From fhtapia at gmail.com  Mon Jul 21 11:48:47 2008
From: fhtapia at gmail.com (Francisco Tapia)
Date: Mon, 21 Jul 2008 09:48:47 -0700
Subject: [dba-SQLServer] INSERT SELECT question
In-Reply-To: <29f585dd0807210811w26d0e8c2l814049f2b81cbb0a@mail.gmail.com>
References: <29f585dd0807210811w26d0e8c2l814049f2b81cbb0a@mail.gmail.com>
Message-ID: <b874372a0807210948k77bafa66we15dd95597693215@mail.gmail.com>

IME, it's been the batch.


On Mon, Jul 21, 2008 at 8:11 AM, Arthur Fuller <fuller.artful at gmail.com>
wrote:

> If I INSERT a group of rows at once based on a SELECT from somewhere, and
> the target table has an INSTEAD OF insert trigger, does that trigger fire
> once for each row inserted or once for the batch of inserts?
>
> Thanks,
> Arthur
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>


-- 
-Francisco
http://sqlthis.blogspot.com | Tsql and More...


From fuller.artful at gmail.com  Mon Jul 21 18:02:01 2008
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Mon, 21 Jul 2008 20:02:01 -0300
Subject: [dba-SQLServer] INSERT SELECT question
In-Reply-To: <b874372a0807210948k77bafa66we15dd95597693215@mail.gmail.com>
References: <29f585dd0807210811w26d0e8c2l814049f2b81cbb0a@mail.gmail.com>
	<b874372a0807210948k77bafa66we15dd95597693215@mail.gmail.com>
Message-ID: <29f585dd0807211602o2872b367t7d77582ede4a8ae5@mail.gmail.com>

Now that I rethink this, it's obvious how to deduce the answer: Insert a
Print statement in the trigger and let the evidence speak for itself.

A.

On Mon, Jul 21, 2008 at 1:48 PM, Francisco Tapia <fhtapia at gmail.com> wrote:

> IME, it's been the batch.
>
>


From fuller.artful at gmail.com  Wed Jul 23 12:32:32 2008
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Wed, 23 Jul 2008 14:32:32 -0300
Subject: [dba-SQLServer] Covering Indexes
Message-ID: <29f585dd0807231032rc223b8bxd868552d949b86a7@mail.gmail.com>

I have always thought that you should have an index for the PK and every FK,
and perhaps also one or more compound indexes for frequent searches. But
recent reading has given me pause, in particular the topic of covering
indexes to avoid bookmark lookups, and also of the order of columns in an
index. For example, here are the existing indexes on one of my tables:

  Index Columns Included Columns  PK_BESTTrade BESTTrade_ID
 IX_BESTTrade__BSID_PID_Act_BIID_BA_ID BESTSecurity_ID TransactionStatus_ID
Portfolio_ID EstimatedShares
IsActive QuantityExecuted
BESTIdea_ID

BESTAction_ID
 IX_BESTTrade__PID_Act_BAID_BSID_BIID Portfolio_ID TransactionStatus_ID
IsActive SizeEuro
BESTAction_ID EstimatedShares
BESTSecurity_ID QuantityExecuted
BESTIdea_ID
 IX_BESTTrade__PID_BAID_BIID_Act_TSID Portfolio_ID Currency_ID
BESTAction_ID SizeEuro
BESTIdea_ID Consideration
IsActive

TransactionStatus_ID

Given the redundancies (columns repeated in a different order) in the
second, third and fourth indexes listed, I'm wondering whether it might make
more sense to have just one index besides the PK that contains and includes
one instance of each column mentioned. Another way to ask the question is,
does column order in an index matter? Won't the cost analyzer figure out
that it can make use of the index anyway?

Arthur


From nancy.lytle at gmail.com  Wed Jul 23 13:13:46 2008
From: nancy.lytle at gmail.com (Nancy Lytle)
Date: Wed, 23 Jul 2008 13:13:46 -0500
Subject: [dba-SQLServer] Covering Indexes
In-Reply-To: <29f585dd0807231032rc223b8bxd868552d949b86a7@mail.gmail.com>
References: <29f585dd0807231032rc223b8bxd868552d949b86a7@mail.gmail.com>
Message-ID: <BAY134-W42875E726D5BAA967CF00884840@phx.gbl>

Yes, my understaning is that column order does matter.Nancy Lytle N_Lytle at terpalum.umd.edu



 EMAILING FOR THE GREATER GOODJoin me

> Date: Wed, 23 Jul 2008 14:32:32 -0300> From: fuller.artful at gmail.com> To: dba-sqlserver at databaseadvisors.com> Subject: [dba-SQLServer] Covering Indexes> > I have always thought that you should have an index for the PK and every FK,> and perhaps also one or more compound indexes for frequent searches. But> recent reading has given me pause, in particular the topic of covering> indexes to avoid bookmark lookups, and also of the order of columns in an> index. For example, here are the existing indexes on one of my tables:> > Index Columns Included Columns PK_BESTTrade BESTTrade_ID> IX_BESTTrade__BSID_PID_Act_BIID_BA_ID BESTSecurity_ID TransactionStatus_ID> Portfolio_ID EstimatedShares> IsActive QuantityExecuted> BESTIdea_ID> > BESTAction_ID> IX_BESTTrade__PID_Act_BAID_BSID_BIID Portfolio_ID TransactionStatus_ID> IsActive SizeEuro> BESTAction_ID EstimatedShares> BESTSecurity_ID QuantityExecuted> BESTIdea_ID> IX_BESTTrade__PID_BAID_BIID_Act_TSID Portfolio_ID Currency_ID> BESTAction_ID SizeEuro> BESTIdea_ID Consideration> IsActive> > TransactionStatus_ID> > Given the redundancies (columns repeated in a different order) in the> second, third and fourth indexes listed, I'm wondering whether it might make> more sense to have just one index besides the PK that contains and includes> one instance of each column mentioned. Another way to ask the question is,> does column order in an index matter? Won't the cost analyzer figure out> that it can make use of the index anyway?> > Arthur> _______________________________________________> dba-SQLServer mailing list> dba-SQLServer at databaseadvisors.com> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver> http://www.databaseadvisors.com> 

From stuart at lexacorp.com.pg  Wed Jul 23 17:10:14 2008
From: stuart at lexacorp.com.pg (Stuart McLachlan)
Date: Thu, 24 Jul 2008 08:10:14 +1000
Subject: [dba-SQLServer] Covering Indexes
In-Reply-To: <29f585dd0807231032rc223b8bxd868552d949b86a7@mail.gmail.com>
Message-ID: <488838E6.13098.2F6E26DE@stuart.lexacorp.com.pg>

Assume  Three Columns 

1  2  3
A  A  A
A  A  B
A  B  A

An index sorted on columns 1,2,3 says that  AAB (row2) follows AAA

A sort on columns 1,3,2 says requires that ABA (row 3) follows AAA - how can it use the 
index? 



On 23 Jul 2008 at 14:32, Arthur Fuller wrote:

> one instance of each column mentioned. Another way to ask the question is,
> does column order in an index matter? Won't the cost analyzer figure out
> that it can make use of the index anyway?
> 



From fuller.artful at gmail.com  Wed Jul 23 18:57:46 2008
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Wed, 23 Jul 2008 20:57:46 -0300
Subject: [dba-SQLServer] Covering Indexes
In-Reply-To: <488838E6.13098.2F6E26DE@stuart.lexacorp.com.pg>
References: <29f585dd0807231032rc223b8bxd868552d949b86a7@mail.gmail.com>
	<488838E6.13098.2F6E26DE@stuart.lexacorp.com.pg>
Message-ID: <29f585dd0807231657h311dd494oe46ed6344e986647@mail.gmail.com>

Well, I'm no expert, but I do know that the sort follows the index seeks.
The index seeks grab the data, then the sort takes place either in memory if
there's enough or in tempdb if not enough memory, so it still seems to me
that the optimizer and cost analyzer can use the index. The sort is a
subsequent process.

Arthur

On Wed, Jul 23, 2008 at 7:10 PM, Stuart McLachlan <stuart at lexacorp.com.pg>wrote:

> Assume  Three Columns
>
> 1  2  3
> A  A  A
> A  A  B
> A  B  A
>
> An index sorted on columns 1,2,3 says that  AAB (row2) follows AAA
>
> A sort on columns 1,3,2 says requires that ABA (row 3) follows AAA - how
> can it use the
> index?
>


From ab-mi at post3.tele.dk  Fri Jul 25 18:32:30 2008
From: ab-mi at post3.tele.dk (Asger Blond)
Date: Sat, 26 Jul 2008 01:32:30 +0200
Subject: [dba-SQLServer] Covering Indexes
In-Reply-To: <BAY134-W42875E726D5BAA967CF00884840@phx.gbl>
Message-ID: <000001c8eeae$b54be7f0$2101a8c0@AB>

Agree.
Elaborating this:
Planning an index you have to distinguish two separate operations performed
by the query engine: criteria search and data capture.
For criteria search, column order is essential: if you create a compound
index then always place the supposed search-column in front.
For data capture, covering index is essential: a covering index means that
the wanted data can be captured inside the index, not forcing the engine to
make a bookmark lookup to the data pages outside the index.
To make the scenario more fascinating Arthur also mentioned an
index-creature called "included column". This is new to SQL Server 2005: an
included column is added to the leaf level of the index. This means that the
included column will aid the possibility of our index being a "covering
index" for queries, but it will lend no assistance in the search operation.

Conclusion: For compound indexes, always place the supposed search-column in
front. For includes columns, don't expect a performance gain for search
operations, but enjoy a performance plus for data capture.

Asger
-----Oprindelig meddelelse-----
Fra: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] P? vegne af Nancy Lytle
Sendt: 23. juli 2008 20:14
Til: Discussion concerning MS SQL Server
Emne: Re: [dba-SQLServer] Covering Indexes

Yes, my understaning is that column order does matter.Nancy Lytle
N_Lytle at terpalum.umd.edu



 EMAILING FOR THE GREATER GOODJoin me

> Date: Wed, 23 Jul 2008 14:32:32 -0300> From: fuller.artful at gmail.com> To:
dba-sqlserver at databaseadvisors.com> Subject: [dba-SQLServer] Covering
Indexes> > I have always thought that you should have an index for the PK
and every FK,> and perhaps also one or more compound indexes for frequent
searches. But> recent reading has given me pause, in particular the topic of
covering> indexes to avoid bookmark lookups, and also of the order of
columns in an> index. For example, here are the existing indexes on one of
my tables:> > Index Columns Included Columns PK_BESTTrade BESTTrade_ID>
IX_BESTTrade__BSID_PID_Act_BIID_BA_ID BESTSecurity_ID TransactionStatus_ID>
Portfolio_ID EstimatedShares> IsActive QuantityExecuted> BESTIdea_ID> >
BESTAction_ID> IX_BESTTrade__PID_Act_BAID_BSID_BIID Portfolio_ID
TransactionStatus_ID> IsActive SizeEuro> BESTAction_ID EstimatedShares>
BESTSecurity_ID QuantityExecuted> BESTIdea_ID>
IX_BESTTrade__PID_BAID_BIID_Act_TSID Portfolio_ID Currency_ID> BESTAc!
 tion_ID SizeEuro> BESTIdea_ID Consideration> IsActive> >
TransactionStatus_ID> > Given the redundancies (columns repeated in a
different order) in the> second, third and fourth indexes listed, I'm
wondering whether it might make> more sense to have just one index besides
the PK that contains and includes> one instance of each column mentioned.
Another way to ask the question is,> does column order in an index matter?
Won't the cost analyzer figure out> that it can make use of the index
anyway?> > Arthur> _______________________________________________>
dba-SQLServer mailing list> dba-SQLServer at databaseadvisors.com>
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver>
http://www.databaseadvisors.com> 
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com





From fuller.artful at gmail.com  Sat Jul 26 03:19:17 2008
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Sat, 26 Jul 2008 05:19:17 -0300
Subject: [dba-SQLServer] Covering Indexes
In-Reply-To: <000001c8eeae$b54be7f0$2101a8c0@AB>
References: <BAY134-W42875E726D5BAA967CF00884840@phx.gbl>
	<000001c8eeae$b54be7f0$2101a8c0@AB>
Message-ID: <29f585dd0807260119m3a5f9c3la075311ae9da7c1b@mail.gmail.com>

Perhaps you can help me understand the distinction between columns indexed
and columns included. Frankly I don't understand the difference. I could for
example create an index on PK column, and decide to include columns a, b, c.
What does that actually mean?

Am I better off creating separate indexes for a, b and c? Or should I
include them?

Let's suppose that a typical query does Where colA = @colA and colb = @colb
and colC = @colC.

Some of the reading I've done suggests that the index ought to be ordered in
terms of frequency of hits. (i.e. a column called IsActive which is a bit
column should be the last examined) -- this says look for the least
frequency first (Portfolo_ID for example) and then include IsActive.

I dont' yet understand the difference between declaring a column as part of
an index and including a column.

If you have any insights into this distinction they would be most
appreciated.

Thanks!
A.

On Fri, Jul 25, 2008 at 8:32 PM, Asger Blond <ab-mi at post3.tele.dk> wrote:

> Agree.
> Elaborating this:
> Planning an index you have to distinguish two separate operations performed
> by the query engine: criteria search and data capture.
> For criteria search, column order is essential: if you create a compound
> index then always place the supposed search-column in front.
> For data capture, covering index is essential: a covering index means that
> the wanted data can be captured inside the index, not forcing the engine to
> make a bookmark lookup to the data pages outside the index.
> To make the scenario more fascinating Arthur also mentioned an
> index-creature called "included column". This is new to SQL Server 2005: an
> included column is added to the leaf level of the index. This means that
> the
> included column will aid the possibility of our index being a "covering
> index" for queries, but it will lend no assistance in the search operation.
>
> Conclusion: For compound indexes, always place the supposed search-column
> in
> front. For includes columns, don't expect a performance gain for search
> operations, but enjoy a performance plus for data capture.
>
> Asger
> -----Oprindelig meddelelse-----
> Fra: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] P? vegne af Nancy
> Lytle
> Sendt: 23. juli 2008 20:14
> Til: Discussion concerning MS SQL Server
> Emne: Re: [dba-SQLServer] Covering Indexes
>
> Yes, my understaning is that column order does matter.Nancy Lytle
> N_Lytle at terpalum.umd.edu
>
>
>
>  EMAILING FOR THE GREATER GOODJoin me
>
> > Date: Wed, 23 Jul 2008 14:32:32 -0300> From: fuller.artful at gmail.com>
> To:
> dba-sqlserver at databaseadvisors.com> Subject: [dba-SQLServer] Covering
> Indexes> > I have always thought that you should have an index for the PK
> and every FK,> and perhaps also one or more compound indexes for frequent
> searches. But> recent reading has given me pause, in particular the topic
> of
> covering> indexes to avoid bookmark lookups, and also of the order of
> columns in an> index. For example, here are the existing indexes on one of
> my tables:> > Index Columns Included Columns PK_BESTTrade BESTTrade_ID>
> IX_BESTTrade__BSID_PID_Act_BIID_BA_ID BESTSecurity_ID TransactionStatus_ID>
> Portfolio_ID EstimatedShares> IsActive QuantityExecuted> BESTIdea_ID> >
> BESTAction_ID> IX_BESTTrade__PID_Act_BAID_BSID_BIID Portfolio_ID
> TransactionStatus_ID> IsActive SizeEuro> BESTAction_ID EstimatedShares>
> BESTSecurity_ID QuantityExecuted> BESTIdea_ID>
> IX_BESTTrade__PID_BAID_BIID_Act_TSID Portfolio_ID Currency_ID> BESTAc!
>  tion_ID SizeEuro> BESTIdea_ID Consideration> IsActive> >
> TransactionStatus_ID> > Given the redundancies (columns repeated in a
> different order) in the> second, third and fourth indexes listed, I'm
> wondering whether it might make> more sense to have just one index besides
> the PK that contains and includes> one instance of each column mentioned.
> Another way to ask the question is,> does column order in an index matter?
> Won't the cost analyzer figure out> that it can make use of the index
> anyway?> > Arthur> _______________________________________________>
> dba-SQLServer mailing list> dba-SQLServer at databaseadvisors.com>
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver>
> http://www.databaseadvisors.com>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>
>
> _______________________________________________
>  dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>


From ab-mi at post3.tele.dk  Sat Jul 26 06:42:23 2008
From: ab-mi at post3.tele.dk (Asger Blond)
Date: Sat, 26 Jul 2008 13:42:23 +0200
Subject: [dba-SQLServer] Covering Indexes
In-Reply-To: <29f585dd0807260119m3a5f9c3la075311ae9da7c1b@mail.gmail.com>
Message-ID: <000501c8ef14$c0abd450$2101a8c0@AB>

Actually you have tree distinct choices: a composite index containing
multiple columns, several separate one-column indexes, and an index with
included columns.
The choice you make have different impact on read versus write operations.
First let's look at the index-physics:
In an index with included columns the included columns are not stored on the
non-leaf level pages of the index, they are only stored on the leaf level
index pages. Therefore the query engine can't use included columns for
search operations, but it certainly can use them to avoid bookmark lookups.
Avoidance of bookmark lookups is what the term "covering index" is about: If
all the data you are referencing in your query are present in the index,
then the engine can fetch the data from the index itself and don't need to
go to data pages outside the index.
In both a one-column index and a multi-column index the indexed
column-values are present on the leaf level as well as on the non-leaf
level. Therefore the query engine can use the values both for its search and
for its data fetch operations.
The difference between using multiple one-column indexes and using a
composite index with multiple columns is this: In a composite index column
order is crucial, whereas this per definition isn't the case for one-column
indexes. Suppose you have a composite index on column a, b, and c (in that
order) and you then make a query with either 1) WHERE colA = @colA and colB
= @colB and colC = @colC or 2) WHERE colC = @colC and colB = @colB and colA
= @colA. The order of the columns in your condition is of no importance
here: the query engine can effectively make use of the composite index in
both cases. But now suppose that you make a query with a condition not using
colA, i.e. 1) WHERE colB = @colB or 2) WHERE colC = @colC or 3) WHERE colB =
@colB and colC = @colC. For these conditions the query engine can't use the
composite index for its search operation. If instead you had created tree
separate one-column indexes for column a, b, and c, then the engine could
use the relevant indexes.
Then what are the pros for a composite index? If the multi-column condition
in your query adhere to the column order of the composite index, then a
composite index is faster than tree separate indexes, because the engine
only have to traverse one index three, whereas tree separate indexes would
require tree traverses and a subsequent combination of the results. Also if
you do an ORDER BY colA, ColB, colC - then the composite index is by far the
most efficient.
And last: what are the pros for an index with included columns? If some
columns in your query are only used in the SELECT part, never or seldom in
the WHERE or ORDER BY part, then an index including these columns could be
the best choice: the storage engine wouldn't have to write the values on the
index's non-leaf level pages, making the index smaller and not so exposed to
page-splits.

HTH
Asger

PS: I'm just leaving for vacation, visiting my daughter in Geneva, and won't
be reading mails for the next week.

-----Oprindelig meddelelse-----
Fra: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] P? vegne af Arthur
Fuller
Sendt: 26. juli 2008 10:19
Til: Discussion concerning MS SQL Server
Emne: Re: [dba-SQLServer] Covering Indexes

Perhaps you can help me understand the distinction between columns indexed
and columns included. Frankly I don't understand the difference. I could for
example create an index on PK column, and decide to include columns a, b, c.
What does that actually mean?

Am I better off creating separate indexes for a, b and c? Or should I
include them?

Let's suppose that a typical query does Where colA = @colA and colb = @colb
and colC = @colC.

Some of the reading I've done suggests that the index ought to be ordered in
terms of frequency of hits. (i.e. a column called IsActive which is a bit
column should be the last examined) -- this says look for the least
frequency first (Portfolo_ID for example) and then include IsActive.

I dont' yet understand the difference between declaring a column as part of
an index and including a column.

If you have any insights into this distinction they would be most
appreciated.

Thanks!
A.

On Fri, Jul 25, 2008 at 8:32 PM, Asger Blond <ab-mi at post3.tele.dk> wrote:

> Agree.
> Elaborating this:
> Planning an index you have to distinguish two separate operations
performed
> by the query engine: criteria search and data capture.
> For criteria search, column order is essential: if you create a compound
> index then always place the supposed search-column in front.
> For data capture, covering index is essential: a covering index means that
> the wanted data can be captured inside the index, not forcing the engine
to
> make a bookmark lookup to the data pages outside the index.
> To make the scenario more fascinating Arthur also mentioned an
> index-creature called "included column". This is new to SQL Server 2005:
an
> included column is added to the leaf level of the index. This means that
> the
> included column will aid the possibility of our index being a "covering
> index" for queries, but it will lend no assistance in the search
operation.
>
> Conclusion: For compound indexes, always place the supposed search-column
> in
> front. For includes columns, don't expect a performance gain for search
> operations, but enjoy a performance plus for data capture.
>
> Asger
> -----Oprindelig meddelelse-----
> Fra: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] P? vegne af Nancy
> Lytle
> Sendt: 23. juli 2008 20:14
> Til: Discussion concerning MS SQL Server
> Emne: Re: [dba-SQLServer] Covering Indexes
>
> Yes, my understaning is that column order does matter.Nancy Lytle
> N_Lytle at terpalum.umd.edu
>
>
>
>  EMAILING FOR THE GREATER GOODJoin me
>
> > Date: Wed, 23 Jul 2008 14:32:32 -0300> From: fuller.artful at gmail.com>
> To:
> dba-sqlserver at databaseadvisors.com> Subject: [dba-SQLServer] Covering
> Indexes> > I have always thought that you should have an index for the PK
> and every FK,> and perhaps also one or more compound indexes for frequent
> searches. But> recent reading has given me pause, in particular the topic
> of
> covering> indexes to avoid bookmark lookups, and also of the order of
> columns in an> index. For example, here are the existing indexes on one of
> my tables:> > Index Columns Included Columns PK_BESTTrade BESTTrade_ID>
> IX_BESTTrade__BSID_PID_Act_BIID_BA_ID BESTSecurity_ID
TransactionStatus_ID>
> Portfolio_ID EstimatedShares> IsActive QuantityExecuted> BESTIdea_ID> >
> BESTAction_ID> IX_BESTTrade__PID_Act_BAID_BSID_BIID Portfolio_ID
> TransactionStatus_ID> IsActive SizeEuro> BESTAction_ID EstimatedShares>
> BESTSecurity_ID QuantityExecuted> BESTIdea_ID>
> IX_BESTTrade__PID_BAID_BIID_Act_TSID Portfolio_ID Currency_ID> BESTAc!
>  tion_ID SizeEuro> BESTIdea_ID Consideration> IsActive> >
> TransactionStatus_ID> > Given the redundancies (columns repeated in a
> different order) in the> second, third and fourth indexes listed, I'm
> wondering whether it might make> more sense to have just one index besides
> the PK that contains and includes> one instance of each column mentioned.
> Another way to ask the question is,> does column order in an index matter?
> Won't the cost analyzer figure out> that it can make use of the index
> anyway?> > Arthur> _______________________________________________>
> dba-SQLServer mailing list> dba-SQLServer at databaseadvisors.com>
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver>
> http://www.databaseadvisors.com>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>
>
> _______________________________________________
>  dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com





From fhtapia at gmail.com  Sat Jul 26 10:08:55 2008
From: fhtapia at gmail.com (Francisco Tapia)
Date: Sat, 26 Jul 2008 08:08:55 -0700
Subject: [dba-SQLServer] Covering Indexes
In-Reply-To: <000501c8ef14$c0abd450$2101a8c0@AB>
References: <000501c8ef14$c0abd450$2101a8c0@AB>
Message-ID: <C1A9708F-C238-4E59-AB00-04E833C74C23@gmail.com>

This was an excellent explanation of the different concepts for  
indexes thanks Asger!

Sent from my iPod

On Jul 26, 2008, at 4:42 AM, "Asger Blond" <ab-mi at post3.tele.dk> wrote:

> Actually you have tree distinct choices: a composite index containing
> multiple columns, several separate one-column indexes, and an index  
> with
> included columns.
> The choice you make have different impact on read versus write  
> operations.
> First let's look at the index-physics:
> In an index with included columns the included columns are not  
> stored on the
> non-leaf level pages of the index, they are only stored on the leaf  
> level
> index pages. Therefore the query engine can't use included columns for
> search operations, but it certainly can use them to avoid bookmark  
> lookups.
> Avoidance of bookmark lookups is what the term "covering index" is  
> about: If
> all the data you are referencing in your query are present in the  
> index,
> then the engine can fetch the data from the index itself and don't  
> need to
> go to data pages outside the index.
> In both a one-column index and a multi-column index the indexed
> column-values are present on the leaf level as well as on the non-leaf
> level. Therefore the query engine can use the values both for its  
> search and
> for its data fetch operations.
> The difference between using multiple one-column indexes and using a
> composite index with multiple columns is this: In a composite index  
> column
> order is crucial, whereas this per definition isn't the case for one- 
> column
> indexes. Suppose you have a composite index on column a, b, and c  
> (in that
> order) and you then make a query with either 1) WHERE colA = @colA  
> and colB
> = @colB and colC = @colC or 2) WHERE colC = @colC and colB = @colB  
> and colA
> = @colA. The order of the columns in your condition is of no  
> importance
> here: the query engine can effectively make use of the composite  
> index in
> both cases. But now suppose that you make a query with a condition  
> not using
> colA, i.e. 1) WHERE colB = @colB or 2) WHERE colC = @colC or 3)  
> WHERE colB =
> @colB and colC = @colC. For these conditions the query engine can't  
> use the
> composite index for its search operation. If instead you had created  
> tree
> separate one-column indexes for column a, b, and c, then the engine  
> could
> use the relevant indexes.
> Then what are the pros for a composite index? If the multi-column  
> condition
> in your query adhere to the column order of the composite index,  
> then a
> composite index is faster than tree separate indexes, because the  
> engine
> only have to traverse one index three, whereas tree separate indexes  
> would
> require tree traverses and a subsequent combination of the results.  
> Also if
> you do an ORDER BY colA, ColB, colC - then the composite index is by  
> far the
> most efficient.
> And last: what are the pros for an index with included columns? If  
> some
> columns in your query are only used in the SELECT part, never or  
> seldom in
> the WHERE or ORDER BY part, then an index including these columns  
> could be
> the best choice: the storage engine wouldn't have to write the  
> values on the
> index's non-leaf level pages, making the index smaller and not so  
> exposed to
> page-splits.
>
> HTH
> Asger
>
> PS: I'm just leaving for vacation, visiting my daughter in Geneva,  
> and won't
> be reading mails for the next week.
>
> -----Oprindelig meddelelse-----
> Fra: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] P? vegne af Arth 
> ur
> Fuller
> Sendt: 26. juli 2008 10:19
> Til: Discussion concerning MS SQL Server
> Emne: Re: [dba-SQLServer] Covering Indexes
>
> Perhaps you can help me understand the distinction between columns  
> indexed
> and columns included. Frankly I don't understand the difference. I  
> could for
> example create an index on PK column, and decide to include columns  
> a, b, c.
> What does that actually mean?
>
> Am I better off creating separate indexes for a, b and c? Or should I
> include them?
>
> Let's suppose that a typical query does Where colA = @colA and colb  
> = @colb
> and colC = @colC.
>
> Some of the reading I've done suggests that the index ought to be  
> ordered in
> terms of frequency of hits. (i.e. a column called IsActive which is  
> a bit
> column should be the last examined) -- this says look for the least
> frequency first (Portfolo_ID for example) and then include IsActive.
>
> I dont' yet understand the difference between declaring a column as  
> part of
> an index and including a column.
>
> If you have any insights into this distinction they would be most
> appreciated.
>
> Thanks!
> A.
>
> On Fri, Jul 25, 2008 at 8:32 PM, Asger Blond <ab-mi at post3.tele.dk>  
> wrote:
>
>> Agree.
>> Elaborating this:
>> Planning an index you have to distinguish two separate operations
> performed
>> by the query engine: criteria search and data capture.
>> For criteria search, column order is essential: if you create a  
>> compound
>> index then always place the supposed search-column in front.
>> For data capture, covering index is essential: a covering index  
>> means that
>> the wanted data can be captured inside the index, not forcing the  
>> engine
> to
>> make a bookmark lookup to the data pages outside the index.
>> To make the scenario more fascinating Arthur also mentioned an
>> index-creature called "included column". This is new to SQL Server  
>> 2005:
> an
>> included column is added to the leaf level of the index. This means  
>> that
>> the
>> included column will aid the possibility of our index being a  
>> "covering
>> index" for queries, but it will lend no assistance in the search
> operation.
>>
>> Conclusion: For compound indexes, always place the supposed search- 
>> column
>> in
>> front. For includes columns, don't expect a performance gain for  
>> search
>> operations, but enjoy a performance plus for data capture.
>>
>> Asger
>> -----Oprindelig meddelelse-----
>> Fra: dba-sqlserver-bounces at databaseadvisors.com
>> [mailto:dba-sqlserver-bounces at databaseadvisors.com] P? vegne af Na 
>> ncy
>> Lytle
>> Sendt: 23. juli 2008 20:14
>> Til: Discussion concerning MS SQL Server
>> Emne: Re: [dba-SQLServer] Covering Indexes
>>
>> Yes, my understaning is that column order does matter.Nancy Lytle
>> N_Lytle at terpalum.umd.edu
>>
>>
>>
>> EMAILING FOR THE GREATER GOODJoin me
>>
>>> Date: Wed, 23 Jul 2008 14:32:32 -0300> From:  
>>> fuller.artful at gmail.com>
>> To:
>> dba-sqlserver at databaseadvisors.com> Subject: [dba-SQLServer] Covering
>> Indexes> > I have always thought that you should have an index for  
>> the PK
>> and every FK,> and perhaps also one or more compound indexes for  
>> frequent
>> searches. But> recent reading has given me pause, in particular the  
>> topic
>> of
>> covering> indexes to avoid bookmark lookups, and also of the order of
>> columns in an> index. For example, here are the existing indexes on  
>> one of
>> my tables:> > Index Columns Included Columns PK_BESTTrade  
>> BESTTrade_ID>
>> IX_BESTTrade__BSID_PID_Act_BIID_BA_ID BESTSecurity_ID
> TransactionStatus_ID>
>> Portfolio_ID EstimatedShares> IsActive QuantityExecuted>  
>> BESTIdea_ID> >
>> BESTAction_ID> IX_BESTTrade__PID_Act_BAID_BSID_BIID Portfolio_ID
>> TransactionStatus_ID> IsActive SizeEuro> BESTAction_ID  
>> EstimatedShares>
>> BESTSecurity_ID QuantityExecuted> BESTIdea_ID>
>> IX_BESTTrade__PID_BAID_BIID_Act_TSID Portfolio_ID Currency_ID>  
>> BESTAc!
>> tion_ID SizeEuro> BESTIdea_ID Consideration> IsActive> >
>> TransactionStatus_ID> > Given the redundancies (columns repeated in a
>> different order) in the> second, third and fourth indexes listed, I'm
>> wondering whether it might make> more sense to have just one index  
>> besides
>> the PK that contains and includes> one instance of each column  
>> mentioned.
>> Another way to ask the question is,> does column order in an index  
>> matter?
>> Won't the cost analyzer figure out> that it can make use of the index
>> anyway?> > Arthur> _______________________________________________>
>> dba-SQLServer mailing list> dba-SQLServer at databaseadvisors.com>
>> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver>
>> http://www.databaseadvisors.com>
>> _______________________________________________
>> dba-SQLServer mailing list
>> dba-SQLServer at databaseadvisors.com
>> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>> http://www.databaseadvisors.com
>>
>>
>>
>> _______________________________________________
>> dba-SQLServer mailing list
>> dba-SQLServer at databaseadvisors.com
>> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>> http://www.databaseadvisors.com
>>
>>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>



From fuller.artful at gmail.com  Tue Jul 29 07:39:25 2008
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Tue, 29 Jul 2008 09:39:25 -0300
Subject: [dba-SQLServer] Streams
Message-ID: <29f585dd0807290539u72871d84n583f9cf595b38dd2@mail.gmail.com>

Please excuse the double post, but I'm unsure how to attack this. Also,
please forgive my ignorance on this topic.

As I understand it, a stream is essentially a file in memory rather than on
disk (although I suppose that it could overflow available ram and end up in
virtual memory, on disk).

Although I have been doing some reading on the subject, I don't think that I
grasp the essentials yet. Imagining a file in memory that is hooked to via a
recordset, how does one peel off the records from the stream and write them
to disk? I guess the important question here is, how do I peel the incoming
records off, as in a FIFO stack operation? A secondary and unimportant (for
work purposes) question is, how is a stream such as the input from BBC or
CBC radio structured? Is the whole stream one giant record or is it somehow
structured into many records?

In the case at hand, the stream of interest is a Bloomberg stock prices
stream.

All these questions arise due to the fact that our star c#/c++ programmer
had a stroke two days ago, and until we hire someone I have to go through
his stuff and attempt to comprehend it. My job definition just got a lot
bigger.

TIA,
Arthur


From dwaters at usinternet.com  Wed Jul 30 16:36:03 2008
From: dwaters at usinternet.com (Dan Waters)
Date: Wed, 30 Jul 2008 16:36:03 -0500
Subject: [dba-SQLServer] Must Relating Fields Have Different Names?
Message-ID: <187844F5BA2A4A25A2A70E43E8404E69@danwaters>

I just went through my first shot at upsizing an mdb using SSMA.  SSMA
changed all the foreign key names to something different.  In Access, I've
been keeping the Foreign Key field names identical to the field it is
related to for ease of programming.  I often need to be explicit about which
table the field is in, but not a big deal.

What would be a big deal for me is to change all the foreign keys to unique
names!  Then, instead of 'MainID = " & txtMainID, txtMainID could be equal
to a variety of different field names.  

Are different names required in SQL Server?  Or is SSMA just trying to be
'helpful'?

Thanks!
Dan




From ssharkins at gmail.com  Wed Jul 30 16:45:38 2008
From: ssharkins at gmail.com (Susan Harkins)
Date: Wed, 30 Jul 2008 17:45:38 -0400
Subject: [dba-SQLServer] Must Relating Fields Have Different Names?
References: <187844F5BA2A4A25A2A70E43E8404E69@danwaters>
Message-ID: <057901c8f28d$9d00b940$2f8601c7@SusanOne>

Did you get a warning? Have you checked the Assessment Report to see if 
there's an explanation?

When you say foreign key names, you mean the foreign key constraint name?

Susan H.



>I just went through my first shot at upsizing an mdb using SSMA.  SSMA
> changed all the foreign key names to something different.  In Access, I've
> been keeping the Foreign Key field names identical to the field it is
> related to for ease of programming.  I often need to be explicit about 
> which
> table the field is in, but not a big deal.
>
> What would be a big deal for me is to change all the foreign keys to 
> unique
> names!  Then, instead of 'MainID = " & txtMainID, txtMainID could be equal
> to a variety of different field names.
>
> Are different names required in SQL Server?  Or is SSMA just trying to be
> 'helpful'?
>
> Thanks!
> Dan
>
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
> 



From Elizabeth.J.Doering at wellsfargo.com  Wed Jul 30 16:48:02 2008
From: Elizabeth.J.Doering at wellsfargo.com (Elizabeth.J.Doering at wellsfargo.com)
Date: Wed, 30 Jul 2008 16:48:02 -0500
Subject: [dba-SQLServer] Must Relating Fields Have Different Names?
References: <187844F5BA2A4A25A2A70E43E8404E69@danwaters>
Message-ID: <AF469F21946F6442B5D4FF79AB854D64769E70@msgswbmnmsp45.wellsfargo.com>

Like you, I believe in naming foreign keys the same as the primary key
in the primary table.  For example, the table Activity has primary key
ActivityID and in the table ActivityPermission you will find ActivityID
as the foreign key that relates back to Activity.ActivityID.)  SQL
Server 2005 certainly has no problem.  

I suspect 'helpfulness'.   

Liz 


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Dan
Waters
Sent: Wednesday, July 30, 2008 4:36 PM
To: SQL Server List
Subject: [dba-SQLServer] Must Relating Fields Have Different Names?

I just went through my first shot at upsizing an mdb using SSMA.  SSMA
changed all the foreign key names to something different.  In Access,
I've been keeping the Foreign Key field names identical to the field it
is related to for ease of programming.  I often need to be explicit
about which table the field is in, but not a big deal.

What would be a big deal for me is to change all the foreign keys to
unique names!  Then, instead of 'MainID = " & txtMainID, txtMainID could
be equal to a variety of different field names.  

Are different names required in SQL Server?  Or is SSMA just trying to
be 'helpful'?

Thanks!
Dan


_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com
 

 
 
This message may contain confidential and/or privileged information. If
you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose, or take any action based on
this message or any information herein. If you have received this
message in error, please advise the sender immediately by reply e-mail
and delete this message. Thank you for your cooperation.






From dwaters at usinternet.com  Wed Jul 30 17:07:34 2008
From: dwaters at usinternet.com (Dan Waters)
Date: Wed, 30 Jul 2008 17:07:34 -0500
Subject: [dba-SQLServer] Must Relating Fields Have Different Names?
In-Reply-To: <057901c8f28d$9d00b940$2f8601c7@SusanOne>
References: <187844F5BA2A4A25A2A70E43E8404E69@danwaters>
	<057901c8f28d$9d00b940$2f8601c7@SusanOne>
Message-ID: <30AC0BEE89DA4FF1B10DDBF71076679A@danwaters>

Susan & Liz

I looked at one of the affected tables in SQL, and it was the FK constraint
name, which I can change.  SSMA also created an extra index, which I can
delete.  I've only got 7 of these so I can carry on!

I got a warning for each of these in the SSMA Report, but it didn't explain
why it was changing the Foreign Key constraint name.

Thanks!
Dan

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Susan
Harkins
Sent: Wednesday, July 30, 2008 4:46 PM
To: Discussion concerning MS SQL Server
Subject: Re: [dba-SQLServer] Must Relating Fields Have Different Names?

Did you get a warning? Have you checked the Assessment Report to see if 
there's an explanation?

When you say foreign key names, you mean the foreign key constraint name?

Susan H.



>I just went through my first shot at upsizing an mdb using SSMA.  SSMA
> changed all the foreign key names to something different.  In Access, I've
> been keeping the Foreign Key field names identical to the field it is
> related to for ease of programming.  I often need to be explicit about 
> which
> table the field is in, but not a big deal.
>
> What would be a big deal for me is to change all the foreign keys to 
> unique
> names!  Then, instead of 'MainID = " & txtMainID, txtMainID could be equal
> to a variety of different field names.
>
> Are different names required in SQL Server?  Or is SSMA just trying to be
> 'helpful'?
>
> Thanks!
> Dan
>
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
> 

_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com



From ssharkins at gmail.com  Wed Jul 30 17:20:58 2008
From: ssharkins at gmail.com (Susan Harkins)
Date: Wed, 30 Jul 2008 18:20:58 -0400
Subject: [dba-SQLServer] Must Relating Fields Have Different Names?
References: <187844F5BA2A4A25A2A70E43E8404E69@danwaters><057901c8f28d$9d00b940$2f8601c7@SusanOne>
	<30AC0BEE89DA4FF1B10DDBF71076679A@danwaters>
Message-ID: <003501c8f292$8d032640$2f8601c7@SusanOne>

If you figure it out, I'd like to know. I'm writing about upsizing right 
now, but I haven't run into that one before.

Susan H.


> Susan & Liz
>
> I looked at one of the affected tables in SQL, and it was the FK 
> constraint
> name, which I can change.  SSMA also created an extra index, which I can
> delete.  I've only got 7 of these so I can carry on!
>
> I got a warning for each of these in the SSMA Report, but it didn't 
> explain
> why it was changing the Foreign Key constraint name.



From dwaters at usinternet.com  Wed Jul 30 18:32:44 2008
From: dwaters at usinternet.com (Dan Waters)
Date: Wed, 30 Jul 2008 18:32:44 -0500
Subject: [dba-SQLServer] Must Relating Fields Have Different Names?
In-Reply-To: <003501c8f292$8d032640$2f8601c7@SusanOne>
References: <187844F5BA2A4A25A2A70E43E8404E69@danwaters><057901c8f28d$9d00b940$2f8601c7@SusanOne><30AC0BEE89DA4FF1B10DDBF71076679A@danwaters>
	<003501c8f292$8d032640$2f8601c7@SusanOne>
Message-ID: <F1F4BB8A51B141B9A7699F886E57F9BD@danwaters>

Have you been using SSMA?

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Susan
Harkins
Sent: Wednesday, July 30, 2008 5:21 PM
To: Discussion concerning MS SQL Server
Subject: Re: [dba-SQLServer] Must Relating Fields Have Different Names?

If you figure it out, I'd like to know. I'm writing about upsizing right 
now, but I haven't run into that one before.

Susan H.


> Susan & Liz
>
> I looked at one of the affected tables in SQL, and it was the FK 
> constraint
> name, which I can change.  SSMA also created an extra index, which I can
> delete.  I've only got 7 of these so I can carry on!
>
> I got a warning for each of these in the SSMA Report, but it didn't 
> explain
> why it was changing the Foreign Key constraint name.

_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com



From ssharkins at gmail.com  Wed Jul 30 18:35:32 2008
From: ssharkins at gmail.com (Susan Harkins)
Date: Wed, 30 Jul 2008 19:35:32 -0400
Subject: [dba-SQLServer] Must Relating Fields Have Different Names?
References: <187844F5BA2A4A25A2A70E43E8404E69@danwaters><057901c8f28d$9d00b940$2f8601c7@SusanOne><30AC0BEE89DA4FF1B10DDBF71076679A@danwaters><003501c8f292$8d032640$2f8601c7@SusanOne>
	<F1F4BB8A51B141B9A7699F886E57F9BD@danwaters>
Message-ID: <009101c8f29c$f77418e0$2f8601c7@SusanOne>

Yes. 

Susan H. 


> Have you been using SSMA?
> 



From dwaters at usinternet.com  Wed Jul 30 18:43:11 2008
From: dwaters at usinternet.com (Dan Waters)
Date: Wed, 30 Jul 2008 18:43:11 -0500
Subject: [dba-SQLServer] Must Relating Fields Have Different Names?
In-Reply-To: <009101c8f29c$f77418e0$2f8601c7@SusanOne>
References: <187844F5BA2A4A25A2A70E43E8404E69@danwaters><057901c8f28d$9d00b940$2f8601c7@SusanOne><30AC0BEE89DA4FF1B10DDBF71076679A@danwaters><003501c8f292$8d032640$2f8601c7@SusanOne><F1F4BB8A51B141B9A7699F886E57F9BD@danwaters>
	<009101c8f29c$f77418e0$2f8601c7@SusanOne>
Message-ID: <97C4A763D2544697B9204160CB9AFDF9@danwaters>

Ok I deserved that.

SSMA says that queries are upsized.  Any luck/problems with that?

Dan

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Susan
Harkins
Sent: Wednesday, July 30, 2008 6:36 PM
To: Discussion concerning MS SQL Server
Subject: Re: [dba-SQLServer] Must Relating Fields Have Different Names?

Yes. 

Susan H. 


> Have you been using SSMA?
> 

_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com



From ssharkins at gmail.com  Wed Jul 30 18:52:43 2008
From: ssharkins at gmail.com (Susan Harkins)
Date: Wed, 30 Jul 2008 19:52:43 -0400
Subject: [dba-SQLServer] Must Relating Fields Have Different Names?
References: <187844F5BA2A4A25A2A70E43E8404E69@danwaters><057901c8f28d$9d00b940$2f8601c7@SusanOne><30AC0BEE89DA4FF1B10DDBF71076679A@danwaters><003501c8f292$8d032640$2f8601c7@SusanOne><F1F4BB8A51B141B9A7699F886E57F9BD@danwaters><009101c8f29c$f77418e0$2f8601c7@SusanOne>
	<97C4A763D2544697B9204160CB9AFDF9@danwaters>
Message-ID: <00e501c8f29f$a4b3d570$2f8601c7@SusanOne>

I'm lost. :) I think maybe I responded to the wrong thread????

Susan H. 


> Ok I deserved that.
> 
> SSMA says that queries are upsized.  Any luck/problems with that?
> 
> Dan

> 
> Yes. 
> 
> Susan H. 
> 
> 
>> Have you been using SSMA?