From ssharkins at gmail.com  Wed Sep  3 09:02:17 2014
From: ssharkins at gmail.com (Susan Harkins)
Date: Wed, 3 Sep 2014 10:02:17 -0400
Subject: [dba-SQLServer] Fwd: SQL Server Primary Key
In-Reply-To: <a559a5ccc1e1adfdad82e554e150ec95@origin01.techrepublic.com>
References: <a559a5ccc1e1adfdad82e554e150ec95@origin01.techrepublic.com>
Message-ID: <CA++Sg+dGVw+eJn9i7fJ=cy26SRX_Z_tZYo7ROJ+oJk3ds=2CAg@mail.gmail.com>

This is from a reader -- seriously over my head. Anyone want to offer some
advice?

Susan H.


On Wed, Sep 3, 2014 at 4:02 AM, Phillip Smith <phillip at creamcow.com> wrote:

> Hi Susan,
> Just reading your post regarding using the right Primary Key. I'm building
> a rehouse to store telephone data. Each phone record can be uniquely
> identified by the DateTime2(7) start time of the call because each record
> is guaranteed to be created in a different 100 nano second window. There
> are 100 million records. The main way to view data is chronological order.
> I'm trying to decide whether to use the CallStart datetime2(7) field for
> the primary key. I can cluster on this key and join to my bridging tables
> using this key. Or should I crate a CallId (Bigint) that encodes the
> datetim, Maybe in yymmddhhmmssnnnnnnn format. You have stated on your post
> that there is an overhead to using Datetime type as the primary key. Is
> this true for my scenario?
> Best regards
>
> Phillip
>

From gustav at cactus.dk  Wed Sep  3 09:08:45 2014
From: gustav at cactus.dk (Gustav Brock)
Date: Wed, 3 Sep 2014 14:08:45 +0000
Subject: [dba-SQLServer] Fwd: SQL Server Primary Key
In-Reply-To: <CA++Sg+dGVw+eJn9i7fJ=cy26SRX_Z_tZYo7ROJ+oJk3ds=2CAg@mail.gmail.com>
References: <a559a5ccc1e1adfdad82e554e150ec95@origin01.techrepublic.com>
	<CA++Sg+dGVw+eJn9i7fJ=cy26SRX_Z_tZYo7ROJ+oJk3ds=2CAg@mail.gmail.com>
Message-ID: <8f90a6b3b9184ef1a11ade0b50b7ee6a@AMSPR06MB357.eurprd06.prod.outlook.com>

Hi Susan

It sounds like a log table. Does he need a PK at all?
A unique index on the call start field should do it.

/gustav

-----Oprindelig meddelelse-----
Fra: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] P? vegne af Susan Harkins
Sendt: 3. september 2014 16:02
Til: Discussion concerning MS SQL Server
Emne: [dba-SQLServer] Fwd: SQL Server Primary Key

This is from a reader -- seriously over my head. Anyone want to offer some advice?

Susan H.


On Wed, Sep 3, 2014 at 4:02 AM, Phillip Smith <phillip at creamcow.com> wrote:

> Hi Susan,
> Just reading your post regarding using the right Primary Key. I'm 
> building a rehouse to store telephone data. Each phone record can be 
> uniquely identified by the DateTime2(7) start time of the call because 
> each record is guaranteed to be created in a different 100 nano second 
> window. There are 100 million records. The main way to view data is chronological order.
> I'm trying to decide whether to use the CallStart datetime2(7) field 
> for the primary key. I can cluster on this key and join to my bridging 
> tables using this key. Or should I crate a CallId (Bigint) that 
> encodes the datetim, Maybe in yymmddhhmmssnnnnnnn format. You have 
> stated on your post that there is an overhead to using Datetime type 
> as the primary key. Is this true for my scenario?
> Best regards
>
> Phillip 



From ssharkins at gmail.com  Wed Sep  3 09:11:52 2014
From: ssharkins at gmail.com (Susan Harkins)
Date: Wed, 3 Sep 2014 10:11:52 -0400
Subject: [dba-SQLServer] Fwd: SQL Server Primary Key
In-Reply-To: <8f90a6b3b9184ef1a11ade0b50b7ee6a@AMSPR06MB357.eurprd06.prod.outlook.com>
References: <a559a5ccc1e1adfdad82e554e150ec95@origin01.techrepublic.com>
	<CA++Sg+dGVw+eJn9i7fJ=cy26SRX_Z_tZYo7ROJ+oJk3ds=2CAg@mail.gmail.com>
	<8f90a6b3b9184ef1a11ade0b50b7ee6a@AMSPR06MB357.eurprd06.prod.outlook.com>
Message-ID: <CA++Sg+eC++u+uvcgfGiDJarQre1i75CnaSNLjgCTXNv=nJ7vbA@mail.gmail.com>

I don't know -- that's why I'm asking you guys! That's some keen insight --
you might be right!

Susan H.


On Wed, Sep 3, 2014 at 10:08 AM, Gustav Brock <gustav at cactus.dk> wrote:

> Hi Susan
>
> It sounds like a log table. Does he need a PK at all?
> A unique index on the call start field should do it.
>
> /gustav
>
> -----Oprindelig meddelelse-----
> Fra: dba-sqlserver-bounces at databaseadvisors.com [mailto:
> dba-sqlserver-bounces at databaseadvisors.com] P? vegne af Susan Harkins
> Sendt: 3. september 2014 16:02
> Til: Discussion concerning MS SQL Server
> Emne: [dba-SQLServer] Fwd: SQL Server Primary Key
>
> This is from a reader -- seriously over my head. Anyone want to offer some
> advice?
>
> Susan H.
>
>
> On Wed, Sep 3, 2014 at 4:02 AM, Phillip Smith <phillip at creamcow.com>
> wrote:
>
> > Hi Susan,
> > Just reading your post regarding using the right Primary Key. I'm
> > building a rehouse to store telephone data. Each phone record can be
> > uniquely identified by the DateTime2(7) start time of the call because
> > each record is guaranteed to be created in a different 100 nano second
> > window. There are 100 million records. The main way to view data is
> chronological order.
> > I'm trying to decide whether to use the CallStart datetime2(7) field
> > for the primary key. I can cluster on this key and join to my bridging
> > tables using this key. Or should I crate a CallId (Bigint) that
> > encodes the datetim, Maybe in yymmddhhmmssnnnnnnn format. You have
> > stated on your post that there is an overhead to using Datetime type
> > as the primary key. Is this true for my scenario?
> > Best regards
> >
> > Phillip
>
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>

From df.waters at outlook.com  Wed Sep  3 09:14:01 2014
From: df.waters at outlook.com (Dan Waters)
Date: Wed, 3 Sep 2014 09:14:01 -0500
Subject: [dba-SQLServer] Fwd: SQL Server Primary Key
In-Reply-To: <CA++Sg+dGVw+eJn9i7fJ=cy26SRX_Z_tZYo7ROJ+oJk3ds=2CAg@mail.gmail.com>
References: <a559a5ccc1e1adfdad82e554e150ec95@origin01.techrepublic.com>
	<CA++Sg+dGVw+eJn9i7fJ=cy26SRX_Z_tZYo7ROJ+oJk3ds=2CAg@mail.gmail.com>
Message-ID: <BLU176-DS4D72DC3874C9A6692B36EF6C40@phx.gbl>

Hi Susan,

What he is talking about, in effect, is using a time value as a primary key.
He says that each time value that would be [automatically] entered into a
database when a new record is create would always be different by at least
100 nanoseconds.

It looks like he might be taking data from one database and using it to
create a new database that is specifically designed for telephone data
analysis (a rather specialized activity).  

He doesn't say what the original database primary key is, so we don't know
why he wants to use a time value instead.  

If I was doing something like this I would certainly use the original
primary key (unless that key has a problem).  But without that key, then
using the time value like he's describing sounds like a reasonable
alternative.

I would not use a time value as a primary key unless I had to.  I always use
autonumbers in Access, or in SQL Server I use the primary key set up as an
integer with an identity, seed = 1, and increment = 1 (this ends up working
just like an autonumber in Access.

So, for your app I'd suggest sticking with Autonumbers for primary keys.

Good Luck!
Dan

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Susan
Harkins
Sent: Wednesday, September 03, 2014 9:02 AM
To: Discussion concerning MS SQL Server
Subject: [dba-SQLServer] Fwd: SQL Server Primary Key

This is from a reader -- seriously over my head. Anyone want to offer some
advice?

Susan H.


On Wed, Sep 3, 2014 at 4:02 AM, Phillip Smith <phillip at creamcow.com> wrote:

> Hi Susan,
> Just reading your post regarding using the right Primary Key. I'm 
> building a rehouse to store telephone data. Each phone record can be 
> uniquely identified by the DateTime2(7) start time of the call because 
> each record is guaranteed to be created in a different 100 nano second 
> window. There are 100 million records. The main way to view data is
chronological order.
> I'm trying to decide whether to use the CallStart datetime2(7) field 
> for the primary key. I can cluster on this key and join to my bridging 
> tables using this key. Or should I crate a CallId (Bigint) that 
> encodes the datetim, Maybe in yymmddhhmmssnnnnnnn format. You have 
> stated on your post that there is an overhead to using Datetime type 
> as the primary key. Is this true for my scenario?
> Best regards
>
> Phillip
>
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com



From paul.hartland at googlemail.com  Wed Sep  3 09:15:30 2014
From: paul.hartland at googlemail.com (Paul Hartland)
Date: Wed, 3 Sep 2014 15:15:30 +0100
Subject: [dba-SQLServer] Fwd: SQL Server Primary Key
In-Reply-To: <CA++Sg+eC++u+uvcgfGiDJarQre1i75CnaSNLjgCTXNv=nJ7vbA@mail.gmail.com>
References: <a559a5ccc1e1adfdad82e554e150ec95@origin01.techrepublic.com>
	<CA++Sg+dGVw+eJn9i7fJ=cy26SRX_Z_tZYo7ROJ+oJk3ds=2CAg@mail.gmail.com>
	<8f90a6b3b9184ef1a11ade0b50b7ee6a@AMSPR06MB357.eurprd06.prod.outlook.com>
	<CA++Sg+eC++u+uvcgfGiDJarQre1i75CnaSNLjgCTXNv=nJ7vbA@mail.gmail.com>
Message-ID: <CALGJE96K3xw5jt7FWFRsuVHnR--h43tGX9OwTHFdf55b9wVm4Q@mail.gmail.com>

I would probably just unique index on telephone number and datetime field,
definitely looks like a log table as was involved in helping a friend a
couple of years back who's company helps look after O2...

Paul


On 3 September 2014 15:11, Susan Harkins <ssharkins at gmail.com> wrote:

> I don't know -- that's why I'm asking you guys! That's some keen insight --
> you might be right!
>
> Susan H.
>
>
> On Wed, Sep 3, 2014 at 10:08 AM, Gustav Brock <gustav at cactus.dk> wrote:
>
> > Hi Susan
> >
> > It sounds like a log table. Does he need a PK at all?
> > A unique index on the call start field should do it.
> >
> > /gustav
> >
> > -----Oprindelig meddelelse-----
> > Fra: dba-sqlserver-bounces at databaseadvisors.com [mailto:
> > dba-sqlserver-bounces at databaseadvisors.com] P? vegne af Susan Harkins
> > Sendt: 3. september 2014 16:02
> > Til: Discussion concerning MS SQL Server
> > Emne: [dba-SQLServer] Fwd: SQL Server Primary Key
> >
> > This is from a reader -- seriously over my head. Anyone want to offer
> some
> > advice?
> >
> > Susan H.
> >
> >
> > On Wed, Sep 3, 2014 at 4:02 AM, Phillip Smith <phillip at creamcow.com>
> > wrote:
> >
> > > Hi Susan,
> > > Just reading your post regarding using the right Primary Key. I'm
> > > building a rehouse to store telephone data. Each phone record can be
> > > uniquely identified by the DateTime2(7) start time of the call because
> > > each record is guaranteed to be created in a different 100 nano second
> > > window. There are 100 million records. The main way to view data is
> > chronological order.
> > > I'm trying to decide whether to use the CallStart datetime2(7) field
> > > for the primary key. I can cluster on this key and join to my bridging
> > > tables using this key. Or should I crate a CallId (Bigint) that
> > > encodes the datetim, Maybe in yymmddhhmmssnnnnnnn format. You have
> > > stated on your post that there is an overhead to using Datetime type
> > > as the primary key. Is this true for my scenario?
> > > Best regards
> > >
> > > Phillip
> >
> >
> > _______________________________________________
> > 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
>
>


-- 
Paul Hartland
paul.hartland at googlemail.com

From rockysmolin at bchacc.com  Wed Sep  3 09:26:07 2014
From: rockysmolin at bchacc.com (Rocky Smolin)
Date: Wed, 3 Sep 2014 07:26:07 -0700
Subject: [dba-SQLServer] Fwd: SQL Server Primary Key
In-Reply-To: <CA++Sg+dGVw+eJn9i7fJ=cy26SRX_Z_tZYo7ROJ+oJk3ds=2CAg@mail.gmail.com>
References: <a559a5ccc1e1adfdad82e554e150ec95@origin01.techrepublic.com>
	<CA++Sg+dGVw+eJn9i7fJ=cy26SRX_Z_tZYo7ROJ+oJk3ds=2CAg@mail.gmail.com>
Message-ID: <CD86F9EEB78F47AB9EF9ABD442AFEA4D@HAL9007>

"Each phone record can be 
> uniquely identified by the DateTime2(7) start time of the call because 
> each record is guaranteed to be created in a different 100 nano second 
> window."

That's probably true.  Probably isn't good enough for a primary key.  Use
Autonumber.

IMHO.

Rocky
 

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Susan
Harkins
Sent: Wednesday, September 03, 2014 7:02 AM
To: Discussion concerning MS SQL Server
Subject: [dba-SQLServer] Fwd: SQL Server Primary Key

This is from a reader -- seriously over my head. Anyone want to offer some
advice?

Susan H.


On Wed, Sep 3, 2014 at 4:02 AM, Phillip Smith <phillip at creamcow.com> wrote:

> Hi Susan,
> Just reading your post regarding using the right Primary Key. I'm 
> building a rehouse to store telephone data. Each phone record can be 
> uniquely identified by the DateTime2(7) start time of the call because 
> each record is guaranteed to be created in a different 100 nano second 
> window. There are 100 million records. The main way to view data is
chronological order.
> I'm trying to decide whether to use the CallStart datetime2(7) field 
> for the primary key. I can cluster on this key and join to my bridging 
> tables using this key. Or should I crate a CallId (Bigint) that 
> encodes the datetim, Maybe in yymmddhhmmssnnnnnnn format. You have 
> stated on your post that there is an overhead to using Datetime type 
> as the primary key. Is this true for my scenario?
> Best regards
>
> Phillip
>
_______________________________________________
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 Sep  3 09:28:10 2014
From: ssharkins at gmail.com (Susan Harkins)
Date: Wed, 3 Sep 2014 10:28:10 -0400
Subject: [dba-SQLServer] Fwd: SQL Server Primary Key
In-Reply-To: <CD86F9EEB78F47AB9EF9ABD442AFEA4D@HAL9007>
References: <a559a5ccc1e1adfdad82e554e150ec95@origin01.techrepublic.com>
	<CA++Sg+dGVw+eJn9i7fJ=cy26SRX_Z_tZYo7ROJ+oJk3ds=2CAg@mail.gmail.com>
	<CD86F9EEB78F47AB9EF9ABD442AFEA4D@HAL9007>
Message-ID: <CA++Sg+fM0m54CGWhXuNJO70CVo58ykMPojwbK8HoUNMMXEVrvQ@mail.gmail.com>

This was my reaction too. Should be just never pans out.

Susan H.


On Wed, Sep 3, 2014 at 10:26 AM, Rocky Smolin <rockysmolin at bchacc.com>
wrote:

> "Each phone record can be
> > uniquely identified by the DateTime2(7) start time of the call because
> > each record is guaranteed to be created in a different 100 nano second
> > window."
>
> That's probably true.  Probably isn't good enough for a primary key.  Use
> Autonumber.
>
> IMHO.
>
> Rocky
>
>
> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Susan
> Harkins
> Sent: Wednesday, September 03, 2014 7:02 AM
> To: Discussion concerning MS SQL Server
> Subject: [dba-SQLServer] Fwd: SQL Server Primary Key
>
> This is from a reader -- seriously over my head. Anyone want to offer some
> advice?
>
> Susan H.
>
>
> On Wed, Sep 3, 2014 at 4:02 AM, Phillip Smith <phillip at creamcow.com>
> wrote:
>
> > Hi Susan,
> > Just reading your post regarding using the right Primary Key. I'm
> > building a rehouse to store telephone data. Each phone record can be
> > uniquely identified by the DateTime2(7) start time of the call because
> > each record is guaranteed to be created in a different 100 nano second
> > window. There are 100 million records. The main way to view data is
> chronological order.
> > I'm trying to decide whether to use the CallStart datetime2(7) field
> > for the primary key. I can cluster on this key and join to my bridging
> > tables using this key. Or should I crate a CallId (Bigint) that
> > encodes the datetim, Maybe in yymmddhhmmssnnnnnnn format. You have
> > stated on your post that there is an overhead to using Datetime type
> > as the primary key. Is this true for my scenario?
> > Best regards
> >
> > Phillip
> >
> _______________________________________________
> 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  Wed Sep  3 10:02:56 2014
From: fhtapia at gmail.com (Francisco Tapia)
Date: Wed, 3 Sep 2014 08:02:56 -0700
Subject: [dba-SQLServer] Fwd: SQL Server Primary Key
In-Reply-To: <CD86F9EEB78F47AB9EF9ABD442AFEA4D@HAL9007>
References: <a559a5ccc1e1adfdad82e554e150ec95@origin01.techrepublic.com>
	<CA++Sg+dGVw+eJn9i7fJ=cy26SRX_Z_tZYo7ROJ+oJk3ds=2CAg@mail.gmail.com>
	<CD86F9EEB78F47AB9EF9ABD442AFEA4D@HAL9007>
Message-ID: <CAP+kXmaR5EJFOzwty1fyyVCnqOBtuMf_5UJ0zMrJS+Jb7+R93g@mail.gmail.com>

Susan,
  I recommend the autonumber int as a pkid, if he estimates that he can end
up with over 4Billion entries, he should then consider a BIG int, so if
that's the case his choice column (datetime) for a pkid is unique enough,
the compromise would be for him to convert his date to yymmddhhmmssnnnnnnn
as he stated, it would give him the benefit of a faster bigint vs datetime.



-Francisco <http://twitter.com/seecoolguy>




On Wed, Sep 3, 2014 at 7:26 AM, Rocky Smolin <rockysmolin at bchacc.com> wrote:

> "Each phone record can be
> > uniquely identified by the DateTime2(7) start time of the call because
> > each record is guaranteed to be created in a different 100 nano second
> > window."
>
> That's probably true.  Probably isn't good enough for a primary key.  Use
> Autonumber.
>
> IMHO.
>
> Rocky
>
>
> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Susan
> Harkins
> Sent: Wednesday, September 03, 2014 7:02 AM
> To: Discussion concerning MS SQL Server
> Subject: [dba-SQLServer] Fwd: SQL Server Primary Key
>
> This is from a reader -- seriously over my head. Anyone want to offer some
> advice?
>
> Susan H.
>
>
> On Wed, Sep 3, 2014 at 4:02 AM, Phillip Smith <phillip at creamcow.com>
> wrote:
>
> > Hi Susan,
> > Just reading your post regarding using the right Primary Key. I'm
> > building a rehouse to store telephone data. Each phone record can be
> > uniquely identified by the DateTime2(7) start time of the call because
> > each record is guaranteed to be created in a different 100 nano second
> > window. There are 100 million records. The main way to view data is
> chronological order.
> > I'm trying to decide whether to use the CallStart datetime2(7) field
> > for the primary key. I can cluster on this key and join to my bridging
> > tables using this key. Or should I crate a CallId (Bigint) that
> > encodes the datetim, Maybe in yymmddhhmmssnnnnnnn format. You have
> > stated on your post that there is an overhead to using Datetime type
> > as the primary key. Is this true for my scenario?
> > Best regards
> >
> > Phillip
> >
> _______________________________________________
> 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 stuart at lexacorp.com.pg  Wed Sep  3 16:42:28 2014
From: stuart at lexacorp.com.pg (Stuart McLachlan)
Date: Thu, 04 Sep 2014 07:42:28 +1000
Subject: [dba-SQLServer] Fwd: SQL Server Primary Key
In-Reply-To: <CA++Sg+fM0m54CGWhXuNJO70CVo58ykMPojwbK8HoUNMMXEVrvQ@mail.gmail.com>
References: <a559a5ccc1e1adfdad82e554e150ec95@origin01.techrepublic.com>,
	<CD86F9EEB78F47AB9EF9ABD442AFEA4D@HAL9007>,
	<CA++Sg+fM0m54CGWhXuNJO70CVo58ykMPojwbK8HoUNMMXEVrvQ@mail.gmail.com>
Message-ID: <54078B44.29723.39C934A7@stuart.lexacorp.com.pg>

Yep, just as one example: every time the computer resynchs its time with a Time Server, 
there is the potential for it to be set back, so a duplicate could occur in the "set back window"


On 3 Sep 2014 at 10:28, Susan Harkins wrote:

> This was my reaction too. Should be just never pans out.
> 
> Susan H.
> 
> 
> On Wed, Sep 3, 2014 at 10:26 AM, Rocky Smolin <rockysmolin at bchacc.com>
> wrote:
> 
> > "Each phone record can be
> > > uniquely identified by the DateTime2(7) start time of the call
> > > because each record is guaranteed to be created in a different 100
> > > nano second window."
> >
> > That's probably true.  Probably isn't good enough for a primary key.
> >  Use Autonumber.
> >
> > IMHO.
> >
> > Rocky
> >
> >
> > -----Original Message-----
> > From: dba-sqlserver-bounces at databaseadvisors.com
> > [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of
> > Susan Harkins Sent: Wednesday, September 03, 2014 7:02 AM To:
> > Discussion concerning MS SQL Server Subject: [dba-SQLServer] Fwd:
> > SQL Server Primary Key
> >
> > This is from a reader -- seriously over my head. Anyone want to
> > offer some advice?
> >
> > Susan H.
> >
> >
> > On Wed, Sep 3, 2014 at 4:02 AM, Phillip Smith <phillip at creamcow.com>
> > wrote:
> >
> > > Hi Susan,
> > > Just reading your post regarding using the right Primary Key. I'm
> > > building a rehouse to store telephone data. Each phone record can
> > > be uniquely identified by the DateTime2(7) start time of the call
> > > because each record is guaranteed to be created in a different 100
> > > nano second window. There are 100 million records. The main way to
> > > view data is
> > chronological order.
> > > I'm trying to decide whether to use the CallStart datetime2(7)
> > > field for the primary key. I can cluster on this key and join to
> > > my bridging tables using this key. Or should I crate a CallId
> > > (Bigint) that encodes the datetim, Maybe in yymmddhhmmssnnnnnnn
> > > format. You have stated on your post that there is an overhead to
> > > using Datetime type as the primary key. Is this true for my
> > > scenario? Best regards
> > >
> > > Phillip
> > >
> > _______________________________________________
> > 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 stuart at lexacorp.com.pg  Wed Sep  3 16:49:04 2014
From: stuart at lexacorp.com.pg (Stuart McLachlan)
Date: Thu, 04 Sep 2014 07:49:04 +1000
Subject: [dba-SQLServer] Fwd: SQL Server Primary Key
In-Reply-To: <CAP+kXmaR5EJFOzwty1fyyVCnqOBtuMf_5UJ0zMrJS+Jb7+R93g@mail.gmail.com>
References: <a559a5ccc1e1adfdad82e554e150ec95@origin01.techrepublic.com>,
	<CD86F9EEB78F47AB9EF9ABD442AFEA4D@HAL9007>,
	<CAP+kXmaR5EJFOzwty1fyyVCnqOBtuMf_5UJ0zMrJS+Jb7+R93g@mail.gmail.com>
Message-ID: <54078CD0.25242.39CF4099@stuart.lexacorp.com.pg>

I wouldn't create the bigint as a representation of the date/time, it still has the same potential 
for conflicts as the actual datetime.  Just autoincrement it.

On 3 Sep 2014 at 8:02, Francisco Tapia wrote:

> Susan,
>   I recommend the autonumber int as a pkid, if he estimates that he
>   can end
> up with over 4Billion entries, he should then consider a BIG int, so
> if that's the case his choice column (datetime) for a pkid is unique
> enough, the compromise would be for him to convert his date to
> yymmddhhmmssnnnnnnn as he stated, it would give him the benefit of a
> faster bigint vs datetime.
> 
> 
> 
> -Francisco <http://twitter.com/seecoolguy>
> 
> 
> 
> 
> On Wed, Sep 3, 2014 at 7:26 AM, Rocky Smolin <rockysmolin at bchacc.com>
> wrote:
> 
> > "Each phone record can be
> > > uniquely identified by the DateTime2(7) start time of the call
> > > because each record is guaranteed to be created in a different 100
> > > nano second window."
> >
> > That's probably true.  Probably isn't good enough for a primary key.
> >  Use Autonumber.
> >
> > IMHO.
> >
> > Rocky
> >
> >
> > -----Original Message-----
> > From: dba-sqlserver-bounces at databaseadvisors.com
> > [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of
> > Susan Harkins Sent: Wednesday, September 03, 2014 7:02 AM To:
> > Discussion concerning MS SQL Server Subject: [dba-SQLServer] Fwd:
> > SQL Server Primary Key
> >
> > This is from a reader -- seriously over my head. Anyone want to
> > offer some advice?
> >
> > Susan H.
> >
> >
> > On Wed, Sep 3, 2014 at 4:02 AM, Phillip Smith <phillip at creamcow.com>
> > wrote:
> >
> > > Hi Susan,
> > > Just reading your post regarding using the right Primary Key. I'm
> > > building a rehouse to store telephone data. Each phone record can
> > > be uniquely identified by the DateTime2(7) start time of the call
> > > because each record is guaranteed to be created in a different 100
> > > nano second window. There are 100 million records. The main way to
> > > view data is
> > chronological order.
> > > I'm trying to decide whether to use the CallStart datetime2(7)
> > > field for the primary key. I can cluster on this key and join to
> > > my bridging tables using this key. Or should I crate a CallId
> > > (Bigint) that encodes the datetim, Maybe in yymmddhhmmssnnnnnnn
> > > format. You have stated on your post that there is an overhead to
> > > using Datetime type as the primary key. Is this true for my
> > > scenario? Best regards
> > >
> > > Phillip
> > >
> > _______________________________________________
> > 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 aclawhon at hiwaay.net  Wed Sep  3 20:29:34 2014
From: aclawhon at hiwaay.net (aclawhon at hiwaay.net)
Date: Wed, 03 Sep 2014 20:29:34 -0500
Subject: [dba-SQLServer] Fwd: SQL Server Primary Key
In-Reply-To: <CD86F9EEB78F47AB9EF9ABD442AFEA4D@HAL9007>
References: <a559a5ccc1e1adfdad82e554e150ec95@origin01.techrepublic.com>
	<CA++Sg+dGVw+eJn9i7fJ=cy26SRX_Z_tZYo7ROJ+oJk3ds=2CAg@mail.gmail.com>
	<CD86F9EEB78F47AB9EF9ABD442AFEA4D@HAL9007>
Message-ID: <20140903202934.11306k9jcd348ygu@webmail.hiwaay.net>

Susan:

I was having doubts/concerns about this very question, but it looks  
like Rocky beat me to the punch.  Your reader states that he believes  
he can use a DateTime field as a "unique" record identifier because  
each record is created in a "different" 100 nanosecond window.  I  
checked this to be sure: A nanosecond is one-billionth of a second or  
1 x ten-to-the-negative-ninth of a second.  (Stated numerically that  
would be 0.000000001 seconds.)

He says each record will be unique because they are all created in a  
"different" 100 nanosecond window.  Numerically, 100 nanoseconds  
equates to 0.000000100 or 1 x ten-to-the-negative-seventh power.  He  
says he has 100 million records or 1 x ten-to-the-eighth power.  With  
that many records, there's no guarantee that two (or possibly more  
than two) of the records might have been created with the exact  
[identical] DateTime value.  (I'm not a good enough mathematician or  
statistician to calculate the probability that two records might be  
created with the same value in the DateTime field, but the probability  
is not zero, therefore the DateTime data type should not be used as  
the PK.

I recall reading a discussion in a book on database theory where this  
very point was debated with respect to whether or not Social Security  
numbers should be used as a PK.  While the probability of two SSNs  
being duplicates was very low, it was not zero so the argument was  
that "artificial" primary keys - such as Social Security numbers -  
should never be used as a PK.

Positive Alan of Huntsville



Quoting Rocky Smolin <rockysmolin at bchacc.com>:

> "Each phone record can be
>> uniquely identified by the DateTime2(7) start time of the call because
>> each record is guaranteed to be created in a different 100 nano second
>> window."
>
> That's probably true.  Probably isn't good enough for a primary key.  Use
> Autonumber.
>
> IMHO.
>
> Rocky
>
>
> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Susan
> Harkins
> Sent: Wednesday, September 03, 2014 7:02 AM
> To: Discussion concerning MS SQL Server
> Subject: [dba-SQLServer] Fwd: SQL Server Primary Key
>
> This is from a reader -- seriously over my head. Anyone want to offer some
> advice?
>
> Susan H.
>
>
> On Wed, Sep 3, 2014 at 4:02 AM, Phillip Smith <phillip at creamcow.com> wrote:
>
>> Hi Susan,
>> Just reading your post regarding using the right Primary Key. I'm
>> building a rehouse to store telephone data. Each phone record can be
>> uniquely identified by the DateTime2(7) start time of the call because
>> each record is guaranteed to be created in a different 100 nano second
>> window. There are 100 million records. The main way to view data is
> chronological order.
>> I'm trying to decide whether to use the CallStart datetime2(7) field
>> for the primary key. I can cluster on this key and join to my bridging
>> tables using this key. Or should I crate a CallId (Bigint) that
>> encodes the datetim, Maybe in yymmddhhmmssnnnnnnn format. You have
>> stated on your post that there is an overhead to using Datetime type
>> as the primary key. Is this true for my scenario?
>> Best regards
>>
>> Phillip
>>
> _______________________________________________
> 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 Sep  3 20:34:06 2014
From: ssharkins at gmail.com (Susan Harkins)
Date: Wed, 3 Sep 2014 21:34:06 -0400
Subject: [dba-SQLServer] Fwd: SQL Server Primary Key
In-Reply-To: <20140903202934.11306k9jcd348ygu@webmail.hiwaay.net>
References: <a559a5ccc1e1adfdad82e554e150ec95@origin01.techrepublic.com>
	<CA++Sg+dGVw+eJn9i7fJ=cy26SRX_Z_tZYo7ROJ+oJk3ds=2CAg@mail.gmail.com>
	<CD86F9EEB78F47AB9EF9ABD442AFEA4D@HAL9007>
	<20140903202934.11306k9jcd348ygu@webmail.hiwaay.net>
Message-ID: <CA++Sg+cpi0Dk8MdTaamajTKK6ck=SbKYhRrBKw_h-_4peDK9kA@mail.gmail.com>

Well, I sent him all of the recommendations and he did exactly what he
proposed to do in the first place. I have no idea why he asked for my
opinion. :)

I wish him well!

Susan H.


On Wed, Sep 3, 2014 at 9:29 PM, <aclawhon at hiwaay.net> wrote:

> Susan:
>
> I was having doubts/concerns about this very question, but it looks like
> Rocky beat me to the punch.  Your reader states that he believes he can use
> a DateTime field as a "unique" record identifier because each record is
> created in a "different" 100 nanosecond window.  I checked this to be sure:
> A nanosecond is one-billionth of a second or 1 x ten-to-the-negative-ninth
> of a second.  (Stated numerically that would be 0.000000001 seconds.)
>
> He says each record will be unique because they are all created in a
> "different" 100 nanosecond window.  Numerically, 100 nanoseconds equates to
> 0.000000100 or 1 x ten-to-the-negative-seventh power.  He says he has 100
> million records or 1 x ten-to-the-eighth power.  With that many records,
> there's no guarantee that two (or possibly more than two) of the records
> might have been created with the exact [identical] DateTime value.  (I'm
> not a good enough mathematician or statistician to calculate the
> probability that two records might be created with the same value in the
> DateTime field, but the probability is not zero, therefore the DateTime
> data type should not be used as the PK.
>
> I recall reading a discussion in a book on database theory where this very
> point was debated with respect to whether or not Social Security numbers
> should be used as a PK.  While the probability of two SSNs being duplicates
> was very low, it was not zero so the argument was that "artificial" primary
> keys - such as Social Security numbers - should never be used as a PK.
>
> Positive Alan of Huntsville
>
>
>
> Quoting Rocky Smolin <rockysmolin at bchacc.com>:
>
>  "Each phone record can be
>>
>>> uniquely identified by the DateTime2(7) start time of the call because
>>> each record is guaranteed to be created in a different 100 nano second
>>> window."
>>>
>>
>> That's probably true.  Probably isn't good enough for a primary key.  Use
>> Autonumber.
>>
>> IMHO.
>>
>> Rocky
>>
>>
>> -----Original Message-----
>> From: dba-sqlserver-bounces at databaseadvisors.com
>> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Susan
>> Harkins
>> Sent: Wednesday, September 03, 2014 7:02 AM
>> To: Discussion concerning MS SQL Server
>> Subject: [dba-SQLServer] Fwd: SQL Server Primary Key
>>
>> This is from a reader -- seriously over my head. Anyone want to offer some
>> advice?
>>
>> Susan H.
>>
>>
>> On Wed, Sep 3, 2014 at 4:02 AM, Phillip Smith <phillip at creamcow.com>
>> wrote:
>>
>>  Hi Susan,
>>> Just reading your post regarding using the right Primary Key. I'm
>>> building a rehouse to store telephone data. Each phone record can be
>>> uniquely identified by the DateTime2(7) start time of the call because
>>> each record is guaranteed to be created in a different 100 nano second
>>> window. There are 100 million records. The main way to view data is
>>>
>> chronological order.
>>
>>> I'm trying to decide whether to use the CallStart datetime2(7) field
>>> for the primary key. I can cluster on this key and join to my bridging
>>> tables using this key. Or should I crate a CallId (Bigint) that
>>> encodes the datetim, Maybe in yymmddhhmmssnnnnnnn format. You have
>>> stated on your post that there is an overhead to using Datetime type
>>> as the primary key. Is this true for my scenario?
>>> Best regards
>>>
>>> Phillip
>>>
>>>  _______________________________________________
>> 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  Wed Sep  3 20:36:17 2014
From: fhtapia at gmail.com (Francisco Tapia)
Date: Wed, 03 Sep 2014 18:36:17 -0700 (PDT)
Subject: [dba-SQLServer] Fwd: SQL Server Primary Key
In-Reply-To: <CA++Sg+cpi0Dk8MdTaamajTKK6ck=SbKYhRrBKw_h-_4peDK9kA@mail.gmail.com>
References: <CA++Sg+cpi0Dk8MdTaamajTKK6ck=SbKYhRrBKw_h-_4peDK9kA@mail.gmail.com>
Message-ID: <1409794577014.38ed4d26@Nodemailer>

When he ends up with duplicate records errors he may ask again (:?


Some people just love natural keys.?
?
Sent from Mailbox

On Wed, Sep 3, 2014 at 6:34 PM, Susan Harkins <ssharkins at gmail.com> wrote:

> Well, I sent him all of the recommendations and he did exactly what he
> proposed to do in the first place. I have no idea why he asked for my
> opinion. :)
> I wish him well!
> Susan H.
> On Wed, Sep 3, 2014 at 9:29 PM, <aclawhon at hiwaay.net> wrote:
>> Susan:
>>
>> I was having doubts/concerns about this very question, but it looks like
>> Rocky beat me to the punch.  Your reader states that he believes he can use
>> a DateTime field as a "unique" record identifier because each record is
>> created in a "different" 100 nanosecond window.  I checked this to be sure:
>> A nanosecond is one-billionth of a second or 1 x ten-to-the-negative-ninth
>> of a second.  (Stated numerically that would be 0.000000001 seconds.)
>>
>> He says each record will be unique because they are all created in a
>> "different" 100 nanosecond window.  Numerically, 100 nanoseconds equates to
>> 0.000000100 or 1 x ten-to-the-negative-seventh power.  He says he has 100
>> million records or 1 x ten-to-the-eighth power.  With that many records,
>> there's no guarantee that two (or possibly more than two) of the records
>> might have been created with the exact [identical] DateTime value.  (I'm
>> not a good enough mathematician or statistician to calculate the
>> probability that two records might be created with the same value in the
>> DateTime field, but the probability is not zero, therefore the DateTime
>> data type should not be used as the PK.
>>
>> I recall reading a discussion in a book on database theory where this very
>> point was debated with respect to whether or not Social Security numbers
>> should be used as a PK.  While the probability of two SSNs being duplicates
>> was very low, it was not zero so the argument was that "artificial" primary
>> keys - such as Social Security numbers - should never be used as a PK.
>>
>> Positive Alan of Huntsville
>>
>>
>>
>> Quoting Rocky Smolin <rockysmolin at bchacc.com>:
>>
>>  "Each phone record can be
>>>
>>>> uniquely identified by the DateTime2(7) start time of the call because
>>>> each record is guaranteed to be created in a different 100 nano second
>>>> window."
>>>>
>>>
>>> That's probably true.  Probably isn't good enough for a primary key.  Use
>>> Autonumber.
>>>
>>> IMHO.
>>>
>>> Rocky
>>>
>>>
>>> -----Original Message-----
>>> From: dba-sqlserver-bounces at databaseadvisors.com
>>> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Susan
>>> Harkins
>>> Sent: Wednesday, September 03, 2014 7:02 AM
>>> To: Discussion concerning MS SQL Server
>>> Subject: [dba-SQLServer] Fwd: SQL Server Primary Key
>>>
>>> This is from a reader -- seriously over my head. Anyone want to offer some
>>> advice?
>>>
>>> Susan H.
>>>
>>>
>>> On Wed, Sep 3, 2014 at 4:02 AM, Phillip Smith <phillip at creamcow.com>
>>> wrote:
>>>
>>>  Hi Susan,
>>>> Just reading your post regarding using the right Primary Key. I'm
>>>> building a rehouse to store telephone data. Each phone record can be
>>>> uniquely identified by the DateTime2(7) start time of the call because
>>>> each record is guaranteed to be created in a different 100 nano second
>>>> window. There are 100 million records. The main way to view data is
>>>>
>>> chronological order.
>>>
>>>> I'm trying to decide whether to use the CallStart datetime2(7) field
>>>> for the primary key. I can cluster on this key and join to my bridging
>>>> tables using this key. Or should I crate a CallId (Bigint) that
>>>> encodes the datetim, Maybe in yymmddhhmmssnnnnnnn format. You have
>>>> stated on your post that there is an overhead to using Datetime type
>>>> as the primary key. Is this true for my scenario?
>>>> Best regards
>>>>
>>>> Phillip
>>>>
>>>>  _______________________________________________
>>> 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 rockysmolin at bchacc.com  Wed Sep  3 20:48:08 2014
From: rockysmolin at bchacc.com (Rocky Smolin)
Date: Wed, 3 Sep 2014 18:48:08 -0700
Subject: [dba-SQLServer] Fwd: SQL Server Primary Key
In-Reply-To: <20140903202934.11306k9jcd348ygu@webmail.hiwaay.net>
References: <a559a5ccc1e1adfdad82e554e150ec95@origin01.techrepublic.com><CA++Sg+dGVw+eJn9i7fJ=cy26SRX_Z_tZYo7ROJ+oJk3ds=2CAg@mail.gmail.com><CD86F9EEB78F47AB9EF9ABD442AFEA4D@HAL9007>
	<20140903202934.11306k9jcd348ygu@webmail.hiwaay.net>
Message-ID: <00C0E4628CA344BBBB3A27FC3A4289FF@HAL9007>

"Your reader states that he believes he can use a DateTime field as a
"unique" record identifier because each record is created in a "different"
100 nanosecond window. "

Let's just call that one of the worst design ideas we've ever read and leave
it at that. :)

r 

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of
aclawhon at hiwaay.net
Sent: Wednesday, September 03, 2014 6:30 PM
To: Discussion concerning MS SQL Server
Subject: Re: [dba-SQLServer] Fwd: SQL Server Primary Key

Susan:

I was having doubts/concerns about this very question, but it looks like
Rocky beat me to the punch.  Your reader states that he believes he can use
a DateTime field as a "unique" record identifier because each record is
created in a "different" 100 nanosecond window.  I checked this to be sure:
A nanosecond is one-billionth of a second or
1 x ten-to-the-negative-ninth of a second.  (Stated numerically that would
be 0.000000001 seconds.)

He says each record will be unique because they are all created in a
"different" 100 nanosecond window.  Numerically, 100 nanoseconds equates to
0.000000100 or 1 x ten-to-the-negative-seventh power.  He says he has 100
million records or 1 x ten-to-the-eighth power.  With that many records,
there's no guarantee that two (or possibly more than two) of the records
might have been created with the exact [identical] DateTime value.  (I'm not
a good enough mathematician or statistician to calculate the probability
that two records might be created with the same value in the DateTime field,
but the probability is not zero, therefore the DateTime data type should not
be used as the PK.

I recall reading a discussion in a book on database theory where this very
point was debated with respect to whether or not Social Security numbers
should be used as a PK.  While the probability of two SSNs being duplicates
was very low, it was not zero so the argument was that "artificial" primary
keys - such as Social Security numbers - should never be used as a PK.

Positive Alan of Huntsville



Quoting Rocky Smolin <rockysmolin at bchacc.com>:

> "Each phone record can be
>> uniquely identified by the DateTime2(7) start time of the call 
>> because each record is guaranteed to be created in a different 100 
>> nano second window."
>
> That's probably true.  Probably isn't good enough for a primary key.  
> Use Autonumber.
>
> IMHO.
>
> Rocky
>
>
> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Susan 
> Harkins
> Sent: Wednesday, September 03, 2014 7:02 AM
> To: Discussion concerning MS SQL Server
> Subject: [dba-SQLServer] Fwd: SQL Server Primary Key
>
> This is from a reader -- seriously over my head. Anyone want to offer 
> some advice?
>
> Susan H.
>
>
> On Wed, Sep 3, 2014 at 4:02 AM, Phillip Smith <phillip at creamcow.com>
wrote:
>
>> Hi Susan,
>> Just reading your post regarding using the right Primary Key. I'm 
>> building a rehouse to store telephone data. Each phone record can be 
>> uniquely identified by the DateTime2(7) start time of the call 
>> because each record is guaranteed to be created in a different 100 
>> nano second window. There are 100 million records. The main way to 
>> view data is
> chronological order.
>> I'm trying to decide whether to use the CallStart datetime2(7) field 
>> for the primary key. I can cluster on this key and join to my 
>> bridging tables using this key. Or should I crate a CallId (Bigint) 
>> that encodes the datetim, Maybe in yymmddhhmmssnnnnnnn format. You 
>> have stated on your post that there is an overhead to using Datetime 
>> type as the primary key. Is this true for my scenario?
>> Best regards
>>
>> Phillip
>>
> _______________________________________________
> 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 rockysmolin at bchacc.com  Wed Sep  3 20:50:13 2014
From: rockysmolin at bchacc.com (Rocky Smolin)
Date: Wed, 3 Sep 2014 18:50:13 -0700
Subject: [dba-SQLServer] Fwd: SQL Server Primary Key
In-Reply-To: <1409794577014.38ed4d26@Nodemailer>
References: <CA++Sg+cpi0Dk8MdTaamajTKK6ck=SbKYhRrBKw_h-_4peDK9kA@mail.gmail.com>
	<1409794577014.38ed4d26@Nodemailer>
Message-ID: <087D89494B9243E09F85BD17E751F2EA@HAL9007>

Some people love self-flagellation and gorgonzola cheese, too. There's no
accounting for taste.

r

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Francisco
Tapia
Sent: Wednesday, September 03, 2014 6:36 PM
To: Discussion concerning MS SQL Server
Cc: Discussion concerning MS SQL Server
Subject: Re: [dba-SQLServer] Fwd: SQL Server Primary Key

When he ends up with duplicate records errors he may ask again (:?


Some people just love natural keys.
?
Sent from Mailbox

On Wed, Sep 3, 2014 at 6:34 PM, Susan Harkins <ssharkins at gmail.com> wrote:

> Well, I sent him all of the recommendations and he did exactly what he 
> proposed to do in the first place. I have no idea why he asked for my 
> opinion. :) I wish him well!
> Susan H.
> On Wed, Sep 3, 2014 at 9:29 PM, <aclawhon at hiwaay.net> wrote:
>> Susan:
>>
>> I was having doubts/concerns about this very question, but it looks 
>> like Rocky beat me to the punch.  Your reader states that he believes 
>> he can use a DateTime field as a "unique" record identifier because 
>> each record is created in a "different" 100 nanosecond window.  I checked
this to be sure:
>> A nanosecond is one-billionth of a second or 1 x 
>> ten-to-the-negative-ninth of a second.  (Stated numerically that 
>> would be 0.000000001 seconds.)
>>
>> He says each record will be unique because they are all created in a 
>> "different" 100 nanosecond window.  Numerically, 100 nanoseconds 
>> equates to 0.000000100 or 1 x ten-to-the-negative-seventh power.  He 
>> says he has 100 million records or 1 x ten-to-the-eighth power.  With 
>> that many records, there's no guarantee that two (or possibly more 
>> than two) of the records might have been created with the exact 
>> [identical] DateTime value.  (I'm not a good enough mathematician or 
>> statistician to calculate the probability that two records might be 
>> created with the same value in the DateTime field, but the 
>> probability is not zero, therefore the DateTime data type should not be
used as the PK.
>>
>> I recall reading a discussion in a book on database theory where this 
>> very point was debated with respect to whether or not Social Security 
>> numbers should be used as a PK.  While the probability of two SSNs 
>> being duplicates was very low, it was not zero so the argument was 
>> that "artificial" primary keys - such as Social Security numbers - should
never be used as a PK.
>>
>> Positive Alan of Huntsville
>>
>>
>>
>> Quoting Rocky Smolin <rockysmolin at bchacc.com>:
>>
>>  "Each phone record can be
>>>
>>>> uniquely identified by the DateTime2(7) start time of the call 
>>>> because each record is guaranteed to be created in a different 100 
>>>> nano second window."
>>>>
>>>
>>> That's probably true.  Probably isn't good enough for a primary key.  
>>> Use Autonumber.
>>>
>>> IMHO.
>>>
>>> Rocky
>>>
>>>
>>> -----Original Message-----
>>> From: dba-sqlserver-bounces at databaseadvisors.com
>>> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of 
>>> Susan Harkins
>>> Sent: Wednesday, September 03, 2014 7:02 AM
>>> To: Discussion concerning MS SQL Server
>>> Subject: [dba-SQLServer] Fwd: SQL Server Primary Key
>>>
>>> This is from a reader -- seriously over my head. Anyone want to 
>>> offer some advice?
>>>
>>> Susan H.
>>>
>>>
>>> On Wed, Sep 3, 2014 at 4:02 AM, Phillip Smith <phillip at creamcow.com>
>>> wrote:
>>>
>>>  Hi Susan,
>>>> Just reading your post regarding using the right Primary Key. I'm 
>>>> building a rehouse to store telephone data. Each phone record can 
>>>> be uniquely identified by the DateTime2(7) start time of the call 
>>>> because each record is guaranteed to be created in a different 100 
>>>> nano second window. There are 100 million records. The main way to 
>>>> view data is
>>>>
>>> chronological order.
>>>
>>>> I'm trying to decide whether to use the CallStart datetime2(7) 
>>>> field for the primary key. I can cluster on this key and join to my 
>>>> bridging tables using this key. Or should I crate a CallId (Bigint) 
>>>> that encodes the datetim, Maybe in yymmddhhmmssnnnnnnn format. You 
>>>> have stated on your post that there is an overhead to using 
>>>> Datetime type as the primary key. Is this true for my scenario?
>>>> Best regards
>>>>
>>>> Phillip
>>>>
>>>>  _______________________________________________
>>> 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 aclawhon at hiwaay.net  Wed Sep  3 21:21:36 2014
From: aclawhon at hiwaay.net (aclawhon at hiwaay.net)
Date: Wed, 03 Sep 2014 21:21:36 -0500
Subject: [dba-SQLServer] Fwd: SQL Server Primary Key
In-Reply-To: <CA++Sg+cpi0Dk8MdTaamajTKK6ck=SbKYhRrBKw_h-_4peDK9kA@mail.gmail.com>
References: <a559a5ccc1e1adfdad82e554e150ec95@origin01.techrepublic.com>
	<CA++Sg+dGVw+eJn9i7fJ=cy26SRX_Z_tZYo7ROJ+oJk3ds=2CAg@mail.gmail.com>
	<CD86F9EEB78F47AB9EF9ABD442AFEA4D@HAL9007>
	<20140903202934.11306k9jcd348ygu@webmail.hiwaay.net>
	<CA++Sg+cpi0Dk8MdTaamajTKK6ck=SbKYhRrBKw_h-_4peDK9kA@mail.gmail.com>
Message-ID: <20140903212136.47591jja5kq1694g@webmail.hiwaay.net>

Susan:

If he winds up with a PK conflict, I have a feeling you'll hear about  
it ... he might send you [another] email full of exasperation as to  
why a noted database "authority" (that would be you) didn't warn him  
that this could happen.  (Ha! Ha!)

It won't be that big of a deal though.  He'll just have to redo his  
application - once he figures out why it's not working.  If he  
encounters a duplicate, the SQL Server engine will give him some kind  
of error message and not allow the record to be entered.  Then he  
starts panicking ...

Positive Alan of Huntsville


Quoting Susan Harkins <ssharkins at gmail.com>:

> Well, I sent him all of the recommendations and he did exactly what he
> proposed to do in the first place. I have no idea why he asked for my
> opinion. :)
>
> I wish him well!
>
> Susan H.
>
>
> On Wed, Sep 3, 2014 at 9:29 PM, <aclawhon at hiwaay.net> wrote:
>
>> Susan:
>>
>> I was having doubts/concerns about this very question, but it looks like
>> Rocky beat me to the punch.  Your reader states that he believes he can use
>> a DateTime field as a "unique" record identifier because each record is
>> created in a "different" 100 nanosecond window.  I checked this to be sure:
>> A nanosecond is one-billionth of a second or 1 x ten-to-the-negative-ninth
>> of a second.  (Stated numerically that would be 0.000000001 seconds.)
>>
>> He says each record will be unique because they are all created in a
>> "different" 100 nanosecond window.  Numerically, 100 nanoseconds equates to
>> 0.000000100 or 1 x ten-to-the-negative-seventh power.  He says he has 100
>> million records or 1 x ten-to-the-eighth power.  With that many records,
>> there's no guarantee that two (or possibly more than two) of the records
>> might have been created with the exact [identical] DateTime value.  (I'm
>> not a good enough mathematician or statistician to calculate the
>> probability that two records might be created with the same value in the
>> DateTime field, but the probability is not zero, therefore the DateTime
>> data type should not be used as the PK.
>>
>> I recall reading a discussion in a book on database theory where this very
>> point was debated with respect to whether or not Social Security numbers
>> should be used as a PK.  While the probability of two SSNs being duplicates
>> was very low, it was not zero so the argument was that "artificial" primary
>> keys - such as Social Security numbers - should never be used as a PK.
>>
>> Positive Alan of Huntsville
>>
>>
>>
>> Quoting Rocky Smolin <rockysmolin at bchacc.com>:
>>
>>  "Each phone record can be
>>>
>>>> uniquely identified by the DateTime2(7) start time of the call because
>>>> each record is guaranteed to be created in a different 100 nano second
>>>> window."
>>>>
>>>
>>> That's probably true.  Probably isn't good enough for a primary key.  Use
>>> Autonumber.
>>>
>>> IMHO.
>>>
>>> Rocky
>>>
>>>
>>> -----Original Message-----
>>> From: dba-sqlserver-bounces at databaseadvisors.com
>>> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Susan
>>> Harkins
>>> Sent: Wednesday, September 03, 2014 7:02 AM
>>> To: Discussion concerning MS SQL Server
>>> Subject: [dba-SQLServer] Fwd: SQL Server Primary Key
>>>
>>> This is from a reader -- seriously over my head. Anyone want to offer some
>>> advice?
>>>
>>> Susan H.
>>>
>>>
>>> On Wed, Sep 3, 2014 at 4:02 AM, Phillip Smith <phillip at creamcow.com>
>>> wrote:
>>>
>>>  Hi Susan,
>>>> Just reading your post regarding using the right Primary Key. I'm
>>>> building a rehouse to store telephone data. Each phone record can be
>>>> uniquely identified by the DateTime2(7) start time of the call because
>>>> each record is guaranteed to be created in a different 100 nano second
>>>> window. There are 100 million records. The main way to view data is
>>>>
>>> chronological order.
>>>
>>>> I'm trying to decide whether to use the CallStart datetime2(7) field
>>>> for the primary key. I can cluster on this key and join to my bridging
>>>> tables using this key. Or should I crate a CallId (Bigint) that
>>>> encodes the datetim, Maybe in yymmddhhmmssnnnnnnn format. You have
>>>> stated on your post that there is an overhead to using Datetime type
>>>> as the primary key. Is this true for my scenario?
>>>> Best regards
>>>>
>>>> Phillip
>>>>
>>>>  _______________________________________________
>>> 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 darryl at whittleconsulting.com.au  Wed Sep  3 21:33:11 2014
From: darryl at whittleconsulting.com.au (Darryl Collins)
Date: Thu, 4 Sep 2014 02:33:11 +0000
Subject: [dba-SQLServer] Fwd: SQL Server Primary Key
In-Reply-To: <20140903212136.47591jja5kq1694g@webmail.hiwaay.net>
References: <a559a5ccc1e1adfdad82e554e150ec95@origin01.techrepublic.com>
	<CA++Sg+dGVw+eJn9i7fJ=cy26SRX_Z_tZYo7ROJ+oJk3ds=2CAg@mail.gmail.com>
	<CD86F9EEB78F47AB9EF9ABD442AFEA4D@HAL9007>
	<20140903202934.11306k9jcd348ygu@webmail.hiwaay.net>
	<CA++Sg+cpi0Dk8MdTaamajTKK6ck=SbKYhRrBKw_h-_4peDK9kA@mail.gmail.com>
	<20140903212136.47591jja5kq1694g@webmail.hiwaay.net>
Message-ID: <9528949165934b17a018383fa267e901@HKXPR04MB360.apcprd04.prod.outlook.com>

Agreed.  I don't understand this obsession with 'natural' PK's when there is such a painless and automated way to avoid all of that risk and bother. Just put in a damn autokey for heaven's sake!!
Oh well.  Each to their own I guess.

Cheers
Darryl.

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of aclawhon at hiwaay.net
Sent: Thursday, 4 September 2014 12:22 PM
To: Discussion concerning MS SQL Server
Subject: Re: [dba-SQLServer] Fwd: SQL Server Primary Key

Susan:

If he winds up with a PK conflict, I have a feeling you'll hear about it ... he might send you [another] email full of exasperation as to why a noted database "authority" (that would be you) didn't warn him that this could happen.  (Ha! Ha!)

It won't be that big of a deal though.  He'll just have to redo his application - once he figures out why it's not working.  If he encounters a duplicate, the SQL Server engine will give him some kind of error message and not allow the record to be entered.  Then he starts panicking ...

Positive Alan of Huntsville


Quoting Susan Harkins <ssharkins at gmail.com>:

> Well, I sent him all of the recommendations and he did exactly what he 
> proposed to do in the first place. I have no idea why he asked for my 
> opinion. :)
>
> I wish him well!
>
> Susan H.
>
>
> On Wed, Sep 3, 2014 at 9:29 PM, <aclawhon at hiwaay.net> wrote:
>
>> Susan:
>>
>> I was having doubts/concerns about this very question, but it looks 
>> like Rocky beat me to the punch.  Your reader states that he believes 
>> he can use a DateTime field as a "unique" record identifier because 
>> each record is created in a "different" 100 nanosecond window.  I checked this to be sure:
>> A nanosecond is one-billionth of a second or 1 x 
>> ten-to-the-negative-ninth of a second.  (Stated numerically that 
>> would be 0.000000001 seconds.)
>>
>> He says each record will be unique because they are all created in a 
>> "different" 100 nanosecond window.  Numerically, 100 nanoseconds 
>> equates to
>> 0.000000100 or 1 x ten-to-the-negative-seventh power.  He says he has 
>> 100 million records or 1 x ten-to-the-eighth power.  With that many 
>> records, there's no guarantee that two (or possibly more than two) of 
>> the records might have been created with the exact [identical] 
>> DateTime value.  (I'm not a good enough mathematician or statistician 
>> to calculate the probability that two records might be created with 
>> the same value in the DateTime field, but the probability is not 
>> zero, therefore the DateTime data type should not be used as the PK.
>>
>> I recall reading a discussion in a book on database theory where this 
>> very point was debated with respect to whether or not Social Security 
>> numbers should be used as a PK.  While the probability of two SSNs 
>> being duplicates was very low, it was not zero so the argument was 
>> that "artificial" primary keys - such as Social Security numbers - should never be used as a PK.
>>
>> Positive Alan of Huntsville
>>
>>
>>
>> Quoting Rocky Smolin <rockysmolin at bchacc.com>:
>>
>>  "Each phone record can be
>>>
>>>> uniquely identified by the DateTime2(7) start time of the call 
>>>> because each record is guaranteed to be created in a different 100 
>>>> nano second window."
>>>>
>>>
>>> That's probably true.  Probably isn't good enough for a primary key.  
>>> Use Autonumber.
>>>
>>> IMHO.
>>>
>>> Rocky
>>>
>>>
>>> -----Original Message-----
>>> From: dba-sqlserver-bounces at databaseadvisors.com
>>> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of 
>>> Susan Harkins
>>> Sent: Wednesday, September 03, 2014 7:02 AM
>>> To: Discussion concerning MS SQL Server
>>> Subject: [dba-SQLServer] Fwd: SQL Server Primary Key
>>>
>>> This is from a reader -- seriously over my head. Anyone want to 
>>> offer some advice?
>>>
>>> Susan H.
>>>
>>>
>>> On Wed, Sep 3, 2014 at 4:02 AM, Phillip Smith <phillip at creamcow.com>
>>> wrote:
>>>
>>>  Hi Susan,
>>>> Just reading your post regarding using the right Primary Key. I'm 
>>>> building a rehouse to store telephone data. Each phone record can 
>>>> be uniquely identified by the DateTime2(7) start time of the call 
>>>> because each record is guaranteed to be created in a different 100 
>>>> nano second window. There are 100 million records. The main way to 
>>>> view data is
>>>>
>>> chronological order.
>>>
>>>> I'm trying to decide whether to use the CallStart datetime2(7) 
>>>> field for the primary key. I can cluster on this key and join to my 
>>>> bridging tables using this key. Or should I crate a CallId (Bigint) 
>>>> that encodes the datetim, Maybe in yymmddhhmmssnnnnnnn format. You 
>>>> have stated on your post that there is an overhead to using 
>>>> Datetime type as the primary key. Is this true for my scenario?
>>>> Best regards
>>>>
>>>> Phillip
>>>>
>>>>  _______________________________________________
>>> 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 aclawhon at hiwaay.net  Wed Sep  3 21:48:12 2014
From: aclawhon at hiwaay.net (aclawhon at hiwaay.net)
Date: Wed, 03 Sep 2014 21:48:12 -0500
Subject: [dba-SQLServer] Fwd: SQL Server Primary Key
In-Reply-To: <CA++Sg+fM0m54CGWhXuNJO70CVo58ykMPojwbK8HoUNMMXEVrvQ@mail.gmail.com>
References: <a559a5ccc1e1adfdad82e554e150ec95@origin01.techrepublic.com>
	<CA++Sg+dGVw+eJn9i7fJ=cy26SRX_Z_tZYo7ROJ+oJk3ds=2CAg@mail.gmail.com>
	<CD86F9EEB78F47AB9EF9ABD442AFEA4D@HAL9007>
	<CA++Sg+fM0m54CGWhXuNJO70CVo58ykMPojwbK8HoUNMMXEVrvQ@mail.gmail.com>
Message-ID: <20140903214812.19154y1i3i3xqwa4@webmail.hiwaay.net>

Susan:

Look at the bright side.  This guy has just handed you a great article  
to write if you're still submitting occasional articles to  
TechRepublic or whoever it is that you write for.

You can write an article on the general topic of factors to consider  
when selecting a primary key and cite - without embarrassing this guy  
by calling him out by name - the specific scenario/application/query  
that he presented to you.  Your article title might be something like:  
"Primary Keys: Artificial Key Or AutoNumber Key?" or something like  
that.  (There's plenty of discussion of this topic in various database  
theory books.)

If you think it will help, feel free to use my brilliant "mathematical  
analysis" of his application.  (One of your editors at TechRepublic  
can help with figuring out the math with respect to the probability  
that he'll get a duplicate record and "break" his design.)  I'm going  
to "guess" (off the top of my head) that the odds are somewhere in the  
1-in-100 to 1-in-10,000 range - which is too great a probability to  
risk - especially if this guy is creating a database that will be  
heavily utilized and/or one where quite a bit of money is involved.

Positive Alan of Huntsville


Quoting Susan Harkins <ssharkins at gmail.com>:

> This was my reaction too. Should be just never pans out.
>
> Susan H.
>
>
> On Wed, Sep 3, 2014 at 10:26 AM, Rocky Smolin <rockysmolin at bchacc.com>
> wrote:
>
>> "Each phone record can be
>> > uniquely identified by the DateTime2(7) start time of the call because
>> > each record is guaranteed to be created in a different 100 nano second
>> > window."
>>
>> That's probably true.  Probably isn't good enough for a primary key.  Use
>> Autonumber.
>>
>> IMHO.
>>
>> Rocky
>>
>>
>> -----Original Message-----
>> From: dba-sqlserver-bounces at databaseadvisors.com
>> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Susan
>> Harkins
>> Sent: Wednesday, September 03, 2014 7:02 AM
>> To: Discussion concerning MS SQL Server
>> Subject: [dba-SQLServer] Fwd: SQL Server Primary Key
>>
>> This is from a reader -- seriously over my head. Anyone want to offer some
>> advice?
>>
>> Susan H.
>>
>>
>> On Wed, Sep 3, 2014 at 4:02 AM, Phillip Smith <phillip at creamcow.com>
>> wrote:
>>
>> > Hi Susan,
>> > Just reading your post regarding using the right Primary Key. I'm
>> > building a rehouse to store telephone data. Each phone record can be
>> > uniquely identified by the DateTime2(7) start time of the call because
>> > each record is guaranteed to be created in a different 100 nano second
>> > window. There are 100 million records. The main way to view data is
>> chronological order.
>> > I'm trying to decide whether to use the CallStart datetime2(7) field
>> > for the primary key. I can cluster on this key and join to my bridging
>> > tables using this key. Or should I crate a CallId (Bigint) that
>> > encodes the datetim, Maybe in yymmddhhmmssnnnnnnn format. You have
>> > stated on your post that there is an overhead to using Datetime type
>> > as the primary key. Is this true for my scenario?
>> > Best regards
>> >
>> > Phillip
>> >
>> _______________________________________________
>> 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 gustav at cactus.dk  Thu Sep  4 02:42:44 2014
From: gustav at cactus.dk (Gustav Brock)
Date: Thu, 4 Sep 2014 07:42:44 +0000
Subject: [dba-SQLServer] Fwd: SQL Server Primary Key
Message-ID: <a0bc128b60dc4a4d8593895daf3c287c@AMSPR06MB357.eurprd06.prod.outlook.com>

Hi Rocky

Nothing wrong with gorgonzola cheese. One of my favourites.

/gustav

-----Oprindelig meddelelse-----
Fra: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] P? vegne af Rocky Smolin
Sendt: 4. september 2014 03:50
Til: 'Discussion concerning MS SQL Server'
Emne: Re: [dba-SQLServer] Fwd: SQL Server Primary Key

Some people love self-flagellation and gorgonzola cheese, too. There's no accounting for taste.

r 



From gustav at cactus.dk  Thu Sep  4 02:56:08 2014
From: gustav at cactus.dk (Gustav Brock)
Date: Thu, 4 Sep 2014 07:56:08 +0000
Subject: [dba-SQLServer] Fwd: SQL Server Primary Key
Message-ID: <4592f8fcd4e049cdabc159d92f3cb9c2@AMSPR06MB357.eurprd06.prod.outlook.com>

Hi Susan

Well, before we bash this guy to the ground ... if he has 100 mio. records with no duplicate call time entry, I think he will do just fine.

Also, sometimes you ask for alternatives or opinions, but if those you receive are those you know of and may have rejected for some reason, your preferred alternative will not change.

/gustav

-----Oprindelig meddelelse-----
Fra: dba-sqlserver-bounces at databaseadvisors.com [mailto:dba-sqlserver-bounces at databaseadvisors.com] P? vegne af Susan Harkins
Sendt: 4. september 2014 03:34
Til: Discussion concerning MS SQL Server
Emne: Re: [dba-SQLServer] Fwd: SQL Server Primary Key

Well, I sent him all of the recommendations and he did exactly what he proposed to do in the first place. I have no idea why he asked for my opinion. :)

I wish him well!

Susan H. 



From ssharkins at gmail.com  Thu Sep  4 07:23:13 2014
From: ssharkins at gmail.com (Susan Harkins)
Date: Thu, 4 Sep 2014 08:23:13 -0400
Subject: [dba-SQLServer] Fwd: SQL Server Primary Key
Message-ID: <CA++Sg+fc2JLsFF6OAuUn7sBZv__k06yrZTRdNf03OmXfYsuHUQ@mail.gmail.com>

Well, Martin and I wrote the pk natural/surrogate article a few years back.
:) I could do it again, but I'd have a hard time selling it -- right now,
I'm writing about Office and that's pretty much it. The audience
appreciates an occasional Access technique, but I think the discussion
might not fit that crowd.

I enjoyed the discussion though. :)

Susan H.

>
>
> You can write an article on the general topic of factors to consider when
> selecting a primary key and cite - without embarrassing this guy by calling
> him out by name - the specific scenario/application/query that he presented
> to you.  Your article title might be something like: "Primary Keys:
> Artificial Key Or AutoNumber Key?" or something like that.  (There's plenty
> of discussion of this topic in various database theory books.)
>

From ssharkins at gmail.com  Thu Sep  4 07:24:57 2014
From: ssharkins at gmail.com (Susan Harkins)
Date: Thu, 4 Sep 2014 08:24:57 -0400
Subject: [dba-SQLServer] Fwd: SQL Server Primary Key
Message-ID: <CA++Sg+cv+t=OtKjJ24=TYsnD86EM2e8v=_YMbB9b=+HO8G7abQ@mail.gmail.com>

He'll need more help than I can provide -- way over my head -- at least for
free. :)

Susan H.


On Wed, Sep 3, 2014 at 9:36 PM, Francisco Tapia <fhtapia at gmail.com> wrote:

> When he ends up with duplicate records errors he may ask again (:
>
>
> Some people just love natural keys.
> ?
>

From ssharkins at gmail.com  Thu Sep  4 17:15:57 2014
From: ssharkins at gmail.com (Susan Harkins)
Date: Thu, 4 Sep 2014 18:15:57 -0400
Subject: [dba-SQLServer] Fwd: SQL Server Primary Key
In-Reply-To: <4592f8fcd4e049cdabc159d92f3cb9c2@AMSPR06MB357.eurprd06.prod.outlook.com>
References: <4592f8fcd4e049cdabc159d92f3cb9c2@AMSPR06MB357.eurprd06.prod.outlook.com>
Message-ID: <CA++Sg+cFW3Q8+JDwYBJgopYzF7LA4b88FM+zbDxrs2FRvA2uAg@mail.gmail.com>

Oh, I don't mind being a sound board at all Gustav. I hope it works great
for him. No ill feelings on my part. :)

Susan H.


On Thu, Sep 4, 2014 at 3:56 AM, Gustav Brock <gustav at cactus.dk> wrote:

> Hi Susan
>
> Well, before we bash this guy to the ground ... if he has 100 mio. records
> with no duplicate call time entry, I think he will do just fine.
>
> Also, sometimes you ask for alternatives or opinions, but if those you
> receive are those you know of and may have rejected for some reason, your
> preferred alternative will not change.
>
> /gustav
>
> -----Oprindelig meddelelse-----
> Fra: dba-sqlserver-bounces at databaseadvisors.com [mailto:
> dba-sqlserver-bounces at databaseadvisors.com] P? vegne af Susan Harkins
> Sendt: 4. september 2014 03:34
> Til: Discussion concerning MS SQL Server
> Emne: Re: [dba-SQLServer] Fwd: SQL Server Primary Key
>
> Well, I sent him all of the recommendations and he did exactly what he
> proposed to do in the first place. I have no idea why he asked for my
> opinion. :)
>
> I wish him well!
>
> Susan H.
>
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>

From darryl at whittleconsulting.com.au  Tue Sep  9 01:28:25 2014
From: darryl at whittleconsulting.com.au (Darryl Collins)
Date: Tue, 9 Sep 2014 06:28:25 +0000
Subject: [dba-SQLServer] "SELECT @SQL" - A bit lost.
Message-ID: <e1848a60744943f1ac241478e752c3b6@HKXPR04MB360.apcprd04.prod.outlook.com>

Hi everyone,

I have done this sort of thing in the past and it has worked fine, but I cannot seem to get this to work.

I am taking this approach as I am passing thru the table name as a variable plus using IF statements to alter the code depending of certain criteria

I could just rewrite these into numerous stored procs with fixed table names and criteria without all of this bother, but this way seemed neater and more elegant - I have used this approach a lot in VBA without issue.

Anyone got any suggestions as to why the 'EXEC (@SQL)' returns nothing?  - oh, I have checked that it should return 'something' - and indeed stripped out all of the criteria so it has to return something, but I get nothing.  The SQL string doesn't seem to build in the Sproc at all.   It is hopefully something stupid and obvious I have done here.

Using 2012 Express.

Cheers
Darryl.

'==============================================================
ALTER PROCEDURE [dbo].[spBuildInOut_Summary_SPOnly]

@Procedure NVARCHAR(100),
@SourceTable NVARCHAR(100),
@ProdClassType int,
@ProdClassName int,
@ProdName int,
@Activity int,
@MatClassName int


AS
BEGIN
	-- SELECT NOCOUNT ON added to prevent extra result SELECTs from
	-- interfering with SELECT statements.
	SET NOCOUNT ON;


DECLARE @SQL NVARCHAR(Max)

        SELECT @SQL = 'INSERT INTO'
        SELECT @SQL = @SQL + ' Temp_tblEveSteps_Temp'
        SELECT @SQL = @SQL + '('
        SELECT @SQL = @SQL + 'ProcedureClassType,'
        SELECT @SQL = @SQL + ' ProcedureClassName,'
        SELECT @SQL = @SQL + ' ProcedureName,'
        SELECT @SQL = @SQL + ' MaterialClassName,'
        SELECT @SQL = @SQL + ' MaterialTypeName,'
        SELECT @SQL = @SQL + ' QuantityTypeName,'
        SELECT @SQL = @SQL + ' SeqID_ProcClassManual,'
        SELECT @SQL = @SQL + ' SeqID_QuanType,'
        SELECT @SQL = @SQL + ' SeqID_MatClassType,'
        SELECT @SQL = @SQL + ' PortionType,'
        SELECT @SQL = @SQL + ' Activity,'
        SELECT @SQL = @SQL + ' ActivityFocus,'
        SELECT @SQL = @SQL + ' FromActivity,'
        SELECT @SQL = @SQL + ' FromFocus'
        SELECT @SQL = @SQL + ')'
		
        SELECT @SQL = @SQL + ' SELECT'
        SELECT @SQL = @SQL + ' ProcedureClassType,'
        SELECT @SQL = @SQL + ' ProcedureClassName,'
        SELECT @SQL = @SQL + ' ProcedureName,'
        SELECT @SQL = @SQL + ' MaterialClassName,'
        SELECT @SQL = @SQL + ' MaterialTypeName,'
        SELECT @SQL = @SQL + ' QuantityTypeName,'
        SELECT @SQL = @SQL + ' SeqID_ProcClassManual,'
        SELECT @SQL = @SQL + ' SeqID_QuanType,'
        SELECT @SQL = @SQL + ' SeqID_MatClassType,'
        SELECT @SQL = @SQL + ' PortionType,'
        SELECT @SQL = @SQL + ' Activity,'
        SELECT @SQL = @SQL + ' ActivityFocus,'
        SELECT @SQL = @SQL + ' FromActivity,'
        SELECT @SQL = @SQL + ' FromFocus'
        SELECT @SQL = @SQL + ' FROM ' + @SourceTable + ''
       
        SELECT @SQL = @SQL + ' GROUP BY'
        SELECT @SQL = @SQL + ' ProcedureClassType,'
        SELECT @SQL = @SQL + ' ProcedureClassName,'
        SELECT @SQL = @SQL + ' ProcedureName,'
        SELECT @SQL = @SQL + ' MaterialClassName,'
        SELECT @SQL = @SQL + ' MaterialTypeName,'
        SELECT @SQL = @SQL + ' QuantityTypeName,'
        SELECT @SQL = @SQL + ' SeqID_ProcClassManual,'
        SELECT @SQL = @SQL + ' SeqID_QuanType,'
        SELECT @SQL = @SQL + ' SeqID_MatClassType,'
        SELECT @SQL = @SQL + ' PortionType,'
        SELECT @SQL = @SQL + ' Activity,'
        SELECT @SQL = @SQL + ' ActivityFocus,'
        SELECT @SQL = @SQL + ' FromActivity,'
        SELECT @SQL = @SQL + ' FromFocus'
    
        SELECT @SQL = @SQL + ' HAVING ProcedureClassType = ' + CAST(@ProdClassType as NVARCHAR(6)) + ''
        SELECT @SQL = @SQL + ' AND ProcedureClassName =  ' + CAST(@ProdClassName as NVARCHAR(6)) + ''
    
		-------------------------------------------------------------------------------------------------------
        If @Procedure = 'Mining'
                SELECT @SQL = @SQL + ' AND ProcedureName = ' + CAST(@ProdName as nvarchar(6)) + ''

		If @Procedure = 'Downstream'
                SELECT @SQL = @SQL + ' AND ProcedureName = ' + CAST(@ProdName as nvarchar(6)) + ''
		-------------------------------------------------------------------------------------------------------
        
        If @Procedure = 'Stockpile'
			SELECT @SQL = @SQL + ' AND ActivityFocus = ' + CAST(@Activity as nvarchar(6)) + ''
		
		ELSE IF @Procedure = 'Discard'
			SELECT @SQL = @SQL + ' AND ActivityFocus = ' + CAST(@Activity as nvarchar(6)) + ''

		ELSE IF @Procedure = 'Rehandle'
			SELECT @SQL = @SQL + ' AND FromActivity = ' + CAST(@Activity as nvarchar(6)) + ''

		ELSE
			SELECT @SQL = @SQL + ' AND Activity = ' + CAST(@Activity as nvarchar(6)) + ''
		-------------------------------------------------------------------------------------------------------

        SELECT @SQL = @SQL + ' AND MaterialClassName = ' + CAST(@MatClassName as NVARCHAR(6)) + ''
	

        EXECUTE (@SQL)

END


From newsgrps at dalyn.co.nz  Tue Sep  9 01:52:53 2014
From: newsgrps at dalyn.co.nz (David Emerson)
Date: Tue, 9 Sep 2014 18:52:53 +1200
Subject: [dba-SQLServer] "SELECT @SQL" - A bit lost.
In-Reply-To: <e1848a60744943f1ac241478e752c3b6@HKXPR04MB360.apcprd04.prod.outlook.com>
References: <e1848a60744943f1ac241478e752c3b6@HKXPR04MB360.apcprd04.prod.outlook.com>
Message-ID: <00cf01cfcbfa$ae434360$0ac9ca20$@dalyn.co.nz>

Hi Darryl,

Have you tried putting PRINT(@SQL) at the end of the procedure to see that
the string is creating correctly?

Regards

David Emerson
Dalyn Software Ltd
Wellington, New Zealand



-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Darryl
Collins
Sent: Tuesday, 9 September 2014 6:28 p.m.
To: Discussion concerning MS SQL Server
Subject: [dba-SQLServer] "SELECT @SQL" - A bit lost.

Hi everyone,

I have done this sort of thing in the past and it has worked fine, but I
cannot seem to get this to work.

I am taking this approach as I am passing thru the table name as a variable
plus using IF statements to alter the code depending of certain criteria

I could just rewrite these into numerous stored procs with fixed table names
and criteria without all of this bother, but this way seemed neater and more
elegant - I have used this approach a lot in VBA without issue.

Anyone got any suggestions as to why the 'EXEC (@SQL)' returns nothing?  -
oh, I have checked that it should return 'something' - and indeed stripped
out all of the criteria so it has to return something, but I get nothing.
The SQL string doesn't seem to build in the Sproc at all.   It is hopefully
something stupid and obvious I have done here.

Using 2012 Express.

Cheers
Darryl.

'==============================================================
ALTER PROCEDURE [dbo].[spBuildInOut_Summary_SPOnly]

@Procedure NVARCHAR(100),
@SourceTable NVARCHAR(100),
@ProdClassType int,
@ProdClassName int,
@ProdName int,
@Activity int,
@MatClassName int


AS
BEGIN
	-- SELECT NOCOUNT ON added to prevent extra result SELECTs from
	-- interfering with SELECT statements.
	SET NOCOUNT ON;


DECLARE @SQL NVARCHAR(Max)

        SELECT @SQL = 'INSERT INTO'
        SELECT @SQL = @SQL + ' Temp_tblEveSteps_Temp'
        SELECT @SQL = @SQL + '('
        SELECT @SQL = @SQL + 'ProcedureClassType,'
        SELECT @SQL = @SQL + ' ProcedureClassName,'
        SELECT @SQL = @SQL + ' ProcedureName,'
        SELECT @SQL = @SQL + ' MaterialClassName,'
        SELECT @SQL = @SQL + ' MaterialTypeName,'
        SELECT @SQL = @SQL + ' QuantityTypeName,'
        SELECT @SQL = @SQL + ' SeqID_ProcClassManual,'
        SELECT @SQL = @SQL + ' SeqID_QuanType,'
        SELECT @SQL = @SQL + ' SeqID_MatClassType,'
        SELECT @SQL = @SQL + ' PortionType,'
        SELECT @SQL = @SQL + ' Activity,'
        SELECT @SQL = @SQL + ' ActivityFocus,'
        SELECT @SQL = @SQL + ' FromActivity,'
        SELECT @SQL = @SQL + ' FromFocus'
        SELECT @SQL = @SQL + ')'
		
        SELECT @SQL = @SQL + ' SELECT'
        SELECT @SQL = @SQL + ' ProcedureClassType,'
        SELECT @SQL = @SQL + ' ProcedureClassName,'
        SELECT @SQL = @SQL + ' ProcedureName,'
        SELECT @SQL = @SQL + ' MaterialClassName,'
        SELECT @SQL = @SQL + ' MaterialTypeName,'
        SELECT @SQL = @SQL + ' QuantityTypeName,'
        SELECT @SQL = @SQL + ' SeqID_ProcClassManual,'
        SELECT @SQL = @SQL + ' SeqID_QuanType,'
        SELECT @SQL = @SQL + ' SeqID_MatClassType,'
        SELECT @SQL = @SQL + ' PortionType,'
        SELECT @SQL = @SQL + ' Activity,'
        SELECT @SQL = @SQL + ' ActivityFocus,'
        SELECT @SQL = @SQL + ' FromActivity,'
        SELECT @SQL = @SQL + ' FromFocus'
        SELECT @SQL = @SQL + ' FROM ' + @SourceTable + ''
       
        SELECT @SQL = @SQL + ' GROUP BY'
        SELECT @SQL = @SQL + ' ProcedureClassType,'
        SELECT @SQL = @SQL + ' ProcedureClassName,'
        SELECT @SQL = @SQL + ' ProcedureName,'
        SELECT @SQL = @SQL + ' MaterialClassName,'
        SELECT @SQL = @SQL + ' MaterialTypeName,'
        SELECT @SQL = @SQL + ' QuantityTypeName,'
        SELECT @SQL = @SQL + ' SeqID_ProcClassManual,'
        SELECT @SQL = @SQL + ' SeqID_QuanType,'
        SELECT @SQL = @SQL + ' SeqID_MatClassType,'
        SELECT @SQL = @SQL + ' PortionType,'
        SELECT @SQL = @SQL + ' Activity,'
        SELECT @SQL = @SQL + ' ActivityFocus,'
        SELECT @SQL = @SQL + ' FromActivity,'
        SELECT @SQL = @SQL + ' FromFocus'
    
        SELECT @SQL = @SQL + ' HAVING ProcedureClassType = ' +
CAST(@ProdClassType as NVARCHAR(6)) + ''
        SELECT @SQL = @SQL + ' AND ProcedureClassName =  ' +
CAST(@ProdClassName as NVARCHAR(6)) + ''
    
	
----------------------------------------------------------------------------
---------------------------
        If @Procedure = 'Mining'
                SELECT @SQL = @SQL + ' AND ProcedureName = ' +
CAST(@ProdName as nvarchar(6)) + ''

		If @Procedure = 'Downstream'
                SELECT @SQL = @SQL + ' AND ProcedureName = ' +
CAST(@ProdName as nvarchar(6)) + ''
	
----------------------------------------------------------------------------
---------------------------
        
        If @Procedure = 'Stockpile'
			SELECT @SQL = @SQL + ' AND ActivityFocus = ' +
CAST(@Activity as nvarchar(6)) + ''
		
		ELSE IF @Procedure = 'Discard'
			SELECT @SQL = @SQL + ' AND ActivityFocus = ' +
CAST(@Activity as nvarchar(6)) + ''

		ELSE IF @Procedure = 'Rehandle'
			SELECT @SQL = @SQL + ' AND FromActivity = ' +
CAST(@Activity as nvarchar(6)) + ''

		ELSE
			SELECT @SQL = @SQL + ' AND Activity = ' +
CAST(@Activity as nvarchar(6)) + ''
	
----------------------------------------------------------------------------
---------------------------

        SELECT @SQL = @SQL + ' AND MaterialClassName = ' +
CAST(@MatClassName as NVARCHAR(6)) + ''
	

        EXECUTE (@SQL)

END

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


From marklbreen at gmail.com  Tue Sep  9 03:20:20 2014
From: marklbreen at gmail.com (Mark Breen)
Date: Tue, 9 Sep 2014 09:20:20 +0100
Subject: [dba-SQLServer] "SELECT @SQL" - A bit lost.
In-Reply-To: <00cf01cfcbfa$ae434360$0ac9ca20$@dalyn.co.nz>
References: <e1848a60744943f1ac241478e752c3b6@HKXPR04MB360.apcprd04.prod.outlook.com>
	<00cf01cfcbfa$ae434360$0ac9ca20$@dalyn.co.nz>
Message-ID: <CAGXtTCgOsgnxyAK3xVMVD1L2Be6Pe-3CkPd+t8C9Asww6+kE0A@mail.gmail.com>

Hi Darryl,

Just curious why you have '' at the end of some lines, eg SELECT @SQL =
@SQL + ' AND MaterialClassName = ' + CAST(@MatClassName as NVARCHAR(6)) + ''

I am guessing you are using them as some sort of closing exercise, but
curious what the reason is ?

Re your problem, I would do my usual trick of back to the beginnning and
evaluate each step, getting them to known good before moving on.

Are the inserts working, are they clean?
Is the first If firing?

Sometimes in a longish sproc, I introduce a variable
Declare @FireNotifications bit = 1

And then in various sections of the sproc, I include one discreet line
similar to the following
If @FireNotifications = 1 Select @Procedure

At other times, I do this
If @FireNotifications =1 Insert into LogTable (Values.....) Select MyValues
to review when proc is finished......

Sorry I could not see the problem


HTH



On 9 September 2014 07:52, David Emerson <newsgrps at dalyn.co.nz> wrote:

> Hi Darryl,
>
> Have you tried putting PRINT(@SQL) at the end of the procedure to see that
> the string is creating correctly?
>
> Regards
>
> David Emerson
> Dalyn Software Ltd
> Wellington, New Zealand
>
>
>
> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Darryl
> Collins
> Sent: Tuesday, 9 September 2014 6:28 p.m.
> To: Discussion concerning MS SQL Server
> Subject: [dba-SQLServer] "SELECT @SQL" - A bit lost.
>
> Hi everyone,
>
> I have done this sort of thing in the past and it has worked fine, but I
> cannot seem to get this to work.
>
> I am taking this approach as I am passing thru the table name as a variable
> plus using IF statements to alter the code depending of certain criteria
>
> I could just rewrite these into numerous stored procs with fixed table
> names
> and criteria without all of this bother, but this way seemed neater and
> more
> elegant - I have used this approach a lot in VBA without issue.
>
> Anyone got any suggestions as to why the 'EXEC (@SQL)' returns nothing?  -
> oh, I have checked that it should return 'something' - and indeed stripped
> out all of the criteria so it has to return something, but I get nothing.
> The SQL string doesn't seem to build in the Sproc at all.   It is hopefully
> something stupid and obvious I have done here.
>
> Using 2012 Express.
>
> Cheers
> Darryl.
>
> '==============================================================
> ALTER PROCEDURE [dbo].[spBuildInOut_Summary_SPOnly]
>
> @Procedure NVARCHAR(100),
> @SourceTable NVARCHAR(100),
> @ProdClassType int,
> @ProdClassName int,
> @ProdName int,
> @Activity int,
> @MatClassName int
>
>
> AS
> BEGIN
>         -- SELECT NOCOUNT ON added to prevent extra result SELECTs from
>         -- interfering with SELECT statements.
>         SET NOCOUNT ON;
>
>
> DECLARE @SQL NVARCHAR(Max)
>
>         SELECT @SQL = 'INSERT INTO'
>         SELECT @SQL = @SQL + ' Temp_tblEveSteps_Temp'
>         SELECT @SQL = @SQL + '('
>         SELECT @SQL = @SQL + 'ProcedureClassType,'
>         SELECT @SQL = @SQL + ' ProcedureClassName,'
>         SELECT @SQL = @SQL + ' ProcedureName,'
>         SELECT @SQL = @SQL + ' MaterialClassName,'
>         SELECT @SQL = @SQL + ' MaterialTypeName,'
>         SELECT @SQL = @SQL + ' QuantityTypeName,'
>         SELECT @SQL = @SQL + ' SeqID_ProcClassManual,'
>         SELECT @SQL = @SQL + ' SeqID_QuanType,'
>         SELECT @SQL = @SQL + ' SeqID_MatClassType,'
>         SELECT @SQL = @SQL + ' PortionType,'
>         SELECT @SQL = @SQL + ' Activity,'
>         SELECT @SQL = @SQL + ' ActivityFocus,'
>         SELECT @SQL = @SQL + ' FromActivity,'
>         SELECT @SQL = @SQL + ' FromFocus'
>         SELECT @SQL = @SQL + ')'
>
>         SELECT @SQL = @SQL + ' SELECT'
>         SELECT @SQL = @SQL + ' ProcedureClassType,'
>         SELECT @SQL = @SQL + ' ProcedureClassName,'
>         SELECT @SQL = @SQL + ' ProcedureName,'
>         SELECT @SQL = @SQL + ' MaterialClassName,'
>         SELECT @SQL = @SQL + ' MaterialTypeName,'
>         SELECT @SQL = @SQL + ' QuantityTypeName,'
>         SELECT @SQL = @SQL + ' SeqID_ProcClassManual,'
>         SELECT @SQL = @SQL + ' SeqID_QuanType,'
>         SELECT @SQL = @SQL + ' SeqID_MatClassType,'
>         SELECT @SQL = @SQL + ' PortionType,'
>         SELECT @SQL = @SQL + ' Activity,'
>         SELECT @SQL = @SQL + ' ActivityFocus,'
>         SELECT @SQL = @SQL + ' FromActivity,'
>         SELECT @SQL = @SQL + ' FromFocus'
>         SELECT @SQL = @SQL + ' FROM ' + @SourceTable + ''
>
>         SELECT @SQL = @SQL + ' GROUP BY'
>         SELECT @SQL = @SQL + ' ProcedureClassType,'
>         SELECT @SQL = @SQL + ' ProcedureClassName,'
>         SELECT @SQL = @SQL + ' ProcedureName,'
>         SELECT @SQL = @SQL + ' MaterialClassName,'
>         SELECT @SQL = @SQL + ' MaterialTypeName,'
>         SELECT @SQL = @SQL + ' QuantityTypeName,'
>         SELECT @SQL = @SQL + ' SeqID_ProcClassManual,'
>         SELECT @SQL = @SQL + ' SeqID_QuanType,'
>         SELECT @SQL = @SQL + ' SeqID_MatClassType,'
>         SELECT @SQL = @SQL + ' PortionType,'
>         SELECT @SQL = @SQL + ' Activity,'
>         SELECT @SQL = @SQL + ' ActivityFocus,'
>         SELECT @SQL = @SQL + ' FromActivity,'
>         SELECT @SQL = @SQL + ' FromFocus'
>
>         SELECT @SQL = @SQL + ' HAVING ProcedureClassType = ' +
> CAST(@ProdClassType as NVARCHAR(6)) + ''
>         SELECT @SQL = @SQL + ' AND ProcedureClassName =  ' +
> CAST(@ProdClassName as NVARCHAR(6)) + ''
>
>
>
> ----------------------------------------------------------------------------
> ---------------------------
>         If @Procedure = 'Mining'
>                 SELECT @SQL = @SQL + ' AND ProcedureName = ' +
> CAST(@ProdName as nvarchar(6)) + ''
>
>                 If @Procedure = 'Downstream'
>                 SELECT @SQL = @SQL + ' AND ProcedureName = ' +
> CAST(@ProdName as nvarchar(6)) + ''
>
>
> ----------------------------------------------------------------------------
> ---------------------------
>
>         If @Procedure = 'Stockpile'
>                         SELECT @SQL = @SQL + ' AND ActivityFocus = ' +
> CAST(@Activity as nvarchar(6)) + ''
>
>                 ELSE IF @Procedure = 'Discard'
>                         SELECT @SQL = @SQL + ' AND ActivityFocus = ' +
> CAST(@Activity as nvarchar(6)) + ''
>
>                 ELSE IF @Procedure = 'Rehandle'
>                         SELECT @SQL = @SQL + ' AND FromActivity = ' +
> CAST(@Activity as nvarchar(6)) + ''
>
>                 ELSE
>                         SELECT @SQL = @SQL + ' AND Activity = ' +
> CAST(@Activity as nvarchar(6)) + ''
>
>
> ----------------------------------------------------------------------------
> ---------------------------
>
>         SELECT @SQL = @SQL + ' AND MaterialClassName = ' +
> CAST(@MatClassName as NVARCHAR(6)) + ''
>
>
>         EXECUTE (@SQL)
>
> END
>
> _______________________________________________
> 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 at whittleconsulting.com.au  Tue Sep  9 03:41:18 2014
From: darryl at whittleconsulting.com.au (Darryl Collins)
Date: Tue, 9 Sep 2014 08:41:18 +0000
Subject: [dba-SQLServer] "SELECT @SQL" - A bit lost.
In-Reply-To: <00cf01cfcbfa$ae434360$0ac9ca20$@dalyn.co.nz>
References: <e1848a60744943f1ac241478e752c3b6@HKXPR04MB360.apcprd04.prod.outlook.com>,
	<00cf01cfcbfa$ae434360$0ac9ca20$@dalyn.co.nz>
Message-ID: <omy5pn3dycttpniprwl0c6g7.1410252073773@email.android.com>

Yep. And I get nothing.  Not sure why as it looks ok. Clearly I am missing something here. Hmmm.


Sent from my Galaxy Note II. Please excuse any gibberish and/or brevity.


-------- Original message --------
From: David Emerson
Date:09/09/2014 16:55 (GMT+10:00)
To: 'Discussion concerning MS SQL Server'
Subject: Re: [dba-SQLServer] "SELECT @SQL" - A bit lost.

Hi Darryl,

Have you tried putting PRINT(@SQL) at the end of the procedure to see that
the string is creating correctly?

Regards

David Emerson
Dalyn Software Ltd
Wellington, New Zealand



-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Darryl
Collins
Sent: Tuesday, 9 September 2014 6:28 p.m.
To: Discussion concerning MS SQL Server
Subject: [dba-SQLServer] "SELECT @SQL" - A bit lost.

Hi everyone,

I have done this sort of thing in the past and it has worked fine, but I
cannot seem to get this to work.

I am taking this approach as I am passing thru the table name as a variable
plus using IF statements to alter the code depending of certain criteria

I could just rewrite these into numerous stored procs with fixed table names
and criteria without all of this bother, but this way seemed neater and more
elegant - I have used this approach a lot in VBA without issue.

Anyone got any suggestions as to why the 'EXEC (@SQL)' returns nothing?  -
oh, I have checked that it should return 'something' - and indeed stripped
out all of the criteria so it has to return something, but I get nothing.
The SQL string doesn't seem to build in the Sproc at all.   It is hopefully
something stupid and obvious I have done here.

Using 2012 Express.

Cheers
Darryl.

'==============================================================
ALTER PROCEDURE [dbo].[spBuildInOut_Summary_SPOnly]

@Procedure NVARCHAR(100),
@SourceTable NVARCHAR(100),
@ProdClassType int,
@ProdClassName int,
@ProdName int,
@Activity int,
@MatClassName int


AS
BEGIN
        -- SELECT NOCOUNT ON added to prevent extra result SELECTs from
        -- interfering with SELECT statements.
        SET NOCOUNT ON;


DECLARE @SQL NVARCHAR(Max)

        SELECT @SQL = 'INSERT INTO'
        SELECT @SQL = @SQL + ' Temp_tblEveSteps_Temp'
        SELECT @SQL = @SQL + '('
        SELECT @SQL = @SQL + 'ProcedureClassType,'
        SELECT @SQL = @SQL + ' ProcedureClassName,'
        SELECT @SQL = @SQL + ' ProcedureName,'
        SELECT @SQL = @SQL + ' MaterialClassName,'
        SELECT @SQL = @SQL + ' MaterialTypeName,'
        SELECT @SQL = @SQL + ' QuantityTypeName,'
        SELECT @SQL = @SQL + ' SeqID_ProcClassManual,'
        SELECT @SQL = @SQL + ' SeqID_QuanType,'
        SELECT @SQL = @SQL + ' SeqID_MatClassType,'
        SELECT @SQL = @SQL + ' PortionType,'
        SELECT @SQL = @SQL + ' Activity,'
        SELECT @SQL = @SQL + ' ActivityFocus,'
        SELECT @SQL = @SQL + ' FromActivity,'
        SELECT @SQL = @SQL + ' FromFocus'
        SELECT @SQL = @SQL + ')'

        SELECT @SQL = @SQL + ' SELECT'
        SELECT @SQL = @SQL + ' ProcedureClassType,'
        SELECT @SQL = @SQL + ' ProcedureClassName,'
        SELECT @SQL = @SQL + ' ProcedureName,'
        SELECT @SQL = @SQL + ' MaterialClassName,'
        SELECT @SQL = @SQL + ' MaterialTypeName,'
        SELECT @SQL = @SQL + ' QuantityTypeName,'
        SELECT @SQL = @SQL + ' SeqID_ProcClassManual,'
        SELECT @SQL = @SQL + ' SeqID_QuanType,'
        SELECT @SQL = @SQL + ' SeqID_MatClassType,'
        SELECT @SQL = @SQL + ' PortionType,'
        SELECT @SQL = @SQL + ' Activity,'
        SELECT @SQL = @SQL + ' ActivityFocus,'
        SELECT @SQL = @SQL + ' FromActivity,'
        SELECT @SQL = @SQL + ' FromFocus'
        SELECT @SQL = @SQL + ' FROM ' + @SourceTable + ''

        SELECT @SQL = @SQL + ' GROUP BY'
        SELECT @SQL = @SQL + ' ProcedureClassType,'
        SELECT @SQL = @SQL + ' ProcedureClassName,'
        SELECT @SQL = @SQL + ' ProcedureName,'
        SELECT @SQL = @SQL + ' MaterialClassName,'
        SELECT @SQL = @SQL + ' MaterialTypeName,'
        SELECT @SQL = @SQL + ' QuantityTypeName,'
        SELECT @SQL = @SQL + ' SeqID_ProcClassManual,'
        SELECT @SQL = @SQL + ' SeqID_QuanType,'
        SELECT @SQL = @SQL + ' SeqID_MatClassType,'
        SELECT @SQL = @SQL + ' PortionType,'
        SELECT @SQL = @SQL + ' Activity,'
        SELECT @SQL = @SQL + ' ActivityFocus,'
        SELECT @SQL = @SQL + ' FromActivity,'
        SELECT @SQL = @SQL + ' FromFocus'

        SELECT @SQL = @SQL + ' HAVING ProcedureClassType = ' +
CAST(@ProdClassType as NVARCHAR(6)) + ''
        SELECT @SQL = @SQL + ' AND ProcedureClassName =  ' +
CAST(@ProdClassName as NVARCHAR(6)) + ''


----------------------------------------------------------------------------
---------------------------
        If @Procedure = 'Mining'
                SELECT @SQL = @SQL + ' AND ProcedureName = ' +
CAST(@ProdName as nvarchar(6)) + ''

                If @Procedure = 'Downstream'
                SELECT @SQL = @SQL + ' AND ProcedureName = ' +
CAST(@ProdName as nvarchar(6)) + ''

----------------------------------------------------------------------------
---------------------------

        If @Procedure = 'Stockpile'
                        SELECT @SQL = @SQL + ' AND ActivityFocus = ' +
CAST(@Activity as nvarchar(6)) + ''

                ELSE IF @Procedure = 'Discard'
                        SELECT @SQL = @SQL + ' AND ActivityFocus = ' +
CAST(@Activity as nvarchar(6)) + ''

                ELSE IF @Procedure = 'Rehandle'
                        SELECT @SQL = @SQL + ' AND FromActivity = ' +
CAST(@Activity as nvarchar(6)) + ''

                ELSE
                        SELECT @SQL = @SQL + ' AND Activity = ' +
CAST(@Activity as nvarchar(6)) + ''

----------------------------------------------------------------------------
---------------------------

        SELECT @SQL = @SQL + ' AND MaterialClassName = ' +
CAST(@MatClassName as NVARCHAR(6)) + ''


        EXECUTE (@SQL)

END

_______________________________________________
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 at whittleconsulting.com.au  Tue Sep  9 20:58:43 2014
From: darryl at whittleconsulting.com.au (Darryl Collins)
Date: Wed, 10 Sep 2014 01:58:43 +0000
Subject: [dba-SQLServer] "SELECT @SQL" - A bit lost.
In-Reply-To: <omy5pn3dycttpniprwl0c6g7.1410252073773@email.android.com>
References: <e1848a60744943f1ac241478e752c3b6@HKXPR04MB360.apcprd04.prod.outlook.com>,
	<00cf01cfcbfa$ae434360$0ac9ca20$@dalyn.co.nz>
	<omy5pn3dycttpniprwl0c6g7.1410252073773@email.android.com>
Message-ID: <ecd097b278b245579527768ddad9c816@HKXPR04MB360.apcprd04.prod.outlook.com>

Ok.... I seem to have this one working ok now - largely thanks to some guidance from you folks - so a big thank you for your advice and feedback.

As suspected - it was partly an issue of ignorance and tiredness.  I actually had two problems to correct.  

The first one corrected id'd by David Lewis being the IF statements in the SPROC were not correctly formed.  I did try this yesterday, but clearly I fouled it up as today it is working fine.

The 2nd issue was the VBA code I use to pass the parameter to SQL server was not set up correctly - I was passing thru a couple of the parameters in the wrong order. That was easy enough to spot once I got the SPROC to manually fire correctly.

Mark was asking about the use of the syntax using CAST

SELECT @SQL = @SQL + ' AND MaterialClassName = ' + CAST(@MatClassName as NVARCHAR(6)) + ''

The reason I need to do this is the Server is expected to execute a string and unlike VBA built strings you need to explicitly convert anything that is not a string (so all the integer parameters passed into the sproc in this example) into strings *before* it is executed.  You can use either CAST or CONVERT for this.  I have always used CAST which has performed flawlessly, but that comes down to ignorance and luck.  There may be a good / better reason to use CONVERT instead but as CAST has always worked for me I have been happy to stick with it for now.

The VBA that passes the parameters is below - this works great now I have the darn append parameter lines in the correct sequence.

'============================================================================================================
Public Function BuildInOut_Summary_SPOnly_SSSP(Procedure As String, _
                                        SourceTable As String, _
                                        ProdClassType As Integer, _
                                        ProdClassName As Integer, _
                                        ProdName As Integer, _
                                        Activity As Integer, _
                                        MatClassName As Integer _
                                        ) As Boolean
    

    Dim cmd As New ADODB.Command
    
    On Error GoTo ErrHandle
    
    With cmd
        .ActiveConnection = gDbADOConStr
        .CommandType = adCmdStoredProc
        .CommandText = "spBuildInOut_Summary_SPOnly"
    End With
    
    With cmd.Parameters
        .Append cmd.CreateParameter("Procedure", adVarChar, adParamInput, 100, Procedure)
        .Append cmd.CreateParameter("SourceTable", adVarChar, adParamInput, 100, SourceTable)
        .Append cmd.CreateParameter("ProdClassType", adInteger, adParamInput, , ProdClassType)
        .Append cmd.CreateParameter("ProdClassName", adInteger, adParamInput, , ProdClassName)
        .Append cmd.CreateParameter("ProdName", adInteger, adParamInput, , ProdName)
        .Append cmd.CreateParameter("Activity", adInteger, adParamInput, , Activity)
        .Append cmd.CreateParameter("MatClassName", adInteger, adParamInput, , MatClassName)
    End With
    
    cmd.Execute
    Set cmd = Nothing
    
Exit Function

ErrHandle:

BuildInOut_Summary_SPOnly_SSSP = False
    
End Function
'============================================================================================================

So the functional SQL SERVER SPROC code looks like this now:

ALTER PROCEDURE [dbo].[spBuildInOut_Summary_SPOnly]

@Procedure NVARCHAR(100),
@SourceTable NVARCHAR(100),
@ProdClassType int,
@ProdClassName int,
@ProdName int,
@Activity int,
@MatClassName int


AS
BEGIN
	-- SELECT NOCOUNT ON added to prevent extra result SELECTs from
	-- interfering with SELECT statements.
	SET NOCOUNT ON;


DECLARE @SQL NVARCHAR(Max)

        SELECT @SQL = 'INSERT INTO'
        SELECT @SQL = @SQL + ' Temp_tblEveSteps_Temp'
        SELECT @SQL = @SQL + '('
        SELECT @SQL = @SQL + 'ProcedureClassType,'
        SELECT @SQL = @SQL + ' ProcedureClassName,'
        SELECT @SQL = @SQL + ' ProcedureName,'
        SELECT @SQL = @SQL + ' MaterialClassName,'
        SELECT @SQL = @SQL + ' MaterialTypeName,'
        SELECT @SQL = @SQL + ' QuantityTypeName,'
        SELECT @SQL = @SQL + ' SeqID_ProcClassManual,'
        SELECT @SQL = @SQL + ' SeqID_QuanType,'
        SELECT @SQL = @SQL + ' SeqID_MatClassType,'
        SELECT @SQL = @SQL + ' PortionType,'
        SELECT @SQL = @SQL + ' Activity,'
        SELECT @SQL = @SQL + ' ActivityFocus,'
        SELECT @SQL = @SQL + ' FromActivity,'
        SELECT @SQL = @SQL + ' FromFocus'
        SELECT @SQL = @SQL + ')'
		
        SELECT @SQL = @SQL + ' SELECT'
        SELECT @SQL = @SQL + ' ProcedureClassType,'
        SELECT @SQL = @SQL + ' ProcedureClassName,'
        SELECT @SQL = @SQL + ' ProcedureName,'
        SELECT @SQL = @SQL + ' MaterialClassName,'
        SELECT @SQL = @SQL + ' MaterialTypeName,'
        SELECT @SQL = @SQL + ' QuantityTypeName,'
        SELECT @SQL = @SQL + ' SeqID_ProcClassManual,'
        SELECT @SQL = @SQL + ' SeqID_QuanType,'
        SELECT @SQL = @SQL + ' SeqID_MatClassType,'
        SELECT @SQL = @SQL + ' PortionType,'
        SELECT @SQL = @SQL + ' Activity,'
        SELECT @SQL = @SQL + ' ActivityFocus,'
        SELECT @SQL = @SQL + ' FromActivity,'
        SELECT @SQL = @SQL + ' FromFocus'
        SELECT @SQL = @SQL + ' FROM ' + @SourceTable + ''
       
        SELECT @SQL = @SQL + ' GROUP BY'
        SELECT @SQL = @SQL + ' ProcedureClassType,'
        SELECT @SQL = @SQL + ' ProcedureClassName,'
        SELECT @SQL = @SQL + ' ProcedureName,'
        SELECT @SQL = @SQL + ' MaterialClassName,'
        SELECT @SQL = @SQL + ' MaterialTypeName,'
        SELECT @SQL = @SQL + ' QuantityTypeName,'
        SELECT @SQL = @SQL + ' SeqID_ProcClassManual,'
        SELECT @SQL = @SQL + ' SeqID_QuanType,'
        SELECT @SQL = @SQL + ' SeqID_MatClassType,'
        SELECT @SQL = @SQL + ' PortionType,'
        SELECT @SQL = @SQL + ' Activity,'
        SELECT @SQL = @SQL + ' ActivityFocus,'
        SELECT @SQL = @SQL + ' FromActivity,'
        SELECT @SQL = @SQL + ' FromFocus'
    
        SELECT @SQL = @SQL + ' HAVING ProcedureClassType = ' + CAST(@ProdClassType as NVARCHAR(6)) + ''
        SELECT @SQL = @SQL + ' AND ProcedureClassName =  ' + CAST(@ProdClassName as NVARCHAR(6)) + ''
    
		-------------------------------------------------------------------------------------------------------
        If @Procedure = 'Mining'
		BEGIN
                	SELECT @SQL = @SQL + ' AND ProcedureName = ' + CAST(@ProdName as nvarchar(6)) + ''
		END

		If @Procedure = 'Downstream'
		BEGIN
                	SELECT @SQL = @SQL + ' AND ProcedureName = ' + CAST(@ProdName as nvarchar(6)) + ''
		END
		-------------------------------------------------------------------------------------------------------
        
         If @Procedure = 'Stockpile'
		BEGIN
		SELECT @SQL = @SQL + ' AND ActivityFocus = ' + CAST(@Activity as nvarchar(6)) + ''
		END
		
         ELSE IF @Procedure = 'Discard'
		BEGIN
		SELECT @SQL = @SQL + ' AND ActivityFocus = ' + CAST(@Activity as nvarchar(6)) + ''
		END

         ELSE IF @Procedure = 'Rehandle'
		BEGIN
		SELECT @SQL = @SQL + ' AND FromActivity = ' + CAST(@Activity as nvarchar(6)) + ''
		END

         ELSE
		SELECT @SQL = @SQL + ' AND Activity = ' + CAST(@Activity as nvarchar(6)) + ''
		-------------------------------------------------------------------------------------------------------

        SELECT @SQL = @SQL + ' AND MaterialClassName = ' + CAST(@MatClassName as NVARCHAR(6)) + ''
	
		--PRINT @sql

        EXECUTE (@SQL)


END

'============================================================================================================

Thanks everyone.

Cheers
Darryl


From darryl at whittleconsulting.com.au  Tue Sep  9 18:52:53 2014
From: darryl at whittleconsulting.com.au (Darryl Collins)
Date: Tue, 09 Sep 2014 23:52:53 -0000
Subject: [dba-SQLServer] sql string
In-Reply-To: <5b7a2dc1c0824bdfa601e85b8bbfe1c1@cic-ex13mb-03.sierranevada.corp>
References: <5b7a2dc1c0824bdfa601e85b8bbfe1c1@cic-ex13mb-03.sierranevada.corp>
Message-ID: <89fe90fcab0a4aeea1e2a1c970377d8e@HKXPR04MB360.apcprd04.prod.outlook.com>

Thanks David,

Appreciate your thoughts, time and efforts with this.

I did try some BEGIN / END combinations on the IF's but didn't seem to get it right.  Mind you it was getting late in the day and I was frustrated so I will start again fresh today.  Part of the problem will be my own darn ignorance.  I have used SQL Server for years, but my actual knowledge is 'wider' rather than deeper - if that makes sense.  I am pretty much a one trick pony and have done well with that trick but I often struggle when doing some of the more tricky stuff in SQL Server - Google can often help but in this instance I have found nothing for the "ah-hah!" moment.

These little blocks are all good as I will learn some new stuff and better ways to do things so I really appreciate everyone's thoughts and patience here.

I had already tried the (most excellent) suggestion of cutting it down and staring with something simple.
I tried just the SELECT part of the SQL String with a table name hard coded - and I still got nothing - which was a worry.

Anyway - today is a new day and I am feeling fresh.  So time to get cracking after I install my 25 Update Wednesday MS updates and reboot - (yeah, I know it is update Tuesday, but we get them on Wednesday due to those pesky time zones).

Will let you know how all this works out.

Cheers
Darryl

From: David Lewis [mailto:David at sierranevada.com]
Sent: Wednesday, 10 September 2014 1:35 AM
To: Darryl Collins
Subject: sql string

Darryl:

Your issue is at the end with the several IF statements.  After an IF statement explicitly wrap the code to execute within BEGIN    END blocks, as with the following.  Also, you have an ELSE statement that is important, but it is not clear where that ELSE should be evaluated.  Here is non-sproc code to test with.  Also, when you are building strings like this, printing out the string without executing is the way to debug.
Up to the final ELSE statement, I think the code with BEGIN END blocks does what you are expecting.

DECLARE @Procedure NVARCHAR(100), @SourceTable NVARCHAR(100), @ProdClassType int, @ProdClassName int, @ProdName int, @Activity int, @MatClassName int
DECLARE @SQL NVARCHAR(Max)

SET @SourceTable='TestTable'
SET @Procedure='Discard'
SET @ProdClassType=0
SET @ProdClassName=1
SET @ProdName=2
SET @Activity=3
SET @MatClassName=4

        SELECT @SQL = 'INSERT INTO'
PRINT @sql
        SELECT @SQL = @SQL + ' Temp_tblEveSteps_Temp'
PRINT @sql
           SELECT @SQL = @SQL + '('
     PRINT @sql
           SELECT @SQL = @SQL + 'ProcedureClassType,'
       PRINT @sql
           SELECT @SQL = @SQL + ' ProcedureClassName,'
       PRINT @sql
           SELECT @SQL = @SQL + ' ProcedureName,'
       PRINT @sql
           SELECT @SQL = @SQL + ' MaterialClassName,'
       PRINT @sql
           SELECT @SQL = @SQL + ' MaterialTypeName,'
       PRINT @sql
           SELECT @SQL = @SQL + ' QuantityTypeName,'
       PRINT @sql
           SELECT @SQL = @SQL + ' SeqID_ProcClassManual,'
       PRINT @sql
           SELECT @SQL = @SQL + ' SeqID_QuanType,'
       PRINT @sql
           SELECT @SQL = @SQL + ' SeqID_MatClassType,'
       PRINT @sql
           SELECT @SQL = @SQL + ' PortionType,'
     PRINT @sql
           SELECT @SQL = @SQL + ' Activity,'
    PRINT @sql
           SELECT @SQL = @SQL + ' ActivityFocus,'
    PRINT @sql
           SELECT @SQL = @SQL + ' FromActivity,'
    PRINT @sql
           SELECT @SQL = @SQL + ' FromFocus'
      PRINT @sql
           SELECT @SQL = @SQL + ')'
              PRINT @sql
        SELECT @SQL = @SQL + ' SELECT'
   PRINT @sql
        SELECT @SQL = @SQL + ' ProcedureClassType,'
    PRINT @sql
           SELECT @SQL = @SQL + ' ProcedureClassName,'
    PRINT @sql
           SELECT @SQL = @SQL + ' ProcedureName,'
    PRINT @sql
           SELECT @SQL = @SQL + ' MaterialClassName,'
    PRINT @sql
           SELECT @SQL = @SQL + ' MaterialTypeName,'
    PRINT @sql
           SELECT @SQL = @SQL + ' QuantityTypeName,'
    PRINT @sql
           SELECT @SQL = @SQL + ' SeqID_ProcClassManual,'
    PRINT @sql
           SELECT @SQL = @SQL + ' SeqID_QuanType,'
    PRINT @sql
           SELECT @SQL = @SQL + ' SeqID_MatClassType,'
    PRINT @sql
           SELECT @SQL = @SQL + ' PortionType,'
    PRINT @sql
           SELECT @SQL = @SQL + ' Activity,'
     PRINT @sql
           SELECT @SQL = @SQL + ' ActivityFocus,'
    PRINT @sql
           SELECT @SQL = @SQL + ' FromActivity,'
    PRINT @sql
           SELECT @SQL = @SQL + ' FromFocus'
   PRINT @sql
        SELECT @SQL = @SQL + ' FROM ' + @SourceTable + ''
       PRINT @sql
        SELECT @SQL = @SQL + ' GROUP BY'
     PRINT @sql
           SELECT @SQL = @SQL + ' ProcedureClassType,'
     PRINT @sql
           SELECT @SQL = @SQL + ' ProcedureClassName,'
     PRINT @sql
           SELECT @SQL = @SQL + ' ProcedureName,'
     PRINT @sql
           SELECT @SQL = @SQL + ' MaterialClassName,'
     PRINT @sql
           SELECT @SQL = @SQL + ' MaterialTypeName,'
     PRINT @sql
           SELECT @SQL = @SQL + ' QuantityTypeName,'
     PRINT @sql
           SELECT @SQL = @SQL + ' SeqID_ProcClassManual,'
     PRINT @sql
           SELECT @SQL = @SQL + ' SeqID_QuanType,'
     PRINT @sql
           SELECT @SQL = @SQL + ' SeqID_MatClassType,'
     PRINT @sql
           SELECT @SQL = @SQL + ' PortionType,'
     PRINT @sql
           SELECT @SQL = @SQL + ' Activity,'
     PRINT @sql
           SELECT @SQL = @SQL + ' ActivityFocus,'
     PRINT @sql
           SELECT @SQL = @SQL + ' FromActivity,'
     PRINT @sql
           SELECT @SQL = @SQL + ' FromFocus'
    PRINT @sql

        SELECT @SQL = @SQL + ' HAVING ProcedureClassType = ' + CAST(@ProdClassType as NVARCHAR(6)) + ''
PRINT @sql
           SELECT @SQL = @SQL + ' AND ProcedureClassName =  ' + CAST(@ProdClassName as NVARCHAR(6)) + ''
   PRINT @sql
              -------------------------------------------------------------------------------------------------------
        If @Procedure = 'Mining'
              BEGIN
                SELECT @SQL = @SQL + ' AND ProcedureName = ' + CAST(@ProdName as nvarchar(6)) + ''
PRINT 'First IF ' +  @sql
              END

              If @Procedure = 'Downstream'
              BEGIN
                SELECT @SQL = @SQL + ' AND ProcedureName = ' + CAST(@ProdName as nvarchar(6)) + ''
              -------------------------------------------------------------------------------------------------------
PRINT 'Second IF ' + @sql
              END


        If @Procedure = 'Stockpile'
              BEGIN
                     SELECT @SQL = @SQL + ' AND ActivityFocus = ' + CAST(@Activity as nvarchar(6)) + ''
PRINT 'Third IF ' + @sql
              END

              IF @Procedure = 'Discard'
              BEGIN
                     SELECT @SQL = @SQL + ' AND ActivityFocus = ' + CAST(@Activity as nvarchar(6)) + ''
PRINT ' Fourth IF ' +  @sql
              END

              IF @Procedure = 'Rehandle'
              BEGIN
                     SELECT @SQL = @SQL + ' AND FromActivity = ' + CAST(@Activity as nvarchar(6)) + ''
PRINT 'Fifth IF ' + @sql
              END

              ELSE
                     SELECT @SQL = @SQL + ' AND Activity = ' + CAST(@Activity as nvarchar(6)) + ''
              -------------------------------------------------------------------------------------------------------

        SELECT @SQL = @SQL + ' AND MaterialClassName = ' + CAST(@MatClassName as NVARCHAR(6)) + ''


        --EXECUTE (@SQL)
PRINT @sql


________________________________

The contents of this e-mail message and its attachments are covered by the Electronic Communications Privacy Act (18 U.S.C. 2510-2521) and are intended solely for the addressee(s) hereof. If you are not the named recipient, or the employee or agent responsible for delivering the message to the intended recipient, or if this message has been addressed to you in error, you are directed not to read, disclose, reproduce, distribute, disseminate or otherwise use this transmission. If you have received this communication in error, please notify us immediately by return e-mail or by telephone, 530-893-3520, and delete and/or destroy all copies of the message immediately.

From marklbreen at gmail.com  Wed Sep 10 03:07:59 2014
From: marklbreen at gmail.com (Mark Breen)
Date: Wed, 10 Sep 2014 08:07:59 -0000
Subject: [dba-SQLServer] "SELECT @SQL" - A bit lost.
In-Reply-To: <ecd097b278b245579527768ddad9c816@HKXPR04MB360.apcprd04.prod.outlook.com>
References: <e1848a60744943f1ac241478e752c3b6@HKXPR04MB360.apcprd04.prod.outlook.com>
	<00cf01cfcbfa$ae434360$0ac9ca20$@dalyn.co.nz>
	<omy5pn3dycttpniprwl0c6g7.1410252073773@email.android.com>
	<ecd097b278b245579527768ddad9c816@HKXPR04MB360.apcprd04.prod.outlook.com>
Message-ID: <CAGXtTChQOQPEXVnPrtvhug0ARnUJdYkvZQRq3co+u0-B4kPOwA@mail.gmail.com>

Hello Darryl

thanks for the reply,

My question was not about the cast


Phrasing it differently,

could you use either of the following two lines
SELECT @SQL = @SQL + ' AND MaterialClassName = ' + CAST(@MatClassName as
NVARCHAR(6)) + ''

SELECT @SQL = @SQL + ' AND MaterialClassName = ' + CAST(@MatClassName as
NVARCHAR(6))

I do not see why you are appending on a zero length string to the @SQL

thanks

Mark




On 10 September 2014 02:58, Darryl Collins <darryl at whittleconsulting.com.au>
wrote:

> Ok.... I seem to have this one working ok now - largely thanks to some
> guidance from you folks - so a big thank you for your advice and feedback.
>
> As suspected - it was partly an issue of ignorance and tiredness.  I
> actually had two problems to correct.
>
> The first one corrected id'd by David Lewis being the IF statements in the
> SPROC were not correctly formed.  I did try this yesterday, but clearly I
> fouled it up as today it is working fine.
>
> The 2nd issue was the VBA code I use to pass the parameter to SQL server
> was not set up correctly - I was passing thru a couple of the parameters in
> the wrong order. That was easy enough to spot once I got the SPROC to
> manually fire correctly.
>
> Mark was asking about the use of the syntax using CAST
>
> SELECT @SQL = @SQL + ' AND MaterialClassName = ' + CAST(@MatClassName as
> NVARCHAR(6)) + ''
>
> The reason I need to do this is the Server is expected to execute a string
> and unlike VBA built strings you need to explicitly convert anything that
> is not a string (so all the integer parameters passed into the sproc in
> this example) into strings *before* it is executed.  You can use either
> CAST or CONVERT for this.  I have always used CAST which has performed
> flawlessly, but that comes down to ignorance and luck.  There may be a good
> / better reason to use CONVERT instead but as CAST has always worked for me
> I have been happy to stick with it for now.
>
> The VBA that passes the parameters is below - this works great now I have
> the darn append parameter lines in the correct sequence.
>
>
> '============================================================================================================
> Public Function BuildInOut_Summary_SPOnly_SSSP(Procedure As String, _
>                                         SourceTable As String, _
>                                         ProdClassType As Integer, _
>                                         ProdClassName As Integer, _
>                                         ProdName As Integer, _
>                                         Activity As Integer, _
>                                         MatClassName As Integer _
>                                         ) As Boolean
>
>
>     Dim cmd As New ADODB.Command
>
>     On Error GoTo ErrHandle
>
>     With cmd
>         .ActiveConnection = gDbADOConStr
>         .CommandType = adCmdStoredProc
>         .CommandText = "spBuildInOut_Summary_SPOnly"
>     End With
>
>     With cmd.Parameters
>         .Append cmd.CreateParameter("Procedure", adVarChar, adParamInput,
> 100, Procedure)
>         .Append cmd.CreateParameter("SourceTable", adVarChar,
> adParamInput, 100, SourceTable)
>         .Append cmd.CreateParameter("ProdClassType", adInteger,
> adParamInput, , ProdClassType)
>         .Append cmd.CreateParameter("ProdClassName", adInteger,
> adParamInput, , ProdClassName)
>         .Append cmd.CreateParameter("ProdName", adInteger, adParamInput, ,
> ProdName)
>         .Append cmd.CreateParameter("Activity", adInteger, adParamInput, ,
> Activity)
>         .Append cmd.CreateParameter("MatClassName", adInteger,
> adParamInput, , MatClassName)
>     End With
>
>     cmd.Execute
>     Set cmd = Nothing
>
> Exit Function
>
> ErrHandle:
>
> BuildInOut_Summary_SPOnly_SSSP = False
>
> End Function
>
> '============================================================================================================
>
> So the functional SQL SERVER SPROC code looks like this now:
>
> ALTER PROCEDURE [dbo].[spBuildInOut_Summary_SPOnly]
>
> @Procedure NVARCHAR(100),
> @SourceTable NVARCHAR(100),
> @ProdClassType int,
> @ProdClassName int,
> @ProdName int,
> @Activity int,
> @MatClassName int
>
>
> AS
> BEGIN
>         -- SELECT NOCOUNT ON added to prevent extra result SELECTs from
>         -- interfering with SELECT statements.
>         SET NOCOUNT ON;
>
>
> DECLARE @SQL NVARCHAR(Max)
>
>         SELECT @SQL = 'INSERT INTO'
>         SELECT @SQL = @SQL + ' Temp_tblEveSteps_Temp'
>         SELECT @SQL = @SQL + '('
>         SELECT @SQL = @SQL + 'ProcedureClassType,'
>         SELECT @SQL = @SQL + ' ProcedureClassName,'
>         SELECT @SQL = @SQL + ' ProcedureName,'
>         SELECT @SQL = @SQL + ' MaterialClassName,'
>         SELECT @SQL = @SQL + ' MaterialTypeName,'
>         SELECT @SQL = @SQL + ' QuantityTypeName,'
>         SELECT @SQL = @SQL + ' SeqID_ProcClassManual,'
>         SELECT @SQL = @SQL + ' SeqID_QuanType,'
>         SELECT @SQL = @SQL + ' SeqID_MatClassType,'
>         SELECT @SQL = @SQL + ' PortionType,'
>         SELECT @SQL = @SQL + ' Activity,'
>         SELECT @SQL = @SQL + ' ActivityFocus,'
>         SELECT @SQL = @SQL + ' FromActivity,'
>         SELECT @SQL = @SQL + ' FromFocus'
>         SELECT @SQL = @SQL + ')'
>
>         SELECT @SQL = @SQL + ' SELECT'
>         SELECT @SQL = @SQL + ' ProcedureClassType,'
>         SELECT @SQL = @SQL + ' ProcedureClassName,'
>         SELECT @SQL = @SQL + ' ProcedureName,'
>         SELECT @SQL = @SQL + ' MaterialClassName,'
>         SELECT @SQL = @SQL + ' MaterialTypeName,'
>         SELECT @SQL = @SQL + ' QuantityTypeName,'
>         SELECT @SQL = @SQL + ' SeqID_ProcClassManual,'
>         SELECT @SQL = @SQL + ' SeqID_QuanType,'
>         SELECT @SQL = @SQL + ' SeqID_MatClassType,'
>         SELECT @SQL = @SQL + ' PortionType,'
>         SELECT @SQL = @SQL + ' Activity,'
>         SELECT @SQL = @SQL + ' ActivityFocus,'
>         SELECT @SQL = @SQL + ' FromActivity,'
>         SELECT @SQL = @SQL + ' FromFocus'
>         SELECT @SQL = @SQL + ' FROM ' + @SourceTable + ''
>
>         SELECT @SQL = @SQL + ' GROUP BY'
>         SELECT @SQL = @SQL + ' ProcedureClassType,'
>         SELECT @SQL = @SQL + ' ProcedureClassName,'
>         SELECT @SQL = @SQL + ' ProcedureName,'
>         SELECT @SQL = @SQL + ' MaterialClassName,'
>         SELECT @SQL = @SQL + ' MaterialTypeName,'
>         SELECT @SQL = @SQL + ' QuantityTypeName,'
>         SELECT @SQL = @SQL + ' SeqID_ProcClassManual,'
>         SELECT @SQL = @SQL + ' SeqID_QuanType,'
>         SELECT @SQL = @SQL + ' SeqID_MatClassType,'
>         SELECT @SQL = @SQL + ' PortionType,'
>         SELECT @SQL = @SQL + ' Activity,'
>         SELECT @SQL = @SQL + ' ActivityFocus,'
>         SELECT @SQL = @SQL + ' FromActivity,'
>         SELECT @SQL = @SQL + ' FromFocus'
>
>         SELECT @SQL = @SQL + ' HAVING ProcedureClassType = ' +
> CAST(@ProdClassType as NVARCHAR(6)) + ''
>         SELECT @SQL = @SQL + ' AND ProcedureClassName =  ' +
> CAST(@ProdClassName as NVARCHAR(6)) + ''
>
>
> -------------------------------------------------------------------------------------------------------
>         If @Procedure = 'Mining'
>                 BEGIN
>                         SELECT @SQL = @SQL + ' AND ProcedureName = ' +
> CAST(@ProdName as nvarchar(6)) + ''
>                 END
>
>                 If @Procedure = 'Downstream'
>                 BEGIN
>                         SELECT @SQL = @SQL + ' AND ProcedureName = ' +
> CAST(@ProdName as nvarchar(6)) + ''
>                 END
>
> -------------------------------------------------------------------------------------------------------
>
>          If @Procedure = 'Stockpile'
>                 BEGIN
>                 SELECT @SQL = @SQL + ' AND ActivityFocus = ' +
> CAST(@Activity as nvarchar(6)) + ''
>                 END
>
>          ELSE IF @Procedure = 'Discard'
>                 BEGIN
>                 SELECT @SQL = @SQL + ' AND ActivityFocus = ' +
> CAST(@Activity as nvarchar(6)) + ''
>                 END
>
>          ELSE IF @Procedure = 'Rehandle'
>                 BEGIN
>                 SELECT @SQL = @SQL + ' AND FromActivity = ' +
> CAST(@Activity as nvarchar(6)) + ''
>                 END
>
>          ELSE
>                 SELECT @SQL = @SQL + ' AND Activity = ' + CAST(@Activity
> as nvarchar(6)) + ''
>
> -------------------------------------------------------------------------------------------------------
>
>         SELECT @SQL = @SQL + ' AND MaterialClassName = ' +
> CAST(@MatClassName as NVARCHAR(6)) + ''
>
>                 --PRINT @sql
>
>         EXECUTE (@SQL)
>
>
> END
>
>
> '============================================================================================================
>
> Thanks everyone.
>
> Cheers
> Darryl
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>