From markamatte at hotmail.com  Fri Jun  1 11:53:08 2007
From: markamatte at hotmail.com (Mark A Matte)
Date: Fri, 01 Jun 2007 16:53:08 +0000
Subject: [dba-SQLServer] SQL Server versus Oracle
In-Reply-To: <1C2084FD2472124AB1812A5476EA3B7A0174047E@msgswbmnmsp04.wellsfargo.com>
Message-ID: <BAY127-F38AA9841C7E0B82931C3F1D22C0@phx.gbl>

Liz,

I would not consider myself an expert on either...but recently I found a 
distinct advantage that SQL server has over DB2 and informix(possibly oracle 
as well).  I do alot of investigative reporting for our legal department 
where I have to do wild card searches against their 'notes' fields(TEXT 
FIELDS)...and we found that you can NOT do these in DB2 or Informix.  You 
can in SQL Server.

I'm not sure about Oracle...but this simple ability, or lack there of, 
scared the heck out of the legal dept when they could not get their data.

Just a thought to look into.

Mark


>From: <Elizabeth.J.Doering at wellsfargo.com>
>Reply-To: dba-sqlserver at databaseadvisors.com
>To: <dba-sqlserver at databaseadvisors.com>
>Subject: [dba-SQLServer] SQL Server versus Oracle
>Date: Thu, 31 May 2007 14:25:15 -0500
>
>
>Come to find out, I am speaking in 30 minutes about the virtues of SQL
>Server 2005 versus those of Oracle.  Given that my knowledge of Oracle
>could still dance comfortably on the head of a pin, I am frantically
>googling up details for my 'speech', and I would love to have your
>opinions
>
>I can easily say that we have already SQL Server and that Oracle is
>going to cost us $$$$$ that we hadn't budgeted for.  The thing I am most
>up against is a contention that 650 users are going to generate more
>data in a year or two than SQL Server can possibly hold.  I'm of the
>opinion that with a normalized database in a call center environment,
>users generating 10 or 12 records per call can go for years without
>seeing much if any slowdown.  Is this accurate?
>
>Oracle isn't being suggested for the production environment however.
>Oracle is being pushed for the REPORTING side of this system, for the 3
>or 4 analysts who will be looking at the long term performance of the
>folks in the call center.
>
>Is this making sense?  The production staff can live with SQL Server,
>but 3 or 4 analysts need the big bucks spent on Oracle for running their
>reports.
>
>Opinions, please?
>
>
>Thanks,
>
>
>Liz
>
>
>Liz Doering
>elizabeth.j.doering at wellsfargo.com
>612.667.2447
>
>
>This message may contain confidential and/or privileged information. If
>you are not the addressee or authorized to receive this for the
>addressee, you must not use, copy, disclose, or take any action based on
>this message or any information herein. If you have received this
>message in error, please advise the sender immediately by reply e-mail
>and delete this message. Thank you for your cooperation.
>
>
>_______________________________________________
>dba-SQLServer mailing list
>dba-SQLServer at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>http://www.databaseadvisors.com
>

_________________________________________________________________
PC Magazine?s 2007 editors? choice for best Web mail?award-winning Windows 
Live Hotmail. 
http://imagine-windowslive.com/hotmail/?locale=en-us&ocid=TXT_TAGHM_migration_HM_mini_pcmag_0507



From jlawrenc1 at shaw.ca  Fri Jun  1 15:19:31 2007
From: jlawrenc1 at shaw.ca (Jim Lawrence)
Date: Fri, 01 Jun 2007 13:19:31 -0700
Subject: [dba-SQLServer] SQL Server versus Oracle
In-Reply-To: <BAY127-F38AA9841C7E0B82931C3F1D22C0@phx.gbl>
Message-ID: <0JIZ00DYK480NSX0@l-daemon>


Oracle has made some steps into O-O with it latest release of 10g
(http://www.adp-gmbh.ch/ora/plsql/oo/example_1.html). As well as coding data
structures that can be easily created attaching the lineage (group of
tables) to a field in the next table up. The process is not as easy to
navigate if the data is needed in another groups but it is a good step. At
this moment the whole design is probably just a front end simulation and the
back-end is still totally relational but it is a start. 

With MS buying out a spacial data company can adoption of O-O within it SQL
database be far behind... like Access and purchase of Foxpro and the
implementation of its Rushmore technologies. 

Whether it will be a big jump or a slow migration over 10 years is the
question. Slow migration is my prediction but I believe that is the trend.
MS SQL will have to follow or they can lead.

Of all the computer disciplines DBAs are the most conservative group and
they tend to be 5 to 10 years behind the wave.

Jim 



From rl_stewart at highstream.net  Fri Jun  1 13:47:27 2007
From: rl_stewart at highstream.net (Robert L. Stewart)
Date: Fri, 01 Jun 2007 13:47:27 -0500
Subject: [dba-SQLServer] Source Control
In-Reply-To: <mailman.5.1180717211.23996.dba-sqlserver@databaseadvisors. com>
References: <mailman.5.1180717211.23996.dba-sqlserver@databaseadvisors.com>
Message-ID: <200706012100.l51L0nLP023953@databaseadvisors.com>

Does anybody have a solution they are using
for version control of source SQL statements;
DDL, stored procedures, functions, etc?

Robert




From Erwin.Craps at ithelps.eu  Fri Jun  1 16:14:39 2007
From: Erwin.Craps at ithelps.eu (Erwin Craps - IT Helps)
Date: Fri, 1 Jun 2007 23:14:39 +0200
Subject: [dba-SQLServer] FTP a query result from within a SQL server
	procedure.
Message-ID: <430E80531228BA4497C5EB1A7BA786B01B4545@stekelbes.ithelps.local>

Hi group
 
 
How can one FTP a queryresult (dataset) from within a MS SQL server
without dooing a shell?
Does anyone have some code for that or how to do that?
 
 
 
 
 

Erwin 

 


From jwcolby at colbyconsulting.com  Sat Jun  2 03:19:01 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Sat, 2 Jun 2007 04:19:01 -0400
Subject: [dba-SQLServer] SQL Server 2005 - Build a table in a database using
	a stored procedure
Message-ID: <20070602081903.2EC47BD16@smtp-auth.no-ip.com>

I am trying to build a table in a database "on demand".  I have a sql
statement (see immediately below) that I got from the "script to query
window wizard".  It works just fine and I have used it several times (to
test it) just changing the "USE database" statement.

USE [MyDatabaseName]
GO
/****** Object:  Table [dbo].[tblDataMapCSVOut]    Script Date: 06/02/2007
04:01:30 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
SET ANSI_PADDING ON
GO
CREATE TABLE [dbo].[tblDataMapCSVOut](
	[CSVID] [int] IDENTITY(1,1) NOT NULL,
	[CSVFldNameInTable] [varchar](50) COLLATE
SQL_Latin1_General_CP1_CI_AS NULL,
	[CSVFldNameInFile] [varchar](50) COLLATE
SQL_Latin1_General_CP1_CI_AS NULL
) ON [PRIMARY]

GO
SET ANSI_PADDING OFFEND
GO

Works fine.  Now I want to put that in a stored procedure so that I can just
call the sp, pass in the name of the database to create the table in and go.
I created a stored procedure as below:

-- ================================================
-- Template generated from Template Explorer using:
-- Create Procedure (New Menu).SQL
--
-- Use the Specify Values for Template Parameters 
-- command (Ctrl-Shift-M) to fill in the parameter 
-- values below.
--
-- This block of comments will not be included in
-- the definition of the procedure.
-- ================================================
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
-- =============================================
-- Author:		<Author,,Name>
-- Create date: <Create Date,,>
-- Description:	<Description,,>
-- =============================================
CREATE PROCEDURE sp_CreateDataMapCSVOut
	-- Add the parameters for the stored procedure here
	@DatabaseName	varchar(255)
AS
BEGIN
	-- SET NOCOUNT ON added to prevent extra result sets from
	-- interfering with SELECT statements.
	SET NOCOUNT ON;

    -- Insert statements for procedure here
USE '[' + @DatabaseName + ']'
GO
/****** Object:  Table [dbo].[tblDataMapCSVOut]    Script Date: 06/02/2007
04:01:30 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
SET ANSI_PADDING ON
GO
CREATE TABLE [dbo].[tblDataMapCSVOut](
	[CSVID] [int] IDENTITY(1,1) NOT NULL,
	[CSVFldNameInTable] [varchar](50) COLLATE
SQL_Latin1_General_CP1_CI_AS NULL,
	[CSVFldNameInFile] [varchar](50) COLLATE
SQL_Latin1_General_CP1_CI_AS NULL
) ON [PRIMARY]

GO
SET ANSI_PADDING OFFEND
GO


Notice that I am trying to pass in the name of the database and use that
parameter to determine where the table is created.  This does not work fine,
giving me the following errors when I try to run it.

Msg 154, Level 15, State 1, Procedure sp_CreateDataMapCSVOut, Line 16
a USE database statement is not allowed in a procedure, function or trigger.
Msg 102, Level 15, State 4, Line 1
Incorrect syntax near 'ANSI_PADDING'.

Is there a way to do this?  Can someone "fix me up" here so that this works?

John W. Colby
Colby Consulting
www.ColbyConsulting.com 



From shait at mindspring.com  Sat Jun  2 06:24:53 2007
From: shait at mindspring.com (Stephen Hait)
Date: Sat, 2 Jun 2007 07:24:53 -0400
Subject: [dba-SQLServer] SQL Server 2005 - Build a table in a database
	using a stored procedure
In-Reply-To: <20070602081903.2EC47BD16@smtp-auth.no-ip.com>
References: <20070602081903.2EC47BD16@smtp-auth.no-ip.com>
Message-ID: <bb9d2d1e0706020424s59bffd64q2e9a3d1c060434c4@mail.gmail.com>

On 6/2/07, jwcolby <jwcolby at colbyconsulting.com> wrote:
> CREATE TABLE [dbo].[tblDataMapCSVOut](
>         [CSVID] [int] IDENTITY(1,1) NOT NULL,
>         [CSVFldNameInTable] [varchar](50) COLLATE
> SQL_Latin1_General_CP1_CI_AS NULL,
>         [CSVFldNameInFile] [varchar](50) COLLATE
> SQL_Latin1_General_CP1_CI_AS NULL
> ) ON [PRIMARY]

<snip>

> Msg 154, Level 15, State 1, Procedure sp_CreateDataMapCSVOut, Line 16
> a USE database statement is not allowed in a procedure, function or trigger.
> Msg 102, Level 15, State 4, Line 1
> Incorrect syntax near 'ANSI_PADDING'.
>
> Is there a way to do this?  Can someone "fix me up" here so that this works?

I'm no expert but would it work if you did something like this instead
and skipped the USE?

CREATE TABLE [@DatabaseName].[dbo].[tblDataMapCSVOut]
...

-Stephen


From jwcolby at colbyconsulting.com  Sat Jun  2 09:38:50 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Sat, 2 Jun 2007 10:38:50 -0400
Subject: [dba-SQLServer] VB.Net - Connection Open doesn't
Message-ID: <20070602143852.145E7BD07@smtp-auth.no-ip.com>

I created the following code, which was tested and working when running on
the machine that the database server resides on.  I am now trying to run it
from my laptop, which is my development machine.  This class is initialized
in the button click on a form just for troubleshooting purposes.  The code
steps in to the new constructor , the mobjCn is set, it drops into the Try
and then steps into the open and hangs, never to return.

StrConnection is:

Provider=SQLOLEDB;Data Source = Azul;Initial Catalog = Infutor;Integrated
Security=SSPI

Azul is both the name of the machine running SQL Server 2005 and the name of
a SQL Server instance on machine Azul, which can be seen and manipulated
from the laptop.  Infutor is a specific database which can be seen and
manipulated from the laptop.  SSPI I do not understand the definition of, it
was something that I tried and it worked from the SQL Server machine (also
named Azul).

Public Class clsProcessData
    Private mobjCn As OleDbConnection
    Private mobjDA As New OleDbDataAdapter
    Private mobjDS As DataSet
    ''' <summary>
    ''' 
    ''' </summary>
    ''' <param name="strConnection"></param>
    ''' <remarks></remarks>
    Public Sub New(ByVal strConnection As String)
        mobjCn = New OleDbConnection(strConnection)
        Try
            Debug.Print(strConnection)
            mobjCn.Open()
        Catch ex As OleDbException
            MessageBox.Show("Could not open the connection: " +
strConnection)
        End Try
        mobjDA.SelectCommand = New OleDbCommand
        mobjDA.SelectCommand.Connection = mobjCn
        mobjDS = New DataSet
    End Sub

Any ideas what to try here?


John W. Colby
Colby Consulting
www.ColbyConsulting.com 



From jwcolby at colbyconsulting.com  Sat Jun  2 08:37:28 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Sat, 2 Jun 2007 09:37:28 -0400
Subject: [dba-SQLServer] SQL Server 2005 - Build a table in a
	databaseusing a stored procedure
In-Reply-To: <bb9d2d1e0706020424s59bffd64q2e9a3d1c060434c4@mail.gmail.com>
Message-ID: <20070602133730.843B7BD31@smtp-auth.no-ip.com>

I'll give it a try. 


John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Stephen
Hait
Sent: Saturday, June 02, 2007 7:25 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] SQL Server 2005 - Build a table in a
databaseusing a stored procedure

On 6/2/07, jwcolby <jwcolby at colbyconsulting.com> wrote:
> CREATE TABLE [dbo].[tblDataMapCSVOut](
>         [CSVID] [int] IDENTITY(1,1) NOT NULL,
>         [CSVFldNameInTable] [varchar](50) COLLATE 
> SQL_Latin1_General_CP1_CI_AS NULL,
>         [CSVFldNameInFile] [varchar](50) COLLATE 
> SQL_Latin1_General_CP1_CI_AS NULL
> ) ON [PRIMARY]

<snip>

> Msg 154, Level 15, State 1, Procedure sp_CreateDataMapCSVOut, Line 16 
> a USE database statement is not allowed in a procedure, function or
trigger.
> Msg 102, Level 15, State 4, Line 1
> Incorrect syntax near 'ANSI_PADDING'.
>
> Is there a way to do this?  Can someone "fix me up" here so that this
works?

I'm no expert but would it work if you did something like this instead and
skipped the USE?

CREATE TABLE [@DatabaseName].[dbo].[tblDataMapCSVOut]
...

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



From fuller.artful at gmail.com  Sat Jun  2 08:26:16 2007
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Sat, 2 Jun 2007 09:26:16 -0400
Subject: [dba-SQLServer] Source Control
In-Reply-To: <200706012100.l51L0nLP023953@databaseadvisors.com>
References: <mailman.5.1180717211.23996.dba-sqlserver@databaseadvisors.com>
	<200706012100.l51L0nLP023953@databaseadvisors.com>
Message-ID: <29f585dd0706020626q2fd3321dl20f6d9fc98c8fa70@mail.gmail.com>

Assuming that you have SQL 2005, then there are two approaches, the standard
old way and the fancy new way. Whether you can use the fancy new way depends
on the version of Visual Studio.NET you have installed. If you have the
standard version you cannot use the fancy new way.

The fancy new way goes something like this:

1. create a database project in VS.NET.
2.Open Solution Explorer.
3. Make sure that the database of interest is listed in the Database
References of the project. If it's not there, right-click Database
References and add it.
4. In Server Explorer, expand the Data Connections node and keep expanding
until you get to the Stored Procedures node.
5. Open the context men for a sproc and select Generate Script to Project.
This will add the script to the Create Scripts folder of the project.
6. Do the same thing with a table and a view and a UDF.
(You may not have to go through all this, depending on your version of
VS.NET. Check to see if you have the command Generate Create Script on the
context menu of the data connection. If you have that command available, you
can do all the objects in the database at once.)

Next step is to add the project and all its files to Visual Source Safe.
This is straightforward so I won't bother detailing it. VSS prompts you to
add a project. Do it. All your scripts will be added to the VSS project and
locked automatically. Then you can check out the one(s) of interest.

The traditional approach (when you do not have VS.NET) goes like this:
In Enterprise Manager or Management Studio, generate scripts for all your
objects.
In VSS, create a new project. Point to the directory into which you
generated all your scripts, and add them.
Check out the one(s) of interest.

hth,
Arthur


On 6/1/07, Robert L. Stewart <rl_stewart at highstream.net> wrote:
>
> Does anybody have a solution they are using
> for version control of source SQL statements;
> DDL, stored procedures, functions, etc?
>
> Robert
>
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>


From ebarro at verizon.net  Sat Jun  2 17:00:08 2007
From: ebarro at verizon.net (Eric Barro)
Date: Sat, 02 Jun 2007 15:00:08 -0700
Subject: [dba-SQLServer] VB.Net - Connection Open doesn't
In-Reply-To: <20070602143852.145E7BD07@smtp-auth.no-ip.com>
Message-ID: <0JJ10074F3SA9TN2@vms040.mailsrvcs.net>

John,

A couple of things to try...

1. Data Source = Azul

Since you are connecting to a remote machine it needs to reference the
machine as \\AZUL\AZUL or <ip address of Azul>\Azul

2. Integrated Security=SSPI

You need to make sure that Windows account you are using on your laptop is
also on the Azul machine, otherwise it won't be able to authenticate
correctly. I use SQL authentication by creating a SQL login.

3. Make sure that Azul has TCPIP port 1433 open so that the remote machine
can connect over a TCPIP connection.

Eric 

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Saturday, June 02, 2007 7:39 AM
To: dba-sqlserver at databaseadvisors.com
Subject: [dba-SQLServer] VB.Net - Connection Open doesn't

I created the following code, which was tested and working when running on
the machine that the database server resides on.  I am now trying to run it
from my laptop, which is my development machine.  This class is initialized
in the button click on a form just for troubleshooting purposes.  The code
steps in to the new constructor , the mobjCn is set, it drops into the Try
and then steps into the open and hangs, never to return.

StrConnection is:

Provider=SQLOLEDB;Data Source = Azul;Initial Catalog = Infutor;Integrated
Security=SSPI

Azul is both the name of the machine running SQL Server 2005 and the name of
a SQL Server instance on machine Azul, which can be seen and manipulated
from the laptop.  Infutor is a specific database which can be seen and
manipulated from the laptop.  SSPI I do not understand the definition of, it
was something that I tried and it worked from the SQL Server machine (also
named Azul).

Public Class clsProcessData
    Private mobjCn As OleDbConnection
    Private mobjDA As New OleDbDataAdapter
    Private mobjDS As DataSet
    ''' <summary>
    ''' 
    ''' </summary>
    ''' <param name="strConnection"></param>
    ''' <remarks></remarks>
    Public Sub New(ByVal strConnection As String)
        mobjCn = New OleDbConnection(strConnection)
        Try
            Debug.Print(strConnection)
            mobjCn.Open()
        Catch ex As OleDbException
            MessageBox.Show("Could not open the connection: " +
strConnection)
        End Try
        mobjDA.SelectCommand = New OleDbCommand
        mobjDA.SelectCommand.Connection = mobjCn
        mobjDS = New DataSet
    End Sub

Any ideas what to try here?


John W. Colby
Colby Consulting
www.ColbyConsulting.com 

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

No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.472 / Virus Database: 269.8.6/828 - Release Date: 6/1/2007
11:22 AM
 



From ebarro at verizon.net  Sat Jun  2 14:20:08 2007
From: ebarro at verizon.net (Eric Barro)
Date: Sat, 02 Jun 2007 12:20:08 -0700
Subject: [dba-SQLServer] SQL Server 2005 - Build a table in a database
 using	a stored procedure
In-Reply-To: <20070602081903.2EC47BD16@smtp-auth.no-ip.com>
Message-ID: <0JJ000CIZWE3NC80@vms048.mailsrvcs.net>

This is what's referred to as dynamic SQL in a sproc....

First declare a variable to hold the commands you want to execute

DECLARE @sql	varchar(4000)
--assign the use command to the variable
SET @sql = 'USE ' + @DatabaseName
--execute the command 
EXEC (@sql)
--assign the create command to the variable
SET @sql = 'CREATE TABLE [dbo].[tblDataMapCSVOut](
	[CSVID] [int] IDENTITY(1,1) NOT NULL,
	[CSVFldNameInTable] [varchar](50) COLLATE
SQL_Latin1_General_CP1_CI_AS NULL,
	[CSVFldNameInFile] [varchar](50) COLLATE
SQL_Latin1_General_CP1_CI_AS NULL
) ON [PRIMARY]'

EXEC (@sql)

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Saturday, June 02, 2007 1:19 AM
To: dba-sqlserver at databaseadvisors.com
Subject: [dba-SQLServer] SQL Server 2005 - Build a table in a database using
a stored procedure

I am trying to build a table in a database "on demand".  I have a sql
statement (see immediately below) that I got from the "script to query
window wizard".  It works just fine and I have used it several times (to
test it) just changing the "USE database" statement.

USE [MyDatabaseName]
GO
/****** Object:  Table [dbo].[tblDataMapCSVOut]    Script Date: 06/02/2007
04:01:30 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
SET ANSI_PADDING ON
GO
CREATE TABLE [dbo].[tblDataMapCSVOut](
	[CSVID] [int] IDENTITY(1,1) NOT NULL,
	[CSVFldNameInTable] [varchar](50) COLLATE
SQL_Latin1_General_CP1_CI_AS NULL,
	[CSVFldNameInFile] [varchar](50) COLLATE
SQL_Latin1_General_CP1_CI_AS NULL
) ON [PRIMARY]

GO
SET ANSI_PADDING OFFEND
GO

Works fine.  Now I want to put that in a stored procedure so that I can just
call the sp, pass in the name of the database to create the table in and go.
I created a stored procedure as below:

-- ================================================
-- Template generated from Template Explorer using:
-- Create Procedure (New Menu).SQL
--
-- Use the Specify Values for Template Parameters
-- command (Ctrl-Shift-M) to fill in the parameter
-- values below.
--
-- This block of comments will not be included in
-- the definition of the procedure.
-- ================================================
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
-- =============================================
-- Author:		<Author,,Name>
-- Create date: <Create Date,,>
-- Description:	<Description,,>
-- =============================================
CREATE PROCEDURE sp_CreateDataMapCSVOut
	-- Add the parameters for the stored procedure here
	@DatabaseName	varchar(255)
AS
BEGIN
	-- SET NOCOUNT ON added to prevent extra result sets from
	-- interfering with SELECT statements.
	SET NOCOUNT ON;

    -- Insert statements for procedure here USE '[' + @DatabaseName + ']'
GO
/****** Object:  Table [dbo].[tblDataMapCSVOut]    Script Date: 06/02/2007
04:01:30 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
SET ANSI_PADDING ON
GO
CREATE TABLE [dbo].[tblDataMapCSVOut](
	[CSVID] [int] IDENTITY(1,1) NOT NULL,
	[CSVFldNameInTable] [varchar](50) COLLATE
SQL_Latin1_General_CP1_CI_AS NULL,
	[CSVFldNameInFile] [varchar](50) COLLATE
SQL_Latin1_General_CP1_CI_AS NULL
) ON [PRIMARY]

GO
SET ANSI_PADDING OFFEND
GO


Notice that I am trying to pass in the name of the database and use that
parameter to determine where the table is created.  This does not work fine,
giving me the following errors when I try to run it.

Msg 154, Level 15, State 1, Procedure sp_CreateDataMapCSVOut, Line 16 a USE
database statement is not allowed in a procedure, function or trigger.
Msg 102, Level 15, State 4, Line 1
Incorrect syntax near 'ANSI_PADDING'.

Is there a way to do this?  Can someone "fix me up" here so that this works?

John W. Colby
Colby Consulting
www.ColbyConsulting.com 

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

No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.472 / Virus Database: 269.8.6/828 - Release Date: 6/1/2007
11:22 AM
 



From mikedorism at verizon.net  Sat Jun  2 08:43:56 2007
From: mikedorism at verizon.net (Doris Manning)
Date: Sat, 02 Jun 2007 09:43:56 -0400
Subject: [dba-SQLServer] SQL Server 2005 - Build a table in a
 databaseusing a stored procedure
In-Reply-To: <bb9d2d1e0706020424s59bffd64q2e9a3d1c060434c4@mail.gmail.com>
References: <20070602081903.2EC47BD16@smtp-auth.no-ip.com>
	<bb9d2d1e0706020424s59bffd64q2e9a3d1c060434c4@mail.gmail.com>
Message-ID: <000001c7a51c$11750ee0$2f01a8c0@Kermit>

<snip>I'm no expert but would it work if you did something like this instead
and skipped the USE?

CREATE TABLE [@DatabaseName].[dbo].[tblDataMapCSVOut]
...
<snip>

This should work just fine.

Doris Manning
Database Administrator
Hargrove Inc.




From fuller.artful at gmail.com  Sat Jun  2 09:00:10 2007
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Sat, 2 Jun 2007 10:00:10 -0400
Subject: [dba-SQLServer] SQL Server 2005 - Build a table in a database
	using a stored procedure
In-Reply-To: <20070602081903.2EC47BD16@smtp-auth.no-ip.com>
References: <20070602081903.2EC47BD16@smtp-auth.no-ip.com>
Message-ID: <29f585dd0706020700n2e6af8bew3847740bf8d3c9f6@mail.gmail.com>

As far as I know, you cannot get from here to there, at least not in the way
you are trying. As the error message says, you cannot use the USE [database]
statement in a sproc, even if you hard coded it.

However, there may be another approach. It depends on where you are calling
your sproc from. You didn't really indicate that. If it's from a query
window and you are calling the sproc yourself, then there is a way around
the problem, but if you're trying to do this from code, then you may have
problems.

First thing I would suggest is that you place the stored procedure in the
master database, so that it's available all the time. From the query window,
issue the USE statement yourself, followed by the call to the procedure
(which will now run in the used database, even though it lives in the master
database).

Note that you may have to run the procedure using its fully qualified name,
that is:

exec master..dbo.sprocname.

hth,
Arthur

P.S.
I would also add this create script to VSS or your preferred version control
program. On the off chance that you have to reinstall SQL, you'd overwrite
master, so you'd want to get the sproc back out of VSS to reinstall it.


On 6/2/07, jwcolby <jwcolby at colbyconsulting.com> wrote:
>
> I am trying to build a table in a database "on demand".  I have a sql
> statement (see immediately below) that I got from the "script to query
> window wizard".  It works just fine and I have used it several times (to
> test it) just changing the "USE database" statement.
>
> USE [MyDatabaseName]
> GO
> /****** Object:  Table [dbo].[tblDataMapCSVOut]    Script Date: 06/02/2007
> 04:01:30 ******/
> SET ANSI_NULLS ON
> GO
> SET QUOTED_IDENTIFIER ON
> GO
> SET ANSI_PADDING ON
> GO
> CREATE TABLE [dbo].[tblDataMapCSVOut](
>        [CSVID] [int] IDENTITY(1,1) NOT NULL,
>        [CSVFldNameInTable] [varchar](50) COLLATE
> SQL_Latin1_General_CP1_CI_AS NULL,
>        [CSVFldNameInFile] [varchar](50) COLLATE
> SQL_Latin1_General_CP1_CI_AS NULL
> ) ON [PRIMARY]
>
> GO
> SET ANSI_PADDING OFFEND
> GO
>
> Works fine.  Now I want to put that in a stored procedure so that I can
> just
> call the sp, pass in the name of the database to create the table in and
> go.
> I created a stored procedure as below:
>
> -- ================================================
> -- Template generated from Template Explorer using:
> -- Create Procedure (New Menu).SQL
> --
> -- Use the Specify Values for Template Parameters
> -- command (Ctrl-Shift-M) to fill in the parameter
> -- values below.
> --
> -- This block of comments will not be included in
> -- the definition of the procedure.
> -- ================================================
> SET ANSI_NULLS ON
> GO
> SET QUOTED_IDENTIFIER ON
> GO
> -- =============================================
> -- Author:              <Author,,Name>
> -- Create date: <Create Date,,>
> -- Description: <Description,,>
> -- =============================================
> CREATE PROCEDURE sp_CreateDataMapCSVOut
>        -- Add the parameters for the stored procedure here
>        @DatabaseName   varchar(255)
> AS
> BEGIN
>        -- SET NOCOUNT ON added to prevent extra result sets from
>        -- interfering with SELECT statements.
>        SET NOCOUNT ON;
>
>    -- Insert statements for procedure here
> USE '[' + @DatabaseName + ']'
> GO
> /****** Object:  Table [dbo].[tblDataMapCSVOut]    Script Date: 06/02/2007
> 04:01:30 ******/
> SET ANSI_NULLS ON
> GO
> SET QUOTED_IDENTIFIER ON
> GO
> SET ANSI_PADDING ON
> GO
> CREATE TABLE [dbo].[tblDataMapCSVOut](
>        [CSVID] [int] IDENTITY(1,1) NOT NULL,
>        [CSVFldNameInTable] [varchar](50) COLLATE
> SQL_Latin1_General_CP1_CI_AS NULL,
>        [CSVFldNameInFile] [varchar](50) COLLATE
> SQL_Latin1_General_CP1_CI_AS NULL
> ) ON [PRIMARY]
>
> GO
> SET ANSI_PADDING OFFEND
> GO
>
>
> Notice that I am trying to pass in the name of the database and use that
> parameter to determine where the table is created.  This does not work
> fine,
> giving me the following errors when I try to run it.
>
> Msg 154, Level 15, State 1, Procedure sp_CreateDataMapCSVOut, Line 16
> a USE database statement is not allowed in a procedure, function or
> trigger.
> Msg 102, Level 15, State 4, Line 1
> Incorrect syntax near 'ANSI_PADDING'.
>
> Is there a way to do this?  Can someone "fix me up" here so that this
> works?
>
> John W. Colby
> Colby Consulting
> www.ColbyConsulting.com
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>


From rl_stewart at highstream.net  Mon Jun  4 08:59:58 2007
From: rl_stewart at highstream.net (Robert L. Stewart)
Date: Mon, 04 Jun 2007 08:59:58 -0500
Subject: [dba-SQLServer] SQL Server 2005 - Build a table in a database
 using	a stored procedure
In-Reply-To: <mailman.5.1180890001.26350.dba-sqlserver@databaseadvisors. com>
References: <mailman.5.1180890001.26350.dba-sqlserver@databaseadvisors.com>
Message-ID: <200706041402.l54E2qXI032663@databaseadvisors.com>

You almost have it correct.

You cannot issue a USE statement.
So do not do that portion of the code.

SET @Sql = 'CREATE TABLE ' + @DatabaseName + '.dbo.tblDataMapCVSOut....

is the only change to the rest of the code Eric sent to you.

Robert

At 12:00 PM 6/3/2007, you wrote:
>Date: Sat, 02 Jun 2007 12:20:08 -0700
>From: "Eric Barro" <ebarro at verizon.net>
>Subject: Re: [dba-SQLServer] SQL Server 2005 - Build a table in a
>         database using  a stored procedure
>To: <dba-sqlserver at databaseadvisors.com>
>Message-ID: <0JJ000CIZWE3NC80 at vms048.mailsrvcs.net>
>Content-Type: text/plain; charset=us-ascii
>
>This is what's referred to as dynamic SQL in a sproc....
>
>First declare a variable to hold the commands you want to execute
>
>DECLARE @sql    varchar(4000)
>--assign the use command to the variable
>SET @sql = 'USE ' + @DatabaseName
>--execute the command
>EXEC (@sql)
>--assign the create command to the variable
>SET @sql = 'CREATE TABLE [dbo].[tblDataMapCSVOut](
>         [CSVID] [int] IDENTITY(1,1) NOT NULL,
>         [CSVFldNameInTable] [varchar](50) COLLATE
>SQL_Latin1_General_CP1_CI_AS NULL,
>         [CSVFldNameInFile] [varchar](50) COLLATE
>SQL_Latin1_General_CP1_CI_AS NULL
>) ON [PRIMARY]'
>
>EXEC (@sql)




From jwcolby at colbyconsulting.com  Mon Jun  4 10:01:07 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Mon, 4 Jun 2007 11:01:07 -0400
Subject: [dba-SQLServer] SQL Server 2005 - Build a table in a database
	using	a stored procedure
In-Reply-To: <200706041402.l54E2qXI032663@databaseadvisors.com>
Message-ID: <20070604150110.F2D54BCA8@smtp-auth.no-ip.com>

Thanks Robert. 


John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Robert L.
Stewart
Sent: Monday, June 04, 2007 10:00 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] SQL Server 2005 - Build a table in a database
using a stored procedure

You almost have it correct.

You cannot issue a USE statement.
So do not do that portion of the code.

SET @Sql = 'CREATE TABLE ' + @DatabaseName + '.dbo.tblDataMapCVSOut....

is the only change to the rest of the code Eric sent to you.

Robert

At 12:00 PM 6/3/2007, you wrote:
>Date: Sat, 02 Jun 2007 12:20:08 -0700
>From: "Eric Barro" <ebarro at verizon.net>
>Subject: Re: [dba-SQLServer] SQL Server 2005 - Build a table in a
>         database using  a stored procedure
>To: <dba-sqlserver at databaseadvisors.com>
>Message-ID: <0JJ000CIZWE3NC80 at vms048.mailsrvcs.net>
>Content-Type: text/plain; charset=us-ascii
>
>This is what's referred to as dynamic SQL in a sproc....
>
>First declare a variable to hold the commands you want to execute
>
>DECLARE @sql    varchar(4000)
>--assign the use command to the variable SET @sql = 'USE ' + 
>@DatabaseName --execute the command EXEC (@sql) --assign the create 
>command to the variable SET @sql = 'CREATE TABLE 
>[dbo].[tblDataMapCSVOut](
>         [CSVID] [int] IDENTITY(1,1) NOT NULL,
>         [CSVFldNameInTable] [varchar](50) COLLATE 
>SQL_Latin1_General_CP1_CI_AS NULL,
>         [CSVFldNameInFile] [varchar](50) COLLATE 
>SQL_Latin1_General_CP1_CI_AS NULL
>) ON [PRIMARY]'
>
>EXEC (@sql)


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



From jwcolby at colbyconsulting.com  Tue Jun  5 09:42:18 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Tue, 5 Jun 2007 10:42:18 -0400
Subject: [dba-SQLServer] Free tools
Message-ID: <20070605144220.921FEBECE@smtp-auth.no-ip.com>

Just found this:

http://www.idera.com/freetools/

John W. Colby
Colby Consulting
www.ColbyConsulting.com 



From rl_stewart at highstream.net  Tue Jun  5 12:47:59 2007
From: rl_stewart at highstream.net (Robert L. Stewart)
Date: Tue, 05 Jun 2007 12:47:59 -0500
Subject: [dba-SQLServer] Source code version control
In-Reply-To: <mailman.5.1181062802.16164.dba-sqlserver@databaseadvisors. com>
References: <mailman.5.1181062802.16164.dba-sqlserver@databaseadvisors.com>
Message-ID: <200706051751.l55Hp18f031893@databaseadvisors.com>

So, I guess since no one responded to my
question, no one on the list is practicing
any kind of source code version control.
And that no one has any suggestions about
it.

Is that true?




From ebarro at verizon.net  Tue Jun  5 13:07:02 2007
From: ebarro at verizon.net (Eric Barro)
Date: Tue, 05 Jun 2007 11:07:02 -0700
Subject: [dba-SQLServer] Source code version control
In-Reply-To: <200706051751.l55Hp18f031893@databaseadvisors.com>
Message-ID: <0JJ600EXGCZ1G3J7@vms044.mailsrvcs.net>

I use M$ Visual Sourcesafe. 

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Robert L.
Stewart
Sent: Tuesday, June 05, 2007 10:48 AM
To: dba-sqlserver at databaseadvisors.com
Subject: [dba-SQLServer] Source code version control

So, I guess since no one responded to my question, no one on the list is
practicing any kind of source code version control.
And that no one has any suggestions about it.

Is that true?


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

 



From fuller.artful at gmail.com  Tue Jun  5 13:14:47 2007
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Tue, 5 Jun 2007 14:14:47 -0400
Subject: [dba-SQLServer] Source code version control
In-Reply-To: <200706051751.l55Hp18f031893@databaseadvisors.com>
References: <mailman.5.1181062802.16164.dba-sqlserver@databaseadvisors.com>
	<200706051751.l55Hp18f031893@databaseadvisors.com>
Message-ID: <29f585dd0706051114r62c0958eqf8292c2ce4370928@mail.gmail.com>

I thought that I responded at length to you. It's not in my drafts. Maybe I
accidentally discarded it. I described the two ways of using it, one with
VS.NET and the other without. I'll see if I can dig it up and re-send it. If
not I'll redo it.

Arthur


On 6/5/07, Robert L. Stewart <rl_stewart at highstream.net> wrote:
>
> So, I guess since no one responded to my
> question, no one on the list is practicing
> any kind of source code version control.
> And that no one has any suggestions about
> it.
>
> Is that true?
>
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>


From ebarro at verizon.net  Tue Jun  5 13:33:33 2007
From: ebarro at verizon.net (Eric Barro)
Date: Tue, 05 Jun 2007 11:33:33 -0700
Subject: [dba-SQLServer] Source code version control
In-Reply-To: <29f585dd0706051114r62c0958eqf8292c2ce4370928@mail.gmail.com>
Message-ID: <0JJ6004MEE7ZDA21@vms042.mailsrvcs.net>

Arthur,

He meant practicing...not theorizing... 

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Arthur
Fuller
Sent: Tuesday, June 05, 2007 11:15 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Source code version control

I thought that I responded at length to you. It's not in my drafts. Maybe I
accidentally discarded it. I described the two ways of using it, one with
VS.NET and the other without. I'll see if I can dig it up and re-send it. If
not I'll redo it.

Arthur


On 6/5/07, Robert L. Stewart <rl_stewart at highstream.net> wrote:
>
> So, I guess since no one responded to my question, no one on the list 
> is practicing any kind of source code version control.
> And that no one has any suggestions about it.
>
> Is that true?
>
>
> _______________________________________________
> 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

No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.472 / Virus Database: 269.8.9/832 - Release Date: 6/4/2007 6:43
PM
 



From jwcolby at colbyconsulting.com  Tue Jun  5 13:39:23 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Tue, 5 Jun 2007 14:39:23 -0400
Subject: [dba-SQLServer] Source code version control
In-Reply-To: <0JJ6004MEE7ZDA21@vms042.mailsrvcs.net>
Message-ID: <20070605183924.3C565BD85@smtp-auth.no-ip.com>

>He meant practicing...not theorizing... 

ROTFLMAO.


John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Eric Barro
Sent: Tuesday, June 05, 2007 2:34 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Source code version control

Arthur,

He meant practicing...not theorizing... 

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Arthur
Fuller
Sent: Tuesday, June 05, 2007 11:15 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Source code version control

I thought that I responded at length to you. It's not in my drafts. Maybe I
accidentally discarded it. I described the two ways of using it, one with
VS.NET and the other without. I'll see if I can dig it up and re-send it. If
not I'll redo it.

Arthur


On 6/5/07, Robert L. Stewart <rl_stewart at highstream.net> wrote:
>
> So, I guess since no one responded to my question, no one on the list 
> is practicing any kind of source code version control.
> And that no one has any suggestions about it.
>
> Is that true?



From fuller.artful at gmail.com  Tue Jun  5 16:12:22 2007
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Tue, 5 Jun 2007 17:12:22 -0400
Subject: [dba-SQLServer] Source code version control
In-Reply-To: <20070605183924.3C565BD85@smtp-auth.no-ip.com>
References: <0JJ6004MEE7ZDA21@vms042.mailsrvcs.net>
	<20070605183924.3C565BD85@smtp-auth.no-ip.com>
Message-ID: <29f585dd0706051412i28d0aec7i9044d7c8d8daadb9@mail.gmail.com>

I'm not sure what that remark meant, but everywhere I've worked with SQL
Server we used VSS to store all our sprocs, functions etc.

I even use it at home for exactly the same purpose.

A.


On 6/5/07, jwcolby <jwcolby at colbyconsulting.com> wrote:
>
> >He meant practicing...not theorizing...
>
> ROTFLMAO.
>
>
> John W. Colby
> Colby Consulting
> www.ColbyConsulting.com
> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Eric
> Barro
> Sent: Tuesday, June 05, 2007 2:34 PM
> To: dba-sqlserver at databaseadvisors.com
> Subject: Re: [dba-SQLServer] Source code version control
>
> Arthur,
>
> He meant practicing...not theorizing...
>
> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Arthur
> Fuller
> Sent: Tuesday, June 05, 2007 11:15 AM
> To: dba-sqlserver at databaseadvisors.com
> Subject: Re: [dba-SQLServer] Source code version control
>
> I thought that I responded at length to you. It's not in my drafts. Maybe
> I
> accidentally discarded it. I described the two ways of using it, one with
> VS.NET and the other without. I'll see if I can dig it up and re-send it.
> If
> not I'll redo it.
>
> Arthur
>
>
> On 6/5/07, Robert L. Stewart <rl_stewart at highstream.net> wrote:
> >
> > So, I guess since no one responded to my question, no one on the list
> > is practicing any kind of source code version control.
> > And that no one has any suggestions about it.
> >
> > Is that true?
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>


From fhtapia at gmail.com  Tue Jun  5 16:42:04 2007
From: fhtapia at gmail.com (Francisco Tapia)
Date: Tue, 5 Jun 2007 14:42:04 -0700
Subject: [dba-SQLServer] Free tools
In-Reply-To: <20070605144220.921FEBECE@smtp-auth.no-ip.com>
References: <20070605144220.921FEBECE@smtp-auth.no-ip.com>
Message-ID: <b874372a0706051442v6f12c7bak1dff8042a34487e6@mail.gmail.com>

John, if you ever need to do backups try their sqlsafe product, I personally
like the red-gate product better as it's more robust, but hey you can't
argue with free ;), btw, I've used the sqlcheck it's cool it's just a fancy
sql monitor, no alerts no nothing but a pretty graph to look at all the same
counters already available.

On 6/5/07, jwcolby <jwcolby at colbyconsulting.com> wrote:
>
> Just found this:
>
> http://www.idera.com/freetools/
>
> John W. Colby
> Colby Consulting
> www.ColbyConsulting.com
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>


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


From jwcolby at colbyconsulting.com  Tue Jun  5 20:33:33 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Tue, 5 Jun 2007 21:33:33 -0400
Subject: [dba-SQLServer] Great Smokey Mountain AccessD Conference
In-Reply-To: <c11.15b2651e.33974229@aol.com>
Message-ID: <20070606013333.E9209BE71@smtp-auth.no-ip.com>

>Too late for a latecomer to the party? 
 
Not at all.  Everybody step right up.  The first annual (or maybe bi-annual)
Great Smokey Mountain AccessD conference will be the weekend of June 23rd at
my house.  Everyone welcome.
 
I think we have a web page under development.  I'll check on that.
 
I tried to do Google earth to get my location but that didn't work.
According to Streets and Trips and the attached GPS device, my house is:
 
35.82548 N, 81.49635 W. 
Altitude 1269 Feet.

The address is:
 
1723 Twin Pines Dr.
Hudson, NC   28638
828-572-0120 is my business phone.
 
Please do not target missiles to that location as there are innocent
civilians present.
 
There will be prize drawings, there will be technical presentations, there
will be food, there will be pretty girls and handsome boys (well, one of
each if you count my two kids).
 
Come on down!

John W. Colby
Colby Consulting
www.ColbyConsulting.com 

 

  _____  

From: DBCfour at aol.com [mailto:DBCfour at aol.com] 
Sent: Tuesday, June 05, 2007 6:48 PM
To: jwcolby at colbyconsulting.com
Subject: Conference


 
John,
 
Too late for a latecomer to the party?  I had to wait until the On Call
rotation came out before I could commit.
 
I'll bring desert! :-)
 
Donna Cook



  _____  

See what's free at AOL.com <http://www.aol.com?ncid=AOLAOF00020000000503> .
8 


From rl_stewart at highstream.net  Wed Jun  6 13:10:57 2007
From: rl_stewart at highstream.net (Robert L. Stewart)
Date: Wed, 06 Jun 2007 13:10:57 -0500
Subject: [dba-SQLServer] Source code version control
In-Reply-To: <mailman.3.1181149201.18163.dba-sqlserver@databaseadvisors. com>
References: <mailman.3.1181149201.18163.dba-sqlserver@databaseadvisors.com>
Message-ID: <200706061812.l56ICZw5005435@databaseadvisors.com>

Thanks Arthur.
Further info.

We have a large db in place with multiple instances of it.
The web guy's bright idea was to take the time to put
each individual object in VSS then keep it up to date.
He got rather upset when I told him "No. It needs more
thought." What I cam up with was to check VSS and see if
an object existed. If not, add the original object and
then the new object. This would build the VSS repository
as we made changes. The idea was to be able to go back
to a previous version of an object if needed.

Robert

At 12:00 PM 6/6/2007, you wrote:
>From: dba-sqlserver-bounces at databaseadvisors.com
>[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Arthur
>Fuller
>Sent: Tuesday, June 05, 2007 11:15 AM
>To: dba-sqlserver at databaseadvisors.com
>Subject: Re: [dba-SQLServer] Source code version control
>
>I thought that I responded at length to you. It's not in my drafts. Maybe I
>accidentally discarded it. I described the two ways of using it, one with
>VS.NET and the other without. I'll see if I can dig it up and re-send it. If
>not I'll redo it.
>
>Arthur




From fuller.artful at gmail.com  Thu Jun  7 06:04:00 2007
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Thu, 7 Jun 2007 07:04:00 -0400
Subject: [dba-SQLServer] Source code version control
In-Reply-To: <200706061812.l56ICZw5005435@databaseadvisors.com>
References: <mailman.3.1181149201.18163.dba-sqlserver@databaseadvisors.com>
	<200706061812.l56ICZw5005435@databaseadvisors.com>
Message-ID: <29f585dd0706070404i488d7fd8mda06e8c46d5c75b8@mail.gmail.com>

Your general strategy is correct, IMO, but I would be tempted to take it a
little further into the past, if possible. This depends on the state of your
backups and available disk space. Think back to milestones of significant
change and see if you have backups before and immediately after such
changes. If so, then if I were you, I would start there, and build up a
history in VSS that culminates in the current build.

Among other things, this would enable you to re-create any past version
relatively painlessly. In several situations in which I worked, this was a
paramount concern, because clients 1, 2 and 3 had build x.yy while clients
4, 5 and 8 had build x+1.00. Should a customer call in with a bug report on
any version, VSS enabled us to quickly recreate exactly the version we
shipped and then duplicate the bug and then address it.

Why is this important? The larger the customer, the more important it is,
IMO. Your developer-code may have moved on from Vx to Vy, and in Vy fixed
this particular bug. But the client doesn't want to migrate; he wants
minimum ripples throughout the firm. He want this and only this bug fixed
and *nothing* else changed. IME, the larger the client firm, the more this
holds true.

That among many other things is why VSS (or any other version control
system) is so vital.

So. Two possible situations pertain: do you have VS.NET <http://vs.net/> or
not?

Yes: even then, it depends on which version you have. Standard and Express
lack features that the expensive versions have.

With VS.Studio:

0. Ensure that VSS is installed and create at least one user besides Admin.
1. Create the database project in VS.NET.
2. Open Solution Explorer.
3. Make sure that your database is one of the Database References. If the
reference does not already exist, right-click Database References and select
New Database Reference to create one that points to your database.
4. In Server Explorer, expand the Data Connections node, then your database
and keep expanding until you get to your list of stored procedures.
5. Right-click one sproc and choose Generate Create Script to Project. The
program adds the script to the Create Script folder of your project.
6. Navigate to the list of tables in your database. Choose a table and
right-click and select Generate Create Script to Project.
(Note: the Generate Create Script command may not be available in your
version of SQL 2005. If it is not available, you can generate scripts using
the Script Wizard. See below.)
7. Now we add the project to VSS. From VS.NET, select File | Source Control
| Add Project to Source Control. Log in on the next dialog.
8. VSS prompts you to add a project. Create a name and optionally add a
comment.

VSS creates a project and locks all the Create scripts you generated. Their
locked status is indicated by a lock icon beside their names. From this
moment on, you must check out a Create script before you can change it. To
view a script from within VS.NET, right-click its name and select Open. This
is a read-only view.

To change a script:

1. Close the View window.
2. Right-click the script name, then choose Check Out. The program prompts
you for a comment.
3. Make some change to the script.
4. Save the changed script and close the window.
5. Right-click the script name and choose Check In. VS.NET saves the new
script in VSS. You now have two versions of the script in VSS. That's why
it's important in Step 2 above to supply a comment that describes the change
you made.
6. *This is important*: if you follow these steps exactly, the stored
procedure *does not yet exist in the database*. To create it there, you must
right-click its name and select Run to deploy it. However, it probably makes
more sense to run the script and fix any errors before adding it to VSS.

--------
Without VS.NET

Use Management Studio to generate scripts for all objects in the database:
1. In Object Explorer, pick a database.
2. Right-click its name, then choose Tasks | Generate Scripts (not Script
Database As | Create To).
3. The Script Wizard opens. Select a database. In the next step, you can
select the scripting options.
4. On the next page, you can select which object types you want to script.
5. For each selected object type, you then get a page listing them and can
select the ones you want to script. (You can even script CLR objects if any
exist.)
6. Last, the wizard prompts you for a destination (file, clipboard or query
window).
7. Now run VSS, create a project and add the scripts you just generated.

hth,
Arthur

On 6/6/07, Robert L. Stewart <rl_stewart at highstream.net> wrote:
>
> Thanks Arthur.
> Further info.
>
> We have a large db in place with multiple instances of it.
> The web guy's bright idea was to take the time to put
> each individual object in VSS then keep it up to date.
> He got rather upset when I told him "No. It needs more
> thought." What I cam up with was to check VSS and see if
> an object existed. If not, add the original object and
> then the new object. This would build the VSS repository
> as we made changes. The idea was to be able to go back
> to a previous version of an object if needed.
>
> Robert
>
> At 12:00 PM 6/6/2007, you wrote:
> >From: dba-sqlserver-bounces at databaseadvisors.com
> >[mailto:dba-sqlserver-bounces at databaseadvisors.com ] On Behalf Of Arthur
> >Fuller
> >Sent: Tuesday, June 05, 2007 11:15 AM
> >To: dba-sqlserver at databaseadvisors.com
> >Subject: Re: [dba-SQLServer] Source code version control
> >
> >I thought that I responded at length to you. It's not in my drafts. Maybe
> I
> >accidentally discarded it. I described the two ways of using it, one with
> >VS.NET <http://vs.net/> and the other without. I'll see if I can dig it
> up and re-send it. If
> >not I'll redo it.
> >
> >Arthur
>
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>


From rl_stewart at highstream.net  Thu Jun  7 13:08:57 2007
From: rl_stewart at highstream.net (Robert L. Stewart)
Date: Thu, 07 Jun 2007 13:08:57 -0500
Subject: [dba-SQLServer] Source code version control
In-Reply-To: <mailman.5.1181235602.4594.dba-sqlserver@databaseadvisors.c
 om>
References: <mailman.5.1181235602.4594.dba-sqlserver@databaseadvisors.com>
Message-ID: <200706071810.l57IArqo028462@databaseadvisors.com>

See comments below...

At 12:00 PM 6/7/2007, you wrote:
>Date: Thu, 7 Jun 2007 07:04:00 -0400
>From: "Arthur Fuller" <fuller.artful at gmail.com>
>Subject: Re: [dba-SQLServer] Source code version control
>To: dba-sqlserver at databaseadvisors.com
>Message-ID:
>         <29f585dd0706070404i488d7fd8mda06e8c46d5c75b8 at mail.gmail.com>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
>Your general strategy is correct, IMO, but I would be tempted to take it a
>little further into the past, if possible. This depends on the state of your
>backups and available disk space. Think back to milestones of significant
>change and see if you have backups before and immediately after such
>changes. If so, then if I were you, I would start there, and build up a
>history in VSS that culminates in the current build.

Essentially, backup space is unlimited. All instances are the same
except for the importing of accounting information in one of them.
It is the only one doing it. The plan was to have a full export of
DDL for all objects as a baseline. Just not saving them individually.

>So. Two possible situations pertain: do you have VS.NET <http://vs.net/> or
>not?

Yes, I have an MSDN Universal subscription, so I have everything. :-)

We have VSS being used for the ColdFusion stuff now. So that is completely
in place.

Thanks for the pointers.

Robert 




From fuller.artful at gmail.com  Thu Jun  7 13:38:51 2007
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Thu, 7 Jun 2007 14:38:51 -0400
Subject: [dba-SQLServer] Source code version control
In-Reply-To: <200706071810.l57IArqo028462@databaseadvisors.com>
References: <mailman.5.1181235602.4594.dba-sqlserver@databaseadvisors.com>
	<200706071810.l57IArqo028462@databaseadvisors.com>
Message-ID: <29f585dd0706071138t44a47d77pf473f811375205c7@mail.gmail.com>

Then you're away to the races! Follow the VS.NET instructions that I gave
you to the letter, save the part about *Run*, since your databases already
contain the objects that the Create scripts would create.

Since your backup space is unlimited, if I were you I would go back at least
one significant build in the project(s) of interest, and recreate it|them,
then follow the instructions for VS.NET+VSS. Repeat for each build of
significance. After restoring each build, you can destroy the previous. Add
each build to VSS as a separate project. (This is not how you would do it in
practice, but it's a good way to get all the previous history in.)

Once your current build has had all its Create scripts generated, then you
can begin doing it right, which is to say, generate the scripts, add them to
VSS -- which will lock them, and from then on check out only the sprocs etc.
that you need to change. Check them out, fix whatever, then check them in.
Add a comment about what was changed and why.

This is beautiful with team projects because nobody can check out something
somebody else has checked out.

In a few places I have worked, everything related to a given project (Word,
PPT, databases, the whole nine yards) was stored in VSS. Since I realized
that VSS could do all that, I have adopted this strategy for my own practice
as well.

Arthur


On 6/7/07, Robert L. Stewart <rl_stewart at highstream.net> wrote:
>
> See comments below...
>
> At 12:00 PM 6/7/2007, you wrote:
> >Date: Thu, 7 Jun 2007 07:04:00 -0400
> >From: "Arthur Fuller" <fuller.artful at gmail.com>
> >Subject: Re: [dba-SQLServer] Source code version control
> >To: dba-sqlserver at databaseadvisors.com
> >Message-ID:
> >         <29f585dd0706070404i488d7fd8mda06e8c46d5c75b8 at mail.gmail.com>
> >Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> >
> >Your general strategy is correct, IMO, but I would be tempted to take it
> a
> >little further into the past, if possible. This depends on the state of
> your
> >backups and available disk space. Think back to milestones of significant
> >change and see if you have backups before and immediately after such
> >changes. If so, then if I were you, I would start there, and build up a
> >history in VSS that culminates in the current build.
>
> Essentially, backup space is unlimited. All instances are the same
> except for the importing of accounting information in one of them.
> It is the only one doing it. The plan was to have a full export of
> DDL for all objects as a baseline. Just not saving them individually.
>
> >So. Two possible situations pertain: do you have VS.NET <http://vs.net/>
> or
> >not?
>
> Yes, I have an MSDN Universal subscription, so I have everything. :-)
>
> We have VSS being used for the ColdFusion stuff now. So that is completely
> in place.
>
> Thanks for the pointers.
>
> Robert
>
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>


From fuller.artful at gmail.com  Sat Jun  9 10:09:19 2007
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Sat, 9 Jun 2007 11:09:19 -0400
Subject: [dba-SQLServer] Version Control
Message-ID: <29f585dd0706090809g5ecb3828m1195406aadbb0921@mail.gmail.com>

I tried replying to Mr. Stewart but maybe the reply was too lengthy. For the
benefit of others interested in how to use VSS with SQL, I am posting this
(hoping it won't appear twice):

 Your general strategy is correct, IMO, but I would be tempted to take it a
little further into the past, if possible. This depends on the state of your
backups and available disk space. Think back to milestones of significant
change and see if you have backups before and immediately after such
changes. If so, then if I were you, I would start there, and build up a
history in VSS that culminates in the current build.

Among other things, this would enable you to re-create any past version
relatively painlessly. In several situations in which I worked, this was a
paramount concern, because clients 1, 2 and 3 had build x.yy while clients
4, 5 and 8 had build x+1.00. Should a customer call in with a bug report on
any version, VSS enabled us to quickly recreate exactly the version we
shipped and then duplicate the bug and then address it.

Why is this important? The larger the customer, the more important it is,
IMO. Your developer-code may have moved on from Vx to Vy, and in Vy fixed
this particular bug. But the client doesn't want to migrate; he wants
minimum ripples throughout the firm. He want this and only this bug fixed
and *nothing* else changed. IME, the larger the client firm, the more this
holds true.

That among many other things is why VSS (or any other version control
system) is so vital.

So. Two possible situations pertain: do you have VS.NET <http://vs.net/> or
not?

Yes: even then, it depends on which version you have. Standard and Express
lack features that the expensive versions have.

With VS.Studio:

0. Ensure that VSS is installed and create at least one user besides Admin.
1. Create the database project in VS.NET <http://vs.net/> .
2. Open Solution Explorer.
3. Make sure that your database is one of the Database References. If the
reference does not already exist, right-click Database References and select
New Database Reference to create one that points to your database.
4. In Server Explorer, expand the Data Connections node, then your database
and keep expanding until you get to your list of stored procedures.
5. Right-click one sproc and choose Generate Create Script to Project. The
program adds the script to the Create Script folder of your project.
6. Navigate to the list of tables in your database. Choose a table and
right-click and select Generate Create Script to Project.
(Note: the Generate Create Script command may not be available in your
version of SQL 2005. If it is not available, you can generate scripts using
the Script Wizard. See below.)
7. Now we add the project to VSS. From VS.NET <http://vs.net/>, select File
| Source Control | Add Project to Source Control. Log in on the next dialog.

8. VSS prompts you to add a project. Create a name and optionally add a
comment.

VSS creates a project and locks all the Create scripts you generated. Their
locked status is indicated by a lock icon beside their names. From this
moment on, you must check out a Create script before you can change it. To
view a script from within VS.NET <http://vs.net/>, right-click its name and
select Open. This is a read-only view.

To change a script:

1. Close the View window.
2. Right-click the script name, then choose Check Out. The program prompts
you for a comment.
3. Make some change to the script.
4. Save the changed script and close the window.
5. Right-click the script name and choose Check In. VS.NET
<http://vs.net/>saves the new script in VSS. You now have two versions
of the script in VSS.
That's why it's important in Step 2 above to supply a comment that describes
the change you made.
6. *This is important*: if you follow these steps exactly, the stored
procedure *does not yet exist in the database*. To create it there, you must
right-click its name and select Run to deploy it. However, it probably makes
more sense to run the script and fix any errors before adding it to VSS.

--------
Without VS.NET <http://vs.net/>

Use Management Studio to generate scripts for all objects in the database:
1. In Object Explorer, pick a database.
2. Right-click its name, then choose Tasks | Generate Scripts (not Script
Database As | Create To).
3. The Script Wizard opens. Select a database. In the next step, you can
select the scripting options.
4. On the next page, you can select which object types you want to script.
5. For each selected object type, you then get a page listing them and can
select the ones you want to script. (You can even script CLR objects if any
exist.)
6. Last, the wizard prompts you for a destination (file, clipboard or query
window).
7. Now run VSS, create a project and add the scripts you just generated.

hth,
Arthur


From jlawrenc1 at shaw.ca  Sat Jun  9 19:23:25 2007
From: jlawrenc1 at shaw.ca (Jim Lawrence)
Date: Sat, 09 Jun 2007 17:23:25 -0700
Subject: [dba-SQLServer] Version Control
In-Reply-To: <29f585dd0706090809g5ecb3828m1195406aadbb0921@mail.gmail.com>
Message-ID: <0JJE00DEY8V6D3B0@l-daemon>

Hi Arthur:

Thanks for the information. Would you mind if I posted it to the DBA web
site as I feel it would be good reference material.

Jim

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Arthur
Fuller
Sent: Saturday, June 09, 2007 8:09 AM
To: dba-sqlserver at databaseadvisors.com
Subject: [dba-SQLServer] Version Control

I tried replying to Mr. Stewart but maybe the reply was too lengthy. For the
benefit of others interested in how to use VSS with SQL, I am posting this
(hoping it won't appear twice):

 Your general strategy is correct, IMO, but I would be tempted to take it a
little further into the past, if possible. This depends on the state of your
backups and available disk space. Think back to milestones of significant
change and see if you have backups before and immediately after such
changes. If so, then if I were you, I would start there, and build up a
history in VSS that culminates in the current build.

Among other things, this would enable you to re-create any past version
relatively painlessly. In several situations in which I worked, this was a
paramount concern, because clients 1, 2 and 3 had build x.yy while clients
4, 5 and 8 had build x+1.00. Should a customer call in with a bug report on
any version, VSS enabled us to quickly recreate exactly the version we
shipped and then duplicate the bug and then address it.

Why is this important? The larger the customer, the more important it is,
IMO. Your developer-code may have moved on from Vx to Vy, and in Vy fixed
this particular bug. But the client doesn't want to migrate; he wants
minimum ripples throughout the firm. He want this and only this bug fixed
and *nothing* else changed. IME, the larger the client firm, the more this
holds true.

That among many other things is why VSS (or any other version control
system) is so vital.

So. Two possible situations pertain: do you have VS.NET <http://vs.net/> or
not?

Yes: even then, it depends on which version you have. Standard and Express
lack features that the expensive versions have.

With VS.Studio:

0. Ensure that VSS is installed and create at least one user besides Admin.
1. Create the database project in VS.NET <http://vs.net/> .
2. Open Solution Explorer.
3. Make sure that your database is one of the Database References. If the
reference does not already exist, right-click Database References and select
New Database Reference to create one that points to your database.
4. In Server Explorer, expand the Data Connections node, then your database
and keep expanding until you get to your list of stored procedures.
5. Right-click one sproc and choose Generate Create Script to Project. The
program adds the script to the Create Script folder of your project.
6. Navigate to the list of tables in your database. Choose a table and
right-click and select Generate Create Script to Project.
(Note: the Generate Create Script command may not be available in your
version of SQL 2005. If it is not available, you can generate scripts using
the Script Wizard. See below.)
7. Now we add the project to VSS. From VS.NET <http://vs.net/>, select File
| Source Control | Add Project to Source Control. Log in on the next dialog.

8. VSS prompts you to add a project. Create a name and optionally add a
comment.

VSS creates a project and locks all the Create scripts you generated. Their
locked status is indicated by a lock icon beside their names. From this
moment on, you must check out a Create script before you can change it. To
view a script from within VS.NET <http://vs.net/>, right-click its name and
select Open. This is a read-only view.

To change a script:

1. Close the View window.
2. Right-click the script name, then choose Check Out. The program prompts
you for a comment.
3. Make some change to the script.
4. Save the changed script and close the window.
5. Right-click the script name and choose Check In. VS.NET
<http://vs.net/>saves the new script in VSS. You now have two versions
of the script in VSS.
That's why it's important in Step 2 above to supply a comment that describes
the change you made.
6. *This is important*: if you follow these steps exactly, the stored
procedure *does not yet exist in the database*. To create it there, you must
right-click its name and select Run to deploy it. However, it probably makes
more sense to run the script and fix any errors before adding it to VSS.

--------
Without VS.NET <http://vs.net/>

Use Management Studio to generate scripts for all objects in the database:
1. In Object Explorer, pick a database.
2. Right-click its name, then choose Tasks | Generate Scripts (not Script
Database As | Create To).
3. The Script Wizard opens. Select a database. In the next step, you can
select the scripting options.
4. On the next page, you can select which object types you want to script.
5. For each selected object type, you then get a page listing them and can
select the ones you want to script. (You can even script CLR objects if any
exist.)
6. Last, the wizard prompts you for a destination (file, clipboard or query
window).
7. Now run VSS, create a project and add the scripts you just generated.

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



From fuller.artful at gmail.com  Sat Jun  9 19:26:38 2007
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Sat, 9 Jun 2007 20:26:38 -0400
Subject: [dba-SQLServer] Version Control
In-Reply-To: <0JJE00DEY8V6D3B0@l-daemon>
References: <29f585dd0706090809g5ecb3828m1195406aadbb0921@mail.gmail.com>
	<0JJE00DEY8V6D3B0@l-daemon>
Message-ID: <29f585dd0706091726j2a1c5149lf325ab9990450b00@mail.gmail.com>

I have no objections at all, Jim, and in fact I attempted to post it there
but apparently stepped over the word-length limit because I did not see it
there. My intention was to post it for all, which didn't work, which is why
I sent it to you privately.

On 6/9/07, Jim Lawrence <jlawrenc1 at shaw.ca> wrote:
>
> Hi Arthur:
>
> Thanks for the information. Would you mind if I posted it to the DBA web
> site as I feel it would be good reference material.
>
> Jim
>


From fuller.artful at gmail.com  Sun Jun 10 12:04:42 2007
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Sun, 10 Jun 2007 13:04:42 -0400
Subject: [dba-SQLServer] More on Version control
Message-ID: <29f585dd0706101004y2efbca6ak1a7acf8f70e42b3b@mail.gmail.com>

There is commercial software available from Acorden Software that lets you
interact with VSS over the internet. This is enormously useful if your team
is geographically distributed. See
http://www.acorden.com/VSSAction/features.htm.

Arthur


From jwcolby at colbyconsulting.com  Mon Jun 11 08:26:03 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Mon, 11 Jun 2007 09:26:03 -0400
Subject: [dba-SQLServer] Get list of servers,
	databases and tables in a database
Message-ID: <20070611132604.A9853BC8D@smtp-auth.no-ip.com>

I need to allow a user (me) to navigate through my servers, databases and
tables in databases to select a specific table, for example to export to
CSV.  Does anyone know how to determine instances of database servers, then
get lists of databases in those servers, then get tables in a specific
database?

John W. Colby
Colby Consulting
www.ColbyConsulting.com 



From mwp.reid at qub.ac.uk  Mon Jun 11 08:37:55 2007
From: mwp.reid at qub.ac.uk (Martin Reid)
Date: Mon, 11 Jun 2007 14:37:55 +0100
Subject: [dba-SQLServer] Get list of servers,
	databases and tables in a database
References: <20070611132604.A9853BC8D@smtp-auth.no-ip.com>
Message-ID: <D0BF9C78D1C45C418541C852C8944FE201086B7C@qub-xchange-01.ads.qub.ac.uk>

John
 
Sent you a demo of list
 
 
Martin
 
Martin WP Reid
Training and Assessment Unit
Riddle Hall
Belfast
 
tel: 02890 974465
 

________________________________

From: dba-sqlserver-bounces at databaseadvisors.com on behalf of jwcolby
Sent: Mon 11/06/2007 14:26
To: dba-sqlserver at databaseadvisors.com; dba-vb at databaseadvisors.com
Subject: [dba-SQLServer] Get list of servers,databases and tables in a database



I need to allow a user (me) to navigate through my servers, databases and
tables in databases to select a specific table, for example to export to
CSV.  Does anyone know how to determine instances of database servers, then
get lists of databases in those servers, then get tables in a specific
database?

John W. Colby
Colby Consulting
www.ColbyConsulting.com

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




From jwcolby at colbyconsulting.com  Mon Jun 11 08:49:11 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Mon, 11 Jun 2007 09:49:11 -0400
Subject: [dba-SQLServer] [dba-VB] Get list of servers,
	databases and tables in a database
In-Reply-To: <20070611132604.A9853BC8D@smtp-auth.no-ip.com>
Message-ID: <20070611134912.6A83EC03A@smtp-auth.no-ip.com>

I forgot to specify that I am using VB.Net for this.  So I need to know how
to do all this inside of VB.Net. 


John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: dba-vb-bounces at databaseadvisors.com
[mailto:dba-vb-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Monday, June 11, 2007 9:26 AM
To: dba-sqlserver at databaseadvisors.com; dba-vb at databaseadvisors.com
Subject: [dba-VB] Get list of servers, databases and tables in a database

I need to allow a user (me) to navigate through my servers, databases and
tables in databases to select a specific table, for example to export to
CSV.  Does anyone know how to determine instances of database servers, then
get lists of databases in those servers, then get tables in a specific
database?

John W. Colby
Colby Consulting
www.ColbyConsulting.com 

_______________________________________________
dba-VB mailing list
dba-VB at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-vb
http://www.databaseadvisors.com



From jwcolby at colbyconsulting.com  Mon Jun 11 10:10:19 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Mon, 11 Jun 2007 11:10:19 -0400
Subject: [dba-SQLServer] SQL Server 2005 - Keeping servers registered
Message-ID: <20070611151020.07C5DBED8@smtp-auth.no-ip.com>

Whenever my laptop is rebooted, I lose the connected servers, i.e. I have to
go connect manually to whatever servers I had already connected to before
the reboot.  Is there a way to have the last connected servers "refreshed or
already there?  I seem to remember that it worked that way in the past, no
se why not now.

John W. Colby
Colby Consulting
www.ColbyConsulting.com 



From ebarro at verizon.net  Mon Jun 11 10:22:15 2007
From: ebarro at verizon.net (Eric Barro)
Date: Mon, 11 Jun 2007 08:22:15 -0700
Subject: [dba-SQLServer] SQL Server 2005 - Keeping servers registered
In-Reply-To: <20070611151020.07C5DBED8@smtp-auth.no-ip.com>
Message-ID: <0JJH007GZ9CTK2X4@vms048.mailsrvcs.net>

Can you see the registered servers view or are you looking at the Object
Explorer view? If you are in Object Explorer view you can right click on the
server icon and then select Register. When SQL Management Studio loads it
doesn't "remember" any connections in the Object Explorer view but it does
remember the registered servers. 

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Monday, June 11, 2007 8:10 AM
To: dba-sqlserver at databaseadvisors.com
Subject: [dba-SQLServer] SQL Server 2005 - Keeping servers registered

Whenever my laptop is rebooted, I lose the connected servers, i.e. I have to
go connect manually to whatever servers I had already connected to before
the reboot.  Is there a way to have the last connected servers "refreshed or
already there?  I seem to remember that it worked that way in the past, no
se why not now.

John W. Colby
Colby Consulting
www.ColbyConsulting.com 

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

 



From jwcolby at colbyconsulting.com  Mon Jun 11 10:31:47 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Mon, 11 Jun 2007 11:31:47 -0400
Subject: [dba-SQLServer] SQL Server 2005 - Keeping servers registered
In-Reply-To: <0JJH007GZ9CTK2X4@vms048.mailsrvcs.net>
Message-ID: <20070611153148.68B35BD20@smtp-auth.no-ip.com>

Eric,

I am in the object explorer.  I have to drop down the "connect" and then
perform a connect.  So basically I register them all then just double click
the registered server to connect to it.  With both the Registered Servers
window and the Object Explorer window pinned, that works well.

Thanks,

John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Eric Barro
Sent: Monday, June 11, 2007 11:22 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] SQL Server 2005 - Keeping servers registered

Can you see the registered servers view or are you looking at the Object
Explorer view? If you are in Object Explorer view you can right click on the
server icon and then select Register. When SQL Management Studio loads it
doesn't "remember" any connections in the Object Explorer view but it does
remember the registered servers. 

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Monday, June 11, 2007 8:10 AM
To: dba-sqlserver at databaseadvisors.com
Subject: [dba-SQLServer] SQL Server 2005 - Keeping servers registered

Whenever my laptop is rebooted, I lose the connected servers, i.e. I have to
go connect manually to whatever servers I had already connected to before
the reboot.  Is there a way to have the last connected servers "refreshed or
already there?  I seem to remember that it worked that way in the past, no
se why not now.

John W. Colby
Colby Consulting
www.ColbyConsulting.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 Jeff at outbaktech.com  Mon Jun 11 14:33:24 2007
From: Jeff at outbaktech.com (Jeff Barrows)
Date: Mon, 11 Jun 2007 14:33:24 -0500
Subject: [dba-SQLServer] Creating Multiple copies of a database
Message-ID: <E2FBF0A51D2A324C90BA16C566366A6D0D9216@belgarion.Outbak.local>

I have a need to create 35 copies of a SQL database, all with different names on the same server.  Is there a quick and easy way to do this?
 
Jeff Barrows
MCP, MCAD, MCSD
 
Outbak Technologies, LLC
Racine, WI
jeff at outbaktech.com


From fuller.artful at gmail.com  Mon Jun 11 16:00:04 2007
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Mon, 11 Jun 2007 17:00:04 -0400
Subject: [dba-SQLServer] Creating Multiple copies of a database
In-Reply-To: <E2FBF0A51D2A324C90BA16C566366A6D0D9216@belgarion.Outbak.local>
References: <E2FBF0A51D2A324C90BA16C566366A6D0D9216@belgarion.Outbak.local>
Message-ID: <29f585dd0706111400h19ce25fbl1dcaff4537ad55b7@mail.gmail.com>

I can think of several methods, Jeff. My first choice would be SMO (in SQL
2005), or DTS (in 2000). There are lots of good examples for SMO usage.
Google same and you'll be there in no time.

Arthur


On 6/11/07, Jeff Barrows <Jeff at outbaktech.com> wrote:
>
> I have a need to create 35 copies of a SQL database, all with different
> names on the same server.  Is there a quick and easy way to do this?
>
> Jeff Barrows
> MCP, MCAD, MCSD
>
> Outbak Technologies, LLC
> Racine, WI
> jeff at outbaktech.com
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>


From jwcolby at colbyconsulting.com  Tue Jun 12 08:00:48 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Tue, 12 Jun 2007 09:00:48 -0400
Subject: [dba-SQLServer] SQL Server 2005 - long count time
Message-ID: <20070612130049.6F7E0BD81@smtp-auth.no-ip.com>

I have a table of 99 million records.  The table has a PK (int) which is the
PK.  It has a CLUSTERED unique index, which is being used to enforce the
unique attribute.  When I try to do a count on that field, it takes forever
(timed out!).  I have another table with a non-clustered index on the PKID
and it takes a couple of seconds to return a count.

1) Is it the fact that the index is clustered that is causing it to take so
long to count, or is it something else?
2) A clustered index is inappropriate anyway correct?  This field is a
unique integer value.
3) I am trying to delete the index but it is telling me that it is being
used to enforce the PK unique attribute.  I try to (manually) remove the
"PK" attribute from the field but it times out deleting the index!!!  How do
I get rid of this thing?  I think I am going to have to write a SQL
statement to remove the PK attribute from the field but that is a bit beyond
my SQL writing skills.

John W. Colby
Colby Consulting
www.ColbyConsulting.com 



From jwcolby at colbyconsulting.com  Tue Jun 12 08:09:24 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Tue, 12 Jun 2007 09:09:24 -0400
Subject: [dba-SQLServer] SQL Server 2005 - long count time
In-Reply-To: <20070612130049.6F7E0BD81@smtp-auth.no-ip.com>
Message-ID: <20070612130925.8815BBE93@smtp-auth.no-ip.com>

Just an FYI, I created an ADDITIONAL non-clustered unique index and can now
get a count of that table in a second or so.  I think I still would like to
get rid of the clustered index.


John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Tuesday, June 12, 2007 9:01 AM
To: dba-sqlserver at databaseadvisors.com
Subject: [dba-SQLServer] SQL Server 2005 - long count time

I have a table of 99 million records.  The table has a PK (int) which is the
PK.  It has a CLUSTERED unique index, which is being used to enforce the
unique attribute.  When I try to do a count on that field, it takes forever
(timed out!).  I have another table with a non-clustered index on the PKID
and it takes a couple of seconds to return a count.

1) Is it the fact that the index is clustered that is causing it to take so
long to count, or is it something else?
2) A clustered index is inappropriate anyway correct?  This field is a
unique integer value.
3) I am trying to delete the index but it is telling me that it is being
used to enforce the PK unique attribute.  I try to (manually) remove the
"PK" attribute from the field but it times out deleting the index!!!  How do
I get rid of this thing?  I think I am going to have to write a SQL
statement to remove the PK attribute from the field but that is a bit beyond
my SQL writing skills.

John W. Colby
Colby Consulting
www.ColbyConsulting.com 

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



From Elizabeth.J.Doering at wellsfargo.com  Tue Jun 12 10:32:59 2007
From: Elizabeth.J.Doering at wellsfargo.com (Elizabeth.J.Doering at wellsfargo.com)
Date: Tue, 12 Jun 2007 10:32:59 -0500
Subject: [dba-SQLServer] Scheduling DTSX packages in SQL Server 2005
References: <20070612130925.8815BBE93@smtp-auth.no-ip.com>
Message-ID: <1C2084FD2472124AB1812A5476EA3B7A017DD7E5@msgswbmnmsp04.wellsfargo.com>

Dear List,

I have created a perfectly nice dtsx package which moves data from a
table in one database on a server (running SQL Server 2000) to an
identical table on another server running SQL Server 2005. When I save
the package to my desktop and double click on it, it runs perfectly.  

Because it's from 2000 to 2005, I don't have the option to do this in
2000.  

When I schedule that package to run every hour, it fails.  On the hour
and when I randomly click on it and "Start Job at Step".  I have done
everything I can think of to make the nasty thing run, but all it
reports in History is "The job failed.  The Job was invoked by User
AD-ENT\elizabeth.j.doering.  The last step to run was step 1 (Step1)."
This is beginning to feel rather personal here, like the server gods
have it in for User AD-ENT\elizabeth.j.doering, i.e, me.  

I've done everything I can think of, but that was a short list, mostly
involving rescheduling the package.  I've also torn my hair and jumped
up and down, but those don't seem to help either.  Ideas, anyone?


Thanks, 


Liz 


Liz Doering
elizabeth.j.doering at wellsfargo.com
612.667.2447


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



From jwcolby at colbyconsulting.com  Tue Jun 12 10:47:35 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Tue, 12 Jun 2007 11:47:35 -0400
Subject: [dba-SQLServer] Scheduling DTSX packages in SQL Server 2005
In-Reply-To: <1C2084FD2472124AB1812A5476EA3B7A017DD7E5@msgswbmnmsp04.wellsfargo.com>
Message-ID: <20070612154736.9C860BF4E@smtp-auth.no-ip.com>

Did you hop up and down ON ONE FOOT?  Try alternating feet?  Try kneeling
facing east and kissing the floor three times while chanting
"aaaaoooooommmmmmm...... Thisiswhatidoforaliving....
Aaaoooooommmmmm......thisiswhatidoforaliving.....aaaaooooommmmm...... 

;-)

John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of
Elizabeth.J.Doering at wellsfargo.com
Sent: Tuesday, June 12, 2007 11:33 AM
To: dba-sqlserver at databaseadvisors.com
Subject: [dba-SQLServer] Scheduling DTSX packages in SQL Server 2005

Dear List,

I have created a perfectly nice dtsx package which moves data from a table
in one database on a server (running SQL Server 2000) to an identical table
on another server running SQL Server 2005. When I save the package to my
desktop and double click on it, it runs perfectly.  

Because it's from 2000 to 2005, I don't have the option to do this in 2000.


When I schedule that package to run every hour, it fails.  On the hour and
when I randomly click on it and "Start Job at Step".  I have done everything
I can think of to make the nasty thing run, but all it reports in History is
"The job failed.  The Job was invoked by User AD-ENT\elizabeth.j.doering.
The last step to run was step 1 (Step1)."
This is beginning to feel rather personal here, like the server gods have it
in for User AD-ENT\elizabeth.j.doering, i.e, me.  

I've done everything I can think of, but that was a short list, mostly
involving rescheduling the package.  I've also torn my hair and jumped up
and down, but those don't seem to help either.  Ideas, anyone?


Thanks, 


Liz 


Liz Doering
elizabeth.j.doering at wellsfargo.com
612.667.2447


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

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



From ebarro at verizon.net  Tue Jun 12 10:48:53 2007
From: ebarro at verizon.net (Eric Barro)
Date: Tue, 12 Jun 2007 08:48:53 -0700
Subject: [dba-SQLServer] Scheduling DTSX packages in SQL Server 2005
In-Reply-To: <1C2084FD2472124AB1812A5476EA3B7A017DD7E5@msgswbmnmsp04.wellsfargo.com>
Message-ID: <0JJJ00HKV59Y27P7@vms040.mailsrvcs.net>

Check show details to see why it's failing. You're just skimming the surface
when you view job history. 

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of
Elizabeth.J.Doering at wellsfargo.com
Sent: Tuesday, June 12, 2007 8:33 AM
To: dba-sqlserver at databaseadvisors.com
Subject: [dba-SQLServer] Scheduling DTSX packages in SQL Server 2005

Dear List,

I have created a perfectly nice dtsx package which moves data from a table
in one database on a server (running SQL Server 2000) to an identical table
on another server running SQL Server 2005. When I save the package to my
desktop and double click on it, it runs perfectly.  

Because it's from 2000 to 2005, I don't have the option to do this in 2000.


When I schedule that package to run every hour, it fails.  On the hour and
when I randomly click on it and "Start Job at Step".  I have done everything
I can think of to make the nasty thing run, but all it reports in History is
"The job failed.  The Job was invoked by User AD-ENT\elizabeth.j.doering.
The last step to run was step 1 (Step1)."
This is beginning to feel rather personal here, like the server gods have it
in for User AD-ENT\elizabeth.j.doering, i.e, me.  

I've done everything I can think of, but that was a short list, mostly
involving rescheduling the package.  I've also torn my hair and jumped up
and down, but those don't seem to help either.  Ideas, anyone?


Thanks, 


Liz 


Liz Doering
elizabeth.j.doering at wellsfargo.com
612.667.2447


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

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

No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.472 / Virus Database: 269.8.14/845 - Release Date: 6/12/2007
6:39 AM
 



From fuller.artful at gmail.com  Tue Jun 12 10:56:31 2007
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Tue, 12 Jun 2007 11:56:31 -0400
Subject: [dba-SQLServer] Scheduling DTSX packages in SQL Server 2005
In-Reply-To: <1C2084FD2472124AB1812A5476EA3B7A017DD7E5@msgswbmnmsp04.wellsfargo.com>
References: <20070612130925.8815BBE93@smtp-auth.no-ip.com>
	<1C2084FD2472124AB1812A5476EA3B7A017DD7E5@msgswbmnmsp04.wellsfargo.com>
Message-ID: <29f585dd0706120856o69932963g7db3431d42f2743@mail.gmail.com>

Try saving the package to vbScript rather than the database, and send it to
me off-list. That would be a big help in diagnosing your problem.

Arthur


On 6/12/07, Elizabeth.J.Doering at wellsfargo.com <
Elizabeth.J.Doering at wellsfargo.com> wrote:
>
> Dear List,
>
> I have created a perfectly nice dtsx package which moves data from a
> table in one database on a server (running SQL Server 2000) to an
> identical table on another server running SQL Server 2005. When I save
> the package to my desktop and double click on it, it runs perfectly.
>
> Because it's from 2000 to 2005, I don't have the option to do this in
> 2000.
>
> When I schedule that package to run every hour, it fails.  On the hour
> and when I randomly click on it and "Start Job at Step".  I have done
> everything I can think of to make the nasty thing run, but all it
> reports in History is "The job failed.  The Job was invoked by User
> AD-ENT\elizabeth.j.doering.  The last step to run was step 1 (Step1)."
> This is beginning to feel rather personal here, like the server gods
> have it in for User AD-ENT\elizabeth.j.doering, i.e, me.
>
> I've done everything I can think of, but that was a short list, mostly
> involving rescheduling the package.  I've also torn my hair and jumped
> up and down, but those don't seem to help either.  Ideas, anyone?
>
>
> Thanks,
>
>
> Liz
>
>
> Liz Doering
> elizabeth.j.doering at wellsfargo.com
> 612.667.2447
>
>
> This message may contain confidential and/or privileged information. If
> you are not the addressee or authorized to receive this for the
> addressee, you must not use, copy, disclose, or take any action based on
> this message or any information herein. If you have received this
> message in error, please advise the sender immediately by reply e-mail
> and delete this message. Thank you for your cooperation.
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>


From Elizabeth.J.Doering at wellsfargo.com  Tue Jun 12 10:59:50 2007
From: Elizabeth.J.Doering at wellsfargo.com (Elizabeth.J.Doering at wellsfargo.com)
Date: Tue, 12 Jun 2007 10:59:50 -0500
Subject: [dba-SQLServer] Scheduling DTSX packages in SQL Server 2005
References: <0JJJ00HKV59Y27P7@vms040.mailsrvcs.net>
Message-ID: <1C2084FD2472124AB1812A5476EA3B7A017DD7FD@msgswbmnmsp04.wellsfargo.com>

Thanks for the suggestion, Eric.  Here's the details:

Date		6/12/2007 8:21:04 AM
Log		Job History (ImportJM)

Step ID		0
Server		RBWZP4051
Job Name		ImportJM
Step Name		(Job outcome)
Duration		00:00:01
Sql Severity		0
Sql Message ID		0
Operator Emailed		
Operator Net sent		
Operator Paged		
Retries Attempted		0

Message
The job failed.  The Job was invoked by User AD-ENT\elizabeth.j.doering.
The last step to run was step 1 (Step1).

There is only one step.  I have a DateImported field in the table, which
defaults to getdate().   It's not getting updated.  

Liz

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Eric
Barro
Sent: Tuesday, June 12, 2007 10:49 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Scheduling DTSX packages in SQL Server 2005

Check show details to see why it's failing. You're just skimming the
surface when you view job history. 

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of
Elizabeth.J.Doering at wellsfargo.com
Sent: Tuesday, June 12, 2007 8:33 AM
To: dba-sqlserver at databaseadvisors.com
Subject: [dba-SQLServer] Scheduling DTSX packages in SQL Server 2005

Dear List,

I have created a perfectly nice dtsx package which moves data from a
table in one database on a server (running SQL Server 2000) to an
identical table on another server running SQL Server 2005. When I save
the package to my desktop and double click on it, it runs perfectly.  

Because it's from 2000 to 2005, I don't have the option to do this in
2000.


When I schedule that package to run every hour, it fails.  On the hour
and when I randomly click on it and "Start Job at Step".  I have done
everything I can think of to make the nasty thing run, but all it
reports in History is "The job failed.  The Job was invoked by User
AD-ENT\elizabeth.j.doering.
The last step to run was step 1 (Step1)."
This is beginning to feel rather personal here, like the server gods
have it in for User AD-ENT\elizabeth.j.doering, i.e, me.  

I've done everything I can think of, but that was a short list, mostly
involving rescheduling the package.  I've also torn my hair and jumped
up and down, but those don't seem to help either.  Ideas, anyone?


Thanks, 


Liz 


Liz Doering
elizabeth.j.doering at wellsfargo.com
612.667.2447


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

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

No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.472 / Virus Database: 269.8.14/845 - Release Date:
6/12/2007
6:39 AM
 

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





From ebarro at verizon.net  Tue Jun 12 12:36:50 2007
From: ebarro at verizon.net (Eric Barro)
Date: Tue, 12 Jun 2007 10:36:50 -0700
Subject: [dba-SQLServer] Scheduling DTSX packages in SQL Server 2005
In-Reply-To: <1C2084FD2472124AB1812A5476EA3B7A017DD7FD@msgswbmnmsp04.wellsfargo.com>
Message-ID: <0JJJ00I5VA9LP0D0@vms046.mailsrvcs.net>

1. So the DTSX package runs on your machine when you run it right?
2. The scheduled job fail when you manually run it and when it is scheduled
to run?

I would go check the following:

1. Context under which the scheduled job is run. In other words, what login
is the job using when it runs?
2. Is RBWZP4051 your machine name?
3. In both instances, you are running it from your machine right?

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of
Elizabeth.J.Doering at wellsfargo.com
Sent: Tuesday, June 12, 2007 9:00 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Scheduling DTSX packages in SQL Server 2005

Thanks for the suggestion, Eric.  Here's the details:

Date		6/12/2007 8:21:04 AM
Log		Job History (ImportJM)

Step ID		0
Server		RBWZP4051
Job Name		ImportJM
Step Name		(Job outcome)
Duration		00:00:01
Sql Severity		0
Sql Message ID		0
Operator Emailed		
Operator Net sent		
Operator Paged		
Retries Attempted		0

Message
The job failed.  The Job was invoked by User AD-ENT\elizabeth.j.doering.
The last step to run was step 1 (Step1).

There is only one step.  I have a DateImported field in the table, which
defaults to getdate().   It's not getting updated.  

Liz

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Eric Barro
Sent: Tuesday, June 12, 2007 10:49 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Scheduling DTSX packages in SQL Server 2005

Check show details to see why it's failing. You're just skimming the surface
when you view job history. 

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of
Elizabeth.J.Doering at wellsfargo.com
Sent: Tuesday, June 12, 2007 8:33 AM
To: dba-sqlserver at databaseadvisors.com
Subject: [dba-SQLServer] Scheduling DTSX packages in SQL Server 2005

Dear List,

I have created a perfectly nice dtsx package which moves data from a table
in one database on a server (running SQL Server 2000) to an identical table
on another server running SQL Server 2005. When I save the package to my
desktop and double click on it, it runs perfectly.  

Because it's from 2000 to 2005, I don't have the option to do this in 2000.


When I schedule that package to run every hour, it fails.  On the hour and
when I randomly click on it and "Start Job at Step".  I have done everything
I can think of to make the nasty thing run, but all it reports in History is
"The job failed.  The Job was invoked by User AD-ENT\elizabeth.j.doering.
The last step to run was step 1 (Step1)."
This is beginning to feel rather personal here, like the server gods have it
in for User AD-ENT\elizabeth.j.doering, i.e, me.  

I've done everything I can think of, but that was a short list, mostly
involving rescheduling the package.  I've also torn my hair and jumped up
and down, but those don't seem to help either.  Ideas, anyone?


Thanks, 


Liz 


Liz Doering
elizabeth.j.doering at wellsfargo.com
612.667.2447


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

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

No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.472 / Virus Database: 269.8.14/845 - Release Date:
6/12/2007
6:39 AM
 

_______________________________________________
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

No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.472 / Virus Database: 269.8.14/845 - Release Date: 6/12/2007
6:39 AM
 



From mwp.reid at qub.ac.uk  Tue Jun 12 12:45:09 2007
From: mwp.reid at qub.ac.uk (Martin Reid)
Date: Tue, 12 Jun 2007 18:45:09 +0100
Subject: [dba-SQLServer] Scheduling DTSX packages in SQL Server 2005
References: <20070612154736.9C860BF4E@smtp-auth.no-ip.com>
Message-ID: <D0BF9C78D1C45C418541C852C8944FE201086B95@qub-xchange-01.ads.qub.ac.uk>

Now John you know that only works on the third friday in december when the moon is in the east and you dye your hair red!
 
Martin
 
Sorry could not resist
 
Martin WP Reid
Training and Assessment Unit
Riddle Hall
Belfast
 
tel: 02890 974465
 

________________________________

From: dba-sqlserver-bounces at databaseadvisors.com on behalf of jwcolby
Sent: Tue 12/06/2007 16:47
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Scheduling DTSX packages in SQL Server 2005



Did you hop up and down ON ONE FOOT?  Try alternating feet?  Try kneeling
facing east and kissing the floor three times while chanting
"aaaaoooooommmmmmm...... Thisiswhatidoforaliving....
Aaaoooooommmmmm......thisiswhatidoforaliving.....aaaaooooommmmm......

;-)

John W. Colby
Colby Consulting
www.ColbyConsulting.com
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of
Elizabeth.J.Doering at wellsfargo.com
Sent: Tuesday, June 12, 2007 11:33 AM
To: dba-sqlserver at databaseadvisors.com
Subject: [dba-SQLServer] Scheduling DTSX packages in SQL Server 2005

Dear 


From jwcolby at colbyconsulting.com  Tue Jun 12 12:56:19 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Tue, 12 Jun 2007 13:56:19 -0400
Subject: [dba-SQLServer] Scheduling DTSX packages in SQL Server 2005
In-Reply-To: <D0BF9C78D1C45C418541C852C8944FE201086B95@qub-xchange-01.ads.qub.ac.uk>
Message-ID: <20070612175620.5FA00BD45@smtp-auth.no-ip.com>

>Now John you know that only works on the third friday in december when the
moon is in the east and you dye your hair red!

True, but at least you have a once yearly shot at it working.  And you can
always dye your hair back.


John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Martin Reid
Sent: Tuesday, June 12, 2007 1:45 PM
To: dba-sqlserver at databaseadvisors.com
Subject: [dba-SQLServer] Scheduling DTSX packages in SQL Server 2005

Now John you know that only works on the third friday in december when the
moon is in the east and you dye your hair red!
 
Martin
 
Sorry could not resist
 
Martin WP Reid
Training and Assessment Unit
Riddle Hall
Belfast
 
tel: 02890 974465
 

________________________________

From: dba-sqlserver-bounces at databaseadvisors.com on behalf of jwcolby
Sent: Tue 12/06/2007 16:47
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Scheduling DTSX packages in SQL Server 2005



Did you hop up and down ON ONE FOOT?  Try alternating feet?  Try kneeling
facing east and kissing the floor three times while chanting
"aaaaoooooommmmmmm...... Thisiswhatidoforaliving....
Aaaoooooommmmmm......thisiswhatidoforaliving.....aaaaooooommmmm......

;-)

John W. Colby
Colby Consulting
www.ColbyConsulting.com
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of
Elizabeth.J.Doering at wellsfargo.com
Sent: Tuesday, June 12, 2007 11:33 AM
To: dba-sqlserver at databaseadvisors.com
Subject: [dba-SQLServer] Scheduling DTSX packages in SQL Server 2005

Dear 




From ab-mi at post3.tele.dk  Tue Jun 12 16:54:17 2007
From: ab-mi at post3.tele.dk (Asger Blond)
Date: Tue, 12 Jun 2007 23:54:17 +0200
Subject: [dba-SQLServer] Assembly informations
Message-ID: <000601c7ad3c$3bb48dc0$2101a8c0@AB>

Hi group

 

Does anyone know how to obtain informations about namespaces, classes, and
methods exposed by a CLR-assembly registrered in a SQL Server database?

I can't find any T-SQL way to this information. Do I really need the source
code for the dll? Or perhaps a hot relation to the programmer of the dll
herself?

 

Asger



From michael at ddisolutions.com.au  Tue Jun 12 21:50:32 2007
From: michael at ddisolutions.com.au (Michael Maddison)
Date: Wed, 13 Jun 2007 12:50:32 +1000
Subject: [dba-SQLServer] SQL Server 2005 - long count time
References: <20070612130925.8815BBE93@smtp-auth.no-ip.com>
Message-ID: <59A61174B1F5B54B97FD4ADDE71E7D012898FB@ddi-01.DDI.local>

John,

I don't know why the heap index was quicker but I would seriously
hesitate to remove the clustered index.  
Maybe the rsult of the 1st query was cached when you ran the 2nd query?

As the physical data is stored in clustered index order (a clustered
index is basically the data) removing it turns the table into a heap,
literally.
This can have serious consequences for performance particularly on large
tables.  It can also cause fragmentation problems which again can have
performance issues.  AFAIK clustered indexes are preferred for all
tables with more then a dozen or so rows, of course knowing which
column/s
to index is a grey area.
I recommend you research slow count queries before making such a radical
change.

cheers

Michael M

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Tuesday, 12 June 2007 11:09 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] SQL Server 2005 - long count time

Just an FYI, I created an ADDITIONAL non-clustered unique index and can
now get a count of that table in a second or so.  I think I still would
like to get rid of the clustered index.


John W. Colby
Colby Consulting
www.ColbyConsulting.com
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Tuesday, June 12, 2007 9:01 AM
To: dba-sqlserver at databaseadvisors.com
Subject: [dba-SQLServer] SQL Server 2005 - long count time

I have a table of 99 million records.  The table has a PK (int) which is
the PK.  It has a CLUSTERED unique index, which is being used to enforce
the unique attribute.  When I try to do a count on that field, it takes
forever (timed out!).  I have another table with a non-clustered index
on the PKID and it takes a couple of seconds to return a count.

1) Is it the fact that the index is clustered that is causing it to take
so long to count, or is it something else?
2) A clustered index is inappropriate anyway correct?  This field is a
unique integer value.
3) I am trying to delete the index but it is telling me that it is being
used to enforce the PK unique attribute.  I try to (manually) remove the
"PK" attribute from the field but it times out deleting the index!!!
How do I get rid of this thing?  I think I am going to have to write a
SQL statement to remove the PK attribute from the field but that is a
bit beyond my SQL writing skills.

John W. Colby
Colby Consulting
www.ColbyConsulting.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 jwcolby at colbyconsulting.com  Tue Jun 12 22:19:42 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Tue, 12 Jun 2007 23:19:42 -0400
Subject: [dba-SQLServer] SQL Server 2005 - long count time
In-Reply-To: <59A61174B1F5B54B97FD4ADDE71E7D012898FB@ddi-01.DDI.local>
Message-ID: <20070613031943.9001DBCBB@smtp-auth.no-ip.com>

Michael,

Thanks for the reply.  Let me expand a little here.

This table is the 99 million record data set that I imported the other day.
The data came with some sort of PK field but it was nothing I created and
had no meaning to me.  It still exists.  

After the import, I created a PKID field, integer, autoincrement etc.
Somehow I created a primary key on that new integer field which used a
clustered index.  I did not intend to.  I can in fact, if I so desire (and
can cause it to happen) delete this PKID field entirely and start over.  I
created it, it is not integral to my data in any way, it is just a method of
setting up a unique record identifier (PK) based on an autoincrement
integer.  

One of the problems that dogs me still is that I cannot do particular things
in SQL Server from the "wizards", things like run a view of any complexity.
They simply time out (after about 1 minute or so).  I can copy and paste the
identical SQL from the view into a "new query" in the same database and it
will run just fine, even if the query takes 30 minutes to run.  It will not
time out.  I have yet to figure that one out.  The impact of that issue
however is that if I try to do things like delete a field in a large table
(for example), it takes so long that the operation times out, again after
about 1 minute.

So, I try to delete this clustered index - timeout.  Try to delete the PK
symbol from the field - timeout.  Try to create a new index - works fine.

So, I have a new non-clustered index on the PKID field, as well as the
clustered index which I cannot delete.  It seems redundant to have both, and
I certainly do not need a clustered index AFAIK.  I really do not understand
the clustered thing (sad, I know), I have read several explanations and I
just haven't yet wrapped my mind around it.

Anyway, other than the fact that I do not need the clustered index (none of
my other such huge tables have one, all are non-clustered) and it is taking
up space, it seems to not cause me any harm.  I was just looking to get rid
of it because AFAIK I do not need it (and it takes up room, or so I
thought).

John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Michael
Maddison
Sent: Tuesday, June 12, 2007 10:51 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] SQL Server 2005 - long count time

John,

I don't know why the heap index was quicker but I would seriously hesitate
to remove the clustered index.  
Maybe the rsult of the 1st query was cached when you ran the 2nd query?

As the physical data is stored in clustered index order (a clustered index
is basically the data) removing it turns the table into a heap, literally.
This can have serious consequences for performance particularly on large
tables.  It can also cause fragmentation problems which again can have
performance issues.  AFAIK clustered indexes are preferred for all tables
with more then a dozen or so rows, of course knowing which column/s to index
is a grey area.
I recommend you research slow count queries before making such a radical
change.

cheers

Michael M



From michael at ddisolutions.com.au  Tue Jun 12 22:37:24 2007
From: michael at ddisolutions.com.au (Michael Maddison)
Date: Wed, 13 Jun 2007 13:37:24 +1000
Subject: [dba-SQLServer] SQL Server 2005 - long count time
References: <20070613031943.9001DBCBB@smtp-auth.no-ip.com>
Message-ID: <59A61174B1F5B54B97FD4ADDE71E7D012898FD@ddi-01.DDI.local>

Hi John,

Heres a great explanation I saved from another list....

//starts here//
Just wanted to throw in some bits and pieces to the puzzle.. =;o)
 
First off, there's no absolutes here. Like most other stuff, it depends.
Though many times one or the other may be considered 'best', it's not
the same as 'is always so'. Just wanted to make that clear. 
 
Also, there's sometimes a religious aspect to the debate on indexes. Not
so much as other topics (eg nulls - to be or not to be), but sometimes
there is a hint of it. It doesn't matter, it's just different opinions.
Again, there is no absolute truth that applies to all, only those we
ourselves choose to like. 
 
So..  my point is that some stuff is 'recommended', that is true. But,
most important is that we try to make our own choices, because we know
our own situations best. To be able to choose wisely, we need to have
information. So, it helps to know a bit about how this stuff works, what
it does, and sometimes what it doesn't... 
 
Consider a lone table, with no indexes at all. This is also known as a
'heap'.
Add a nonclustered index (nci), or several nci's. We still have a heap.
A 'heap' is basically (in my mind anyway) something that is unordered.
What a heap cannot do, is to order itself, or 'defrag' or 'compact'
itself, because there is no spoon (..err order)
 
nci's in a heap looks like this - the actual data from the column(s)
that is covered by the nci, and a pointer that points to the datapage
where the rest of the row is stored. This is important to know.
 
If we add a clustered index (ci) the table is no longer a heap. It's is
know ordered by the ci. So there is a physical aspect to the table.
Now, we may defrag, resort, reorg or compact the table - that is one
thing that a ci is the tool for.
 
A ci looks like this - it contains the actual data from the column(s)
that is covered by the ci in it's indexpages - but the leafnode is the
entire row. There is no pointer, because none is needed, you're already
'home'. 
This also makes a 'ci scan' the same as a 'table scan'.
Since the leafnode is also the already existing data, a ci takes about
90% less space as an index, compared to a nci.
 
Another aspect is that a ci must always be unique. It's not the same as
we can only place one on unique data, we are allowed to place a ci on
non-unique data, but... when we do that, an extra uniqifier is created
for us, so that internally, the data becomes unique. Thus, a ci is
always unique. This is good to know, because if data has to be
'uniquefied', it requires extra space, and the ci then becomes a little
wider than if it was created on unique data. 

Now, suppose we've done the above, what about the nci's we started out
with? 
Well, stuff has happened since the ci came into play.
 
nci's *not* in a heap looks like this - the actual data from the
column(s) that is covered by the nci, but the pointer that earlier
pointed to the datapage where the rest of the row was stored, is now
replaced by the *entire ci* - sort of 'key in key'. This is also
important to know. 
 
This also tells us that the coice of ci in terms of how wide it is, also
affects all our nci's, since they will each and everyone inherit the ci
into themselves. In the end this transforms to space, and space
transforms to performance. 
 
Anyone confused yet? =;o)
Is any of this relevant, worth remembering or not?
I think it is. It helps us decide what to prioritize when balancing on
the edge of 'index-magics'.
There's no absolute rights or wrongs here, it's all a tradeoff between
'good' and 'bad' aspects of index-types, coverings, behaviours etc.
But, the more we know about the bits, the more educated guesses we can
make, and maybe more importantly, we can also provide our intentions and
reasoning behind those choices.
 
...anyways, that's how I understand it...
 
=;o)
/Kenneth 

//to here//

cheers

Michael M




Michael,

Thanks for the reply.  Let me expand a little here.

This table is the 99 million record data set that I imported the other
day.
The data came with some sort of PK field but it was nothing I created
and had no meaning to me.  It still exists.  

After the import, I created a PKID field, integer, autoincrement etc.
Somehow I created a primary key on that new integer field which used a
clustered index.  I did not intend to.  I can in fact, if I so desire
(and can cause it to happen) delete this PKID field entirely and start
over.  I created it, it is not integral to my data in any way, it is
just a method of setting up a unique record identifier (PK) based on an
autoincrement integer.  

One of the problems that dogs me still is that I cannot do particular
things in SQL Server from the "wizards", things like run a view of any
complexity.
They simply time out (after about 1 minute or so).  I can copy and paste
the identical SQL from the view into a "new query" in the same database
and it will run just fine, even if the query takes 30 minutes to run.
It will not time out.  I have yet to figure that one out.  The impact of
that issue however is that if I try to do things like delete a field in
a large table (for example), it takes so long that the operation times
out, again after about 1 minute.

So, I try to delete this clustered index - timeout.  Try to delete the
PK symbol from the field - timeout.  Try to create a new index - works
fine.

So, I have a new non-clustered index on the PKID field, as well as the
clustered index which I cannot delete.  It seems redundant to have both,
and I certainly do not need a clustered index AFAIK.  I really do not
understand the clustered thing (sad, I know), I have read several
explanations and I just haven't yet wrapped my mind around it.

Anyway, other than the fact that I do not need the clustered index (none
of my other such huge tables have one, all are non-clustered) and it is
taking up space, it seems to not cause me any harm.  I was just looking
to get rid of it because AFAIK I do not need it (and it takes up room,
or so I thought).

John W. Colby
Colby Consulting
www.ColbyConsulting.com
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Michael
Maddison
Sent: Tuesday, June 12, 2007 10:51 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] SQL Server 2005 - long count time

John,

I don't know why the heap index was quicker but I would seriously
hesitate to remove the clustered index.  
Maybe the rsult of the 1st query was cached when you ran the 2nd query?

As the physical data is stored in clustered index order (a clustered
index is basically the data) removing it turns the table into a heap,
literally.
This can have serious consequences for performance particularly on large
tables.  It can also cause fragmentation problems which again can have
performance issues.  AFAIK clustered indexes are preferred for all
tables with more then a dozen or so rows, of course knowing which
column/s to index is a grey area.
I recommend you research slow count queries before making such a radical
change.

cheers

Michael M

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




From jwcolby at colbyconsulting.com  Tue Jun 12 23:02:22 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Wed, 13 Jun 2007 00:02:22 -0400
Subject: [dba-SQLServer] SQL Server 2005 - long count time
In-Reply-To: <59A61174B1F5B54B97FD4ADDE71E7D012898FD@ddi-01.DDI.local>
Message-ID: <20070613040223.AC14FBDF5@smtp-auth.no-ip.com>

Interesting but also confusing.  It sounds like a CI is always preferable
but apparently not or there would not be a "religious" aspect to it.  But
the author does not describe any downsides, or at least in sufficient extent
to allow me to discern it as such. 

If a nci is a separate object somewhere, with pointers to the real object
(which describes my understanding if the nci) then is it faster to scan,
looking for matches (because it is not a table scan)?  IOW, my understanding
of a table scan was that each row of data is stored (more less) together on
the disk.  Thus a "table scan" has to wade through 99 million reads of the
entire record, whereas a NCI is a separate structure and thus the data read
while "scanning" the index is just the data (an integer in this case) plus
the leaf pointer (probably another integer) - less data to read off the
disk.

In this case, the data in an autonumber integer PK has no meaning, it is
nothing more than a pointer to the data, thus all of the arguments for using
a ci are moot.  Sorting by the autonumber integer PKID is meaningless.  Even
if the data was originally stored in some order (last name / first name or
something) the integer PKID does not reflect that meaning in any way.

Defrag?  Compact?  Are we saying that without a ci the data store with rows
missing cannot be physically rearranged on the disk to fill in the holes
left buy the deleted records?  I find that difficult to believe but what do
I know?

So in the end, I am left with a slightly better understanding of the issue
but not enough to see whether I need one or not.  I suspect not.

Sigh.

John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Michael
Maddison
Sent: Tuesday, June 12, 2007 11:37 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] SQL Server 2005 - long count time

Hi John,

Heres a great explanation I saved from another list....

//starts here//
Just wanted to throw in some bits and pieces to the puzzle.. =;o)
 
First off, there's no absolutes here. Like most other stuff, it depends.
Though many times one or the other may be considered 'best', it's not the
same as 'is always so'. Just wanted to make that clear. 
 
Also, there's sometimes a religious aspect to the debate on indexes. Not so
much as other topics (eg nulls - to be or not to be), but sometimes there is
a hint of it. It doesn't matter, it's just different opinions.
Again, there is no absolute truth that applies to all, only those we
ourselves choose to like. 
 
So..  my point is that some stuff is 'recommended', that is true. But, most
important is that we try to make our own choices, because we know our own
situations best. To be able to choose wisely, we need to have information.
So, it helps to know a bit about how this stuff works, what it does, and
sometimes what it doesn't... 
 
Consider a lone table, with no indexes at all. This is also known as a
'heap'.
Add a nonclustered index (nci), or several nci's. We still have a heap.
A 'heap' is basically (in my mind anyway) something that is unordered.
What a heap cannot do, is to order itself, or 'defrag' or 'compact'
itself, because there is no spoon (..err order)
 
nci's in a heap looks like this - the actual data from the column(s) that is
covered by the nci, and a pointer that points to the datapage where the rest
of the row is stored. This is important to know.
 
If we add a clustered index (ci) the table is no longer a heap. It's is know
ordered by the ci. So there is a physical aspect to the table.
Now, we may defrag, resort, reorg or compact the table - that is one thing
that a ci is the tool for.
 
A ci looks like this - it contains the actual data from the column(s) that
is covered by the ci in it's indexpages - but the leafnode is the entire
row. There is no pointer, because none is needed, you're already 'home'. 
This also makes a 'ci scan' the same as a 'table scan'.
Since the leafnode is also the already existing data, a ci takes about 90%
less space as an index, compared to a nci.
 
Another aspect is that a ci must always be unique. It's not the same as we
can only place one on unique data, we are allowed to place a ci on
non-unique data, but... when we do that, an extra uniqifier is created for
us, so that internally, the data becomes unique. Thus, a ci is always
unique. This is good to know, because if data has to be 'uniquefied', it
requires extra space, and the ci then becomes a little wider than if it was
created on unique data. 

Now, suppose we've done the above, what about the nci's we started out with?

Well, stuff has happened since the ci came into play.
 
nci's *not* in a heap looks like this - the actual data from the
column(s) that is covered by the nci, but the pointer that earlier pointed
to the datapage where the rest of the row was stored, is now replaced by the
*entire ci* - sort of 'key in key'. This is also important to know. 
 
This also tells us that the coice of ci in terms of how wide it is, also
affects all our nci's, since they will each and everyone inherit the ci into
themselves. In the end this transforms to space, and space transforms to
performance. 
 
Anyone confused yet? =;o)
Is any of this relevant, worth remembering or not?
I think it is. It helps us decide what to prioritize when balancing on the
edge of 'index-magics'.
There's no absolute rights or wrongs here, it's all a tradeoff between
'good' and 'bad' aspects of index-types, coverings, behaviours etc.
But, the more we know about the bits, the more educated guesses we can make,
and maybe more importantly, we can also provide our intentions and reasoning
behind those choices.
 
...anyways, that's how I understand it...
 
=;o)
/Kenneth 

//to here//

cheers

Michael M




Michael,

Thanks for the reply.  Let me expand a little here.

This table is the 99 million record data set that I imported the other day.
The data came with some sort of PK field but it was nothing I created and
had no meaning to me.  It still exists.  

After the import, I created a PKID field, integer, autoincrement etc.
Somehow I created a primary key on that new integer field which used a
clustered index.  I did not intend to.  I can in fact, if I so desire (and
can cause it to happen) delete this PKID field entirely and start over.  I
created it, it is not integral to my data in any way, it is just a method of
setting up a unique record identifier (PK) based on an autoincrement
integer.  

One of the problems that dogs me still is that I cannot do particular things
in SQL Server from the "wizards", things like run a view of any complexity.
They simply time out (after about 1 minute or so).  I can copy and paste the
identical SQL from the view into a "new query" in the same database and it
will run just fine, even if the query takes 30 minutes to run.
It will not time out.  I have yet to figure that one out.  The impact of
that issue however is that if I try to do things like delete a field in a
large table (for example), it takes so long that the operation times out,
again after about 1 minute.

So, I try to delete this clustered index - timeout.  Try to delete the PK
symbol from the field - timeout.  Try to create a new index - works fine.

So, I have a new non-clustered index on the PKID field, as well as the
clustered index which I cannot delete.  It seems redundant to have both, and
I certainly do not need a clustered index AFAIK.  I really do not understand
the clustered thing (sad, I know), I have read several explanations and I
just haven't yet wrapped my mind around it.

Anyway, other than the fact that I do not need the clustered index (none of
my other such huge tables have one, all are non-clustered) and it is taking
up space, it seems to not cause me any harm.  I was just looking to get rid
of it because AFAIK I do not need it (and it takes up room, or so I
thought).

John W. Colby
Colby Consulting
www.ColbyConsulting.com



From michael at ddisolutions.com.au  Tue Jun 12 23:18:07 2007
From: michael at ddisolutions.com.au (Michael Maddison)
Date: Wed, 13 Jun 2007 14:18:07 +1000
Subject: [dba-SQLServer] SQL Server 2005 - long count time
References: <20070613040223.AC14FBDF5@smtp-auth.no-ip.com>
Message-ID: <59A61174B1F5B54B97FD4ADDE71E7D012898FE@ddi-01.DDI.local>

It is interesting stuff ;-)

I'd like to see and compare the Execution plans for the two queries you
ran.  I don't know how to get them in 2005 though.

cheers

Michael M

Subject: Re: [dba-SQLServer] SQL Server 2005 - long count time

Interesting but also confusing.  It sounds like a CI is always
preferable but apparently not or there would not be a "religious" aspect
to it.  But the author does not describe any downsides, or at least in
sufficient extent to allow me to discern it as such. 

If a nci is a separate object somewhere, with pointers to the real
object (which describes my understanding if the nci) then is it faster
to scan, looking for matches (because it is not a table scan)?  IOW, my
understanding of a table scan was that each row of data is stored (more
less) together on the disk.  Thus a "table scan" has to wade through 99
million reads of the entire record, whereas a NCI is a separate
structure and thus the data read while "scanning" the index is just the
data (an integer in this case) plus the leaf pointer (probably another
integer) - less data to read off the disk.

In this case, the data in an autonumber integer PK has no meaning, it is
nothing more than a pointer to the data, thus all of the arguments for
using a ci are moot.  Sorting by the autonumber integer PKID is
meaningless.  Even if the data was originally stored in some order (last
name / first name or
something) the integer PKID does not reflect that meaning in any way.

Defrag?  Compact?  Are we saying that without a ci the data store with
rows missing cannot be physically rearranged on the disk to fill in the
holes left buy the deleted records?  I find that difficult to believe
but what do I know?

So in the end, I am left with a slightly better understanding of the
issue but not enough to see whether I need one or not.  I suspect not.

Sigh.

John W. Colby
Colby Consulting
www.ColbyConsulting.com
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Michael
Maddison
Sent: Tuesday, June 12, 2007 11:37 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] SQL Server 2005 - long count time

Hi John,

Heres a great explanation I saved from another list....

//starts here//
Just wanted to throw in some bits and pieces to the puzzle.. =;o)
 
First off, there's no absolutes here. Like most other stuff, it depends.
Though many times one or the other may be considered 'best', it's not
the same as 'is always so'. Just wanted to make that clear. 
 
Also, there's sometimes a religious aspect to the debate on indexes. Not
so much as other topics (eg nulls - to be or not to be), but sometimes
there is a hint of it. It doesn't matter, it's just different opinions.
Again, there is no absolute truth that applies to all, only those we
ourselves choose to like. 
 
So..  my point is that some stuff is 'recommended', that is true. But,
most important is that we try to make our own choices, because we know
our own situations best. To be able to choose wisely, we need to have
information.
So, it helps to know a bit about how this stuff works, what it does, and
sometimes what it doesn't... 
 
Consider a lone table, with no indexes at all. This is also known as a
'heap'.
Add a nonclustered index (nci), or several nci's. We still have a heap.
A 'heap' is basically (in my mind anyway) something that is unordered.
What a heap cannot do, is to order itself, or 'defrag' or 'compact'
itself, because there is no spoon (..err order)
 
nci's in a heap looks like this - the actual data from the column(s)
that is covered by the nci, and a pointer that points to the datapage
where the rest of the row is stored. This is important to know.
 
If we add a clustered index (ci) the table is no longer a heap. It's is
know ordered by the ci. So there is a physical aspect to the table.
Now, we may defrag, resort, reorg or compact the table - that is one
thing that a ci is the tool for.
 
A ci looks like this - it contains the actual data from the column(s)
that is covered by the ci in it's indexpages - but the leafnode is the
entire row. There is no pointer, because none is needed, you're already
'home'. 
This also makes a 'ci scan' the same as a 'table scan'.
Since the leafnode is also the already existing data, a ci takes about
90% less space as an index, compared to a nci.
 
Another aspect is that a ci must always be unique. It's not the same as
we can only place one on unique data, we are allowed to place a ci on
non-unique data, but... when we do that, an extra uniqifier is created
for us, so that internally, the data becomes unique. Thus, a ci is
always unique. This is good to know, because if data has to be
'uniquefied', it requires extra space, and the ci then becomes a little
wider than if it was created on unique data. 

Now, suppose we've done the above, what about the nci's we started out
with?

Well, stuff has happened since the ci came into play.
 
nci's *not* in a heap looks like this - the actual data from the
column(s) that is covered by the nci, but the pointer that earlier
pointed to the datapage where the rest of the row was stored, is now
replaced by the *entire ci* - sort of 'key in key'. This is also
important to know. 
 
This also tells us that the coice of ci in terms of how wide it is, also
affects all our nci's, since they will each and everyone inherit the ci
into themselves. In the end this transforms to space, and space
transforms to performance. 
 
Anyone confused yet? =;o)
Is any of this relevant, worth remembering or not?
I think it is. It helps us decide what to prioritize when balancing on
the edge of 'index-magics'.
There's no absolute rights or wrongs here, it's all a tradeoff between
'good' and 'bad' aspects of index-types, coverings, behaviours etc.
But, the more we know about the bits, the more educated guesses we can
make, and maybe more importantly, we can also provide our intentions and
reasoning behind those choices.
 
...anyways, that's how I understand it...
 
=;o)
/Kenneth 

//to here//

cheers

Michael M




Michael,

Thanks for the reply.  Let me expand a little here.

This table is the 99 million record data set that I imported the other
day.
The data came with some sort of PK field but it was nothing I created
and had no meaning to me.  It still exists.  

After the import, I created a PKID field, integer, autoincrement etc.
Somehow I created a primary key on that new integer field which used a
clustered index.  I did not intend to.  I can in fact, if I so desire
(and can cause it to happen) delete this PKID field entirely and start
over.  I created it, it is not integral to my data in any way, it is
just a method of setting up a unique record identifier (PK) based on an
autoincrement integer.  

One of the problems that dogs me still is that I cannot do particular
things in SQL Server from the "wizards", things like run a view of any
complexity.
They simply time out (after about 1 minute or so).  I can copy and paste
the identical SQL from the view into a "new query" in the same database
and it will run just fine, even if the query takes 30 minutes to run.
It will not time out.  I have yet to figure that one out.  The impact of
that issue however is that if I try to do things like delete a field in
a large table (for example), it takes so long that the operation times
out, again after about 1 minute.

So, I try to delete this clustered index - timeout.  Try to delete the
PK symbol from the field - timeout.  Try to create a new index - works
fine.

So, I have a new non-clustered index on the PKID field, as well as the
clustered index which I cannot delete.  It seems redundant to have both,
and I certainly do not need a clustered index AFAIK.  I really do not
understand the clustered thing (sad, I know), I have read several
explanations and I just haven't yet wrapped my mind around it.

Anyway, other than the fact that I do not need the clustered index (none
of my other such huge tables have one, all are non-clustered) and it is
taking up space, it seems to not cause me any harm.  I was just looking
to get rid of it because AFAIK I do not need it (and it takes up room,
or so I thought).

John W. Colby
Colby Consulting
www.ColbyConsulting.com

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




From michael at ddisolutions.com.au  Wed Jun 13 02:20:39 2007
From: michael at ddisolutions.com.au (Michael Maddison)
Date: Wed, 13 Jun 2007 17:20:39 +1000
Subject: [dba-SQLServer] SQL Server 2005 - long count time
References: <20070613040223.AC14FBDF5@smtp-auth.no-ip.com>
Message-ID: <59A61174B1F5B54B97FD4ADDE71E7D01289900@ddi-01.DDI.local>

Hi John,

Having a slow day so I decided to test your problem.
In my test scenario with 3mill rows the query select count(*) from
[testtable]
was minutes faster on a heap, which I wouldn't have expected...
It seemed to be the only query that was faster though.

There is a quick way to get the rowcount on a CI table though.  Just a
note of caution this method does not give 'guarenteed' results.

    SELECT rowcnt AS [RowCount]
    FROM sysindexes
    WHERE indid IN (1,0)
        AND OBJECTPROPERTY(id, 'IsUserTable') = 1
        AND OBJECT_NAME(id) = 'testtable' 


cheers


Michael M

Interesting but also confusing.  It sounds like a CI is always
preferable but apparently not or there would not be a "religious" aspect
to it.  But the author does not describe any downsides, or at least in
sufficient extent to allow me to discern it as such. 

If a nci is a separate object somewhere, with pointers to the real
object (which describes my understanding if the nci) then is it faster
to scan, looking for matches (because it is not a table scan)?  IOW, my
understanding of a table scan was that each row of data is stored (more
less) together on the disk.  Thus a "table scan" has to wade through 99
million reads of the entire record, whereas a NCI is a separate
structure and thus the data read while "scanning" the index is just the
data (an integer in this case) plus the leaf pointer (probably another
integer) - less data to read off the disk.

In this case, the data in an autonumber integer PK has no meaning, it is
nothing more than a pointer to the data, thus all of the arguments for
using a ci are moot.  Sorting by the autonumber integer PKID is
meaningless.  Even if the data was originally stored in some order (last
name / first name or
something) the integer PKID does not reflect that meaning in any way.

Defrag?  Compact?  Are we saying that without a ci the data store with
rows missing cannot be physically rearranged on the disk to fill in the
holes left buy the deleted records?  I find that difficult to believe
but what do I know?

So in the end, I am left with a slightly better understanding of the
issue but not enough to see whether I need one or not.  I suspect not.

Sigh.

John W. Colby
Colby Consulting
www.ColbyConsulting.com
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Michael
Maddison
Sent: Tuesday, June 12, 2007 11:37 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] SQL Server 2005 - long count time

Hi John,

Heres a great explanation I saved from another list....

//starts here//
Just wanted to throw in some bits and pieces to the puzzle.. =;o)
 
First off, there's no absolutes here. Like most other stuff, it depends.
Though many times one or the other may be considered 'best', it's not
the same as 'is always so'. Just wanted to make that clear. 
 
Also, there's sometimes a religious aspect to the debate on indexes. Not
so much as other topics (eg nulls - to be or not to be), but sometimes
there is a hint of it. It doesn't matter, it's just different opinions.
Again, there is no absolute truth that applies to all, only those we
ourselves choose to like. 
 
So..  my point is that some stuff is 'recommended', that is true. But,
most important is that we try to make our own choices, because we know
our own situations best. To be able to choose wisely, we need to have
information.
So, it helps to know a bit about how this stuff works, what it does, and
sometimes what it doesn't... 
 
Consider a lone table, with no indexes at all. This is also known as a
'heap'.
Add a nonclustered index (nci), or several nci's. We still have a heap.
A 'heap' is basically (in my mind anyway) something that is unordered.
What a heap cannot do, is to order itself, or 'defrag' or 'compact'
itself, because there is no spoon (..err order)
 
nci's in a heap looks like this - the actual data from the column(s)
that is covered by the nci, and a pointer that points to the datapage
where the rest of the row is stored. This is important to know.
 
If we add a clustered index (ci) the table is no longer a heap. It's is
know ordered by the ci. So there is a physical aspect to the table.
Now, we may defrag, resort, reorg or compact the table - that is one
thing that a ci is the tool for.
 
A ci looks like this - it contains the actual data from the column(s)
that is covered by the ci in it's indexpages - but the leafnode is the
entire row. There is no pointer, because none is needed, you're already
'home'. 
This also makes a 'ci scan' the same as a 'table scan'.
Since the leafnode is also the already existing data, a ci takes about
90% less space as an index, compared to a nci.
 
Another aspect is that a ci must always be unique. It's not the same as
we can only place one on unique data, we are allowed to place a ci on
non-unique data, but... when we do that, an extra uniqifier is created
for us, so that internally, the data becomes unique. Thus, a ci is
always unique. This is good to know, because if data has to be
'uniquefied', it requires extra space, and the ci then becomes a little
wider than if it was created on unique data. 

Now, suppose we've done the above, what about the nci's we started out
with?

Well, stuff has happened since the ci came into play.
 
nci's *not* in a heap looks like this - the actual data from the
column(s) that is covered by the nci, but the pointer that earlier
pointed to the datapage where the rest of the row was stored, is now
replaced by the *entire ci* - sort of 'key in key'. This is also
important to know. 
 
This also tells us that the coice of ci in terms of how wide it is, also
affects all our nci's, since they will each and everyone inherit the ci
into themselves. In the end this transforms to space, and space
transforms to performance. 
 
Anyone confused yet? =;o)
Is any of this relevant, worth remembering or not?
I think it is. It helps us decide what to prioritize when balancing on
the edge of 'index-magics'.
There's no absolute rights or wrongs here, it's all a tradeoff between
'good' and 'bad' aspects of index-types, coverings, behaviours etc.
But, the more we know about the bits, the more educated guesses we can
make, and maybe more importantly, we can also provide our intentions and
reasoning behind those choices.
 
...anyways, that's how I understand it...
 
=;o)
/Kenneth 

//to here//

cheers

Michael M




Michael,

Thanks for the reply.  Let me expand a little here.

This table is the 99 million record data set that I imported the other
day.
The data came with some sort of PK field but it was nothing I created
and had no meaning to me.  It still exists.  

After the import, I created a PKID field, integer, autoincrement etc.
Somehow I created a primary key on that new integer field which used a
clustered index.  I did not intend to.  I can in fact, if I so desire
(and can cause it to happen) delete this PKID field entirely and start
over.  I created it, it is not integral to my data in any way, it is
just a method of setting up a unique record identifier (PK) based on an
autoincrement integer.  

One of the problems that dogs me still is that I cannot do particular
things in SQL Server from the "wizards", things like run a view of any
complexity.
They simply time out (after about 1 minute or so).  I can copy and paste
the identical SQL from the view into a "new query" in the same database
and it will run just fine, even if the query takes 30 minutes to run.
It will not time out.  I have yet to figure that one out.  The impact of
that issue however is that if I try to do things like delete a field in
a large table (for example), it takes so long that the operation times
out, again after about 1 minute.

So, I try to delete this clustered index - timeout.  Try to delete the
PK symbol from the field - timeout.  Try to create a new index - works
fine.

So, I have a new non-clustered index on the PKID field, as well as the
clustered index which I cannot delete.  It seems redundant to have both,
and I certainly do not need a clustered index AFAIK.  I really do not
understand the clustered thing (sad, I know), I have read several
explanations and I just haven't yet wrapped my mind around it.

Anyway, other than the fact that I do not need the clustered index (none
of my other such huge tables have one, all are non-clustered) and it is
taking up space, it seems to not cause me any harm.  I was just looking
to get rid of it because AFAIK I do not need it (and it takes up room,
or so I thought).

John W. Colby
Colby Consulting
www.ColbyConsulting.com

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




From jwcolby at colbyconsulting.com  Wed Jun 13 08:05:08 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Wed, 13 Jun 2007 09:05:08 -0400
Subject: [dba-SQLServer] SQL Server 2005 - long count time
In-Reply-To: <59A61174B1F5B54B97FD4ADDE71E7D01289900@ddi-01.DDI.local>
Message-ID: <20070613130509.314ABBE5B@smtp-auth.no-ip.com>

Michael,

>In my test scenario with 3mill rows the query select count(*) from
[testtable] was minutes faster on a heap, which I wouldn't have expected...
>It seemed to be the only query that was faster though.


Now take into account that it was minutes faster on a 3 million row table,
how much faster on a 90 million row table.

This leaves us to wonder if perhaps both would not be beneficial?  The nci
for doing counts (and I do a LOT of them!!!) and a clustered index for
actual joins, leaving it up to SQL Server as to which it uses.  The thing to
understand here is that ATM I have use a system where I have two actual
tables, a 90 million "original data" table and a matching N million "address
validated" table, which contains ONLY the address fields, NOT any additional
demographics fields.  The reason that the address validated table is "N
million" is that I delete non valid addresses from that table in order to
pare down the size.  So the "address validated table" has the same PKID
values as the "original data" table.  

When I process data, I use the original "data table" in where clauses
because that table contains the demographics - age, income, children,
preferences.  The "address validated" table has address information, but it
also has information that the address is valid just in the PK alone.  In
other words, the fact that it is in the valid address table in and of itself
means that the address is valid (because I deleted all non-valid records
from THAT table.

So my client calls me and says "give me a count of all the households
(another subject) in these zips".  I can do that without ever going back to
the original data table.  In other cases he says "give me a count of all the
addresses in these zips where age=x, income is between y and z and has
female children.  That query needs to go back to the original data table for
the demographics information.

So you can see that these PK indexes play an absolutely huge role in my
business, both from the perspective of joins between the two tables as well
as from the perspective of raw counts when demographics are not needed.

Now, I can hear the protestations already:

1) Why not merge the valid address back in to the demographics table.  

Because this is but one of the demographics tables I deal with, there will
be literally dozens of them.  At some point in time the valid address data
from each demographics table has to be merged into a single valid address
table with an even more complex m-m table saying this valid address is
linked to THESE (multiple) demographics tables.

2) OK then why not delete the non-valid addresses from the demographics
table?

This is a "should be done" but in the end it makes only a small (but still
significant) dent in the total number of records in the demographics table,
about 20% maximum (so far).  What I really need to do is go back and remove
ALL address data from the demographics table.  Basically, someone DID merge
all of the address validation data back in to the demographics table (back
before I got ahold of it) and so the demographics table now has probably 40
(out of 700) fields that are old, out of date address validation info.

Even if I do that, I STILL need the PKs in both tables in order to join
demographics with valid address, and I need them to be FAST.  Now that I
understand what the CI indexes do, I will probably go back and add both a CI
and a NCI to each table, on the PKID, in order to allow SQL Server to decide
which is more efficient in any given case and use whichever it needs in each
situation.

John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Michael
Maddison
Sent: Wednesday, June 13, 2007 3:21 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] SQL Server 2005 - long count time

Hi John,

Having a slow day so I decided to test your problem.
In my test scenario with 3mill rows the query select count(*) from
[testtable] was minutes faster on a heap, which I wouldn't have expected...
It seemed to be the only query that was faster though.

There is a quick way to get the rowcount on a CI table though.  Just a note
of caution this method does not give 'guarenteed' results.

    SELECT rowcnt AS [RowCount]
    FROM sysindexes
    WHERE indid IN (1,0)
        AND OBJECTPROPERTY(id, 'IsUserTable') = 1
        AND OBJECT_NAME(id) = 'testtable' 


cheers


Michael M

Interesting but also confusing.  It sounds like a CI is always preferable
but apparently not or there would not be a "religious" aspect to it.  But
the author does not describe any downsides, or at least in sufficient extent
to allow me to discern it as such. 

If a nci is a separate object somewhere, with pointers to the real object
(which describes my understanding if the nci) then is it faster to scan,
looking for matches (because it is not a table scan)?  IOW, my understanding
of a table scan was that each row of data is stored (more
less) together on the disk.  Thus a "table scan" has to wade through 99
million reads of the entire record, whereas a NCI is a separate structure
and thus the data read while "scanning" the index is just the data (an
integer in this case) plus the leaf pointer (probably another
integer) - less data to read off the disk.

In this case, the data in an autonumber integer PK has no meaning, it is
nothing more than a pointer to the data, thus all of the arguments for using
a ci are moot.  Sorting by the autonumber integer PKID is meaningless.  Even
if the data was originally stored in some order (last name / first name or
something) the integer PKID does not reflect that meaning in any way.

Defrag?  Compact?  Are we saying that without a ci the data store with rows
missing cannot be physically rearranged on the disk to fill in the holes
left buy the deleted records?  I find that difficult to believe but what do
I know?

So in the end, I am left with a slightly better understanding of the issue
but not enough to see whether I need one or not.  I suspect not.

Sigh.

John W. Colby
Colby Consulting
www.ColbyConsulting.com



From michael at ddisolutions.com.au  Wed Jun 13 08:55:33 2007
From: michael at ddisolutions.com.au (Michael Maddison)
Date: Wed, 13 Jun 2007 23:55:33 +1000
Subject: [dba-SQLServer] SQL Server 2005 - long count time
References: <20070613130509.314ABBE5B@smtp-auth.no-ip.com>
Message-ID: <59A61174B1F5B54B97FD4ADDE71E7D01289903@ddi-01.DDI.local>

' Now that I understand what the CI indexes do, I will probably go back
and add both a CI and a NCI to each table, on the PKID, in order to
allow SQL Server to decide which is more efficient in any given case and
use whichever it needs in each situation.'

>>>Also as inserts and updates aren't an issue makes sure that both
sides of any join fields have indexes as well.
Also any columns in the where clause.  

cheers

MM

Michael,

>In my test scenario with 3mill rows the query select count(*) from
[testtable] was minutes faster on a heap, which I wouldn't have
expected...
>It seemed to be the only query that was faster though.


Now take into account that it was minutes faster on a 3 million row
table, how much faster on a 90 million row table.

This leaves us to wonder if perhaps both would not be beneficial?  The
nci for doing counts (and I do a LOT of them!!!) and a clustered index
for actual joins, leaving it up to SQL Server as to which it uses.  The
thing to understand here is that ATM I have use a system where I have
two actual tables, a 90 million "original data" table and a matching N
million "address validated" table, which contains ONLY the address
fields, NOT any additional demographics fields.  The reason that the
address validated table is "N million" is that I delete non valid
addresses from that table in order to pare down the size.  So the
"address validated table" has the same PKID values as the "original
data" table.  

When I process data, I use the original "data table" in where clauses
because that table contains the demographics - age, income, children,
preferences.  The "address validated" table has address information, but
it also has information that the address is valid just in the PK alone.
In other words, the fact that it is in the valid address table in and of
itself means that the address is valid (because I deleted all non-valid
records from THAT table.

So my client calls me and says "give me a count of all the households
(another subject) in these zips".  I can do that without ever going back
to the original data table.  In other cases he says "give me a count of
all the addresses in these zips where age=x, income is between y and z
and has female children.  That query needs to go back to the original
data table for the demographics information.

So you can see that these PK indexes play an absolutely huge role in my
business, both from the perspective of joins between the two tables as
well as from the perspective of raw counts when demographics are not
needed.

Now, I can hear the protestations already:

1) Why not merge the valid address back in to the demographics table.  

Because this is but one of the demographics tables I deal with, there
will be literally dozens of them.  At some point in time the valid
address data from each demographics table has to be merged into a single
valid address table with an even more complex m-m table saying this
valid address is linked to THESE (multiple) demographics tables.

2) OK then why not delete the non-valid addresses from the demographics
table?

This is a "should be done" but in the end it makes only a small (but
still
significant) dent in the total number of records in the demographics
table, about 20% maximum (so far).  What I really need to do is go back
and remove ALL address data from the demographics table.  Basically,
someone DID merge all of the address validation data back in to the
demographics table (back before I got ahold of it) and so the
demographics table now has probably 40 (out of 700) fields that are old,
out of date address validation info.

Even if I do that, I STILL need the PKs in both tables in order to join
demographics with valid address, and I need them to be FAST.  Now that I
understand what the CI indexes do, I will probably go back and add both
a CI and a NCI to each table, on the PKID, in order to allow SQL Server
to decide which is more efficient in any given case and use whichever it
needs in each situation.

John W. Colby
Colby Consulting
www.ColbyConsulting.com
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Michael
Maddison
Sent: Wednesday, June 13, 2007 3:21 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] SQL Server 2005 - long count time

Hi John,

Having a slow day so I decided to test your problem.
In my test scenario with 3mill rows the query select count(*) from
[testtable] was minutes faster on a heap, which I wouldn't have
expected...
It seemed to be the only query that was faster though.

There is a quick way to get the rowcount on a CI table though.  Just a
note of caution this method does not give 'guarenteed' results.

    SELECT rowcnt AS [RowCount]
    FROM sysindexes
    WHERE indid IN (1,0)
        AND OBJECTPROPERTY(id, 'IsUserTable') = 1
        AND OBJECT_NAME(id) = 'testtable' 


cheers


Michael M

Interesting but also confusing.  It sounds like a CI is always
preferable but apparently not or there would not be a "religious" aspect
to it.  But the author does not describe any downsides, or at least in
sufficient extent to allow me to discern it as such. 

If a nci is a separate object somewhere, with pointers to the real
object (which describes my understanding if the nci) then is it faster
to scan, looking for matches (because it is not a table scan)?  IOW, my
understanding of a table scan was that each row of data is stored (more
less) together on the disk.  Thus a "table scan" has to wade through 99
million reads of the entire record, whereas a NCI is a separate
structure and thus the data read while "scanning" the index is just the
data (an integer in this case) plus the leaf pointer (probably another
integer) - less data to read off the disk.

In this case, the data in an autonumber integer PK has no meaning, it is
nothing more than a pointer to the data, thus all of the arguments for
using a ci are moot.  Sorting by the autonumber integer PKID is
meaningless.  Even if the data was originally stored in some order (last
name / first name or
something) the integer PKID does not reflect that meaning in any way.

Defrag?  Compact?  Are we saying that without a ci the data store with
rows missing cannot be physically rearranged on the disk to fill in the
holes left buy the deleted records?  I find that difficult to believe
but what do I know?

So in the end, I am left with a slightly better understanding of the
issue but not enough to see whether I need one or not.  I suspect not.

Sigh.

John W. Colby
Colby Consulting
www.ColbyConsulting.com

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




From jwcolby at colbyconsulting.com  Wed Jun 13 09:09:53 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Wed, 13 Jun 2007 10:09:53 -0400
Subject: [dba-SQLServer] SQL Server 2005 - long count time
In-Reply-To: <59A61174B1F5B54B97FD4ADDE71E7D01289903@ddi-01.DDI.local>
Message-ID: <20070613140954.0D7F1BDD5@smtp-auth.no-ip.com>

 
Michael,

The indexes on the where clauses are the biggie.  There are about 650
demographics fields (on one of these tables, 65 million demographics
records).  Putting an index on each field is time consuming to say the
least.  Not to mention space consuming.  I am doing that as the client comes
in with orders needing the where clause on a given field.

This whole thing needs to be normalized such that I have a "fact table"
which is a field with the demographics data, a field with the fact name
(name of the original field in the demographics table) plus a field back to
the person/address that "owns" that fact.  Then I could merge all of the
demographics "facts" from every demographics table I get from the client
into a single fact table, and all of the addresses into a person / address
table (system).

I suspect that I will do that down the road a bit (as I get more comfortable
in SQL Server) but I have to make the data usable in the meantime.

John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Michael
Maddison
Sent: Wednesday, June 13, 2007 9:56 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] SQL Server 2005 - long count time

' Now that I understand what the CI indexes do, I will probably go back and
add both a CI and a NCI to each table, on the PKID, in order to allow SQL
Server to decide which is more efficient in any given case and use whichever
it needs in each situation.'

>>>Also as inserts and updates aren't an issue makes sure that both
sides of any join fields have indexes as well.
Also any columns in the where clause.  

cheers

MM

Michael,

>In my test scenario with 3mill rows the query select count(*) from
[testtable] was minutes faster on a heap, which I wouldn't have expected...
>It seemed to be the only query that was faster though.


Now take into account that it was minutes faster on a 3 million row table,
how much faster on a 90 million row table.

This leaves us to wonder if perhaps both would not be beneficial?  The nci
for doing counts (and I do a LOT of them!!!) and a clustered index for
actual joins, leaving it up to SQL Server as to which it uses.  The thing to
understand here is that ATM I have use a system where I have two actual
tables, a 90 million "original data" table and a matching N million "address
validated" table, which contains ONLY the address fields, NOT any additional
demographics fields.  The reason that the address validated table is "N
million" is that I delete non valid addresses from that table in order to
pare down the size.  So the "address validated table" has the same PKID
values as the "original data" table.  

When I process data, I use the original "data table" in where clauses
because that table contains the demographics - age, income, children,
preferences.  The "address validated" table has address information, but it
also has information that the address is valid just in the PK alone.
In other words, the fact that it is in the valid address table in and of
itself means that the address is valid (because I deleted all non-valid
records from THAT table.

So my client calls me and says "give me a count of all the households
(another subject) in these zips".  I can do that without ever going back to
the original data table.  In other cases he says "give me a count of all the
addresses in these zips where age=x, income is between y and z and has
female children.  That query needs to go back to the original data table for
the demographics information.

So you can see that these PK indexes play an absolutely huge role in my
business, both from the perspective of joins between the two tables as well
as from the perspective of raw counts when demographics are not needed.

Now, I can hear the protestations already:

1) Why not merge the valid address back in to the demographics table.  

Because this is but one of the demographics tables I deal with, there will
be literally dozens of them.  At some point in time the valid address data
from each demographics table has to be merged into a single valid address
table with an even more complex m-m table saying this valid address is
linked to THESE (multiple) demographics tables.

2) OK then why not delete the non-valid addresses from the demographics
table?

This is a "should be done" but in the end it makes only a small (but still
significant) dent in the total number of records in the demographics table,
about 20% maximum (so far).  What I really need to do is go back and remove
ALL address data from the demographics table.  Basically, someone DID merge
all of the address validation data back in to the demographics table (back
before I got ahold of it) and so the demographics table now has probably 40
(out of 700) fields that are old, out of date address validation info.

Even if I do that, I STILL need the PKs in both tables in order to join
demographics with valid address, and I need them to be FAST.  Now that I
understand what the CI indexes do, I will probably go back and add both a CI
and a NCI to each table, on the PKID, in order to allow SQL Server to decide
which is more efficient in any given case and use whichever it needs in each
situation.

John W. Colby
Colby Consulting
www.ColbyConsulting.com



From fuller.artful at gmail.com  Wed Jun 13 09:35:28 2007
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Wed, 13 Jun 2007 10:35:28 -0400
Subject: [dba-SQLServer] SQL Server 2005 - long count time
In-Reply-To: <20070613140954.0D7F1BDD5@smtp-auth.no-ip.com>
References: <59A61174B1F5B54B97FD4ADDE71E7D01289903@ddi-01.DDI.local>
	<20070613140954.0D7F1BDD5@smtp-auth.no-ip.com>
Message-ID: <29f585dd0706130735j5a8215e3n16a68c1ca7ff0f23@mail.gmail.com>

I think that I recommended that strategy a while back. Each of those
hundreds of columns ought to be a row (use a SQL Variant column definition
or alternatively have a child table that contains a column of every data
type, but that approach is cumbersome).

Using this approach, only the not-null (or not empty) columns would become
rows. Yes, this table would contain many millions of rows, but you would
achieve search speeds an order of magnitude (or more) better than what you
are currently achieving.

This approach also requires a third table consisting in essence of the
column-names in your current table. So that rather than 500 columns, you
have 500 rows in said lookup table, and if and only if the current
person/household has a value in column 134 do you add a row to the bridge
table PersonAttributes.

Why is this a huge gain? Because the lookup table and the bridge table can
be indexed. For example, let's suppose that we are looking for divorced
females who own a flat-screen TV (and who isn't? but I'll let that slide).
These values constitute 3 rows in the aforementioned Attributes table, with
PKs that can be found quickly. So ultimately a search such as this becomes
something like "SELECT * FROM People INNER JOIN Attributes WHERE
People.PersonID = Attributes.PersonID and AttributeID IN( 123, 234, 345).

Obviously there is a more optimal way to write that Select statement but I
am on a keystroke diet LOL.

A.

On 6/13/07, jwcolby <jwcolby at colbyconsulting.com> wrote:
>
>
> Michael,
>
> The indexes on the where clauses are the biggie.  There are about 650
> demographics fields (on one of these tables, 65 million demographics
> records).  Putting an index on each field is time consuming to say the
> least.  Not to mention space consuming.  I am doing that as the client
> comes
> in with orders needing the where clause on a given field.
>
> This whole thing needs to be normalized such that I have a "fact table"
> which is a field with the demographics data, a field with the fact name
> (name of the original field in the demographics table) plus a field back
> to
> the person/address that "owns" that fact.  Then I could merge all of the
> demographics "facts" from every demographics table I get from the client
> into a single fact table, and all of the addresses into a person / address
> table (system).
>
> I suspect that I will do that down the road a bit (as I get more
> comfortable
> in SQL Server) but I have to make the data usable in the meantime.
>
> John W. Colby
> Colby Consulting
> www.ColbyConsulting.com
> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Michael
> Maddison
> Sent: Wednesday, June 13, 2007 9:56 AM
> To: dba-sqlserver at databaseadvisors.com
> Subject: Re: [dba-SQLServer] SQL Server 2005 - long count time
>
> ' Now that I understand what the CI indexes do, I will probably go back
> and
> add both a CI and a NCI to each table, on the PKID, in order to allow SQL
> Server to decide which is more efficient in any given case and use
> whichever
> it needs in each situation.'
>
> >>>Also as inserts and updates aren't an issue makes sure that both
> sides of any join fields have indexes as well.
> Also any columns in the where clause.
>
> cheers
>
> MM
>
> Michael,
>
> >In my test scenario with 3mill rows the query select count(*) from
> [testtable] was minutes faster on a heap, which I wouldn't have
> expected...
> >It seemed to be the only query that was faster though.
>
>
> Now take into account that it was minutes faster on a 3 million row table,
> how much faster on a 90 million row table.
>
> This leaves us to wonder if perhaps both would not be beneficial?  The nci
> for doing counts (and I do a LOT of them!!!) and a clustered index for
> actual joins, leaving it up to SQL Server as to which it uses.  The thing
> to
> understand here is that ATM I have use a system where I have two actual
> tables, a 90 million "original data" table and a matching N million
> "address
> validated" table, which contains ONLY the address fields, NOT any
> additional
> demographics fields.  The reason that the address validated table is "N
> million" is that I delete non valid addresses from that table in order to
> pare down the size.  So the "address validated table" has the same PKID
> values as the "original data" table.
>
> When I process data, I use the original "data table" in where clauses
> because that table contains the demographics - age, income, children,
> preferences.  The "address validated" table has address information, but
> it
> also has information that the address is valid just in the PK alone.
> In other words, the fact that it is in the valid address table in and of
> itself means that the address is valid (because I deleted all non-valid
> records from THAT table.
>
> So my client calls me and says "give me a count of all the households
> (another subject) in these zips".  I can do that without ever going back
> to
> the original data table.  In other cases he says "give me a count of all
> the
> addresses in these zips where age=x, income is between y and z and has
> female children.  That query needs to go back to the original data table
> for
> the demographics information.
>
> So you can see that these PK indexes play an absolutely huge role in my
> business, both from the perspective of joins between the two tables as
> well
> as from the perspective of raw counts when demographics are not needed.
>
> Now, I can hear the protestations already:
>
> 1) Why not merge the valid address back in to the demographics table.
>
> Because this is but one of the demographics tables I deal with, there will
> be literally dozens of them.  At some point in time the valid address data
> from each demographics table has to be merged into a single valid address
> table with an even more complex m-m table saying this valid address is
> linked to THESE (multiple) demographics tables.
>
> 2) OK then why not delete the non-valid addresses from the demographics
> table?
>
> This is a "should be done" but in the end it makes only a small (but still
> significant) dent in the total number of records in the demographics
> table,
> about 20% maximum (so far).  What I really need to do is go back and
> remove
> ALL address data from the demographics table.  Basically, someone DID
> merge
> all of the address validation data back in to the demographics table (back
> before I got ahold of it) and so the demographics table now has probably
> 40
> (out of 700) fields that are old, out of date address validation info.
>
> Even if I do that, I STILL need the PKs in both tables in order to join
> demographics with valid address, and I need them to be FAST.  Now that I
> understand what the CI indexes do, I will probably go back and add both a
> CI
> and a NCI to each table, on the PKID, in order to allow SQL Server to
> decide
> which is more efficient in any given case and use whichever it needs in
> each
> situation.
>
> John W. Colby
> Colby Consulting
> www.ColbyConsulting.com
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>


From jwcolby at colbyconsulting.com  Wed Jun 13 10:21:04 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Wed, 13 Jun 2007 11:21:04 -0400
Subject: [dba-SQLServer] SQL Server 2005 - long count time
In-Reply-To: <29f585dd0706130735j5a8215e3n16a68c1ca7ff0f23@mail.gmail.com>
Message-ID: <20070613152105.03DA7BBF1@smtp-auth.no-ip.com>

Arthur,

Yes you did recommend that strategy.  And of course it is just the
implementation that is holding me back.

And of course it is not just hundreds of millions rows in the fact table.  

tblHSID - 50 million records * 700 fields = 35 BILLION records
tblInfutor - 90 million records * 120 fields = 10.8 BILLION records
tblAmericanTrust - 70 million records * 50 fields = 3.5 BILLION fields
Etc
Etc
Etc

Thus we are already up to close to 50 billion records in the fact table,
with only three lists processed.  Something tells me that doing searches and
joins on 50 billion records is never going to be fast on the hardware I can
afford. 

This ain't exactly your grandma's recipe database.

John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Arthur
Fuller
Sent: Wednesday, June 13, 2007 10:35 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] SQL Server 2005 - long count time

I think that I recommended that strategy a while back. Each of those
hundreds of columns ought to be a row (use a SQL Variant column definition
or alternatively have a child table that contains a column of every data
type, but that approach is cumbersome).

Using this approach, only the not-null (or not empty) columns would become
rows. Yes, this table would contain many millions of rows, but you would
achieve search speeds an order of magnitude (or more) better than what you
are currently achieving.

This approach also requires a third table consisting in essence of the
column-names in your current table. So that rather than 500 columns, you
have 500 rows in said lookup table, and if and only if the current
person/household has a value in column 134 do you add a row to the bridge
table PersonAttributes.

Why is this a huge gain? Because the lookup table and the bridge table can
be indexed. For example, let's suppose that we are looking for divorced
females who own a flat-screen TV (and who isn't? but I'll let that slide).
These values constitute 3 rows in the aforementioned Attributes table, with
PKs that can be found quickly. So ultimately a search such as this becomes
something like "SELECT * FROM People INNER JOIN Attributes WHERE
People.PersonID = Attributes.PersonID and AttributeID IN( 123, 234, 345).

Obviously there is a more optimal way to write that Select statement but I
am on a keystroke diet LOL.

A.

On 6/13/07, jwcolby <jwcolby at colbyconsulting.com> wrote:
>
>
> Michael,
>
> The indexes on the where clauses are the biggie.  There are about 650 
> demographics fields (on one of these tables, 65 million demographics 
> records).  Putting an index on each field is time consuming to say the 
> least.  Not to mention space consuming.  I am doing that as the client 
> comes in with orders needing the where clause on a given field.
>
> This whole thing needs to be normalized such that I have a "fact table"
> which is a field with the demographics data, a field with the fact 
> name (name of the original field in the demographics table) plus a 
> field back to the person/address that "owns" that fact.  Then I could 
> merge all of the demographics "facts" from every demographics table I 
> get from the client into a single fact table, and all of the addresses 
> into a person / address table (system).
>
> I suspect that I will do that down the road a bit (as I get more 
> comfortable in SQL Server) but I have to make the data usable in the 
> meantime.
>
> John W. Colby
> Colby Consulting
> www.ColbyConsulting.com
> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of 
> Michael Maddison
> Sent: Wednesday, June 13, 2007 9:56 AM
> To: dba-sqlserver at databaseadvisors.com
> Subject: Re: [dba-SQLServer] SQL Server 2005 - long count time
>
> ' Now that I understand what the CI indexes do, I will probably go 
> back and add both a CI and a NCI to each table, on the PKID, in order 
> to allow SQL Server to decide which is more efficient in any given 
> case and use whichever it needs in each situation.'
>
> >>>Also as inserts and updates aren't an issue makes sure that both
> sides of any join fields have indexes as well.
> Also any columns in the where clause.
>
> cheers
>
> MM
>
> Michael,
>
> >In my test scenario with 3mill rows the query select count(*) from
> [testtable] was minutes faster on a heap, which I wouldn't have 
> expected...
> >It seemed to be the only query that was faster though.
>
>
> Now take into account that it was minutes faster on a 3 million row 
> table, how much faster on a 90 million row table.
>
> This leaves us to wonder if perhaps both would not be beneficial?  The 
> nci for doing counts (and I do a LOT of them!!!) and a clustered index 
> for actual joins, leaving it up to SQL Server as to which it uses.  
> The thing to understand here is that ATM I have use a system where I 
> have two actual tables, a 90 million "original data" table and a 
> matching N million "address validated" table, which contains ONLY the 
> address fields, NOT any additional demographics fields.  The reason 
> that the address validated table is "N million" is that I delete non 
> valid addresses from that table in order to pare down the size.  So 
> the "address validated table" has the same PKID values as the 
> "original data" table.
>
> When I process data, I use the original "data table" in where clauses 
> because that table contains the demographics - age, income, children, 
> preferences.  The "address validated" table has address information, 
> but it also has information that the address is valid just in the PK 
> alone.
> In other words, the fact that it is in the valid address table in and 
> of itself means that the address is valid (because I deleted all 
> non-valid records from THAT table.
>
> So my client calls me and says "give me a count of all the households 
> (another subject) in these zips".  I can do that without ever going 
> back to the original data table.  In other cases he says "give me a 
> count of all the addresses in these zips where age=x, income is 
> between y and z and has female children.  That query needs to go back 
> to the original data table for the demographics information.
>
> So you can see that these PK indexes play an absolutely huge role in 
> my business, both from the perspective of joins between the two tables 
> as well as from the perspective of raw counts when demographics are 
> not needed.
>
> Now, I can hear the protestations already:
>
> 1) Why not merge the valid address back in to the demographics table.
>
> Because this is but one of the demographics tables I deal with, there 
> will be literally dozens of them.  At some point in time the valid 
> address data from each demographics table has to be merged into a 
> single valid address table with an even more complex m-m table saying 
> this valid address is linked to THESE (multiple) demographics tables.
>
> 2) OK then why not delete the non-valid addresses from the 
> demographics table?
>
> This is a "should be done" but in the end it makes only a small (but 
> still
> significant) dent in the total number of records in the demographics 
> table, about 20% maximum (so far).  What I really need to do is go 
> back and remove ALL address data from the demographics table.  
> Basically, someone DID merge all of the address validation data back 
> in to the demographics table (back before I got ahold of it) and so 
> the demographics table now has probably 40 (out of 700) fields that 
> are old, out of date address validation info.
>
> Even if I do that, I STILL need the PKs in both tables in order to 
> join demographics with valid address, and I need them to be FAST.  Now 
> that I understand what the CI indexes do, I will probably go back and 
> add both a CI and a NCI to each table, on the PKID, in order to allow 
> SQL Server to decide which is more efficient in any given case and use 
> whichever it needs in each situation.
>
> John W. Colby
> Colby Consulting
> www.ColbyConsulting.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 Elizabeth.J.Doering at wellsfargo.com  Wed Jun 13 10:57:11 2007
From: Elizabeth.J.Doering at wellsfargo.com (Elizabeth.J.Doering at wellsfargo.com)
Date: Wed, 13 Jun 2007 10:57:11 -0500
Subject: [dba-SQLServer] Scheduling DTSX packages in SQL Server 2005
References: <20070612175620.5FA00BD45@smtp-auth.no-ip.com>
Message-ID: <1C2084FD2472124AB1812A5476EA3B7A017DDB6E@msgswbmnmsp04.wellsfargo.com>

Enough Googling finally produced an answer:  I had to create myself as a
proxy with sufficient rights to run SSIS packages.  More info here:
http://www.codeproject.com/useritems/Schedule__Run__SSIS__DTS.asp

If anyone sees pitfalls here, please point them out.

Now I'll go see if this temporary dye will scrub out!

Thanks,

Liz

 


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Tuesday, June 12, 2007 12:56 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Scheduling DTSX packages in SQL Server 2005

>Now John you know that only works on the third friday in december when 
>the
moon is in the east and you dye your hair red!

True, but at least you have a once yearly shot at it working.  And you
can always dye your hair back.


John W. Colby
Colby Consulting
www.ColbyConsulting.com
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Martin
Reid
Sent: Tuesday, June 12, 2007 1:45 PM
To: dba-sqlserver at databaseadvisors.com
Subject: [dba-SQLServer] Scheduling DTSX packages in SQL Server 2005

Now John you know that only works on the third friday in december when
the moon is in the east and you dye your hair red!
 
Martin
 
Sorry could not resist
 
Martin WP Reid
Training and Assessment Unit
Riddle Hall
Belfast
 
tel: 02890 974465
 

________________________________

From: dba-sqlserver-bounces at databaseadvisors.com on behalf of jwcolby
Sent: Tue 12/06/2007 16:47
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Scheduling DTSX packages in SQL Server 2005



Did you hop up and down ON ONE FOOT?  Try alternating feet?  Try
kneeling facing east and kissing the floor three times while chanting
"aaaaoooooommmmmmm...... Thisiswhatidoforaliving....
Aaaoooooommmmmm......thisiswhatidoforaliving.....aaaaooooommmmm......

;-)

John W. Colby
Colby Consulting
www.ColbyConsulting.com
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of
Elizabeth.J.Doering at wellsfargo.com
Sent: Tuesday, June 12, 2007 11:33 AM
To: dba-sqlserver at databaseadvisors.com
Subject: [dba-SQLServer] Scheduling DTSX packages in SQL Server 2005

Dear 


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





From fahooper at trapo.com  Wed Jun 13 11:04:12 2007
From: fahooper at trapo.com (Fred Hooper)
Date: Wed, 13 Jun 2007 12:04:12 -0400
Subject: [dba-SQLServer] SQL Server 2005 - long count time
In-Reply-To: <20070613152105.03DA7BBF1@smtp-auth.no-ip.com>
Message-ID: <003601c7add4$7c187c80$65cee044@fredxp>

John,

How about using olap? This would do a lot of preprocessing to make it quick
and easy to find counts and sums. My understanding is that SQL Server 2005
has very good olap options. (My experience is limited to Cognos, but a 300
million record cube of web site hit data took 20 minutes to process 12-20
dimensions and about 6 measures. The resulting cube gave instant answers.)

If you did that, MDX (similar to SQL) would allow you to write queries
against the olap cube. Because of the pre-processing of the olap cube, MDX
query response should be instant. 

I originally got into this sort of stuff when the cross tabs I was running
with Access as a front end to SQL Server 2000 were taking too long. The
company I was working for wanted to use Cognos (2000's olap was fairly
rudimentary before the development of MDX) so that's the direction I took,
but I've heard lots of good things about 2005's olap.

Fred

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Wednesday, June 13, 2007 11:21 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] SQL Server 2005 - long count time

Arthur,

Yes you did recommend that strategy.  And of course it is just the
implementation that is holding me back.

And of course it is not just hundreds of millions rows in the fact table.  

tblHSID - 50 million records * 700 fields = 35 BILLION records
tblInfutor - 90 million records * 120 fields = 10.8 BILLION records
tblAmericanTrust - 70 million records * 50 fields = 3.5 BILLION fields
Etc
Etc
Etc

Thus we are already up to close to 50 billion records in the fact table,
with only three lists processed.  Something tells me that doing searches and
joins on 50 billion records is never going to be fast on the hardware I can
afford. 

This ain't exactly your grandma's recipe database.

John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Arthur
Fuller
Sent: Wednesday, June 13, 2007 10:35 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] SQL Server 2005 - long count time

I think that I recommended that strategy a while back. Each of those
hundreds of columns ought to be a row (use a SQL Variant column definition
or alternatively have a child table that contains a column of every data
type, but that approach is cumbersome).

Using this approach, only the not-null (or not empty) columns would become
rows. Yes, this table would contain many millions of rows, but you would
achieve search speeds an order of magnitude (or more) better than what you
are currently achieving.

This approach also requires a third table consisting in essence of the
column-names in your current table. So that rather than 500 columns, you
have 500 rows in said lookup table, and if and only if the current
person/household has a value in column 134 do you add a row to the bridge
table PersonAttributes.

Why is this a huge gain? Because the lookup table and the bridge table can
be indexed. For example, let's suppose that we are looking for divorced
females who own a flat-screen TV (and who isn't? but I'll let that slide).
These values constitute 3 rows in the aforementioned Attributes table, with
PKs that can be found quickly. So ultimately a search such as this becomes
something like "SELECT * FROM People INNER JOIN Attributes WHERE
People.PersonID = Attributes.PersonID and AttributeID IN( 123, 234, 345).

Obviously there is a more optimal way to write that Select statement but I
am on a keystroke diet LOL.

A.

On 6/13/07, jwcolby <jwcolby at colbyconsulting.com> wrote:
>
>
> Michael,
>
> The indexes on the where clauses are the biggie.  There are about 650 
> demographics fields (on one of these tables, 65 million demographics 
> records).  Putting an index on each field is time consuming to say the 
> least.  Not to mention space consuming.  I am doing that as the client 
> comes in with orders needing the where clause on a given field.
>
> This whole thing needs to be normalized such that I have a "fact table"
> which is a field with the demographics data, a field with the fact 
> name (name of the original field in the demographics table) plus a 
> field back to the person/address that "owns" that fact.  Then I could 
> merge all of the demographics "facts" from every demographics table I 
> get from the client into a single fact table, and all of the addresses 
> into a person / address table (system).
>
> I suspect that I will do that down the road a bit (as I get more 
> comfortable in SQL Server) but I have to make the data usable in the 
> meantime.
>
> John W. Colby
> Colby Consulting
> www.ColbyConsulting.com
> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of 
> Michael Maddison
> Sent: Wednesday, June 13, 2007 9:56 AM
> To: dba-sqlserver at databaseadvisors.com
> Subject: Re: [dba-SQLServer] SQL Server 2005 - long count time
>
> ' Now that I understand what the CI indexes do, I will probably go 
> back and add both a CI and a NCI to each table, on the PKID, in order 
> to allow SQL Server to decide which is more efficient in any given 
> case and use whichever it needs in each situation.'
>
> >>>Also as inserts and updates aren't an issue makes sure that both
> sides of any join fields have indexes as well.
> Also any columns in the where clause.
>
> cheers
>
> MM
>
> Michael,
>
> >In my test scenario with 3mill rows the query select count(*) from
> [testtable] was minutes faster on a heap, which I wouldn't have 
> expected...
> >It seemed to be the only query that was faster though.
>
>
> Now take into account that it was minutes faster on a 3 million row 
> table, how much faster on a 90 million row table.
>
> This leaves us to wonder if perhaps both would not be beneficial?  The 
> nci for doing counts (and I do a LOT of them!!!) and a clustered index 
> for actual joins, leaving it up to SQL Server as to which it uses.  
> The thing to understand here is that ATM I have use a system where I 
> have two actual tables, a 90 million "original data" table and a 
> matching N million "address validated" table, which contains ONLY the 
> address fields, NOT any additional demographics fields.  The reason 
> that the address validated table is "N million" is that I delete non 
> valid addresses from that table in order to pare down the size.  So 
> the "address validated table" has the same PKID values as the 
> "original data" table.
>
> When I process data, I use the original "data table" in where clauses 
> because that table contains the demographics - age, income, children, 
> preferences.  The "address validated" table has address information, 
> but it also has information that the address is valid just in the PK 
> alone.
> In other words, the fact that it is in the valid address table in and 
> of itself means that the address is valid (because I deleted all 
> non-valid records from THAT table.
>
> So my client calls me and says "give me a count of all the households 
> (another subject) in these zips".  I can do that without ever going 
> back to the original data table.  In other cases he says "give me a 
> count of all the addresses in these zips where age=x, income is 
> between y and z and has female children.  That query needs to go back 
> to the original data table for the demographics information.
>
> So you can see that these PK indexes play an absolutely huge role in 
> my business, both from the perspective of joins between the two tables 
> as well as from the perspective of raw counts when demographics are 
> not needed.
>
> Now, I can hear the protestations already:
>
> 1) Why not merge the valid address back in to the demographics table.
>
> Because this is but one of the demographics tables I deal with, there 
> will be literally dozens of them.  At some point in time the valid 
> address data from each demographics table has to be merged into a 
> single valid address table with an even more complex m-m table saying 
> this valid address is linked to THESE (multiple) demographics tables.
>
> 2) OK then why not delete the non-valid addresses from the 
> demographics table?
>
> This is a "should be done" but in the end it makes only a small (but 
> still
> significant) dent in the total number of records in the demographics 
> table, about 20% maximum (so far).  What I really need to do is go 
> back and remove ALL address data from the demographics table.  
> Basically, someone DID merge all of the address validation data back 
> in to the demographics table (back before I got ahold of it) and so 
> the demographics table now has probably 40 (out of 700) fields that 
> are old, out of date address validation info.
>
> Even if I do that, I STILL need the PKs in both tables in order to 
> join demographics with valid address, and I need them to be FAST.  Now 
> that I understand what the CI indexes do, I will probably go back and 
> add both a CI and a NCI to each table, on the PKID, in order to allow 
> SQL Server to decide which is more efficient in any given case and use 
> whichever it needs in each situation.
>
> John W. Colby
> Colby Consulting
> www.ColbyConsulting.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 jlawrenc1 at shaw.ca  Wed Jun 13 17:58:35 2007
From: jlawrenc1 at shaw.ca (Jim Lawrence)
Date: Wed, 13 Jun 2007 15:58:35 -0700
Subject: [dba-SQLServer] Everything you wanted to know about RAID
In-Reply-To: <003601c7add4$7c187c80$65cee044@fredxp>
Message-ID: <0JJL00IKRJLAJQI1@l-daemon>

A simple representation explaining RAID:

http://reference.creativesystemdesigns.com/downloads/raid.jpg

Jim 



From michael at ddisolutions.com.au  Wed Jun 13 18:08:27 2007
From: michael at ddisolutions.com.au (Michael Maddison)
Date: Thu, 14 Jun 2007 09:08:27 +1000
Subject: [dba-SQLServer] SQL Server 2005 - long count time
References: <003601c7add4$7c187c80$65cee044@fredxp>
Message-ID: <59A61174B1F5B54B97FD4ADDE71E7D01289904@ddi-01.DDI.local>

OLAP may be an option but I think John will still run into issues with
100's of dimensions.
Actually with the changes Arthur recommended then it should work a
treat... in theory...

cheers

Michael M

John,

How about using olap? This would do a lot of preprocessing to make it
quick and easy to find counts and sums. My understanding is that SQL
Server 2005 has very good olap options. (My experience is limited to
Cognos, but a 300 million record cube of web site hit data took 20
minutes to process 12-20 dimensions and about 6 measures. The resulting
cube gave instant answers.)

If you did that, MDX (similar to SQL) would allow you to write queries
against the olap cube. Because of the pre-processing of the olap cube,
MDX query response should be instant. 

I originally got into this sort of stuff when the cross tabs I was
running with Access as a front end to SQL Server 2000 were taking too
long. The company I was working for wanted to use Cognos (2000's olap
was fairly rudimentary before the development of MDX) so that's the
direction I took, but I've heard lots of good things about 2005's olap.

Fred

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Wednesday, June 13, 2007 11:21 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] SQL Server 2005 - long count time

Arthur,

Yes you did recommend that strategy.  And of course it is just the
implementation that is holding me back.

And of course it is not just hundreds of millions rows in the fact
table.  

tblHSID - 50 million records * 700 fields = 35 BILLION records
tblInfutor - 90 million records * 120 fields = 10.8 BILLION records
tblAmericanTrust - 70 million records * 50 fields = 3.5 BILLION fields
Etc Etc Etc

Thus we are already up to close to 50 billion records in the fact table,
with only three lists processed.  Something tells me that doing searches
and joins on 50 billion records is never going to be fast on the
hardware I can afford. 

This ain't exactly your grandma's recipe database.

John W. Colby
Colby Consulting
www.ColbyConsulting.com
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Arthur
Fuller
Sent: Wednesday, June 13, 2007 10:35 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] SQL Server 2005 - long count time

I think that I recommended that strategy a while back. Each of those
hundreds of columns ought to be a row (use a SQL Variant column
definition or alternatively have a child table that contains a column of
every data type, but that approach is cumbersome).

Using this approach, only the not-null (or not empty) columns would
become rows. Yes, this table would contain many millions of rows, but
you would achieve search speeds an order of magnitude (or more) better
than what you are currently achieving.

This approach also requires a third table consisting in essence of the
column-names in your current table. So that rather than 500 columns, you
have 500 rows in said lookup table, and if and only if the current
person/household has a value in column 134 do you add a row to the
bridge table PersonAttributes.

Why is this a huge gain? Because the lookup table and the bridge table
can be indexed. For example, let's suppose that we are looking for
divorced females who own a flat-screen TV (and who isn't? but I'll let
that slide).
These values constitute 3 rows in the aforementioned Attributes table,
with PKs that can be found quickly. So ultimately a search such as this
becomes something like "SELECT * FROM People INNER JOIN Attributes WHERE
People.PersonID = Attributes.PersonID and AttributeID IN( 123, 234,
345).

Obviously there is a more optimal way to write that Select statement but
I am on a keystroke diet LOL.

A.

On 6/13/07, jwcolby <jwcolby at colbyconsulting.com> wrote:
>
>
> Michael,
>
> The indexes on the where clauses are the biggie.  There are about 650 
> demographics fields (on one of these tables, 65 million demographics 
> records).  Putting an index on each field is time consuming to say the

> least.  Not to mention space consuming.  I am doing that as the client

> comes in with orders needing the where clause on a given field.
>
> This whole thing needs to be normalized such that I have a "fact
table"
> which is a field with the demographics data, a field with the fact 
> name (name of the original field in the demographics table) plus a 
> field back to the person/address that "owns" that fact.  Then I could 
> merge all of the demographics "facts" from every demographics table I 
> get from the client into a single fact table, and all of the addresses

> into a person / address table (system).
>
> I suspect that I will do that down the road a bit (as I get more 
> comfortable in SQL Server) but I have to make the data usable in the 
> meantime.
>
> John W. Colby
> Colby Consulting
> www.ColbyConsulting.com
> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of 
> Michael Maddison
> Sent: Wednesday, June 13, 2007 9:56 AM
> To: dba-sqlserver at databaseadvisors.com
> Subject: Re: [dba-SQLServer] SQL Server 2005 - long count time
>
> ' Now that I understand what the CI indexes do, I will probably go 
> back and add both a CI and a NCI to each table, on the PKID, in order 
> to allow SQL Server to decide which is more efficient in any given 
> case and use whichever it needs in each situation.'
>
> >>>Also as inserts and updates aren't an issue makes sure that both
> sides of any join fields have indexes as well.
> Also any columns in the where clause.
>
> cheers
>
> MM
>
> Michael,
>
> >In my test scenario with 3mill rows the query select count(*) from
> [testtable] was minutes faster on a heap, which I wouldn't have 
> expected...
> >It seemed to be the only query that was faster though.
>
>
> Now take into account that it was minutes faster on a 3 million row 
> table, how much faster on a 90 million row table.
>
> This leaves us to wonder if perhaps both would not be beneficial?  The

> nci for doing counts (and I do a LOT of them!!!) and a clustered index

> for actual joins, leaving it up to SQL Server as to which it uses.
> The thing to understand here is that ATM I have use a system where I 
> have two actual tables, a 90 million "original data" table and a 
> matching N million "address validated" table, which contains ONLY the 
> address fields, NOT any additional demographics fields.  The reason 
> that the address validated table is "N million" is that I delete non 
> valid addresses from that table in order to pare down the size.  So 
> the "address validated table" has the same PKID values as the 
> "original data" table.
>
> When I process data, I use the original "data table" in where clauses 
> because that table contains the demographics - age, income, children, 
> preferences.  The "address validated" table has address information, 
> but it also has information that the address is valid just in the PK 
> alone.
> In other words, the fact that it is in the valid address table in and 
> of itself means that the address is valid (because I deleted all 
> non-valid records from THAT table.
>
> So my client calls me and says "give me a count of all the households 
> (another subject) in these zips".  I can do that without ever going 
> back to the original data table.  In other cases he says "give me a 
> count of all the addresses in these zips where age=x, income is 
> between y and z and has female children.  That query needs to go back 
> to the original data table for the demographics information.
>
> So you can see that these PK indexes play an absolutely huge role in 
> my business, both from the perspective of joins between the two tables

> as well as from the perspective of raw counts when demographics are 
> not needed.
>
> Now, I can hear the protestations already:
>
> 1) Why not merge the valid address back in to the demographics table.
>
> Because this is but one of the demographics tables I deal with, there 
> will be literally dozens of them.  At some point in time the valid 
> address data from each demographics table has to be merged into a 
> single valid address table with an even more complex m-m table saying 
> this valid address is linked to THESE (multiple) demographics tables.
>
> 2) OK then why not delete the non-valid addresses from the 
> demographics table?
>
> This is a "should be done" but in the end it makes only a small (but 
> still
> significant) dent in the total number of records in the demographics 
> table, about 20% maximum (so far).  What I really need to do is go 
> back and remove ALL address data from the demographics table.
> Basically, someone DID merge all of the address validation data back 
> in to the demographics table (back before I got ahold of it) and so 
> the demographics table now has probably 40 (out of 700) fields that 
> are old, out of date address validation info.
>
> Even if I do that, I STILL need the PKs in both tables in order to 
> join demographics with valid address, and I need them to be FAST.  Now

> that I understand what the CI indexes do, I will probably go back and 
> add both a CI and a NCI to each table, on the PKID, in order to allow 
> SQL Server to decide which is more efficient in any given case and use

> whichever it needs in each situation.
>
> John W. Colby
> Colby Consulting
> www.ColbyConsulting.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 jwcolby at colbyconsulting.com  Wed Jun 13 18:31:18 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Wed, 13 Jun 2007 19:31:18 -0400
Subject: [dba-SQLServer] SQL Server 2005 - long count time
In-Reply-To: <59A61174B1F5B54B97FD4ADDE71E7D01289904@ddi-01.DDI.local>
Message-ID: <20070613233121.AC4B1BD09@smtp-auth.no-ip.com>

Michael,

Where the rubber meets the road however... Is the process of normalizing
tables with hundreds of fields into a single "fact field" table.  Think of
what is required to do that.  

1) I have to iterate through all of the fields to get the name of each
field.
2) Create a record in a "fact name" table.
3) Get the newly created PKID of that fact name and use it to build a query
that pulls all of the data from the table for exactly and only that field,
writing the fact, the PKID of the fact name, and a PKID of a person/address
into a three field fact table.  Each time I find a new person / address I
have to write a new record to the person / address table (actually three
tables - person/address/mmPersonAddress, but who's counting).  Somehow link
the "factID" with the person/address id.

Remember that each fact "belongs to" a person.  So I either build the fact
table to point directly to the PKID in the demographics table (the easy way)
or normalize out to a person table and point the fact to a PersonID.

Kind of hard to explain without diagrams.

In any event, it would be easiest to run a query that pulls ALL of the data
in a given field WHERE NOT NULL, IOW all of the data from ONE field where
that field contains data.  Then write just those records to the fact table
with a FactNameID and the corresponding DemographicsID.  The DemographicsID
however implies a "tblDemographicsTableName".  IOW each "list" as they are
called is placed in a separate table and therefore has it's own PKID which
starts at zero and increments.  So the PKID of the fact table HSID will
overlap the PKIDs from tblInfutor.

As you can see, this is a mess and demands automation to get it right.  I
will, once I get up to speed on VB.Net and SQL Server, write an application
to normalize fact table XXX.  In the meantime, this is NOT something that
can be done manually.  It will involve at LEAST one query for each field of
each fact table (700 fields in HSID alone).

This is very doable, it is just something that requires fluency in a
programming language up to the task of handling tables / fields out in SQL
Server and dunamically creating and executing all of these fact
normalization queries.  It will be fun once I get around to it.

John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Michael
Maddison
Sent: Wednesday, June 13, 2007 7:08 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] SQL Server 2005 - long count time

OLAP may be an option but I think John will still run into issues with 100's
of dimensions.
Actually with the changes Arthur recommended then it should work a treat...
in theory...

cheers

Michael M

John,

How about using olap? This would do a lot of preprocessing to make it quick
and easy to find counts and sums. My understanding is that SQL Server 2005
has very good olap options. (My experience is limited to Cognos, but a 300
million record cube of web site hit data took 20 minutes to process 12-20
dimensions and about 6 measures. The resulting cube gave instant answers.)

If you did that, MDX (similar to SQL) would allow you to write queries
against the olap cube. Because of the pre-processing of the olap cube, MDX
query response should be instant. 

I originally got into this sort of stuff when the cross tabs I was running
with Access as a front end to SQL Server 2000 were taking too long. The
company I was working for wanted to use Cognos (2000's olap was fairly
rudimentary before the development of MDX) so that's the direction I took,
but I've heard lots of good things about 2005's olap.

Fred




From jwcolby at colbyconsulting.com  Thu Jun 14 09:56:21 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Thu, 14 Jun 2007 10:56:21 -0400
Subject: [dba-SQLServer] Ram use for queries
Message-ID: <20070614145622.9C98ABDE7@smtp-auth.no-ip.com>

Is there any tool for seeing how much ram SQL Server requires to run a
specific query?  Does (or can) SQL Server use disk to handle that temporary
storage.  

I have queries to run against these huge tables which require 1/2 hour or
more to complete.  Trying to move up to servers running enterprise versions
of Windows 2003 and SQL Server and which would run 16 or more of ram would
be hugely expensive, however I can build raid 0 arrays of ram disks for a
"reasonable" price, ~$1600 for a 16gb drive.  Obviously 16gb is not big
enough to put the main databases on, they are up in the 100-200 gb size
range.  However I might be able to put the log files out there, or the
tempdb.  In fact I am reading about placing the tempdb files on ramdisk but
there are no metrics described for how big these things are.

Has anyone ever tried, seen or heard of this being done?  

John W. Colby
Colby Consulting
www.ColbyConsulting.com 



From jwcolby at colbyconsulting.com  Fri Jun 15 08:20:58 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Fri, 15 Jun 2007 09:20:58 -0400
Subject: [dba-SQLServer] Help file for Visual Studio
Message-ID: <20070615132059.6E91DBF52@smtp-auth.no-ip.com>

I never got any answer from the VB forum so I am casting a wider net.

Does anyone know how to select the help file in Visual Studio?  ATM when I
hit F1 the help file for SQL Server opens.  Every part of the help file
clearly states that it is SQL Server.  I cannot get "VB.NET" help to display
which makes it mighty difficult to get at syntax and stuff for VB.

TIA

John W. Colby
Colby Consulting
www.ColbyConsulting.com 



From mwp.reid at qub.ac.uk  Fri Jun 15 08:36:44 2007
From: mwp.reid at qub.ac.uk (Martin Reid)
Date: Fri, 15 Jun 2007 14:36:44 +0100
Subject: [dba-SQLServer] Help file for Visual Studio
References: <20070615132059.6E91DBF52@smtp-auth.no-ip.com>
Message-ID: <D0BF9C78D1C45C418541C852C8944FE201086BA8@qub-xchange-01.ads.qub.ac.uk>

VS 2005
 
I usually hit the search tab and then use the drop downs to select the language or subject I want to find. There are three drop down lists
 
Language
Technology
Content Type
 
 
Martin
 
Martin WP Reid
Training and Assessment Unit
Riddle Hall
Belfast
 
tel: 02890 974465
 

________________________________

From: dba-sqlserver-bounces at databaseadvisors.com on behalf of jwcolby
Sent: Fri 15/06/2007 14:20
To: 'Access Developers discussion and problem solving'; dba-sqlserver at databaseadvisors.com; dba-vb at databaseadvisors.com
Subject: [dba-SQLServer] Help file for Visual Studio



I never got any answer from the VB forum so I am casting a wider net.

Does anyone know how to select the help file in Visual Studio?  ATM when I
hit F1 the help file for SQL Server opens.  Every part of the help file
clearly states that it is SQL Server.  I cannot get "VB.NET" help to display
which makes it mighty difficult to get at syntax and stuff for VB.

TIA

John W. Colby
Colby Consulting
www.ColbyConsulting.com

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




From jwcolby at colbyconsulting.com  Fri Jun 15 08:50:11 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Fri, 15 Jun 2007 09:50:11 -0400
Subject: [dba-SQLServer] Help file for Visual Studio
In-Reply-To: <D0BF9C78D1C45C418541C852C8944FE201086BA8@qub-xchange-01.ads.qub.ac.uk>
Message-ID: <20070615135012.D5D80BCB0@smtp-auth.no-ip.com>

Martin,

When I do that, to the left side is a "filtered by" drop down.  That drop
down only contains things starting with SQL Server, it has an entire list,
but all of them are SQL Server.  

As for the drop downs you mention, the language drop down has only Vb.net
and VB6 selected.  Modifying those dropdowns do not change the contents of
the "filtered by" dropdown on the left hand side.  Basically I cannot see VB
stuff at all.  It is difficult to say for sure because there are so many,
but it appears that the index objects are all SQL Server related.

John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Martin Reid
Sent: Friday, June 15, 2007 9:37 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Help file for Visual Studio

VS 2005
 
I usually hit the search tab and then use the drop downs to select the
language or subject I want to find. There are three drop down lists
 
Language
Technology
Content Type
 
 
Martin
 
Martin WP Reid
Training and Assessment Unit
Riddle Hall
Belfast
 
tel: 02890 974465
 

________________________________

From: dba-sqlserver-bounces at databaseadvisors.com on behalf of jwcolby
Sent: Fri 15/06/2007 14:20
To: 'Access Developers discussion and problem solving';
dba-sqlserver at databaseadvisors.com; dba-vb at databaseadvisors.com
Subject: [dba-SQLServer] Help file for Visual Studio



I never got any answer from the VB forum so I am casting a wider net.

Does anyone know how to select the help file in Visual Studio?  ATM when I
hit F1 the help file for SQL Server opens.  Every part of the help file
clearly states that it is SQL Server.  I cannot get "VB.NET" help to display
which makes it mighty difficult to get at syntax and stuff for VB.

TIA

John W. Colby
Colby Consulting
www.ColbyConsulting.com

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






From jwcolby at colbyconsulting.com  Fri Jun 15 09:01:30 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Fri, 15 Jun 2007 10:01:30 -0400
Subject: [dba-SQLServer] Help file for Visual Studio
In-Reply-To: <20070615135012.D5D80BCB0@smtp-auth.no-ip.com>
Message-ID: <20070615140131.9B148BDFD@smtp-auth.no-ip.com>

Further to that, if I (for example) click on a method of the stringbuilder
class, it will return a page on the string builder.  However if I try to
enter "stringbuilder" in the index to the left, it does not find it,
ostensibly because the index is being filtered to SQL Server stuff which
does not have "stringbuilder".  Thus I cannot go to the help and search for
VB.Net objects directly, I have to USE an object, then click on a class
member to get help about that class.  Rather unhelpful.

John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Friday, June 15, 2007 9:50 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Help file for Visual Studio

Martin,

When I do that, to the left side is a "filtered by" drop down.  That drop
down only contains things starting with SQL Server, it has an entire list,
but all of them are SQL Server.  

As for the drop downs you mention, the language drop down has only Vb.net
and VB6 selected.  Modifying those dropdowns do not change the contents of
the "filtered by" dropdown on the left hand side.  Basically I cannot see VB
stuff at all.  It is difficult to say for sure because there are so many,
but it appears that the index objects are all SQL Server related.

John W. Colby
Colby Consulting
www.ColbyConsulting.com
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Martin Reid
Sent: Friday, June 15, 2007 9:37 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Help file for Visual Studio

VS 2005
 
I usually hit the search tab and then use the drop downs to select the
language or subject I want to find. There are three drop down lists
 
Language
Technology
Content Type
 
 
Martin
 
Martin WP Reid
Training and Assessment Unit
Riddle Hall
Belfast
 
tel: 02890 974465
 

________________________________

From: dba-sqlserver-bounces at databaseadvisors.com on behalf of jwcolby
Sent: Fri 15/06/2007 14:20
To: 'Access Developers discussion and problem solving';
dba-sqlserver at databaseadvisors.com; dba-vb at databaseadvisors.com
Subject: [dba-SQLServer] Help file for Visual Studio



I never got any answer from the VB forum so I am casting a wider net.

Does anyone know how to select the help file in Visual Studio?  ATM when I
hit F1 the help file for SQL Server opens.  Every part of the help file
clearly states that it is SQL Server.  I cannot get "VB.NET" help to display
which makes it mighty difficult to get at syntax and stuff for VB.

TIA

John W. Colby
Colby Consulting
www.ColbyConsulting.com

_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com <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 jwcolby at colbyconsulting.com  Mon Jun 18 00:27:56 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Mon, 18 Jun 2007 01:27:56 -0400
Subject: [dba-SQLServer] The first annual Great Smokey Mountains AccessD
	Conference
Message-ID: <20070618052757.6D8F1BC85@smtp-auth.no-ip.com>

The first annual Great Smokey Mountains AccessD Conference will be happening
this coming Saturday at my house.

To get a map to my house, watch for Wrap of course:

http://maps.google.com/#utm_campaign=en&utm_source=en-ha-na-us-google-gm&utm
_medium=ha&utm_term=map

Type in 1723 Twin Pines Dr, Hudson, 28638.  You should get right there.  Of
course things are never as they seem.  There are really only two left turns
coming south on Horseshoe bend road, the second is my drive.  Just remember
that.

Hudson Weather.  It's looking like high 80s over the weekend.  I do have AC
so we will be comfortable inside.

http://www.weather.com/weather/local/28638

Anyone needing hotels:

http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:official&
channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&sa=X&o
i=local_group&resnum=4&ct=image

Alternately, down in Hickory:

http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:official&
channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&sa=X&o
i=local_group&resnum=4&ct=image

Food in Lenoir:

http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:official&
channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&sa=X&o
i=local_group&resnum=4&ct=image

Food in Hudson:

http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:official&
channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&sa=X&o
i=local_group&resnum=4&ct=image

Strangely enough (or perhaps not?), a search for "night clubs" in Lenoir, nc
turned up nothing, but did show stuff down in Hickory, just south of us.  I
must admit I have not been to a night club since we moved here so I will not
be much help there.

http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:official&
channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&sa=X&o
i=local_group&resnum=4&ct=image

Churches (lots of Baptists down here).  You will always be welcome at my
church, #B - Hudson United Methodist.  I do have enough credit at this point
that I can skip if the conference is still going on.

http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:official&
channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&sa=X&o
i=local_group&resnum=4&ct=image


General NC info:

http://www.visitnc.com/tools_search_results.asp

http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:official&
channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&sa=X&o
i=local_group&resnum=4&ct=image

The plan is to meet at my home on Saturday, and Sunday if there is anyone
still here.  Anyone coming in early (Friday evening / night) is welcome to
call me.  828-572-0120 is my business phone.

I will be doing a BBQ Saturday evening after the conference.  The usual
suspects - chicken / ribs / etc.  I am pretty good on the BBQ.  

I am looking forward to seeing you guys, whoever shows up, so let's meet and
have a good time - no RSVP required, come on down.

John W. Colby
Colby Consulting
www.ColbyConsulting.com 



From garykjos at gmail.com  Mon Jun 18 08:07:21 2007
From: garykjos at gmail.com (Gary Kjos)
Date: Mon, 18 Jun 2007 08:07:21 -0500
Subject: [dba-SQLServer] [AccessD] The first annual Great Smokey
	Mountains AccessD Conference
In-Reply-To: <20070618052757.6D8F1BC85@smtp-auth.no-ip.com>
References: <20070618052757.6D8F1BC85@smtp-auth.no-ip.com>
Message-ID: <aea6c4950706180607i577117a7o5ed589c2163f2122@mail.gmail.com>

Wish I could be joining you John. The thought of barbeque is making my
lmouth water. Hope someone will be taking some photos that can be
shared.

GK

On 6/18/07, jwcolby <jwcolby at colbyconsulting.com> wrote:
> The first annual Great Smokey Mountains AccessD Conference will be happening
> this coming Saturday at my house.
>
> To get a map to my house, watch for Wrap of course:
>
> http://maps.google.com/#utm_campaign=en&utm_source=en-ha-na-us-google-gm&utm
> _medium=ha&utm_term=map
>
> Type in 1723 Twin Pines Dr, Hudson, 28638.  You should get right there.  Of
> course things are never as they seem.  There are really only two left turns
> coming south on Horseshoe bend road, the second is my drive.  Just remember
> that.
>
> Hudson Weather.  It's looking like high 80s over the weekend.  I do have AC
> so we will be comfortable inside.
>
> http://www.weather.com/weather/local/28638
>
> Anyone needing hotels:
>
> http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:official&
> channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&sa=X&o
> i=local_group&resnum=4&ct=image
>
> Alternately, down in Hickory:
>
> http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:official&
> channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&sa=X&o
> i=local_group&resnum=4&ct=image
>
> Food in Lenoir:
>
> http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:official&
> channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&sa=X&o
> i=local_group&resnum=4&ct=image
>
> Food in Hudson:
>
> http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:official&
> channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&sa=X&o
> i=local_group&resnum=4&ct=image
>
> Strangely enough (or perhaps not?), a search for "night clubs" in Lenoir, nc
> turned up nothing, but did show stuff down in Hickory, just south of us.  I
> must admit I have not been to a night club since we moved here so I will not
> be much help there.
>
> http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:official&
> channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&sa=X&o
> i=local_group&resnum=4&ct=image
>
> Churches (lots of Baptists down here).  You will always be welcome at my
> church, #B - Hudson United Methodist.  I do have enough credit at this point
> that I can skip if the conference is still going on.
>
> http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:official&
> channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&sa=X&o
> i=local_group&resnum=4&ct=image
>
>
> General NC info:
>
> http://www.visitnc.com/tools_search_results.asp
>
> http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:official&
> channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&sa=X&o
> i=local_group&resnum=4&ct=image
>
> The plan is to meet at my home on Saturday, and Sunday if there is anyone
> still here.  Anyone coming in early (Friday evening / night) is welcome to
> call me.  828-572-0120 is my business phone.
>
> I will be doing a BBQ Saturday evening after the conference.  The usual
> suspects - chicken / ribs / etc.  I am pretty good on the BBQ.
>
> I am looking forward to seeing you guys, whoever shows up, so let's meet and
> have a good time - no RSVP required, come on down.
>
> John W. Colby
> Colby Consulting
> www.ColbyConsulting.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>


-- 
Gary Kjos
garykjos at gmail.com


From jwcolby at colbyconsulting.com  Mon Jun 18 16:09:06 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Mon, 18 Jun 2007 17:09:06 -0400
Subject: [dba-SQLServer] [AccessD] The first annual Great Smokey
	Mountains AccessDConference
In-Reply-To: <011a01c7b1e9$7602f4b0$0a00a8c0@PCRURI35>
Message-ID: <20070618210907.76D40BDE7@smtp-auth.no-ip.com>

I am thinking not before 8:00 am.  We will start at 9:00 am and run through
12:00 pm (lunch), break till 1:30 or so, then pick up and continue till
around 5:00 pm.  Same schedule for Sunday if there is anyone left around.

Again, anyone in the neighborhood Friday night is welcome to call.  I do
need to work till 5:00 pm Friday, and if you come by before the kids are in
bed (8:00 PM) you will have to deal with Robbie and Allie.  I have a nice
screened porch on the back of the house where we can sit around and shoot
bull.  I am normally up till 11:00 pm or later so it will not be an
inconvenience.

BTW, I also have wireless for those who need to check email etc.  It is
encrypted (WPA?) but you just put in a key and go.

John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Barbara Ryan
Sent: Monday, June 18, 2007 4:44 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] The first annual Great Smokey Mountains
AccessDConference

I'm looking forward to meeting you all.  John, what time should we arrive on
Saturday?

Barb Ryan

----- Original Message -----
From: "jwcolby" <jwcolby at colbyconsulting.com>
To: "'Access Developers discussion and problem solving'" 
<accessd at databaseadvisors.com>; <dba-sqlserver at databaseadvisors.com>;
<dba-vb at databaseadvisors.com>; "'Discussion of Hardware and Software
issues'" <dba-tech at databaseadvisors.com>
Sent: Monday, June 18, 2007 1:27 AM
Subject: [AccessD] The first annual Great Smokey Mountains AccessD
Conference


> The first annual Great Smokey Mountains AccessD Conference will be 
> happening this coming Saturday at my house.
>
> To get a map to my house, watch for Wrap of course:
>
> http://maps.google.com/#utm_campaign=en&utm_source=en-ha-na-us-google-
> gm&utm
> _medium=ha&utm_term=map
>
> Type in 1723 Twin Pines Dr, Hudson, 28638.  You should get right there. 
> Of
> course things are never as they seem.  There are really only two left 
> turns coming south on Horseshoe bend road, the second is my drive.  
> Just remember that.
>
> Hudson Weather.  It's looking like high 80s over the weekend.  I do 
> have AC so we will be comfortable inside.
>
> http://www.weather.com/weather/local/28638
>
> Anyone needing hotels:
>
> http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:off
> icial& 
> channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&
> sa=X&o
> i=local_group&resnum=4&ct=image
>
> Alternately, down in Hickory:
>
> http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:off
> icial& 
> channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&
> sa=X&o
> i=local_group&resnum=4&ct=image
>
> Food in Lenoir:
>
> http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:off
> icial& 
> channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&
> sa=X&o
> i=local_group&resnum=4&ct=image
>
> Food in Hudson:
>
> http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:off
> icial& 
> channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&
> sa=X&o
> i=local_group&resnum=4&ct=image
>
> Strangely enough (or perhaps not?), a search for "night clubs" in 
> Lenoir, nc turned up nothing, but did show stuff down in Hickory, just 
> south of us.
> I
> must admit I have not been to a night club since we moved here so I 
> will not be much help there.
>
> http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:off
> icial& 
> channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&
> sa=X&o
> i=local_group&resnum=4&ct=image
>
> Churches (lots of Baptists down here).  You will always be welcome at 
> my church, #B - Hudson United Methodist.  I do have enough credit at 
> this point that I can skip if the conference is still going on.
>
> http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:off
> icial& 
> channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&
> sa=X&o
> i=local_group&resnum=4&ct=image
>
>
> General NC info:
>
> http://www.visitnc.com/tools_search_results.asp
>
> http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:off
> icial& 
> channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&
> sa=X&o
> i=local_group&resnum=4&ct=image
>
> The plan is to meet at my home on Saturday, and Sunday if there is 
> anyone still here.  Anyone coming in early (Friday evening / night) is 
> welcome to call me.  828-572-0120 is my business phone.
>
> I will be doing a BBQ Saturday evening after the conference.  The 
> usual suspects - chicken / ribs / etc.  I am pretty good on the BBQ.
>
> I am looking forward to seeing you guys, whoever shows up, so let's 
> meet and have a good time - no RSVP required, come on down.
>
> John W. Colby
> Colby Consulting
> www.ColbyConsulting.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com



From paul.hartland at fsmail.net  Tue Jun 19 03:34:09 2007
From: paul.hartland at fsmail.net (paul.hartland at fsmail.net)
Date: Tue, 19 Jun 2007 10:34:09 +0200 (CEST)
Subject: [dba-SQLServer] SQL Server - sysstat & 0xf = 4
Message-ID: <13597680.2012391182242049651.JavaMail.www@wwinf3101>

To all,

Can anyone tell me exactly why this sysstat & 0xf = 4 is used and what exactly it means etc, I know that sysstat is a field in the sysobjects table but the & 0xf = 4 is the bit thats confusing me.  Please ignore my ignorance if this is simple as we are working on a new technology for our stocktaking along with another company, and they have used this is some code to create an SP on the fly:

IF EXISTS (select * from sysobjects where id = object_id('dbo.mySP') and sysstat & 0xf = 4)
 drop procedure dbo.mySP

Thank you for any help on this in advance....


Paul Hartland
paul.hartland at fsmail.net
07730 523179

From robin at musicalmemories.co.uk  Tue Jun 19 04:03:31 2007
From: robin at musicalmemories.co.uk (Robin )
Date: Tue, 19 Jun 2007 10:03:31 +0100
Subject: [dba-SQLServer] SQL Server - sysstat & 0xf = 4
Message-ID: <560E2B80EC8F624B93A87B943B7A9CD559ABB4@rgiserv.rg.local>

Hi Paul,
It's a way of checking if a table exists..

See here
http://www.dotnet247.com/247reference/msgs/21/107015.aspx

Rgds
Robin

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of
paul.hartland at fsmail.net
Sent: 19 June 2007 09:34
To: accessd; dba-sqlserver
Subject: [dba-SQLServer] SQL Server - sysstat & 0xf = 4
Importance: High


To all,

Can anyone tell me exactly why this sysstat & 0xf = 4 is used and what
exactly it means etc, I know that sysstat is a field in the sysobjects
table but the & 0xf = 4 is the bit thats confusing me.  Please ignore my
ignorance if this is simple as we are working on a new technology for
our stocktaking along with another company, and they have used this is
some code to create an SP on the fly:

IF EXISTS (select * from sysobjects where id = object_id('dbo.mySP') and
sysstat & 0xf = 4)  drop procedure dbo.mySP

Thank you for any help on this in advance....


Paul Hartland
paul.hartland at fsmail.net
07730 523179
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com




From robin at musicalmemories.co.uk  Tue Jun 19 04:07:42 2007
From: robin at musicalmemories.co.uk (Robin )
Date: Tue, 19 Jun 2007 10:07:42 +0100
Subject: [dba-SQLServer] SQL Server - sysstat & 0xf = 4
Message-ID: <560E2B80EC8F624B93A87B943B7A9CD559ABB5@rgiserv.rg.local>

Whoops - I meant SP not table....
Rgds
Robin

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of
paul.hartland at fsmail.net
Sent: 19 June 2007 09:34
To: accessd; dba-sqlserver
Subject: [dba-SQLServer] SQL Server - sysstat & 0xf = 4
Importance: High


To all,

Can anyone tell me exactly why this sysstat & 0xf = 4 is used and what
exactly it means etc, I know that sysstat is a field in the sysobjects
table but the & 0xf = 4 is the bit thats confusing me.  Please ignore my
ignorance if this is simple as we are working on a new technology for
our stocktaking along with another company, and they have used this is
some code to create an SP on the fly:

IF EXISTS (select * from sysobjects where id = object_id('dbo.mySP') and
sysstat & 0xf = 4)  drop procedure dbo.mySP

Thank you for any help on this in advance....


Paul Hartland
paul.hartland at fsmail.net
07730 523179
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com




From cfoust at infostatsystems.com  Tue Jun 19 11:28:52 2007
From: cfoust at infostatsystems.com (Charlotte Foust)
Date: Tue, 19 Jun 2007 09:28:52 -0700
Subject: [dba-SQLServer] [dba-VB] [AccessD] The first annual Great
	Smokey MountainsAccessD Conference
In-Reply-To: <aea6c4950706180607i577117a7o5ed589c2163f2122@mail.gmail.com>
References: <20070618052757.6D8F1BC85@smtp-auth.no-ip.com>
	<aea6c4950706180607i577117a7o5ed589c2163f2122@mail.gmail.com>
Message-ID: <F55048AF7E974F429BB24597D7355EEA4BA0D2@INFOSERVER04.infostat.local>

<sigh> Wish I could join you!

Charlotte 

-----Original Message-----
From: dba-vb-bounces at databaseadvisors.com
[mailto:dba-vb-bounces at databaseadvisors.com] On Behalf Of Gary Kjos
Sent: Monday, June 18, 2007 6:07 AM
To: Access Developers discussion and problem solving
Cc: Discussion of Hardware and Software issues;
dba-sqlserver at databaseadvisors.com; dba-vb at databaseadvisors.com
Subject: Re: [dba-VB] [AccessD] The first annual Great Smokey
MountainsAccessD Conference

Wish I could be joining you John. The thought of barbeque is making my
lmouth water. Hope someone will be taking some photos that can be
shared.

GK

On 6/18/07, jwcolby <jwcolby at colbyconsulting.com> wrote:
> The first annual Great Smokey Mountains AccessD Conference will be 
> happening this coming Saturday at my house.
>
> To get a map to my house, watch for Wrap of course:
>
> http://maps.google.com/#utm_campaign=en&utm_source=en-ha-na-us-google-
> gm&utm
> _medium=ha&utm_term=map
>
> Type in 1723 Twin Pines Dr, Hudson, 28638.  You should get right 
> there.  Of course things are never as they seem.  There are really 
> only two left turns coming south on Horseshoe bend road, the second is

> my drive.  Just remember that.
>
> Hudson Weather.  It's looking like high 80s over the weekend.  I do 
> have AC so we will be comfortable inside.
>
> http://www.weather.com/weather/local/28638
>
> Anyone needing hotels:
>
> http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:off
> icial& 
> channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&
> sa=X&o
> i=local_group&resnum=4&ct=image
>
> Alternately, down in Hickory:
>
> http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:off
> icial& 
> channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&
> sa=X&o
> i=local_group&resnum=4&ct=image
>
> Food in Lenoir:
>
> http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:off
> icial& 
> channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&
> sa=X&o
> i=local_group&resnum=4&ct=image
>
> Food in Hudson:
>
> http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:off
> icial& 
> channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&
> sa=X&o
> i=local_group&resnum=4&ct=image
>
> Strangely enough (or perhaps not?), a search for "night clubs" in 
> Lenoir, nc turned up nothing, but did show stuff down in Hickory, just

> south of us.  I must admit I have not been to a night club since we 
> moved here so I will not be much help there.
>
> http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:off
> icial& 
> channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&
> sa=X&o
> i=local_group&resnum=4&ct=image
>
> Churches (lots of Baptists down here).  You will always be welcome at 
> my church, #B - Hudson United Methodist.  I do have enough credit at 
> this point that I can skip if the conference is still going on.
>
> http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:off
> icial& 
> channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&
> sa=X&o
> i=local_group&resnum=4&ct=image
>
>
> General NC info:
>
> http://www.visitnc.com/tools_search_results.asp
>
> http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:off
> icial& 
> channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&
> sa=X&o
> i=local_group&resnum=4&ct=image
>
> The plan is to meet at my home on Saturday, and Sunday if there is 
> anyone still here.  Anyone coming in early (Friday evening / night) is

> welcome to call me.  828-572-0120 is my business phone.
>
> I will be doing a BBQ Saturday evening after the conference.  The 
> usual suspects - chicken / ribs / etc.  I am pretty good on the BBQ.
>
> I am looking forward to seeing you guys, whoever shows up, so let's 
> meet and have a good time - no RSVP required, come on down.
>
> John W. Colby
> Colby Consulting
> www.ColbyConsulting.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>


--
Gary Kjos
garykjos at gmail.com
_______________________________________________
dba-VB mailing list
dba-VB at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-vb
http://www.databaseadvisors.com




From accessd at shaw.ca  Tue Jun 19 12:34:50 2007
From: accessd at shaw.ca (Jim Lawrence)
Date: Tue, 19 Jun 2007 10:34:50 -0700
Subject: [dba-SQLServer] [dba-VB] [AccessD] The first annual
 Great	Smokey MountainsAccessD Conference
In-Reply-To: <F55048AF7E974F429BB24597D7355EEA4BA0D2@INFOSERVER04.infostat.local>
Message-ID: <0JJW003368MOKIL1@l-daemon>

Is there anyone who is going that will be taking pictures and basically
recording the proceedings? 

If you are; record presenters and presentations; basically try and get the
flavour of the event... (BBQ). 

If anyone going is making PowerPoint presentations please send them along so
they can be enjoyed later. 

I wonder how difficult it would be to create a video feed from the NC
location? If is was possible then some of us that just can not make it would
be able to enjoy the event remotely.

Jim    

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Charlotte
Foust
Sent: Tuesday, June 19, 2007 9:29 AM
To: dba-vb at databaseadvisors.com; Access Developers discussion and problem
solving
Cc: Discussion of Hardware and Software issues;
dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] [dba-VB] [AccessD] The first annual Great
Smokey MountainsAccessD Conference

<sigh> Wish I could join you!

Charlotte 

-----Original Message-----
From: dba-vb-bounces at databaseadvisors.com
[mailto:dba-vb-bounces at databaseadvisors.com] On Behalf Of Gary Kjos
Sent: Monday, June 18, 2007 6:07 AM
To: Access Developers discussion and problem solving
Cc: Discussion of Hardware and Software issues;
dba-sqlserver at databaseadvisors.com; dba-vb at databaseadvisors.com
Subject: Re: [dba-VB] [AccessD] The first annual Great Smokey
MountainsAccessD Conference

Wish I could be joining you John. The thought of barbeque is making my
lmouth water. Hope someone will be taking some photos that can be
shared.

GK

On 6/18/07, jwcolby <jwcolby at colbyconsulting.com> wrote:
> The first annual Great Smokey Mountains AccessD Conference will be 
> happening this coming Saturday at my house.
>
> To get a map to my house, watch for Wrap of course:
>
> http://maps.google.com/#utm_campaign=en&utm_source=en-ha-na-us-google-
> gm&utm
> _medium=ha&utm_term=map
>
> Type in 1723 Twin Pines Dr, Hudson, 28638.  You should get right 
> there.  Of course things are never as they seem.  There are really 
> only two left turns coming south on Horseshoe bend road, the second is

> my drive.  Just remember that.
>
> Hudson Weather.  It's looking like high 80s over the weekend.  I do 
> have AC so we will be comfortable inside.
>
> http://www.weather.com/weather/local/28638
>
> Anyone needing hotels:
>
> http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:off
> icial& 
> channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&
> sa=X&o
> i=local_group&resnum=4&ct=image
>
> Alternately, down in Hickory:
>
> http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:off
> icial& 
> channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&
> sa=X&o
> i=local_group&resnum=4&ct=image
>
> Food in Lenoir:
>
> http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:off
> icial& 
> channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&
> sa=X&o
> i=local_group&resnum=4&ct=image
>
> Food in Hudson:
>
> http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:off
> icial& 
> channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&
> sa=X&o
> i=local_group&resnum=4&ct=image
>
> Strangely enough (or perhaps not?), a search for "night clubs" in 
> Lenoir, nc turned up nothing, but did show stuff down in Hickory, just

> south of us.  I must admit I have not been to a night club since we 
> moved here so I will not be much help there.
>
> http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:off
> icial& 
> channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&
> sa=X&o
> i=local_group&resnum=4&ct=image
>
> Churches (lots of Baptists down here).  You will always be welcome at 
> my church, #B - Hudson United Methodist.  I do have enough credit at 
> this point that I can skip if the conference is still going on.
>
> http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:off
> icial& 
> channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&
> sa=X&o
> i=local_group&resnum=4&ct=image
>
>
> General NC info:
>
> http://www.visitnc.com/tools_search_results.asp
>
> http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:off
> icial& 
> channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&
> sa=X&o
> i=local_group&resnum=4&ct=image
>
> The plan is to meet at my home on Saturday, and Sunday if there is 
> anyone still here.  Anyone coming in early (Friday evening / night) is

> welcome to call me.  828-572-0120 is my business phone.
>
> I will be doing a BBQ Saturday evening after the conference.  The 
> usual suspects - chicken / ribs / etc.  I am pretty good on the BBQ.
>
> I am looking forward to seeing you guys, whoever shows up, so let's 
> meet and have a good time - no RSVP required, come on down.
>
> John W. Colby
> Colby Consulting
> www.ColbyConsulting.com
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>


--
Gary Kjos
garykjos at gmail.com
_______________________________________________
dba-VB mailing list
dba-VB at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-vb
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 markamatte at hotmail.com  Wed Jun 20 09:31:48 2007
From: markamatte at hotmail.com (Mark A Matte)
Date: Wed, 20 Jun 2007 14:31:48 +0000
Subject: [dba-SQLServer] [dba-VB] [AccessD] The first annual Great
 Smokey MountainsAccessD Conference
In-Reply-To: <0JJW003368MOKIL1@l-daemon>
Message-ID: <BAY127-F2587392EEC9A88C99DDEDED2110@phx.gbl>

I have a new camera...and (insert self promotion here) some of my picture 
are actually going to be displayed at 2 locations in Greensboro, NC. (end 
self promotion)

I would be more than happy to take pictures of the event.

Thanks,

Mark A. Matte


>From: Jim Lawrence <accessd at shaw.ca>
>Reply-To: dba-sqlserver at databaseadvisors.com
>To: dba-sqlserver at databaseadvisors.com
>Subject: Re: [dba-SQLServer] [dba-VB] [AccessD] The first annual 
>Great	Smokey MountainsAccessD Conference
>Date: Tue, 19 Jun 2007 10:34:50 -0700
>
>Is there anyone who is going that will be taking pictures and basically
>recording the proceedings?
>
>If you are; record presenters and presentations; basically try and get the
>flavour of the event... (BBQ).
>
>If anyone going is making PowerPoint presentations please send them along 
>so
>they can be enjoyed later.
>
>I wonder how difficult it would be to create a video feed from the NC
>location? If is was possible then some of us that just can not make it 
>would
>be able to enjoy the event remotely.
>
>Jim
>
>-----Original Message-----
>From: dba-sqlserver-bounces at databaseadvisors.com
>[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Charlotte
>Foust
>Sent: Tuesday, June 19, 2007 9:29 AM
>To: dba-vb at databaseadvisors.com; Access Developers discussion and problem
>solving
>Cc: Discussion of Hardware and Software issues;
>dba-sqlserver at databaseadvisors.com
>Subject: Re: [dba-SQLServer] [dba-VB] [AccessD] The first annual Great
>Smokey MountainsAccessD Conference
>
><sigh> Wish I could join you!
>
>Charlotte
>
>-----Original Message-----
>From: dba-vb-bounces at databaseadvisors.com
>[mailto:dba-vb-bounces at databaseadvisors.com] On Behalf Of Gary Kjos
>Sent: Monday, June 18, 2007 6:07 AM
>To: Access Developers discussion and problem solving
>Cc: Discussion of Hardware and Software issues;
>dba-sqlserver at databaseadvisors.com; dba-vb at databaseadvisors.com
>Subject: Re: [dba-VB] [AccessD] The first annual Great Smokey
>MountainsAccessD Conference
>
>Wish I could be joining you John. The thought of barbeque is making my
>lmouth water. Hope someone will be taking some photos that can be
>shared.
>
>GK
>
>On 6/18/07, jwcolby <jwcolby at colbyconsulting.com> wrote:
> > The first annual Great Smokey Mountains AccessD Conference will be
> > happening this coming Saturday at my house.
> >
> > To get a map to my house, watch for Wrap of course:
> >
> > http://maps.google.com/#utm_campaign=en&utm_source=en-ha-na-us-google-
> > gm&utm
> > _medium=ha&utm_term=map
> >
> > Type in 1723 Twin Pines Dr, Hudson, 28638.  You should get right
> > there.  Of course things are never as they seem.  There are really
> > only two left turns coming south on Horseshoe bend road, the second is
>
> > my drive.  Just remember that.
> >
> > Hudson Weather.  It's looking like high 80s over the weekend.  I do
> > have AC so we will be comfortable inside.
> >
> > http://www.weather.com/weather/local/28638
> >
> > Anyone needing hotels:
> >
> > http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:off
> > icial&
> > channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&
> > sa=X&o
> > i=local_group&resnum=4&ct=image
> >
> > Alternately, down in Hickory:
> >
> > http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:off
> > icial&
> > channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&
> > sa=X&o
> > i=local_group&resnum=4&ct=image
> >
> > Food in Lenoir:
> >
> > http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:off
> > icial&
> > channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&
> > sa=X&o
> > i=local_group&resnum=4&ct=image
> >
> > Food in Hudson:
> >
> > http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:off
> > icial&
> > channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&
> > sa=X&o
> > i=local_group&resnum=4&ct=image
> >
> > Strangely enough (or perhaps not?), a search for "night clubs" in
> > Lenoir, nc turned up nothing, but did show stuff down in Hickory, just
>
> > south of us.  I must admit I have not been to a night club since we
> > moved here so I will not be much help there.
> >
> > http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:off
> > icial&
> > channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&
> > sa=X&o
> > i=local_group&resnum=4&ct=image
> >
> > Churches (lots of Baptists down here).  You will always be welcome at
> > my church, #B - Hudson United Methodist.  I do have enough credit at
> > this point that I can skip if the conference is still going on.
> >
> > http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:off
> > icial&
> > channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&
> > sa=X&o
> > i=local_group&resnum=4&ct=image
> >
> >
> > General NC info:
> >
> > http://www.visitnc.com/tools_search_results.asp
> >
> > http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:off
> > icial&
> > channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&
> > sa=X&o
> > i=local_group&resnum=4&ct=image
> >
> > The plan is to meet at my home on Saturday, and Sunday if there is
> > anyone still here.  Anyone coming in early (Friday evening / night) is
>
> > welcome to call me.  828-572-0120 is my business phone.
> >
> > I will be doing a BBQ Saturday evening after the conference.  The
> > usual suspects - chicken / ribs / etc.  I am pretty good on the BBQ.
> >
> > I am looking forward to seeing you guys, whoever shows up, so let's
> > meet and have a good time - no RSVP required, come on down.
> >
> > John W. Colby
> > Colby Consulting
> > www.ColbyConsulting.com
> >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
>
>
>--
>Gary Kjos
>garykjos at gmail.com
>_______________________________________________
>dba-VB mailing list
>dba-VB at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/dba-vb
>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
>

_________________________________________________________________
Picture this ? share your photos and you could win big!  
http://www.GETREALPhotoContest.com?ocid=TXT_TAGHM&loc=us



From jwcolby at colbyconsulting.com  Wed Jun 20 10:45:56 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Wed, 20 Jun 2007 11:45:56 -0400
Subject: [dba-SQLServer] Building a permanent result table on-the-fly
Message-ID: <20070620154556.D79A5BE73@smtp-auth.no-ip.com>

When a client asks me to fill an order of names from a name table I end up
with a view that looks something like:

SELECT     TOP (3000) [FName], [LName], [Addr], [City], [ST], [Zip5],
[Zip4], [Zip]
FROM         dbo.tblData
ORDER BY NEWID()

This in fact pulls an apparently random set of names which is good, we like
that.  The problem is that I need to record those names because the client
may come back in a month and say "now give me a DIFFERENT set of names".
Thus I need to know who was pulled last time.  What I need is a way to take
any result set and build a permanent table to hold the results in.  I also
need a way to build a m-m with the PKID of the pulled set and an OrderPK
from an order table (which I am building), but I already know how to do
that.

John W. Colby
Colby Consulting
www.ColbyConsulting.com 



From ebarro at verizon.net  Wed Jun 20 10:50:53 2007
From: ebarro at verizon.net (Eric Barro)
Date: Wed, 20 Jun 2007 08:50:53 -0700
Subject: [dba-SQLServer] Building a permanent result table on-the-fly
In-Reply-To: <20070620154556.D79A5BE73@smtp-auth.no-ip.com>
Message-ID: <0JJX002DHYOMCQLK@vms046.mailsrvcs.net>

Why not just flag the records with a datestamp and add that in the criteria
so that it only displays records that have not been pulled from the previous
query? 

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Wednesday, June 20, 2007 8:46 AM
To: dba-sqlserver at databaseadvisors.com
Subject: [dba-SQLServer] Building a permanent result table on-the-fly

When a client asks me to fill an order of names from a name table I end up
with a view that looks something like:

SELECT     TOP (3000) [FName], [LName], [Addr], [City], [ST], [Zip5],
[Zip4], [Zip]
FROM         dbo.tblData
ORDER BY NEWID()

This in fact pulls an apparently random set of names which is good, we like
that.  The problem is that I need to record those names because the client
may come back in a month and say "now give me a DIFFERENT set of names".
Thus I need to know who was pulled last time.  What I need is a way to take
any result set and build a permanent table to hold the results in.  I also
need a way to build a m-m with the PKID of the pulled set and an OrderPK
from an order table (which I am building), but I already know how to do
that.

John W. Colby
Colby Consulting
www.ColbyConsulting.com 

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


 



From jwcolby at colbyconsulting.com  Wed Jun 20 11:06:55 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Wed, 20 Jun 2007 12:06:55 -0400
Subject: [dba-SQLServer] Building a permanent result table on-the-fly
In-Reply-To: <0JJX002DHYOMCQLK@vms046.mailsrvcs.net>
Message-ID: <20070620160655.B6AE6BE92@smtp-auth.no-ip.com>

A variety of reasons:

1) The data may come from several different tables.  For example the data I
am pulling now comes from two different tables, the first is used until they
have all been used, then the second table is used to fill  in the rest.
2) There may be a hundred different orders against any given address table
over the course of a year.
3) In the end the data is often a join of at two and sometimes three
different tables.  For example I have a ZipCodeWorld table with section
codes, joined by Zip on tblAZTFFSmokers (address validated table) joined by
PK on tblTFFSmokers (demographics table).

The end results are ALWAYS pulled from a set of views, joined into at least
one final "order" view.  I do not send my PK or address hash to the client,
they don't need nor want that data in their text file.  But the PK as well
as the name of the table I pulled from needs to be preserved so that I can
filter it back out later.  I am working on that, however what I would like
for now is a simple "stuff the data in a table" thing so that I at least
know what I sent.  This result set comes from a view.  In Access you can use
a query to build a table.  Access somehow discovers the data types and
(mostly) correctly builds a table out of the data set.  I do not know how to
do that in SQL Server.  I suppose I can go do that in Access just to get off
the dime on this, and revisit it next week when the pressure is off.

John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Eric Barro
Sent: Wednesday, June 20, 2007 11:51 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Building a permanent result table on-the-fly

Why not just flag the records with a datestamp and add that in the criteria
so that it only displays records that have not been pulled from the previous
query? 

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Wednesday, June 20, 2007 8:46 AM
To: dba-sqlserver at databaseadvisors.com
Subject: [dba-SQLServer] Building a permanent result table on-the-fly

When a client asks me to fill an order of names from a name table I end up
with a view that looks something like:

SELECT     TOP (3000) [FName], [LName], [Addr], [City], [ST], [Zip5],
[Zip4], [Zip]
FROM         dbo.tblData
ORDER BY NEWID()

This in fact pulls an apparently random set of names which is good, we like
that.  The problem is that I need to record those names because the client
may come back in a month and say "now give me a DIFFERENT set of names".
Thus I need to know who was pulled last time.  What I need is a way to take
any result set and build a permanent table to hold the results in.  I also
need a way to build a m-m with the PKID of the pulled set and an OrderPK
from an order table (which I am building), but I already know how to do
that.

John W. Colby
Colby Consulting
www.ColbyConsulting.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 accessd at shaw.ca  Wed Jun 20 11:22:47 2007
From: accessd at shaw.ca (Jim Lawrence)
Date: Wed, 20 Jun 2007 09:22:47 -0700
Subject: [dba-SQLServer] [dba-VB] [AccessD] The first annual Great
 Smokey MountainsAccessD Conference
In-Reply-To: <BAY127-F2587392EEC9A88C99DDEDED2110@phx.gbl>
Message-ID: <0JJX007D9ZYHYNS0@l-daemon>

Consider yourself the senior camera man.

Jim

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Mark A
Matte
Sent: Wednesday, June 20, 2007 7:32 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] [dba-VB] [AccessD] The first annual Great
Smokey MountainsAccessD Conference

I have a new camera...and (insert self promotion here) some of my picture 
are actually going to be displayed at 2 locations in Greensboro, NC. (end 
self promotion)

I would be more than happy to take pictures of the event.

Thanks,

Mark A. Matte


>From: Jim Lawrence <accessd at shaw.ca>
>Reply-To: dba-sqlserver at databaseadvisors.com
>To: dba-sqlserver at databaseadvisors.com
>Subject: Re: [dba-SQLServer] [dba-VB] [AccessD] The first annual 
>Great	Smokey MountainsAccessD Conference
>Date: Tue, 19 Jun 2007 10:34:50 -0700
>
>Is there anyone who is going that will be taking pictures and basically
>recording the proceedings?
>
>If you are; record presenters and presentations; basically try and get the
>flavour of the event... (BBQ).
>
>If anyone going is making PowerPoint presentations please send them along 
>so
>they can be enjoyed later.
>
>I wonder how difficult it would be to create a video feed from the NC
>location? If is was possible then some of us that just can not make it 
>would
>be able to enjoy the event remotely.
>
>Jim
>
>-----Original Message-----
>From: dba-sqlserver-bounces at databaseadvisors.com
>[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Charlotte
>Foust
>Sent: Tuesday, June 19, 2007 9:29 AM
>To: dba-vb at databaseadvisors.com; Access Developers discussion and problem
>solving
>Cc: Discussion of Hardware and Software issues;
>dba-sqlserver at databaseadvisors.com
>Subject: Re: [dba-SQLServer] [dba-VB] [AccessD] The first annual Great
>Smokey MountainsAccessD Conference
>
><sigh> Wish I could join you!
>
>Charlotte
>
>-----Original Message-----
>From: dba-vb-bounces at databaseadvisors.com
>[mailto:dba-vb-bounces at databaseadvisors.com] On Behalf Of Gary Kjos
>Sent: Monday, June 18, 2007 6:07 AM
>To: Access Developers discussion and problem solving
>Cc: Discussion of Hardware and Software issues;
>dba-sqlserver at databaseadvisors.com; dba-vb at databaseadvisors.com
>Subject: Re: [dba-VB] [AccessD] The first annual Great Smokey
>MountainsAccessD Conference
>
>Wish I could be joining you John. The thought of barbeque is making my
>lmouth water. Hope someone will be taking some photos that can be
>shared.
>
>GK
>
>On 6/18/07, jwcolby <jwcolby at colbyconsulting.com> wrote:
> > The first annual Great Smokey Mountains AccessD Conference will be
> > happening this coming Saturday at my house.
> >
> > To get a map to my house, watch for Wrap of course:
> >
> > http://maps.google.com/#utm_campaign=en&utm_source=en-ha-na-us-google-
> > gm&utm
> > _medium=ha&utm_term=map
> >
> > Type in 1723 Twin Pines Dr, Hudson, 28638.  You should get right
> > there.  Of course things are never as they seem.  There are really
> > only two left turns coming south on Horseshoe bend road, the second is
>
> > my drive.  Just remember that.
> >
> > Hudson Weather.  It's looking like high 80s over the weekend.  I do
> > have AC so we will be comfortable inside.
> >
> > http://www.weather.com/weather/local/28638
> >
> > Anyone needing hotels:
> >
> > http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:off
> > icial&
> > channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&
> > sa=X&o
> > i=local_group&resnum=4&ct=image
> >
> > Alternately, down in Hickory:
> >
> > http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:off
> > icial&
> > channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&
> > sa=X&o
> > i=local_group&resnum=4&ct=image
> >
> > Food in Lenoir:
> >
> > http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:off
> > icial&
> > channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&
> > sa=X&o
> > i=local_group&resnum=4&ct=image
> >
> > Food in Hudson:
> >
> > http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:off
> > icial&
> > channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&
> > sa=X&o
> > i=local_group&resnum=4&ct=image
> >
> > Strangely enough (or perhaps not?), a search for "night clubs" in
> > Lenoir, nc turned up nothing, but did show stuff down in Hickory, just
>
> > south of us.  I must admit I have not been to a night club since we
> > moved here so I will not be much help there.
> >
> > http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:off
> > icial&
> > channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&
> > sa=X&o
> > i=local_group&resnum=4&ct=image
> >
> > Churches (lots of Baptists down here).  You will always be welcome at
> > my church, #B - Hudson United Methodist.  I do have enough credit at
> > this point that I can skip if the conference is still going on.
> >
> > http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:off
> > icial&
> > channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&
> > sa=X&o
> > i=local_group&resnum=4&ct=image
> >
> >
> > General NC info:
> >
> > http://www.visitnc.com/tools_search_results.asp
> >
> > http://maps.google.com/maps?client=firefox-a&rls=org.mozilla:en-US:off
> > icial&
> > channel=s&hl=en&btnG=Google+Search&um=1&q=hotels&near=Lenoir,+NC&fb=1&
> > sa=X&o
> > i=local_group&resnum=4&ct=image
> >
> > The plan is to meet at my home on Saturday, and Sunday if there is
> > anyone still here.  Anyone coming in early (Friday evening / night) is
>
> > welcome to call me.  828-572-0120 is my business phone.
> >
> > I will be doing a BBQ Saturday evening after the conference.  The
> > usual suspects - chicken / ribs / etc.  I am pretty good on the BBQ.
> >
> > I am looking forward to seeing you guys, whoever shows up, so let's
> > meet and have a good time - no RSVP required, come on down.
> >
> > John W. Colby
> > Colby Consulting
> > www.ColbyConsulting.com
> >
> > --
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
>
>
>--
>Gary Kjos
>garykjos at gmail.com
>_______________________________________________
>dba-VB mailing list
>dba-VB at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/dba-vb
>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
>

_________________________________________________________________
Picture this  share your photos and you could win big!  
http://www.GETREALPhotoContest.com?ocid=TXT_TAGHM&loc=us





From dwaters at usinternet.com  Wed Jun 20 11:22:07 2007
From: dwaters at usinternet.com (Dan Waters)
Date: Wed, 20 Jun 2007 11:22:07 -0500
Subject: [dba-SQLServer] Building a permanent result table on-the-fly
In-Reply-To: <20070620154556.D79A5BE73@smtp-auth.no-ip.com>
References: <20070620154556.D79A5BE73@smtp-auth.no-ip.com>
Message-ID: <002c01c7b357$25b3de60$0200a8c0@danwaters>

John,

Could you add a date field to the table with names - where that date field
records when that name was pulled last?  Or if you want to record all the
times a name was pulled then a small subtable might work.  Perhaps?

Dan

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Wednesday, June 20, 2007 10:46 AM
To: dba-sqlserver at databaseadvisors.com
Subject: [dba-SQLServer] Building a permanent result table on-the-fly

When a client asks me to fill an order of names from a name table I end up
with a view that looks something like:

SELECT     TOP (3000) [FName], [LName], [Addr], [City], [ST], [Zip5],
[Zip4], [Zip]
FROM         dbo.tblData
ORDER BY NEWID()

This in fact pulls an apparently random set of names which is good, we like
that.  The problem is that I need to record those names because the client
may come back in a month and say "now give me a DIFFERENT set of names".
Thus I need to know who was pulled last time.  What I need is a way to take
any result set and build a permanent table to hold the results in.  I also
need a way to build a m-m with the PKID of the pulled set and an OrderPK
from an order table (which I am building), but I already know how to do
that.

John W. Colby
Colby Consulting
www.ColbyConsulting.com 

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














































































































































































From fuller.artful at gmail.com  Wed Jun 20 11:28:52 2007
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Wed, 20 Jun 2007 12:28:52 -0400
Subject: [dba-SQLServer] Building a permanent result table on-the-fly
In-Reply-To: <20070620160655.B6AE6BE92@smtp-auth.no-ip.com>
References: <0JJX002DHYOMCQLK@vms046.mailsrvcs.net>
	<20070620160655.B6AE6BE92@smtp-auth.no-ip.com>
Message-ID: <29f585dd0706200928t141fe879we9d553401d86c44b@mail.gmail.com>

INSERT INTO <newTable>
SELECT x, y, z FROM <yourFinalOrderView>

(assuming that all the desired filtering etc. has already been done by the
time we get to yourFinalOrderView.)

It would be good to have unique keys not dependent upon NewID(), in which
case the selection of a bunch of new folks not previously included is: Outer
Join on the keys and criteria = "WHERE oldBatch.ID IS NULL".

Unless I misunderstood your requirement.

Assuming that I am right... no, wait, I will wait for confirmation on that
hypothesis before continuing.

A.

On 6/20/07, jwcolby <jwcolby at colbyconsulting.com> wrote:
>
> A variety of reasons:
>
> 1) The data may come from several different tables.  For example the data
> I
> am pulling now comes from two different tables, the first is used until
> they
> have all been used, then the second table is used to fill  in the rest.
> 2) There may be a hundred different orders against any given address table
> over the course of a year.
> 3) In the end the data is often a join of at two and sometimes three
> different tables.  For example I have a ZipCodeWorld table with section
> codes, joined by Zip on tblAZTFFSmokers (address validated table) joined
> by
> PK on tblTFFSmokers (demographics table).
>
> The end results are ALWAYS pulled from a set of views, joined into at
> least
> one final "order" view.  I do not send my PK or address hash to the
> client,
> they don't need nor want that data in their text file.  But the PK as well
> as the name of the table I pulled from needs to be preserved so that I can
> filter it back out later.  I am working on that, however what I would like
> for now is a simple "stuff the data in a table" thing so that I at least
> know what I sent.  This result set comes from a view.  In Access you can
> use
> a query to build a table.  Access somehow discovers the data types and
> (mostly) correctly builds a table out of the data set.  I do not know how
> to
> do that in SQL Server.  I suppose I can go do that in Access just to get
> off
> the dime on this, and revisit it next week when the pressure is off.
>
> John W. Colby
> Colby Consulting
> www.ColbyConsulting.com
> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Eric
> Barro
> Sent: Wednesday, June 20, 2007 11:51 AM
> To: dba-sqlserver at databaseadvisors.com
> Subject: Re: [dba-SQLServer] Building a permanent result table on-the-fly
>
> Why not just flag the records with a datestamp and add that in the
> criteria
> so that it only displays records that have not been pulled from the
> previous
> query?
>
> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of jwcolby
> Sent: Wednesday, June 20, 2007 8:46 AM
> To: dba-sqlserver at databaseadvisors.com
> Subject: [dba-SQLServer] Building a permanent result table on-the-fly
>
> When a client asks me to fill an order of names from a name table I end up
> with a view that looks something like:
>
> SELECT     TOP (3000) [FName], [LName], [Addr], [City], [ST], [Zip5],
> [Zip4], [Zip]
> FROM         dbo.tblData
> ORDER BY NEWID()
>
> This in fact pulls an apparently random set of names which is good, we
> like
> that.  The problem is that I need to record those names because the client
> may come back in a month and say "now give me a DIFFERENT set of names".
> Thus I need to know who was pulled last time.  What I need is a way to
> take
> any result set and build a permanent table to hold the results in.  I also
> need a way to build a m-m with the PKID of the pulled set and an OrderPK
> from an order table (which I am building), but I already know how to do
> that.
>
> John W. Colby
> Colby Consulting
> www.ColbyConsulting.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 rl_stewart at highstream.net  Wed Jun 20 11:27:18 2007
From: rl_stewart at highstream.net (Robert)
Date: Wed, 20 Jun 2007 11:27:18 -0500
Subject: [dba-SQLServer] Building a permanent result table on-the-fly
In-Reply-To: <mailman.4624.1182356384.14721.dba-sqlserver@databaseadviso
	rs.com>
References: <mailman.4624.1182356384.14721.dba-sqlserver@databaseadvisors.com>
Message-ID: <200706201630.l5KGUM3C027552@databaseadvisors.com>

Off the top of my head...

SELECT INTO NewTable
TOP (3000) [FName], [LName], [Addr], [City], [ST], [Zip5],
[Zip4], [Zip]
FROM         dbo.tblData
ORDER BY NEWID()

Robert

At 11:19 AM 6/20/2007, you wrote:
>Date: Wed, 20 Jun 2007 11:45:56 -0400
>From: "jwcolby" <jwcolby at colbyconsulting.com>
>Subject: [dba-SQLServer] Building a permanent result table on-the-fly
>To: <dba-sqlserver at databaseadvisors.com>
>Message-ID: <20070620154556.D79A5BE73 at smtp-auth.no-ip.com>
>Content-Type: text/plain;       charset="us-ascii"
>
>When a client asks me to fill an order of names from a name table I end up
>with a view that looks something like:
>
>SELECT     TOP (3000) [FName], [LName], [Addr], [City], [ST], [Zip5],
>[Zip4], [Zip]
>FROM         dbo.tblData
>ORDER BY NEWID()
>
>This in fact pulls an apparently random set of names which is good, we like
>that.  The problem is that I need to record those names because the client
>may come back in a month and say "now give me a DIFFERENT set of names".
>Thus I need to know who was pulled last time.  What I need is a way to take
>any result set and build a permanent table to hold the results in.  I also
>need a way to build a m-m with the PKID of the pulled set and an OrderPK
>from an order table (which I am building), but I already know how to do
>that.
>
>John W. Colby




From fuller.artful at gmail.com  Wed Jun 20 11:32:31 2007
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Wed, 20 Jun 2007 12:32:31 -0400
Subject: [dba-SQLServer] Building a permanent result table on-the-fly
In-Reply-To: <29f585dd0706200928t141fe879we9d553401d86c44b@mail.gmail.com>
References: <0JJX002DHYOMCQLK@vms046.mailsrvcs.net>
	<20070620160655.B6AE6BE92@smtp-auth.no-ip.com>
	<29f585dd0706200928t141fe879we9d553401d86c44b@mail.gmail.com>
Message-ID: <29f585dd0706200932o1eb39e0en8d38a9072d8afa4e@mail.gmail.com>

I think Dan has a point, and it exposes a possible weakness in my proffered
solution: I'm restricted to "not in the last batch" whereas Dan's approach
can exclude anyone who participated in any previous batch.

A.

On 6/20/07, Arthur Fuller <fuller.artful at gmail.com> wrote:
>
> INSERT INTO <newTable>
> SELECT x, y, z FROM <yourFinalOrderView>
>
> (assuming that all the desired filtering etc. has already been done by the
> time we get to yourFinalOrderView.)
>
> It would be good to have unique keys not dependent upon NewID(), in which
> case the selection of a bunch of new folks not previously included is: Outer
> Join on the keys and criteria = "WHERE oldBatch.ID IS NULL".
>
> Unless I misunderstood your requirement.
>
> Assuming that I am right... no, wait, I will wait for confirmation on that
> hypothesis before continuing.
>
> A.
>
> On 6/20/07, jwcolby <jwcolby at colbyconsulting.com> wrote:
> >
> > A variety of reasons:
> >
> > 1) The data may come from several different tables.  For example the
> > data I
> > am pulling now comes from two different tables, the first is used until
> > they
> > have all been used, then the second table is used to fill  in the rest.
> > 2) There may be a hundred different orders against any given address
> > table
> > over the course of a year.
> > 3) In the end the data is often a join of at two and sometimes three
> > different tables.  For example I have a ZipCodeWorld table with section
> > codes, joined by Zip on tblAZTFFSmokers (address validated table) joined
> > by
> > PK on tblTFFSmokers (demographics table).
> >
> > The end results are ALWAYS pulled from a set of views, joined into at
> > least
> > one final "order" view.  I do not send my PK or address hash to the
> > client,
> > they don't need nor want that data in their text file.  But the PK as
> > well
> > as the name of the table I pulled from needs to be preserved so that I
> > can
> > filter it back out later.  I am working on that, however what I would
> > like
> > for now is a simple "stuff the data in a table" thing so that I at least
> > know what I sent.  This result set comes from a view.  In Access you can
> > use
> > a query to build a table.  Access somehow discovers the data types and
> > (mostly) correctly builds a table out of the data set.  I do not know
> > how to
> > do that in SQL Server.  I suppose I can go do that in Access just to get
> > off
> > the dime on this, and revisit it next week when the pressure is off.
> >
> > John W. Colby
> > Colby Consulting
> > www.ColbyConsulting.com
> > -----Original Message-----
> > From: dba-sqlserver-bounces at databaseadvisors.com
> > [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Eric
> > Barro
> > Sent: Wednesday, June 20, 2007 11:51 AM
> > To: dba-sqlserver at databaseadvisors.com
> > Subject: Re: [dba-SQLServer] Building a permanent result table
> > on-the-fly
> >
> > Why not just flag the records with a datestamp and add that in the
> > criteria
> > so that it only displays records that have not been pulled from the
> > previous
> > query?
> >
> > -----Original Message-----
> > From: dba-sqlserver-bounces at databaseadvisors.com
> > [mailto: dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of
> > jwcolby
> > Sent: Wednesday, June 20, 2007 8:46 AM
> > To: dba-sqlserver at databaseadvisors.com
> > Subject: [dba-SQLServer] Building a permanent result table on-the-fly
> >
> > When a client asks me to fill an order of names from a name table I end
> > up
> > with a view that looks something like:
> >
> > SELECT     TOP (3000) [FName], [LName], [Addr], [City], [ST], [Zip5],
> > [Zip4], [Zip]
> > FROM         dbo.tblData
> > ORDER BY NEWID()
> >
> > This in fact pulls an apparently random set of names which is good, we
> > like
> > that.  The problem is that I need to record those names because the
> > client
> > may come back in a month and say "now give me a DIFFERENT set of names".
> >
> > Thus I need to know who was pulled last time.  What I need is a way to
> > take
> > any result set and build a permanent table to hold the results in.  I
> > also
> > need a way to build a m-m with the PKID of the pulled set and an OrderPK
> >
> > from an order table (which I am building), but I already know how to do
> > that.
> >
> > John W. Colby
> > Colby Consulting
> > www.ColbyConsulting.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 jwcolby at colbyconsulting.com  Wed Jun 20 13:43:25 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Wed, 20 Jun 2007 14:43:25 -0400
Subject: [dba-SQLServer] Building a permanent result table on-the-fly
In-Reply-To: <29f585dd0706200928t141fe879we9d553401d86c44b@mail.gmail.com>
Message-ID: <20070620184325.0D4D7BE11@smtp-auth.no-ip.com>

tblOrder does not exist.  I get an error saying Invalid object name
'tblOrder'.

I have just done it in Access, took about 10 minutes from setup of the db
through export of the text file.  AND... The export spec is saved for the
next one.

When you just gotta get it done, right now, use Access. 


John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Arthur
Fuller
Sent: Wednesday, June 20, 2007 12:29 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Building a permanent result table on-the-fly

INSERT INTO <newTable>
SELECT x, y, z FROM <yourFinalOrderView>

(assuming that all the desired filtering etc. has already been done by the
time we get to yourFinalOrderView.)

It would be good to have unique keys not dependent upon NewID(), in which
case the selection of a bunch of new folks not previously included is: Outer
Join on the keys and criteria = "WHERE oldBatch.ID IS NULL".

Unless I misunderstood your requirement.

Assuming that I am right... no, wait, I will wait for confirmation on that
hypothesis before continuing.

A.

On 6/20/07, jwcolby <jwcolby at colbyconsulting.com> wrote:
>
> A variety of reasons:
>
> 1) The data may come from several different tables.  For example the 
> data I am pulling now comes from two different tables, the first is 
> used until they have all been used, then the second table is used to 
> fill  in the rest.
> 2) There may be a hundred different orders against any given address 
> table over the course of a year.
> 3) In the end the data is often a join of at two and sometimes three 
> different tables.  For example I have a ZipCodeWorld table with 
> section codes, joined by Zip on tblAZTFFSmokers (address validated 
> table) joined by PK on tblTFFSmokers (demographics table).
>
> The end results are ALWAYS pulled from a set of views, joined into at 
> least one final "order" view.  I do not send my PK or address hash to 
> the client, they don't need nor want that data in their text file.  
> But the PK as well as the name of the table I pulled from needs to be 
> preserved so that I can filter it back out later.  I am working on 
> that, however what I would like for now is a simple "stuff the data in 
> a table" thing so that I at least know what I sent.  This result set 
> comes from a view.  In Access you can use a query to build a table.  
> Access somehow discovers the data types and
> (mostly) correctly builds a table out of the data set.  I do not know 
> how to do that in SQL Server.  I suppose I can go do that in Access 
> just to get off the dime on this, and revisit it next week when the 
> pressure is off.
>
> John W. Colby
> Colby Consulting
> www.ColbyConsulting.com
> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Eric 
> Barro
> Sent: Wednesday, June 20, 2007 11:51 AM
> To: dba-sqlserver at databaseadvisors.com
> Subject: Re: [dba-SQLServer] Building a permanent result table 
> on-the-fly
>
> Why not just flag the records with a datestamp and add that in the 
> criteria so that it only displays records that have not been pulled 
> from the previous query?
>
> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of 
> jwcolby
> Sent: Wednesday, June 20, 2007 8:46 AM
> To: dba-sqlserver at databaseadvisors.com
> Subject: [dba-SQLServer] Building a permanent result table on-the-fly
>
> When a client asks me to fill an order of names from a name table I 
> end up with a view that looks something like:
>
> SELECT     TOP (3000) [FName], [LName], [Addr], [City], [ST], [Zip5],
> [Zip4], [Zip]
> FROM         dbo.tblData
> ORDER BY NEWID()
>
> This in fact pulls an apparently random set of names which is good, we 
> like that.  The problem is that I need to record those names because 
> the client may come back in a month and say "now give me a DIFFERENT 
> set of names".
> Thus I need to know who was pulled last time.  What I need is a way to 
> take any result set and build a permanent table to hold the results 
> in.  I also need a way to build a m-m with the PKID of the pulled set 
> and an OrderPK from an order table (which I am building), but I 
> already know how to do that.
>
> John W. Colby
> Colby Consulting
> www.ColbyConsulting.com
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>
>
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com



From fuller.artful at gmail.com  Wed Jun 20 14:59:45 2007
From: fuller.artful at gmail.com (Arthur Fuller)
Date: Wed, 20 Jun 2007 15:59:45 -0400
Subject: [dba-SQLServer] Third conference?
Message-ID: <29f585dd0706201259g16f5d807n2c9ac3b9300dac7a@mail.gmail.com>

(A confession which is probably off-topic: in 1968 I was convicted of
possessing some LSD. I was convicted. Five years later I was pardoned. I
haven't been remotely near anything like that since about 1970. However, a
pardon in Canada does not constitute erasure from the databases in USA, with
the result that I cannot attend any of these conferences, much as I would
love to.)

I wonder if there might be any interest in a conference held in Canada. I
live in Mississauga, Ontario. There are hotels nearby. I have space in which
to hold our various presentations. Mississauga, Ontario is .5 hours from
Toronto, the most multi-cultural city in the world (not my claim alone, this
is pretty much universally accepted). Where I live it is very quiet, but I
have parking to suit 100 (ask JC).

It would be fun to host a bunch of you here. I don't want to intrude upon
the prospective schedule, but perhaps a few of you would like to visit this
part of the world for a bit.

A


From carbonnb at gmail.com  Wed Jun 20 15:04:49 2007
From: carbonnb at gmail.com (Bryan Carbonnell)
Date: Wed, 20 Jun 2007 16:04:49 -0400
Subject: [dba-SQLServer] [dba-Tech] Third conference?
In-Reply-To: <29f585dd0706201259g16f5d807n2c9ac3b9300dac7a@mail.gmail.com>
References: <29f585dd0706201259g16f5d807n2c9ac3b9300dac7a@mail.gmail.com>
Message-ID: <e04a6c920706201304h54d14674xc38a3d060fb04275@mail.gmail.com>

Lets try this again with a copy to the appropriate places.

On 6/20/07, Arthur Fuller <fuller.artful at gmail.com> wrote:

> I wonder if there might be any interest in a conference held in Canada. I
> live in Mississauga, Ontario. There are hotels nearby. I have space in which

Hell yea. I even suggested something like this a few years back.

If it got too big, I know of a classroom that can hold 14 folks.

I could even probably rustle up a classroom with 10 +1 workstations :)

-- 
Bryan Carbonnell - carbonnb at gmail.com
Life's journey is not to arrive at the grave safely in a well
preserved body, but rather to skid in sideways, totally worn out,
shouting "What a great ride!"


From jwcolby at colbyconsulting.com  Fri Jun 22 17:10:03 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Fri, 22 Jun 2007 18:10:03 -0400
Subject: [dba-SQLServer] VB.Net / SQl Server 2005 - Export file generator
Message-ID: <20070622221004.4B83CBD4A@smtp-auth.no-ip.com>

I need to export all of the records from my list tables out for address
validation, periodically.  Thus I need to be able to specify the source
table, the size (number of records) each file will contain, the number of
records exported etc.

In order to accomplish this I am building a VB.Net application to allow me
to export specific fields of a specific table into files of size X records.
All of the parameters are in tables that I create.  I have it working now,
and it is now dumping the name / address fields from 99 million records, out
to 1 million record files.  It is interesting to note (and the reason for
this email) that getting the data from SQL Server is the slowest part.  I am
building up a query dynamically (yea, I know I should be using a stored
procedure with parameters, that will follow) with the name of the table, the
field names to pull, and the start PKID and end PKIDs.  VB.Net is having
waitlock issues if the time to get the records is too large so I broke it
down to 100K record sets, then export 10 of those recordsets into a single
file.  In average, 100K records is taking about 20-25 seconds to return the
datasets, and then the VB.Net code that writes the file can write the data
out to the file in about 2 seconds.  So on average I am getting a million
record file built in about 100-120 seconds.  My program creates a unique
name for each file and dumps them in a directory specified in the an export
spec table.

This is the second piece of the big picture where a set of data files is
imported in to sql server, then immediately dumped back out for address
validation (this piece) then imported back in to SQL Server for use.  This
same piece will later be used to periodically dump the data tables that have
already been address validated back out to be validated again (NCOAs).  When
finished, this process will run automatically every week (or other time
period I specify) to dump every one of my tables out for a periodic address
(NCOA) validation.

Without automation this process is immensely time intensive, but with
automation it will be... Well... Automatic, with little or no manual
intervention.  So part two is complete, just a few tweaks left (logging
results and such).

John W. Colby
Colby Consulting
www.ColbyConsulting.com 



From davidmcafee at gmail.com  Fri Jun 22 17:34:29 2007
From: davidmcafee at gmail.com (David McAfee)
Date: Fri, 22 Jun 2007 15:34:29 -0700
Subject: [dba-SQLServer] VB.Net / SQl Server 2005 - Export file generator
In-Reply-To: <20070622221004.4B83CBD4A@smtp-auth.no-ip.com>
References: <20070622221004.4B83CBD4A@smtp-auth.no-ip.com>
Message-ID: <8786a4c00706221534u27ff3f23h8e0a7ecfe3486ae1@mail.gmail.com>

John, are you using "NOLOCK" on your selects?

SELECT * FROM tblPeople WITH (NOLOCK)

and yes, try to use stored procedures whenever possible.



On 6/22/07, jwcolby <jwcolby at colbyconsulting.com> wrote:
>
> I need to export all of the records from my list tables out for address
> validation, periodically.  Thus I need to be able to specify the source
> table, the size (number of records) each file will contain, the number of
> records exported etc.
>
> In order to accomplish this I am building a VB.Net application to allow me
> to export specific fields of a specific table into files of size X
> records.
> All of the parameters are in tables that I create.  I have it working now,
> and it is now dumping the name / address fields from 99 million records,
> out
> to 1 million record files.  It is interesting to note (and the reason for
> this email) that getting the data from SQL Server is the slowest part.  I
> am
> building up a query dynamically (yea, I know I should be using a stored
> procedure with parameters, that will follow) with the name of the table,
> the
> field names to pull, and the start PKID and end PKIDs.  VB.Net is having
> waitlock issues if the time to get the records is too large so I broke it
> down to 100K record sets, then export 10 of those recordsets into a single
> file.  In average, 100K records is taking about 20-25 seconds to return
> the
> datasets, and then the VB.Net code that writes the file can write the data
> out to the file in about 2 seconds.  So on average I am getting a million
> record file built in about 100-120 seconds.  My program creates a unique
> name for each file and dumps them in a directory specified in the an
> export
> spec table.
>
> This is the second piece of the big picture where a set of data files is
> imported in to sql server, then immediately dumped back out for address
> validation (this piece) then imported back in to SQL Server for use.  This
> same piece will later be used to periodically dump the data tables that
> have
> already been address validated back out to be validated again
> (NCOAs).  When
> finished, this process will run automatically every week (or other time
> period I specify) to dump every one of my tables out for a periodic
> address
> (NCOA) validation.
>
> Without automation this process is immensely time intensive, but with
> automation it will be... Well... Automatic, with little or no manual
> intervention.  So part two is complete, just a few tweaks left (logging
> results and such).
>
> John W. Colby
> Colby Consulting
> www.ColbyConsulting.com
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>


From ebarro at verizon.net  Fri Jun 22 17:56:04 2007
From: ebarro at verizon.net (Eric Barro)
Date: Fri, 22 Jun 2007 15:56:04 -0700
Subject: [dba-SQLServer] [dba-VB] VB.Net / SQl Server 2005 - Export file
	generator
In-Reply-To: <20070622221004.4B83CBD4A@smtp-auth.no-ip.com>
Message-ID: <0JK200INB7PHAZTI@vms042.mailsrvcs.net>

Are you using OleDB or the native SQL client driver to interface with SQL
server? 

-----Original Message-----
From: dba-vb-bounces at databaseadvisors.com
[mailto:dba-vb-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Friday, June 22, 2007 3:10 PM
To: dba-sqlserver at databaseadvisors.com; dba-vb at databaseadvisors.com
Subject: [dba-VB] VB.Net / SQl Server 2005 - Export file generator

I need to export all of the records from my list tables out for address
validation, periodically.  Thus I need to be able to specify the source
table, the size (number of records) each file will contain, the number of
records exported etc.

In order to accomplish this I am building a VB.Net application to allow me
to export specific fields of a specific table into files of size X records.
All of the parameters are in tables that I create.  I have it working now,
and it is now dumping the name / address fields from 99 million records, out
to 1 million record files.  It is interesting to note (and the reason for
this email) that getting the data from SQL Server is the slowest part.  I am
building up a query dynamically (yea, I know I should be using a stored
procedure with parameters, that will follow) with the name of the table, the
field names to pull, and the start PKID and end PKIDs.  VB.Net is having
waitlock issues if the time to get the records is too large so I broke it
down to 100K record sets, then export 10 of those recordsets into a single
file.  In average, 100K records is taking about 20-25 seconds to return the
datasets, and then the VB.Net code that writes the file can write the data
out to the file in about 2 seconds.  So on average I am getting a million
record file built in about 100-120 seconds.  My program creates a unique
name for each file and dumps them in a directory specified in the an export
spec table.

This is the second piece of the big picture where a set of data files is
imported in to sql server, then immediately dumped back out for address
validation (this piece) then imported back in to SQL Server for use.  This
same piece will later be used to periodically dump the data tables that have
already been address validated back out to be validated again (NCOAs).  When
finished, this process will run automatically every week (or other time
period I specify) to dump every one of my tables out for a periodic address
(NCOA) validation.

Without automation this process is immensely time intensive, but with
automation it will be... Well... Automatic, with little or no manual
intervention.  So part two is complete, just a few tweaks left (logging
results and such).

John W. Colby
Colby Consulting
www.ColbyConsulting.com 

_______________________________________________
dba-VB mailing list
dba-VB at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-vb
http://www.databaseadvisors.com


 



From jwcolby at colbyconsulting.com  Fri Jun 22 20:28:49 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Fri, 22 Jun 2007 21:28:49 -0400
Subject: [dba-SQLServer] [dba-VB] VB.Net / SQl Server 2005 - Export
	filegenerator
In-Reply-To: <0JK200INB7PHAZTI@vms042.mailsrvcs.net>
Message-ID: <20070623012850.0C9E9BC9E@smtp-auth.no-ip.com>

>Are you using OleDB or the native SQL client driver to interface with SQL
server? 

That is a good question...

"Provider=SQLOLEDB;Data Source = Azul;Initial Catalog = PSM;Integrated
Security=SSPI"

I assume that is OLEDB.
 


John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Eric Barro
Sent: Friday, June 22, 2007 6:56 PM
To: dba-vb at databaseadvisors.com; dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] [dba-VB] VB.Net / SQl Server 2005 - Export
filegenerator

Are you using OleDB or the native SQL client driver to interface with SQL
server? 

-----Original Message-----
From: dba-vb-bounces at databaseadvisors.com
[mailto:dba-vb-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Friday, June 22, 2007 3:10 PM
To: dba-sqlserver at databaseadvisors.com; dba-vb at databaseadvisors.com
Subject: [dba-VB] VB.Net / SQl Server 2005 - Export file generator

I need to export all of the records from my list tables out for address
validation, periodically.  Thus I need to be able to specify the source
table, the size (number of records) each file will contain, the number of
records exported etc.

In order to accomplish this I am building a VB.Net application to allow me
to export specific fields of a specific table into files of size X records.
All of the parameters are in tables that I create.  I have it working now,
and it is now dumping the name / address fields from 99 million records, out
to 1 million record files.  It is interesting to note (and the reason for
this email) that getting the data from SQL Server is the slowest part.  I am
building up a query dynamically (yea, I know I should be using a stored
procedure with parameters, that will follow) with the name of the table, the
field names to pull, and the start PKID and end PKIDs.  VB.Net is having
waitlock issues if the time to get the records is too large so I broke it
down to 100K record sets, then export 10 of those recordsets into a single
file.  In average, 100K records is taking about 20-25 seconds to return the
datasets, and then the VB.Net code that writes the file can write the data
out to the file in about 2 seconds.  So on average I am getting a million
record file built in about 100-120 seconds.  My program creates a unique
name for each file and dumps them in a directory specified in the an export
spec table.

This is the second piece of the big picture where a set of data files is
imported in to sql server, then immediately dumped back out for address
validation (this piece) then imported back in to SQL Server for use.  This
same piece will later be used to periodically dump the data tables that have
already been address validated back out to be validated again (NCOAs).  When
finished, this process will run automatically every week (or other time
period I specify) to dump every one of my tables out for a periodic address
(NCOA) validation.

Without automation this process is immensely time intensive, but with
automation it will be... Well... Automatic, with little or no manual
intervention.  So part two is complete, just a few tweaks left (logging
results and such).

John W. Colby
Colby Consulting
www.ColbyConsulting.com 

_______________________________________________
dba-VB mailing list
dba-VB at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-vb
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 jwcolby at colbyconsulting.com  Fri Jun 22 20:51:08 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Fri, 22 Jun 2007 21:51:08 -0400
Subject: [dba-SQLServer] VB.Net / SQl Server 2005 - Export file generator
In-Reply-To: <8786a4c00706221534u27ff3f23h8e0a7ecfe3486ae1@mail.gmail.com>
Message-ID: <20070623015108.BA42DBC93@smtp-auth.no-ip.com>

NOLOCK makes no apparent difference.  It also says in books online that
nolock is the default for a select so it really might not make any
difference. 


John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of David
McAfee
Sent: Friday, June 22, 2007 6:34 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] VB.Net / SQl Server 2005 - Export file
generator

John, are you using "NOLOCK" on your selects?

SELECT * FROM tblPeople WITH (NOLOCK)

and yes, try to use stored procedures whenever possible.



On 6/22/07, jwcolby <jwcolby at colbyconsulting.com> wrote:
>
> I need to export all of the records from my list tables out for 
> address validation, periodically.  Thus I need to be able to specify 
> the source table, the size (number of records) each file will contain, 
> the number of records exported etc.
>
> In order to accomplish this I am building a VB.Net application to 
> allow me to export specific fields of a specific table into files of 
> size X records.
> All of the parameters are in tables that I create.  I have it working 
> now, and it is now dumping the name / address fields from 99 million 
> records, out to 1 million record files.  It is interesting to note 
> (and the reason for this email) that getting the data from SQL Server 
> is the slowest part.  I am building up a query dynamically (yea, I 
> know I should be using a stored procedure with parameters, that will 
> follow) with the name of the table, the field names to pull, and the 
> start PKID and end PKIDs.  VB.Net is having waitlock issues if the 
> time to get the records is too large so I broke it down to 100K record 
> sets, then export 10 of those recordsets into a single file.  In 
> average, 100K records is taking about 20-25 seconds to return the 
> datasets, and then the VB.Net code that writes the file can write the 
> data out to the file in about 2 seconds.  So on average I am getting a 
> million record file built in about 100-120 seconds.  My program 
> creates a unique name for each file and dumps them in a directory 
> specified in the an export spec table.
>
> This is the second piece of the big picture where a set of data files 
> is imported in to sql server, then immediately dumped back out for 
> address validation (this piece) then imported back in to SQL Server 
> for use.  This same piece will later be used to periodically dump the 
> data tables that have already been address validated back out to be 
> validated again (NCOAs).  When finished, this process will run 
> automatically every week (or other time period I specify) to dump 
> every one of my tables out for a periodic address
> (NCOA) validation.
>
> Without automation this process is immensely time intensive, but with 
> automation it will be... Well... Automatic, with little or no manual 
> intervention.  So part two is complete, just a few tweaks left 
> (logging results and such).
>
> John W. Colby
> Colby Consulting
> www.ColbyConsulting.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 accessd at shaw.ca  Mon Jun 25 13:28:56 2007
From: accessd at shaw.ca (Jim Lawrence)
Date: Mon, 25 Jun 2007 11:28:56 -0700
Subject: [dba-SQLServer] Conference
In-Reply-To: <s67fe70a.045@cactus.dk>
Message-ID: <0JK700K5WF4O1XT1@l-daemon>


How did the Access Conference go? 

All those that attended please send along comments, photos, essays, power
point presentations etc... and they will be edited and posted.

Thanks

Regards
Jim Lawrence  



From jwcolby at colbyconsulting.com  Tue Jun 26 08:49:47 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Tue, 26 Jun 2007 09:49:47 -0400
Subject: [dba-SQLServer] Second bi-annual Greater Smokey Mountain AccessD
	Conference
Message-ID: <20070626134948.D4BCFBDD9@smtp-auth.no-ip.com>

The first bi-annual Greater Smokey Mountain AccessD Conference was a
smashing success.  Geek talk, getting together to discuss whatever access /
database subjects popped to mind, meeting each other in person.  I enjoyed
it thoroughly.

Planning has begun on the Second bi-annual Greater Smokey Mountain AccessD
Conference.  I need input on dates in the fall that work for people.  This
is North Carolina we are discussing so it will probably be nice weather up
through the end of September.  And of course if you come from Canada or the
other far north reaches you might well consider it nice weather even in
January.  In fact I find it to be very nice even in January.

So anyone who would like to attend a conference here, throw out some dates
or date ranges.

Thanks,

John W. Colby
Colby Consulting
www.ColbyConsulting.com 



From jengross at gte.net  Tue Jun 26 10:03:22 2007
From: jengross at gte.net (Jennifer Gross)
Date: Tue, 26 Jun 2007 08:03:22 -0700
Subject: [dba-SQLServer] Viewing and Modifying stored procedures
Message-ID: <00b901c7b803$26f82dc0$6501a8c0@jefferson>

Hi All,

I am brand new to SQL Server - using 2005.  I am tasked to make changes
to a db developed by someone else.  For the life of me I cannot figure
out how to view a stored procedure and modify it.  Using Management
Studio I was hoping that a right click would yield an Open or Design
option - but no luck.  Do I have to modify via T-SQL or is there an
editing window I can use?

Thanks in advance,

Jennifer Gross
databasics
2839 Shirley Drive
Newbury Park, CA 91320-3068
office:  (805) 480-1921
fax:	   (805) 499-0467 




From paul.hartland at fsmail.net  Tue Jun 26 10:13:24 2007
From: paul.hartland at fsmail.net (paul.hartland at fsmail.net)
Date: Tue, 26 Jun 2007 17:13:24 +0200 (CEST)
Subject: [dba-SQLServer] Viewing and Modifying stored procedures
Message-ID: <26889175.2089051182870804030.JavaMail.www@wwinf3206>

Jennifer

One of the folders inside your database should be called programability, in there you will find the stored procedures, then I am sure (bit rusty, as not used it in a while) you should be able to right click and modify it.  Hope this helps as I haven't really had much chance myself to play with 2005

Paul 







Message Received: Jun 26 2007, 04:04 PM
From: "Jennifer Gross" 
To: "SQL Server List" 
Cc: 
Subject: [dba-SQLServer] Viewing and Modifying stored procedures

Hi All,

I am brand new to SQL Server - using 2005. I am tasked to make changes
to a db developed by someone else. For the life of me I cannot figure
out how to view a stored procedure and modify it. Using Management
Studio I was hoping that a right click would yield an Open or Design
option - but no luck. Do I have to modify via T-SQL or is there an
editing window I can use?

Thanks in advance,

Jennifer Gross
databasics
2839 Shirley Drive
Newbury Park, CA 91320-3068
office: (805) 480-1921
fax: (805) 499-0467 


_______________________________________________
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 fsmail.net
07730 523179

From jwcolby at colbyconsulting.com  Tue Jun 26 10:22:49 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Tue, 26 Jun 2007 11:22:49 -0400
Subject: [dba-SQLServer] Interesting article - Oracle "lite" benchmarks
Message-ID: <20070626152250.C1B4BBFF4@smtp-auth.no-ip.com>

The article claims that Oracle is bundling their own Linux and their free
version of Oracle so you can get a "free" database going, even down to the
OS.  Of course the article states that Oracle is so huge that it requires
8gb of RAM to work well.  But memory is cheap right now.

http://www.informationweek.com/news/showArticle.jhtml?articleID=199903273

John W. Colby
Colby Consulting
www.ColbyConsulting.com 



From jengross at gte.net  Tue Jun 26 10:56:01 2007
From: jengross at gte.net (Jennifer Gross)
Date: Tue, 26 Jun 2007 08:56:01 -0700
Subject: [dba-SQLServer] Viewing and Modifying stored procedures
In-Reply-To: <26889175.2089051182870804030.JavaMail.www@wwinf3206>
Message-ID: <00ca01c7b80a$82325970$6501a8c0@jefferson>

Hi Paul,

This is what I hoped as well, but it doesn't seem to be the case.  The
right click menu gives me the option to script a modification, or script
a re-creation of the stored procedure, plus some other stuff.  But I am
not seeing a way to just open the stored procedure, see the code, modify
it and save it again.

Jennifer

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of
paul.hartland at fsmail.net
Sent: Tuesday, June 26, 2007 8:13 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures
Importance: High


Jennifer

One of the folders inside your database should be called programability,
in there you will find the stored procedures, then I am sure (bit rusty,
as not used it in a while) you should be able to right click and modify
it.  Hope this helps as I haven't really had much chance myself to play
with 2005

Paul 







Message Received: Jun 26 2007, 04:04 PM
From: "Jennifer Gross" 
To: "SQL Server List" 
Cc: 
Subject: [dba-SQLServer] Viewing and Modifying stored procedures

Hi All,

I am brand new to SQL Server - using 2005. I am tasked to make changes
to a db developed by someone else. For the life of me I cannot figure
out how to view a stored procedure and modify it. Using Management
Studio I was hoping that a right click would yield an Open or Design
option - but no luck. Do I have to modify via T-SQL or is there an
editing window I can use?

Thanks in advance,

Jennifer Gross
databasics
2839 Shirley Drive
Newbury Park, CA 91320-3068
office: (805) 480-1921
fax: (805) 499-0467 


_______________________________________________
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 fsmail.net
07730 523179
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com





From jwcolby at colbyconsulting.com  Tue Jun 26 11:04:49 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Tue, 26 Jun 2007 12:04:49 -0400
Subject: [dba-SQLServer] [AccessD] Second bi-annual
	GreaterSmokeyMountainAccessDConference
In-Reply-To: <F55048AF7E974F429BB24597D7355EEA4BA1CF@INFOSERVER04.infostat.local>
Message-ID: <20070626160450.7E0C1BEA1@smtp-auth.no-ip.com>

Well I guess that ends the discussion.

The OFFICIAL (Charlotte sanctioned) date for the Second Bi-annual Greater
Smokey Mountain AccessD Conference is September 22nd 2007.  I will need an
attendance count a couple of weeks in advance in order to find a place to
have it.  My office will definitely not do for more than a few attendees.

John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Charlotte Foust
Sent: Tuesday, June 26, 2007 11:38 AM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Second bi-annual
GreaterSmokeyMountainAccessDConference

I already have that weekend on my calendar to spend with you, John. ;->

Charlotte 

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Tuesday, June 26, 2007 7:28 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Second bi-annual Greater
SmokeyMountainAccessDConference

Sept 22 was my suggestion and is fine with me obviously.  I would like to
lock down a date in the next week so that people can make their plans, buy
tickets etc.

John W. Colby
Colby Consulting
www.ColbyConsulting.com
-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Mark Brown
Sent: Tuesday, June 26, 2007 10:20 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] Second bi-annual Greater Smokey
MountainAccessDConference

Sept 22 had been mentioned at one point - that date would work for me.

Mark H Brown
Computer Resolutions Inc.



From jengross at gte.net  Tue Jun 26 11:16:55 2007
From: jengross at gte.net (Jennifer Gross)
Date: Tue, 26 Jun 2007 09:16:55 -0700
Subject: [dba-SQLServer] Viewing and Modifying stored procedures
In-Reply-To: <AF469F21946F6442B5D4FF79AB854D64056FB9@msgswbmnmsp45.wellsfargo.com>
Message-ID: <00d701c7b80d$6d78afe0$6501a8c0@jefferson>

Hi Elizabeth,

Yes, I have modify.  What it does is set up a template T-SQL script to
modify the stored procedure.  If that is the only way to do it, then
that is how I will have to work with it.  I was hoping for just an
editing window.  Since I inherited this database what I really want to
do is poke around and look at the code and I can't seem to find any way
to just look at the code without generating one of these T-SQL
templates.

I hope that makes sense.

Jennifer

-----Original Message-----
From: Elizabeth.J.Doering at wellsfargo.com
[mailto:Elizabeth.J.Doering at wellsfargo.com] 
Sent: Tuesday, June 26, 2007 9:10 AM
To: jengross at gte.net
Subject: FW: [dba-SQLServer] Viewing and Modifying stored procedures


Jennifer,

Don't you have the right click option 'Modify'?  That would be your
friend here.  You can see it on the attached screen shot, and it gives
the results shown as well.

HTH,

Liz 


Liz Doering
elizabeth.j.doering at wellsfargo.com
612.667.2447


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


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of
Jennifer Gross
Sent: Tuesday, June 26, 2007 10:56 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures

Hi Paul,

This is what I hoped as well, but it doesn't seem to be the case.  The
right click menu gives me the option to script a modification, or script
a re-creation of the stored procedure, plus some other stuff.  But I am
not seeing a way to just open the stored procedure, see the code, modify
it and save it again.

Jennifer

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of
paul.hartland at fsmail.net
Sent: Tuesday, June 26, 2007 8:13 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures
Importance: High


Jennifer

One of the folders inside your database should be called programability,
in there you will find the stored procedures, then I am sure (bit rusty,
as not used it in a while) you should be able to right click and modify
it.  Hope this helps as I haven't really had much chance myself to play
with 2005

Paul 







Message Received: Jun 26 2007, 04:04 PM
From: "Jennifer Gross" 
To: "SQL Server List" 
Cc: 
Subject: [dba-SQLServer] Viewing and Modifying stored procedures

Hi All,

I am brand new to SQL Server - using 2005. I am tasked to make changes
to a db developed by someone else. For the life of me I cannot figure
out how to view a stored procedure and modify it. Using Management
Studio I was hoping that a right click would yield an Open or Design
option - but no luck. Do I have to modify via T-SQL or is there an
editing window I can use?

Thanks in advance,

Jennifer Gross
databasics
2839 Shirley Drive
Newbury Park, CA 91320-3068
office: (805) 480-1921
fax: (805) 499-0467 


_______________________________________________
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 fsmail.net
07730 523179
_______________________________________________
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 jengross at gte.net  Tue Jun 26 11:26:22 2007
From: jengross at gte.net (Jennifer Gross)
Date: Tue, 26 Jun 2007 09:26:22 -0700
Subject: [dba-SQLServer] Viewing and Modifying stored procedures
In-Reply-To: <AF469F21946F6442B5D4FF79AB854D64056FC1@msgswbmnmsp45.wellsfargo.com>
Message-ID: <00d801c7b80e$c0b48f20$6501a8c0@jefferson>

Hi Liz,

Yup, I have the stored procedure selected.  It is just that the Modify
option doesn't just show me the stored procedure, it is creating a T-SQL
template - it adds the commands ALTER PROC, etc. which are not part of
the stored procedure, but the means of modifying the stored procedure -
so that you can modify the script and run it to modify the stored
procedure.

I was hoping for a way to look at just the stored procedure, maybe edit
it without having to run an ALTER PROC script, and then save it.  Kind
of like with VB or VBA where you just have an editing window for your
code.  You make the changes in-line and then do a save.

I guess that is just not how it works with SQL Server.  I am learning!

Jennifer



-----Original Message-----
From: Elizabeth.J.Doering at wellsfargo.com
[mailto:Elizabeth.J.Doering at wellsfargo.com] 
Sent: Tuesday, June 26, 2007 9:18 AM
To: jengross at gte.net
Subject: RE: [dba-SQLServer] Viewing and Modifying stored procedures


Did you click on the stored procedure you want to modify first??  Sorry
if that is too simple an answer!


Liz 


-----Original Message-----
From: Jennifer Gross [mailto:jengross at gte.net] 
Sent: Tuesday, June 26, 2007 11:16 AM
To: Doering, Elizabeth J.
Subject: RE: [dba-SQLServer] Viewing and Modifying stored procedures

Hi Elizabeth,

Yes, I have modify.  What it does is set up a template T-SQL script to
modify the stored procedure.  If that is the only way to do it, then
that is how I will have to work with it.  I was hoping for just an
editing window.  Since I inherited this database what I really want to
do is poke around and look at the code and I can't seem to find any way
to just look at the code without generating one of these T-SQL
templates.

I hope that makes sense.

Jennifer

-----Original Message-----
From: Elizabeth.J.Doering at wellsfargo.com
[mailto:Elizabeth.J.Doering at wellsfargo.com]
Sent: Tuesday, June 26, 2007 9:10 AM
To: jengross at gte.net
Subject: FW: [dba-SQLServer] Viewing and Modifying stored procedures


Jennifer,

Don't you have the right click option 'Modify'?  That would be your
friend here.  You can see it on the attached screen shot, and it gives
the results shown as well.

HTH,

Liz 


Liz Doering
elizabeth.j.doering at wellsfargo.com
612.667.2447


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


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of
Jennifer Gross
Sent: Tuesday, June 26, 2007 10:56 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures

Hi Paul,

This is what I hoped as well, but it doesn't seem to be the case.  The
right click menu gives me the option to script a modification, or script
a re-creation of the stored procedure, plus some other stuff.  But I am
not seeing a way to just open the stored procedure, see the code, modify
it and save it again.

Jennifer

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of
paul.hartland at fsmail.net
Sent: Tuesday, June 26, 2007 8:13 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures
Importance: High


Jennifer

One of the folders inside your database should be called programability,
in there you will find the stored procedures, then I am sure (bit rusty,
as not used it in a while) you should be able to right click and modify
it.  Hope this helps as I haven't really had much chance myself to play
with 2005

Paul 







Message Received: Jun 26 2007, 04:04 PM
From: "Jennifer Gross" 
To: "SQL Server List" 
Cc: 
Subject: [dba-SQLServer] Viewing and Modifying stored procedures

Hi All,

I am brand new to SQL Server - using 2005. I am tasked to make changes
to a db developed by someone else. For the life of me I cannot figure
out how to view a stored procedure and modify it. Using Management
Studio I was hoping that a right click would yield an Open or Design
option - but no luck. Do I have to modify via T-SQL or is there an
editing window I can use?

Thanks in advance,

Jennifer Gross
databasics
2839 Shirley Drive
Newbury Park, CA 91320-3068
office: (805) 480-1921
fax: (805) 499-0467 


_______________________________________________
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 fsmail.net
07730 523179
_______________________________________________
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 Elizabeth.J.Doering at wellsfargo.com  Tue Jun 26 11:31:40 2007
From: Elizabeth.J.Doering at wellsfargo.com (Elizabeth.J.Doering at wellsfargo.com)
Date: Tue, 26 Jun 2007 11:31:40 -0500
Subject: [dba-SQLServer] Viewing and Modifying stored procedures
References: <00d801c7b80e$c0b48f20$6501a8c0@jefferson>
Message-ID: <AF469F21946F6442B5D4FF79AB854D64056FCF@msgswbmnmsp45.wellsfargo.com>

Yup, changing a proc is "alter" and it doesn't save until you 'execute'.
Nothing so nice and direct as VBA where you see something, make a change
and save it.  You have to run a proc to accomplish EVERYTHING in SQL
server.

I too am learning this the hard way, having been working in SQL Server
2000 and 2005 simultaneously and from absolute zero since October.  Tons
of Access experience is one thing; SQL server is a different world.


Liz 


-----Original Message-----
From: Jennifer Gross [mailto:jengross at gte.net] 
Sent: Tuesday, June 26, 2007 11:26 AM
To: Doering, Elizabeth J.
Cc: SQL Server List
Subject: RE: [dba-SQLServer] Viewing and Modifying stored procedures

Hi Liz,

Yup, I have the stored procedure selected.  It is just that the Modify
option doesn't just show me the stored procedure, it is creating a T-SQL
template - it adds the commands ALTER PROC, etc. which are not part of
the stored procedure, but the means of modifying the stored procedure -
so that you can modify the script and run it to modify the stored
procedure.

I was hoping for a way to look at just the stored procedure, maybe edit
it without having to run an ALTER PROC script, and then save it.  Kind
of like with VB or VBA where you just have an editing window for your
code.  You make the changes in-line and then do a save.

I guess that is just not how it works with SQL Server.  I am learning!

Jennifer



-----Original Message-----
From: Elizabeth.J.Doering at wellsfargo.com
[mailto:Elizabeth.J.Doering at wellsfargo.com]
Sent: Tuesday, June 26, 2007 9:18 AM
To: jengross at gte.net
Subject: RE: [dba-SQLServer] Viewing and Modifying stored procedures


Did you click on the stored procedure you want to modify first??  Sorry
if that is too simple an answer!


Liz 


-----Original Message-----
From: Jennifer Gross [mailto:jengross at gte.net] 
Sent: Tuesday, June 26, 2007 11:16 AM
To: Doering, Elizabeth J.
Subject: RE: [dba-SQLServer] Viewing and Modifying stored procedures

Hi Elizabeth,

Yes, I have modify.  What it does is set up a template T-SQL script to
modify the stored procedure.  If that is the only way to do it, then
that is how I will have to work with it.  I was hoping for just an
editing window.  Since I inherited this database what I really want to
do is poke around and look at the code and I can't seem to find any way
to just look at the code without generating one of these T-SQL
templates.

I hope that makes sense.

Jennifer

-----Original Message-----
From: Elizabeth.J.Doering at wellsfargo.com
[mailto:Elizabeth.J.Doering at wellsfargo.com]
Sent: Tuesday, June 26, 2007 9:10 AM
To: jengross at gte.net
Subject: FW: [dba-SQLServer] Viewing and Modifying stored procedures


Jennifer,

Don't you have the right click option 'Modify'?  That would be your
friend here.  You can see it on the attached screen shot, and it gives
the results shown as well.

HTH,

Liz 


Liz Doering
elizabeth.j.doering at wellsfargo.com
612.667.2447


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


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of
Jennifer Gross
Sent: Tuesday, June 26, 2007 10:56 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures

Hi Paul,

This is what I hoped as well, but it doesn't seem to be the case.  The
right click menu gives me the option to script a modification, or script
a re-creation of the stored procedure, plus some other stuff.  But I am
not seeing a way to just open the stored procedure, see the code, modify
it and save it again.

Jennifer

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of
paul.hartland at fsmail.net
Sent: Tuesday, June 26, 2007 8:13 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures
Importance: High


Jennifer

One of the folders inside your database should be called programability,
in there you will find the stored procedures, then I am sure (bit rusty,
as not used it in a while) you should be able to right click and modify
it.  Hope this helps as I haven't really had much chance myself to play
with 2005

Paul 







Message Received: Jun 26 2007, 04:04 PM
From: "Jennifer Gross" 
To: "SQL Server List" 
Cc: 
Subject: [dba-SQLServer] Viewing and Modifying stored procedures

Hi All,

I am brand new to SQL Server - using 2005. I am tasked to make changes
to a db developed by someone else. For the life of me I cannot figure
out how to view a stored procedure and modify it. Using Management
Studio I was hoping that a right click would yield an Open or Design
option - but no luck. Do I have to modify via T-SQL or is there an
editing window I can use?

Thanks in advance,

Jennifer Gross
databasics
2839 Shirley Drive
Newbury Park, CA 91320-3068
office: (805) 480-1921
fax: (805) 499-0467 


_______________________________________________
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 fsmail.net
07730 523179
_______________________________________________
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 ebarro at verizon.net  Tue Jun 26 10:09:31 2007
From: ebarro at verizon.net (Eric Barro)
Date: Tue, 26 Jun 2007 08:09:31 -0700
Subject: [dba-SQLServer] Viewing and Modifying stored procedures
In-Reply-To: <00b901c7b803$26f82dc0$6501a8c0@jefferson>
Message-ID: <0JK900G6I0RE577J@vms044.mailsrvcs.net>

Jennifer,

When you right click a sproc you get a context-sensitive menu with an option
called Modify. If you don't have that option then the login you are using
might not have permissions to modify the sproc.

Eric

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Jennifer
Gross
Sent: Tuesday, June 26, 2007 8:03 AM
To: SQL Server List
Subject: [dba-SQLServer] Viewing and Modifying stored procedures

Hi All,

I am brand new to SQL Server - using 2005.  I am tasked to make changes to a
db developed by someone else.  For the life of me I cannot figure out how to
view a stored procedure and modify it.  Using Management Studio I was hoping
that a right click would yield an Open or Design option - but no luck.  Do I
have to modify via T-SQL or is there an editing window I can use?

Thanks in advance,

Jennifer Gross
databasics
2839 Shirley Drive
Newbury Park, CA 91320-3068
office:  (805) 480-1921
fax:	   (805) 499-0467 



 



From rl_stewart at highstream.net  Tue Jun 26 11:36:16 2007
From: rl_stewart at highstream.net (Robert)
Date: Tue, 26 Jun 2007 11:36:16 -0500
Subject: [dba-SQLServer] Viewing and Modifying stored procedures
In-Reply-To: <mailman.1162.1182875203.5399.dba-sqlserver@databaseadvisor s.com>
References: <mailman.1162.1182875203.5399.dba-sqlserver@databaseadvisors.com>
Message-ID: <200706261640.l5QGeW3o020991@databaseadvisors.com>

Jennifer,

That is the "editing" window.
Not sure what you expected.

If you were expecting a grid view,
then you are not going to get it.
Stored procs are not views, but
can be anything from a simple SQL
statement to hundreds of lines
of code to do complex things.

If the stored proc is a simple
select statement and you are not
comfortable writing SQL, use the
view to create the SQL for you.
Then copy and paste it into the
stored proc.

The ALTER statement is how the
code for the stored proc is saved
when you change it. What it is doing
is making a copy of your SP then
allowing you to change it. If you
goof up, you just close the window
and don't save or execute it. Then
open the SP again to get the original
ad start your editing again.

Robert


At 11:26 AM 6/26/2007, you wrote:
>Date: Tue, 26 Jun 2007 09:16:55 -0700
>From: "Jennifer Gross" <jengross at gte.net>
>Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures
>To: "SQL Server List" <dba-sqlserver at databaseadvisors.com>
>Message-ID: <00d701c7b80d$6d78afe0$6501a8c0 at jefferson>
>Content-Type: text/plain; charset=us-ascii
>
>Hi Elizabeth,
>
>Yes, I have modify.  What it does is set up a template T-SQL script to
>modify the stored procedure.  If that is the only way to do it, then
>that is how I will have to work with it.  I was hoping for just an
>editing window.  Since I inherited this database what I really want to
>do is poke around and look at the code and I can't seem to find any way
>to just look at the code without generating one of these T-SQL
>templates.
>
>I hope that makes sense.
>
>Jennifer




From jengross at gte.net  Tue Jun 26 11:44:48 2007
From: jengross at gte.net (Jennifer Gross)
Date: Tue, 26 Jun 2007 09:44:48 -0700
Subject: [dba-SQLServer] Viewing and Modifying stored procedures
In-Reply-To: <200706261640.l5QGeW3o020991@databaseadvisors.com>
Message-ID: <00d901c7b811$4fb475d0$6501a8c0@jefferson>

Thanks Robert.  It is sinking in that this is the way it works in SQL
Server.  Even if I just want to see the stored procedure so that I can
understand what it does (since I inherited this database), I have to
generate this ALTER PROC template and then close the window without
saving.  Seems strange that I just can't take a look at the stored
procedure code, but I guess that's the way it is.

Jennifer

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Robert
Sent: Tuesday, June 26, 2007 9:36 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures


Jennifer,

That is the "editing" window.
Not sure what you expected.

If you were expecting a grid view,
then you are not going to get it.
Stored procs are not views, but
can be anything from a simple SQL
statement to hundreds of lines
of code to do complex things.

If the stored proc is a simple
select statement and you are not
comfortable writing SQL, use the
view to create the SQL for you.
Then copy and paste it into the
stored proc.

The ALTER statement is how the
code for the stored proc is saved
when you change it. What it is doing
is making a copy of your SP then
allowing you to change it. If you
goof up, you just close the window
and don't save or execute it. Then
open the SP again to get the original
ad start your editing again.

Robert


At 11:26 AM 6/26/2007, you wrote:
>Date: Tue, 26 Jun 2007 09:16:55 -0700
>From: "Jennifer Gross" <jengross at gte.net>
>Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures
>To: "SQL Server List" <dba-sqlserver at databaseadvisors.com>
>Message-ID: <00d701c7b80d$6d78afe0$6501a8c0 at jefferson>
>Content-Type: text/plain; charset=us-ascii
>
>Hi Elizabeth,
>
>Yes, I have modify.  What it does is set up a template T-SQL script to 
>modify the stored procedure.  If that is the only way to do it, then 
>that is how I will have to work with it.  I was hoping for just an 
>editing window.  Since I inherited this database what I really want to 
>do is poke around and look at the code and I can't seem to find any way

>to just look at the code without generating one of these T-SQL 
>templates.
>
>I hope that makes sense.
>
>Jennifer


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





From accessd at shaw.ca  Tue Jun 26 15:08:06 2007
From: accessd at shaw.ca (Jim Lawrence)
Date: Tue, 26 Jun 2007 13:08:06 -0700
Subject: [dba-SQLServer] Interesting article - Oracle "lite" benchmarks
In-Reply-To: <20070626152250.C1B4BBFF4@smtp-auth.no-ip.com>
Message-ID: <0JK900HI7EDTDVW0@l-daemon>

Hi John:

But it will run with only 1 GB of RAM. Please note that the new
'Unbreakable' Linux is far from it as it is just an older ripped-off
de-branded Redhat version and is buggy with the latest hardware. Example: Do
not try and run their 64bit version... it fails on a number of the current
platforms and the product will not run with Intel's latest CPU without
disable the advanced interrupt features. Fortunately, that can be turned off
through startup code. If you are thinking of running a Linux version of
Oracle it is strongly recommended that you use either Debian or Ubuntu
Linux... far superior in design and stability.      

Jim  

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Tuesday, June 26, 2007 8:23 AM
To: 'Access Developers discussion and problem solving';
dba-sqlserver at databaseadvisors.com
Subject: [dba-SQLServer] Interesting article - Oracle "lite" benchmarks

The article claims that Oracle is bundling their own Linux and their free
version of Oracle so you can get a "free" database going, even down to the
OS.  Of course the article states that Oracle is so huge that it requires
8gb of RAM to work well.  But memory is cheap right now.

http://www.informationweek.com/news/showArticle.jhtml?articleID=199903273

John W. Colby
Colby Consulting
www.ColbyConsulting.com 

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



From markamatte at hotmail.com  Tue Jun 26 15:32:10 2007
From: markamatte at hotmail.com (Mark A Matte)
Date: Tue, 26 Jun 2007 20:32:10 +0000
Subject: [dba-SQLServer] Viewing and Modifying stored procedures
In-Reply-To: <00d901c7b811$4fb475d0$6501a8c0@jefferson>
Message-ID: <BAY127-F39390C8FEA5ABCB9AB6CF6D20B0@phx.gbl>

Jennifer,

I currently use an older version of SQL Server...7 actually...and all I have 
to do is double click a stored procedure and it opens in a window for me to 
edit it...

Probably not useful...just thought I'd share.

Mark A. Matte


>From: "Jennifer Gross" <jengross at gte.net>
>Reply-To: dba-sqlserver at databaseadvisors.com
>To: <dba-sqlserver at databaseadvisors.com>
>Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures
>Date: Tue, 26 Jun 2007 09:44:48 -0700
>
>Thanks Robert.  It is sinking in that this is the way it works in SQL
>Server.  Even if I just want to see the stored procedure so that I can
>understand what it does (since I inherited this database), I have to
>generate this ALTER PROC template and then close the window without
>saving.  Seems strange that I just can't take a look at the stored
>procedure code, but I guess that's the way it is.
>
>Jennifer
>
>-----Original Message-----
>From: dba-sqlserver-bounces at databaseadvisors.com
>[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Robert
>Sent: Tuesday, June 26, 2007 9:36 AM
>To: dba-sqlserver at databaseadvisors.com
>Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures
>
>
>Jennifer,
>
>That is the "editing" window.
>Not sure what you expected.
>
>If you were expecting a grid view,
>then you are not going to get it.
>Stored procs are not views, but
>can be anything from a simple SQL
>statement to hundreds of lines
>of code to do complex things.
>
>If the stored proc is a simple
>select statement and you are not
>comfortable writing SQL, use the
>view to create the SQL for you.
>Then copy and paste it into the
>stored proc.
>
>The ALTER statement is how the
>code for the stored proc is saved
>when you change it. What it is doing
>is making a copy of your SP then
>allowing you to change it. If you
>goof up, you just close the window
>and don't save or execute it. Then
>open the SP again to get the original
>ad start your editing again.
>
>Robert
>
>
>At 11:26 AM 6/26/2007, you wrote:
> >Date: Tue, 26 Jun 2007 09:16:55 -0700
> >From: "Jennifer Gross" <jengross at gte.net>
> >Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures
> >To: "SQL Server List" <dba-sqlserver at databaseadvisors.com>
> >Message-ID: <00d701c7b80d$6d78afe0$6501a8c0 at jefferson>
> >Content-Type: text/plain; charset=us-ascii
> >
> >Hi Elizabeth,
> >
> >Yes, I have modify.  What it does is set up a template T-SQL script to
> >modify the stored procedure.  If that is the only way to do it, then
> >that is how I will have to work with it.  I was hoping for just an
> >editing window.  Since I inherited this database what I really want to
> >do is poke around and look at the code and I can't seem to find any way
>
> >to just look at the code without generating one of these T-SQL
> >templates.
> >
> >I hope that makes sense.
> >
> >Jennifer
>
>
>_______________________________________________
>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
>

_________________________________________________________________
Picture this ? share your photos and you could win big!  
http://www.GETREALPhotoContest.com?ocid=TXT_TAGHM&loc=us



From jengross at gte.net  Tue Jun 26 21:13:44 2007
From: jengross at gte.net (Jennifer Gross)
Date: Tue, 26 Jun 2007 19:13:44 -0700
Subject: [dba-SQLServer] Viewing and Modifying stored procedures
In-Reply-To: <BAY127-F39390C8FEA5ABCB9AB6CF6D20B0@phx.gbl>
Message-ID: <003901c7b860$ccfb7030$6501a8c0@jefferson>

Hi Mark,

That makes complete sense, but it doesn't work :(  I read somewhere that
the Query Analyzer in previous versions of SQL Server is no longer a
part of SQL Server 2005.  I am not sure, but have a feeling, that this
missing Query Analyzer is the reason I can't do what I want to do.
Apparently, unless you use T-SQL to edit stored procedures, the only
other way they can be edited is through Visual Studio.  It can't be done
directly in what is now called SQL Server Management Studio.  It appears
I need to learn how to navigate Visual Studio 2005 as well as SQL Server
2005.

Here is an article I found about editing SQL Server 2005 stored
procedures through Visual Studio -
http://aspnet.4guysfromrolla.com/articles/051607-1.aspx

Thanks for the help,

Jennifer



-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Mark A
Matte
Sent: Tuesday, June 26, 2007 1:32 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures


Jennifer,

I currently use an older version of SQL Server...7 actually...and all I
have 
to do is double click a stored procedure and it opens in a window for me
to 
edit it...

Probably not useful...just thought I'd share.

Mark A. Matte


>From: "Jennifer Gross" <jengross at gte.net>
>Reply-To: dba-sqlserver at databaseadvisors.com
>To: <dba-sqlserver at databaseadvisors.com>
>Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures
>Date: Tue, 26 Jun 2007 09:44:48 -0700
>
>Thanks Robert.  It is sinking in that this is the way it works in SQL 
>Server.  Even if I just want to see the stored procedure so that I can 
>understand what it does (since I inherited this database), I have to 
>generate this ALTER PROC template and then close the window without 
>saving.  Seems strange that I just can't take a look at the stored 
>procedure code, but I guess that's the way it is.
>
>Jennifer
>
>-----Original Message-----
>From: dba-sqlserver-bounces at databaseadvisors.com
>[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Robert
>Sent: Tuesday, June 26, 2007 9:36 AM
>To: dba-sqlserver at databaseadvisors.com
>Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures
>
>
>Jennifer,
>
>That is the "editing" window.
>Not sure what you expected.
>
>If you were expecting a grid view,
>then you are not going to get it.
>Stored procs are not views, but
>can be anything from a simple SQL
>statement to hundreds of lines
>of code to do complex things.
>
>If the stored proc is a simple
>select statement and you are not
>comfortable writing SQL, use the
>view to create the SQL for you.
>Then copy and paste it into the
>stored proc.
>
>The ALTER statement is how the
>code for the stored proc is saved
>when you change it. What it is doing
>is making a copy of your SP then
>allowing you to change it. If you
>goof up, you just close the window
>and don't save or execute it. Then
>open the SP again to get the original
>ad start your editing again.
>
>Robert
>
>
>At 11:26 AM 6/26/2007, you wrote:
> >Date: Tue, 26 Jun 2007 09:16:55 -0700
> >From: "Jennifer Gross" <jengross at gte.net>
> >Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures
> >To: "SQL Server List" <dba-sqlserver at databaseadvisors.com>
> >Message-ID: <00d701c7b80d$6d78afe0$6501a8c0 at jefferson>
> >Content-Type: text/plain; charset=us-ascii
> >
> >Hi Elizabeth,
> >
> >Yes, I have modify.  What it does is set up a template T-SQL script 
> >to modify the stored procedure.  If that is the only way to do it, 
> >then that is how I will have to work with it.  I was hoping for just 
> >an editing window.  Since I inherited this database what I really 
> >want to do is poke around and look at the code and I can't seem to 
> >find any way
>
> >to just look at the code without generating one of these T-SQL 
> >templates.
> >
> >I hope that makes sense.
> >
> >Jennifer
>
>
>_______________________________________________
>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
>

_________________________________________________________________
Picture this - share your photos and you could win big!  
http://www.GETREALPhotoContest.com?ocid=TXT_TAGHM&loc=us





From ebarro at verizon.net  Tue Jun 26 22:03:18 2007
From: ebarro at verizon.net (Eric Barro)
Date: Tue, 26 Jun 2007 20:03:18 -0700
Subject: [dba-SQLServer] Viewing and Modifying stored procedures
In-Reply-To: <003901c7b860$ccfb7030$6501a8c0@jefferson>
Message-ID: <0JK900H3JXTEJFVF@vms040.mailsrvcs.net>

Jennifer,

When you right click the sproc you should have an option to Modify or Script
the sproc to a Query window. If the login you are using doesn't have
permissions to do that then you won't be able to Modify the sproc.

Eric 

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Jennifer
Gross
Sent: Tuesday, June 26, 2007 7:14 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures

Hi Mark,

That makes complete sense, but it doesn't work :(  I read somewhere that the
Query Analyzer in previous versions of SQL Server is no longer a part of SQL
Server 2005.  I am not sure, but have a feeling, that this missing Query
Analyzer is the reason I can't do what I want to do.
Apparently, unless you use T-SQL to edit stored procedures, the only other
way they can be edited is through Visual Studio.  It can't be done directly
in what is now called SQL Server Management Studio.  It appears I need to
learn how to navigate Visual Studio 2005 as well as SQL Server 2005.

Here is an article I found about editing SQL Server 2005 stored procedures
through Visual Studio -
http://aspnet.4guysfromrolla.com/articles/051607-1.aspx

Thanks for the help,

Jennifer



-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Mark A
Matte
Sent: Tuesday, June 26, 2007 1:32 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures


Jennifer,

I currently use an older version of SQL Server...7 actually...and all I have
to do is double click a stored procedure and it opens in a window for me to
edit it...

Probably not useful...just thought I'd share.

Mark A. Matte


>From: "Jennifer Gross" <jengross at gte.net>
>Reply-To: dba-sqlserver at databaseadvisors.com
>To: <dba-sqlserver at databaseadvisors.com>
>Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures
>Date: Tue, 26 Jun 2007 09:44:48 -0700
>
>Thanks Robert.  It is sinking in that this is the way it works in SQL 
>Server.  Even if I just want to see the stored procedure so that I can 
>understand what it does (since I inherited this database), I have to 
>generate this ALTER PROC template and then close the window without 
>saving.  Seems strange that I just can't take a look at the stored 
>procedure code, but I guess that's the way it is.
>
>Jennifer
>
>-----Original Message-----
>From: dba-sqlserver-bounces at databaseadvisors.com
>[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Robert
>Sent: Tuesday, June 26, 2007 9:36 AM
>To: dba-sqlserver at databaseadvisors.com
>Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures
>
>
>Jennifer,
>
>That is the "editing" window.
>Not sure what you expected.
>
>If you were expecting a grid view,
>then you are not going to get it.
>Stored procs are not views, but
>can be anything from a simple SQL
>statement to hundreds of lines
>of code to do complex things.
>
>If the stored proc is a simple
>select statement and you are not
>comfortable writing SQL, use the
>view to create the SQL for you.
>Then copy and paste it into the
>stored proc.
>
>The ALTER statement is how the
>code for the stored proc is saved
>when you change it. What it is doing
>is making a copy of your SP then
>allowing you to change it. If you
>goof up, you just close the window
>and don't save or execute it. Then
>open the SP again to get the original
>ad start your editing again.
>
>Robert
>
>
>At 11:26 AM 6/26/2007, you wrote:
> >Date: Tue, 26 Jun 2007 09:16:55 -0700
> >From: "Jennifer Gross" <jengross at gte.net>
> >Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures
> >To: "SQL Server List" <dba-sqlserver at databaseadvisors.com>
> >Message-ID: <00d701c7b80d$6d78afe0$6501a8c0 at jefferson>
> >Content-Type: text/plain; charset=us-ascii
> >
> >Hi Elizabeth,
> >
> >Yes, I have modify.  What it does is set up a template T-SQL script 
> >to modify the stored procedure.  If that is the only way to do it, 
> >then that is how I will have to work with it.  I was hoping for just 
> >an editing window.  Since I inherited this database what I really 
> >want to do is poke around and look at the code and I can't seem to 
> >find any way
>
> >to just look at the code without generating one of these T-SQL 
> >templates.
> >
> >I hope that makes sense.
> >
> >Jennifer
>
>
>_______________________________________________
>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
>

_________________________________________________________________
Picture this - share your photos and you could win big!  
http://www.GETREALPhotoContest.com?ocid=TXT_TAGHM&loc=us



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

No virus found in this incoming message.
Checked by AVG Free Edition. 
Version: 7.5.476 / Virus Database: 269.9.9/870 - Release Date: 6/26/2007
10:07 AM
 



From markamatte at hotmail.com  Wed Jun 27 10:04:41 2007
From: markamatte at hotmail.com (Mark A Matte)
Date: Wed, 27 Jun 2007 15:04:41 +0000
Subject: [dba-SQLServer] Viewing and Modifying stored procedures
In-Reply-To: <003901c7b860$ccfb7030$6501a8c0@jefferson>
Message-ID: <BAY127-F3070CC99455BEAAC9D0116D20A0@phx.gbl>

I use SQL Server Enterprise Manager to modify the SP...never did it through 
Query Analizer...

Sorry,

Mark


>From: "Jennifer Gross" <jengross at gte.net>
>Reply-To: dba-sqlserver at databaseadvisors.com
>To: <dba-sqlserver at databaseadvisors.com>
>Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures
>Date: Tue, 26 Jun 2007 19:13:44 -0700
>
>Hi Mark,
>
>That makes complete sense, but it doesn't work :(  I read somewhere that
>the Query Analyzer in previous versions of SQL Server is no longer a
>part of SQL Server 2005.  I am not sure, but have a feeling, that this
>missing Query Analyzer is the reason I can't do what I want to do.
>Apparently, unless you use T-SQL to edit stored procedures, the only
>other way they can be edited is through Visual Studio.  It can't be done
>directly in what is now called SQL Server Management Studio.  It appears
>I need to learn how to navigate Visual Studio 2005 as well as SQL Server
>2005.
>
>Here is an article I found about editing SQL Server 2005 stored
>procedures through Visual Studio -
>http://aspnet.4guysfromrolla.com/articles/051607-1.aspx
>
>Thanks for the help,
>
>Jennifer
>
>
>
>-----Original Message-----
>From: dba-sqlserver-bounces at databaseadvisors.com
>[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Mark A
>Matte
>Sent: Tuesday, June 26, 2007 1:32 PM
>To: dba-sqlserver at databaseadvisors.com
>Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures
>
>
>Jennifer,
>
>I currently use an older version of SQL Server...7 actually...and all I
>have
>to do is double click a stored procedure and it opens in a window for me
>to
>edit it...
>
>Probably not useful...just thought I'd share.
>
>Mark A. Matte
>
>
> >From: "Jennifer Gross" <jengross at gte.net>
> >Reply-To: dba-sqlserver at databaseadvisors.com
> >To: <dba-sqlserver at databaseadvisors.com>
> >Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures
> >Date: Tue, 26 Jun 2007 09:44:48 -0700
> >
> >Thanks Robert.  It is sinking in that this is the way it works in SQL
> >Server.  Even if I just want to see the stored procedure so that I can
> >understand what it does (since I inherited this database), I have to
> >generate this ALTER PROC template and then close the window without
> >saving.  Seems strange that I just can't take a look at the stored
> >procedure code, but I guess that's the way it is.
> >
> >Jennifer
> >
> >-----Original Message-----
> >From: dba-sqlserver-bounces at databaseadvisors.com
> >[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Robert
> >Sent: Tuesday, June 26, 2007 9:36 AM
> >To: dba-sqlserver at databaseadvisors.com
> >Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures
> >
> >
> >Jennifer,
> >
> >That is the "editing" window.
> >Not sure what you expected.
> >
> >If you were expecting a grid view,
> >then you are not going to get it.
> >Stored procs are not views, but
> >can be anything from a simple SQL
> >statement to hundreds of lines
> >of code to do complex things.
> >
> >If the stored proc is a simple
> >select statement and you are not
> >comfortable writing SQL, use the
> >view to create the SQL for you.
> >Then copy and paste it into the
> >stored proc.
> >
> >The ALTER statement is how the
> >code for the stored proc is saved
> >when you change it. What it is doing
> >is making a copy of your SP then
> >allowing you to change it. If you
> >goof up, you just close the window
> >and don't save or execute it. Then
> >open the SP again to get the original
> >ad start your editing again.
> >
> >Robert
> >
> >
> >At 11:26 AM 6/26/2007, you wrote:
> > >Date: Tue, 26 Jun 2007 09:16:55 -0700
> > >From: "Jennifer Gross" <jengross at gte.net>
> > >Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures
> > >To: "SQL Server List" <dba-sqlserver at databaseadvisors.com>
> > >Message-ID: <00d701c7b80d$6d78afe0$6501a8c0 at jefferson>
> > >Content-Type: text/plain; charset=us-ascii
> > >
> > >Hi Elizabeth,
> > >
> > >Yes, I have modify.  What it does is set up a template T-SQL script
> > >to modify the stored procedure.  If that is the only way to do it,
> > >then that is how I will have to work with it.  I was hoping for just
> > >an editing window.  Since I inherited this database what I really
> > >want to do is poke around and look at the code and I can't seem to
> > >find any way
> >
> > >to just look at the code without generating one of these T-SQL
> > >templates.
> > >
> > >I hope that makes sense.
> > >
> > >Jennifer
> >
> >
> >_______________________________________________
> >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
> >
>
>_________________________________________________________________
>Picture this - share your photos and you could win big!
>http://www.GETREALPhotoContest.com?ocid=TXT_TAGHM&loc=us
>
>
>
>_______________________________________________
>dba-SQLServer mailing list
>dba-SQLServer at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>http://www.databaseadvisors.com
>

_________________________________________________________________
Hotmail to go? Get your Hotmail, news, sports and much more! 
http://mobile.msn.com



From rl_stewart at highstream.net  Wed Jun 27 12:53:59 2007
From: rl_stewart at highstream.net (Robert)
Date: Wed, 27 Jun 2007 12:53:59 -0500
Subject: [dba-SQLServer] Viewing and Modifying stored procedures
In-Reply-To: <mailman.5.1182963602.8945.dba-sqlserver@databaseadvisors.c
 om>
References: <mailman.5.1182963602.8945.dba-sqlserver@databaseadvisors.com>
Message-ID: <200706271754.l5RHskit031676@databaseadvisors.com>

Jennifer,

The query analyzer is not missing. It is what you would
get when you do the modify. Instead of being a different
program like the old days, it is built in.

What he is getting when he double clicks it in the old
version is the same thing he would get by right-clicking
and going to properties.

I am not sure what you mean by "it cannot be edited directly."
How much more directly can you get?

Of course you are going to use T-SQL to do the editing, that is
what it is written in. What were you expecting to use?  VBA?

I am a DBA and SQL Programmer. I much prefer the new interface
over the old one.  Stop fighting it and learn to use it. You do
not need Visual Studio for anything.  Unless you want to buy
the big build of it and get the "Database" version of it.  But,
even then you are not editing it directly like you would be
with management studio. I have it because of my MSDN subscription
and I tried it once and stopped using it.  It was way too cumbersome.


Robert

At 12:00 PM 6/27/2007, you wrote:
>Date: Tue, 26 Jun 2007 19:13:44 -0700
>From: "Jennifer Gross" <jengross at gte.net>
>Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures
>To: <dba-sqlserver at databaseadvisors.com>
>Message-ID: <003901c7b860$ccfb7030$6501a8c0 at jefferson>
>Content-Type: text/plain; charset=us-ascii
>
>Hi Mark,
>
>That makes complete sense, but it doesn't work :(  I read somewhere that
>the Query Analyzer in previous versions of SQL Server is no longer a
>part of SQL Server 2005.  I am not sure, but have a feeling, that this
>missing Query Analyzer is the reason I can't do what I want to do.
>Apparently, unless you use T-SQL to edit stored procedures, the only
>other way they can be edited is through Visual Studio.  It can't be done
>directly in what is now called SQL Server Management Studio.  It appears
>I need to learn how to navigate Visual Studio 2005 as well as SQL Server
>2005.
>
>Here is an article I found about editing SQL Server 2005 stored
>procedures through Visual Studio -
>http://aspnet.4guysfromrolla.com/articles/051607-1.aspx
>
>Thanks for the help,
>
>Jennifer




From jengross at gte.net  Wed Jun 27 13:54:04 2007
From: jengross at gte.net (Jennifer Gross)
Date: Wed, 27 Jun 2007 11:54:04 -0700
Subject: [dba-SQLServer] Viewing and Modifying stored procedures
In-Reply-To: <200706271754.l5RHskit031676@databaseadvisors.com>
Message-ID: <010301c7b8ec$8bcf9be0$6501a8c0@jefferson>

Hi Robert,

Wow.  I never expected or received such animosity and direct criticism
from a request for help from this list or any other I belong to.  

Jennifer

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Robert
Sent: Wednesday, June 27, 2007 10:54 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures


Jennifer,

The query analyzer is not missing. It is what you would
get when you do the modify. Instead of being a different program like
the old days, it is built in.

What he is getting when he double clicks it in the old
version is the same thing he would get by right-clicking
and going to properties.

I am not sure what you mean by "it cannot be edited directly." How much
more directly can you get?

Of course you are going to use T-SQL to do the editing, that is what it
is written in. What were you expecting to use?  VBA?

I am a DBA and SQL Programmer. I much prefer the new interface over the
old one.  Stop fighting it and learn to use it. You do not need Visual
Studio for anything.  Unless you want to buy the big build of it and get
the "Database" version of it.  But, even then you are not editing it
directly like you would be with management studio. I have it because of
my MSDN subscription and I tried it once and stopped using it.  It was
way too cumbersome.


Robert

At 12:00 PM 6/27/2007, you wrote:
>Date: Tue, 26 Jun 2007 19:13:44 -0700
>From: "Jennifer Gross" <jengross at gte.net>
>Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures
>To: <dba-sqlserver at databaseadvisors.com>
>Message-ID: <003901c7b860$ccfb7030$6501a8c0 at jefferson>
>Content-Type: text/plain; charset=us-ascii
>
>Hi Mark,
>
>That makes complete sense, but it doesn't work :(  I read somewhere 
>that the Query Analyzer in previous versions of SQL Server is no longer

>a part of SQL Server 2005.  I am not sure, but have a feeling, that 
>this missing Query Analyzer is the reason I can't do what I want to do.

>Apparently, unless you use T-SQL to edit stored procedures, the only 
>other way they can be edited is through Visual Studio.  It can't be 
>done directly in what is now called SQL Server Management Studio.  It 
>appears I need to learn how to navigate Visual Studio 2005 as well as 
>SQL Server 2005.
>
>Here is an article I found about editing SQL Server 2005 stored 
>procedures through Visual Studio - 
>http://aspnet.4guysfromrolla.com/articles/051607-1.aspx
>
>Thanks for the help,
>
>Jennifer


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





From markamatte at hotmail.com  Wed Jun 27 14:43:08 2007
From: markamatte at hotmail.com (Mark A Matte)
Date: Wed, 27 Jun 2007 19:43:08 +0000
Subject: [dba-SQLServer] Viewing and Modifying stored procedures
In-Reply-To: <BAY127-F3070CC99455BEAAC9D0116D20A0@phx.gbl>
Message-ID: <BAY127-F30967D8F5510A18AACCC29D20A0@phx.gbl>

Jennifer,

After I read the other posts...I went back and looked at my version of SQL 
Server...to find out how to edit a SP without the double click...if I right 
click on the SP and choose PROPERTIES...it opens the same edit window as the 
double click.

Hope that helps,

Mark


>From: "Mark A Matte" <markamatte at hotmail.com>
>Reply-To: dba-sqlserver at databaseadvisors.com
>To: dba-sqlserver at databaseadvisors.com
>Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures
>Date: Wed, 27 Jun 2007 15:04:41 +0000
>
>I use SQL Server Enterprise Manager to modify the SP...never did it through
>Query Analizer...
>
>Sorry,
>
>Mark
>
>
> >From: "Jennifer Gross" <jengross at gte.net>
> >Reply-To: dba-sqlserver at databaseadvisors.com
> >To: <dba-sqlserver at databaseadvisors.com>
> >Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures
> >Date: Tue, 26 Jun 2007 19:13:44 -0700
> >
> >Hi Mark,
> >
> >That makes complete sense, but it doesn't work :(  I read somewhere that
> >the Query Analyzer in previous versions of SQL Server is no longer a
> >part of SQL Server 2005.  I am not sure, but have a feeling, that this
> >missing Query Analyzer is the reason I can't do what I want to do.
> >Apparently, unless you use T-SQL to edit stored procedures, the only
> >other way they can be edited is through Visual Studio.  It can't be done
> >directly in what is now called SQL Server Management Studio.  It appears
> >I need to learn how to navigate Visual Studio 2005 as well as SQL Server
> >2005.
> >
> >Here is an article I found about editing SQL Server 2005 stored
> >procedures through Visual Studio -
> >http://aspnet.4guysfromrolla.com/articles/051607-1.aspx
> >
> >Thanks for the help,
> >
> >Jennifer
> >
> >
> >
> >-----Original Message-----
> >From: dba-sqlserver-bounces at databaseadvisors.com
> >[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Mark A
> >Matte
> >Sent: Tuesday, June 26, 2007 1:32 PM
> >To: dba-sqlserver at databaseadvisors.com
> >Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures
> >
> >
> >Jennifer,
> >
> >I currently use an older version of SQL Server...7 actually...and all I
> >have
> >to do is double click a stored procedure and it opens in a window for me
> >to
> >edit it...
> >
> >Probably not useful...just thought I'd share.
> >
> >Mark A. Matte
> >
> >
> > >From: "Jennifer Gross" <jengross at gte.net>
> > >Reply-To: dba-sqlserver at databaseadvisors.com
> > >To: <dba-sqlserver at databaseadvisors.com>
> > >Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures
> > >Date: Tue, 26 Jun 2007 09:44:48 -0700
> > >
> > >Thanks Robert.  It is sinking in that this is the way it works in SQL
> > >Server.  Even if I just want to see the stored procedure so that I can
> > >understand what it does (since I inherited this database), I have to
> > >generate this ALTER PROC template and then close the window without
> > >saving.  Seems strange that I just can't take a look at the stored
> > >procedure code, but I guess that's the way it is.
> > >
> > >Jennifer
> > >
> > >-----Original Message-----
> > >From: dba-sqlserver-bounces at databaseadvisors.com
> > >[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Robert
> > >Sent: Tuesday, June 26, 2007 9:36 AM
> > >To: dba-sqlserver at databaseadvisors.com
> > >Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures
> > >
> > >
> > >Jennifer,
> > >
> > >That is the "editing" window.
> > >Not sure what you expected.
> > >
> > >If you were expecting a grid view,
> > >then you are not going to get it.
> > >Stored procs are not views, but
> > >can be anything from a simple SQL
> > >statement to hundreds of lines
> > >of code to do complex things.
> > >
> > >If the stored proc is a simple
> > >select statement and you are not
> > >comfortable writing SQL, use the
> > >view to create the SQL for you.
> > >Then copy and paste it into the
> > >stored proc.
> > >
> > >The ALTER statement is how the
> > >code for the stored proc is saved
> > >when you change it. What it is doing
> > >is making a copy of your SP then
> > >allowing you to change it. If you
> > >goof up, you just close the window
> > >and don't save or execute it. Then
> > >open the SP again to get the original
> > >ad start your editing again.
> > >
> > >Robert
> > >
> > >
> > >At 11:26 AM 6/26/2007, you wrote:
> > > >Date: Tue, 26 Jun 2007 09:16:55 -0700
> > > >From: "Jennifer Gross" <jengross at gte.net>
> > > >Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures
> > > >To: "SQL Server List" <dba-sqlserver at databaseadvisors.com>
> > > >Message-ID: <00d701c7b80d$6d78afe0$6501a8c0 at jefferson>
> > > >Content-Type: text/plain; charset=us-ascii
> > > >
> > > >Hi Elizabeth,
> > > >
> > > >Yes, I have modify.  What it does is set up a template T-SQL script
> > > >to modify the stored procedure.  If that is the only way to do it,
> > > >then that is how I will have to work with it.  I was hoping for just
> > > >an editing window.  Since I inherited this database what I really
> > > >want to do is poke around and look at the code and I can't seem to
> > > >find any way
> > >
> > > >to just look at the code without generating one of these T-SQL
> > > >templates.
> > > >
> > > >I hope that makes sense.
> > > >
> > > >Jennifer
> > >
> > >
> > >_______________________________________________
> > >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
> > >
> >
> >_________________________________________________________________
> >Picture this - share your photos and you could win big!
> >http://www.GETREALPhotoContest.com?ocid=TXT_TAGHM&loc=us
> >
> >
> >
> >_______________________________________________
> >dba-SQLServer mailing list
> >dba-SQLServer at databaseadvisors.com
> >http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> >http://www.databaseadvisors.com
> >
>
>_________________________________________________________________
>Hotmail to go? Get your Hotmail, news, sports and much more!
>http://mobile.msn.com
>
>_______________________________________________
>dba-SQLServer mailing list
>dba-SQLServer at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>http://www.databaseadvisors.com
>

_________________________________________________________________
Who's that on the Red Carpet? Play & win glamorous prizes. 
http://club.live.com/red_carpet_reveal.aspx?icid=REDCARPET_hotmailtextlink3



From chizotz at mchsi.com  Wed Jun 27 14:49:23 2007
From: chizotz at mchsi.com (Ron Allen)
Date: Wed, 27 Jun 2007 19:49:23 +0000
Subject: [dba-SQLServer] Viewing and Modifying stored procedures
Message-ID: <062720071949.22770.4682BF43000AFE3E000058F2219791280203010CD2079C080C03BF969B019607080C@mchsi.com>

Hi Jennifer,

I am still on SQL Server 2000, using Enterprise Manager and Query Analyzer, 
but understand that all of that functionality is built into 2005 just named 
differently.

You are correct that the way to edit stored procedures in SQL server is 
through T-SQL using the CREATE or ALTER syntax. There is no Access-like query 
builder that lets you build a query visually. Whether this is good or bad or 
right or wrong can be debated endlessly, and there are what I consider valid 
arguments on both sides. 

That said, in SQL Server 2000 there are at least two ways to simply see the SP 
code. You can edit the SP in Query Analyzer or you can select "properties" for 
the SP in Enterprise Manager. In either case, you will also see the "ALTER" 
or "CREATE" portion of the syntax because that is a part of the syntax of the 
SP. It isn't a "template", which I'm thinking may be one of the places you 
need to make a conceptual shift.

Don't get discouraged, because a vast number of things that you learned in 
Access will be useful when working with SQL Server, but usually only in that 
it makes things familiar not because there is a direct correlation on the 
nitty gritty details. 

Ron




> That makes complete sense, but it doesn't work :(  I read somewhere that
> the Query Analyzer in previous versions of SQL Server is no longer a
> part of SQL Server 2005.  I am not sure, but have a feeling, that this
> missing Query Analyzer is the reason I can't do what I want to do.
> Apparently, unless you use T-SQL to edit stored procedures, the only
> other way they can be edited is through Visual Studio.  It can't be done
> directly in what is now called SQL Server Management Studio.  It appears
> I need to learn how to navigate Visual Studio 2005 as well as SQL Server
> 2005.
> 

> >
> >Thanks Robert.  It is sinking in that this is the way it works in SQL 
> >Server.  Even if I just want to see the stored procedure so that I can 
> >understand what it does (since I inherited this database), I have to 
> >generate this ALTER PROC template and then close the window without 
> >saving.  Seems strange that I just can't take a look at the stored 
> >procedure code, but I guess that's the way it is.


From jengross at gte.net  Wed Jun 27 15:12:51 2007
From: jengross at gte.net (Jennifer Gross)
Date: Wed, 27 Jun 2007 13:12:51 -0700
Subject: [dba-SQLServer] Viewing and Modifying stored procedures
In-Reply-To: <062720071949.22770.4682BF43000AFE3E000058F2219791280203010CD2079C080C03BF969B019607080C@mchsi.com>
Message-ID: <011901c7b8f7$8d3d0d90$6501a8c0@jefferson>

Hi Ron,

Thanks for this.  In SQL Server 2005 Management Studio right click
Properties on a SP brings up a different kind of window - similar to the
Properties window of the database itself, showing permissions,
encryption info, etc.  It is the right click > Modify option that brings
up the SP with an ALTER key word - an example is a right click > Modify
on the SP dbo.addUserQueue will bring up a query editor window
containing the following:

ALTER  PROC [dbo].[addUserQueue] @userid varchar(12),
  @Queueuserid varchar(12)
  as

    if (select count(UserID) from UserQueues where userID        
           = @UserID and QueueUserID = @QueueUserID) = 0
	Begin
  	 Insert into UserQueues (UserID,  QueueUserID)
  		  values (@UserID, @QueueUserID)
	End

I may be wrong, but I don't think that ALTER is a part of this SP, but
is there so that you can make any modifications to the SP and then
Execute the script (if that is the right word for it), in order to make
the changes necessary to the SP.

It is a conceptual shift that I need to make.  I was not looking for a
QBE grid, but more of how a module is edited in Access - in an editing
window with a Save command.  I now think I've got it that for SQL Server
SPs I need to Execute an ALTER command to modify the stored procedure,
and if I just want to take a look at the SP's functionality I have to
right click > Modify which brings up the SP along with this ALTER key
word, ready to be modified and executed.  When I am done looking I just
close the window without saving.

Thanks for the help,

Jennifer



-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Ron
Allen
Sent: Wednesday, June 27, 2007 12:49 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures


Hi Jennifer,

I am still on SQL Server 2000, using Enterprise Manager and Query
Analyzer, 
but understand that all of that functionality is built into 2005 just
named 
differently.

You are correct that the way to edit stored procedures in SQL server is 
through T-SQL using the CREATE or ALTER syntax. There is no Access-like
query 
builder that lets you build a query visually. Whether this is good or
bad or 
right or wrong can be debated endlessly, and there are what I consider
valid 
arguments on both sides. 

That said, in SQL Server 2000 there are at least two ways to simply see
the SP 
code. You can edit the SP in Query Analyzer or you can select
"properties" for 
the SP in Enterprise Manager. In either case, you will also see the
"ALTER" 
or "CREATE" portion of the syntax because that is a part of the syntax
of the 
SP. It isn't a "template", which I'm thinking may be one of the places
you 
need to make a conceptual shift.

Don't get discouraged, because a vast number of things that you learned
in 
Access will be useful when working with SQL Server, but usually only in
that 
it makes things familiar not because there is a direct correlation on
the 
nitty gritty details. 

Ron




> That makes complete sense, but it doesn't work :(  I read somewhere 
> that the Query Analyzer in previous versions of SQL Server is no 
> longer a part of SQL Server 2005.  I am not sure, but have a feeling, 
> that this missing Query Analyzer is the reason I can't do what I want 
> to do. Apparently, unless you use T-SQL to edit stored procedures, the

> only other way they can be edited is through Visual Studio.  It can't 
> be done directly in what is now called SQL Server Management Studio.  
> It appears I need to learn how to navigate Visual Studio 2005 as well 
> as SQL Server 2005.
> 

> >
> >Thanks Robert.  It is sinking in that this is the way it works in SQL
> >Server.  Even if I just want to see the stored procedure so that I
can 
> >understand what it does (since I inherited this database), I have to 
> >generate this ALTER PROC template and then close the window without 
> >saving.  Seems strange that I just can't take a look at the stored 
> >procedure code, but I guess that's the way it is.
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com





From ebarro at verizon.net  Wed Jun 27 15:24:13 2007
From: ebarro at verizon.net (Eric Barro)
Date: Wed, 27 Jun 2007 13:24:13 -0700
Subject: [dba-SQLServer] Viewing and Modifying stored procedures
In-Reply-To: <011901c7b8f7$8d3d0d90$6501a8c0@jefferson>
Message-ID: <0JKB0092QA1OEB9M@vms040.mailsrvcs.net>

Jennifer,

What you are seeing is the script that will allow you to make modifications
and when you run it, it will save your mods to the existing sproc. When you
create a new sproc it will say CREATE instead of ALTER. 

The general format is..

CREATE objectype objectname objectparameters
AS

<everything in between is your SQL code>

END 

If you simply want to look at the code that's how you do it. If you don't
click the execute icon it will simply stay as it is. SQL server's user
interface takes a while getting used to as it was the case when Microsoft
Access first came out. A paradigm shift into object-oriented, event-driven,
point and click from the usual UI was necessary. In essence, don't count too
much on point and click operations in SQL server because you will be
expected to know and learn SQL syntax.

Just ask John Colby...he knows what's involved...LOL.

Eric

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Jennifer
Gross
Sent: Wednesday, June 27, 2007 1:13 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures

Hi Ron,

Thanks for this.  In SQL Server 2005 Management Studio right click
Properties on a SP brings up a different kind of window - similar to the
Properties window of the database itself, showing permissions, encryption
info, etc.  It is the right click > Modify option that brings up the SP with
an ALTER key word - an example is a right click > Modify on the SP
dbo.addUserQueue will bring up a query editor window containing the
following:

ALTER  PROC [dbo].[addUserQueue] @userid varchar(12),
  @Queueuserid varchar(12)
  as

    if (select count(UserID) from UserQueues where userID        
           = @UserID and QueueUserID = @QueueUserID) = 0
	Begin
  	 Insert into UserQueues (UserID,  QueueUserID)
  		  values (@UserID, @QueueUserID)
	End

I may be wrong, but I don't think that ALTER is a part of this SP, but is
there so that you can make any modifications to the SP and then Execute the
script (if that is the right word for it), in order to make the changes
necessary to the SP.

It is a conceptual shift that I need to make.  I was not looking for a QBE
grid, but more of how a module is edited in Access - in an editing window
with a Save command.  I now think I've got it that for SQL Server SPs I need
to Execute an ALTER command to modify the stored procedure, and if I just
want to take a look at the SP's functionality I have to right click > Modify
which brings up the SP along with this ALTER key word, ready to be modified
and executed.  When I am done looking I just close the window without
saving.

Thanks for the help,

Jennifer



-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Ron Allen
Sent: Wednesday, June 27, 2007 12:49 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures


Hi Jennifer,

I am still on SQL Server 2000, using Enterprise Manager and Query Analyzer,
but understand that all of that functionality is built into 2005 just named
differently.

You are correct that the way to edit stored procedures in SQL server is
through T-SQL using the CREATE or ALTER syntax. There is no Access-like
query builder that lets you build a query visually. Whether this is good or
bad or right or wrong can be debated endlessly, and there are what I
consider valid arguments on both sides. 

That said, in SQL Server 2000 there are at least two ways to simply see the
SP code. You can edit the SP in Query Analyzer or you can select
"properties" for the SP in Enterprise Manager. In either case, you will also
see the "ALTER" 
or "CREATE" portion of the syntax because that is a part of the syntax of
the SP. It isn't a "template", which I'm thinking may be one of the places
you need to make a conceptual shift.

Don't get discouraged, because a vast number of things that you learned in
Access will be useful when working with SQL Server, but usually only in that
it makes things familiar not because there is a direct correlation on the
nitty gritty details. 

Ron




> That makes complete sense, but it doesn't work :(  I read somewhere 
> that the Query Analyzer in previous versions of SQL Server is no 
> longer a part of SQL Server 2005.  I am not sure, but have a feeling, 
> that this missing Query Analyzer is the reason I can't do what I want 
> to do. Apparently, unless you use T-SQL to edit stored procedures, the

> only other way they can be edited is through Visual Studio.  It can't 
> be done directly in what is now called SQL Server Management Studio.
> It appears I need to learn how to navigate Visual Studio 2005 as well 
> as SQL Server 2005.
> 

> >
> >Thanks Robert.  It is sinking in that this is the way it works in SQL 
> >Server.  Even if I just want to see the stored procedure so that I
can 
> >understand what it does (since I inherited this database), I have to 
> >generate this ALTER PROC template and then close the window without 
> >saving.  Seems strange that I just can't take a look at the stored 
> >procedure code, but I guess that's the way it is.
_______________________________________________

 



From jwcolby at colbyconsulting.com  Wed Jun 27 15:35:51 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Wed, 27 Jun 2007 16:35:51 -0400
Subject: [dba-SQLServer] Viewing and Modifying stored procedures
In-Reply-To: <0JKB0092QA1OEB9M@vms040.mailsrvcs.net>
Message-ID: <20070627203552.37FA8BD37@smtp-auth.no-ip.com>

I have been watching this thread with amusement.  I still have a very poor
handle on this stuff and likely will for quite some time.  SQL Server is for
REAL MEN (and WOMEN).  Wooses need not apply.  We edit our SQL statements
with notepad, and that only because they took away our copy of Edit (go to
the command prompt and type Edit).  We don't need no steenkin mouse!


John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Eric Barro
Sent: Wednesday, June 27, 2007 4:24 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures

Jennifer,

What you are seeing is the script that will allow you to make modifications
and when you run it, it will save your mods to the existing sproc. When you
create a new sproc it will say CREATE instead of ALTER. 

The general format is..

CREATE objectype objectname objectparameters AS

<everything in between is your SQL code>

END 

If you simply want to look at the code that's how you do it. If you don't
click the execute icon it will simply stay as it is. SQL server's user
interface takes a while getting used to as it was the case when Microsoft
Access first came out. A paradigm shift into object-oriented, event-driven,
point and click from the usual UI was necessary. In essence, don't count too
much on point and click operations in SQL server because you will be
expected to know and learn SQL syntax.

Just ask John Colby...he knows what's involved...LOL.

Eric

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Jennifer
Gross
Sent: Wednesday, June 27, 2007 1:13 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures

Hi Ron,

Thanks for this.  In SQL Server 2005 Management Studio right click
Properties on a SP brings up a different kind of window - similar to the
Properties window of the database itself, showing permissions, encryption
info, etc.  It is the right click > Modify option that brings up the SP with
an ALTER key word - an example is a right click > Modify on the SP
dbo.addUserQueue will bring up a query editor window containing the
following:

ALTER  PROC [dbo].[addUserQueue] @userid varchar(12),
  @Queueuserid varchar(12)
  as

    if (select count(UserID) from UserQueues where userID        
           = @UserID and QueueUserID = @QueueUserID) = 0
	Begin
  	 Insert into UserQueues (UserID,  QueueUserID)
  		  values (@UserID, @QueueUserID)
	End

I may be wrong, but I don't think that ALTER is a part of this SP, but is
there so that you can make any modifications to the SP and then Execute the
script (if that is the right word for it), in order to make the changes
necessary to the SP.

It is a conceptual shift that I need to make.  I was not looking for a QBE
grid, but more of how a module is edited in Access - in an editing window
with a Save command.  I now think I've got it that for SQL Server SPs I need
to Execute an ALTER command to modify the stored procedure, and if I just
want to take a look at the SP's functionality I have to right click > Modify
which brings up the SP along with this ALTER key word, ready to be modified
and executed.  When I am done looking I just close the window without
saving.

Thanks for the help,

Jennifer



-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Ron Allen
Sent: Wednesday, June 27, 2007 12:49 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures


Hi Jennifer,

I am still on SQL Server 2000, using Enterprise Manager and Query Analyzer,
but understand that all of that functionality is built into 2005 just named
differently.

You are correct that the way to edit stored procedures in SQL server is
through T-SQL using the CREATE or ALTER syntax. There is no Access-like
query builder that lets you build a query visually. Whether this is good or
bad or right or wrong can be debated endlessly, and there are what I
consider valid arguments on both sides. 

That said, in SQL Server 2000 there are at least two ways to simply see the
SP code. You can edit the SP in Query Analyzer or you can select
"properties" for the SP in Enterprise Manager. In either case, you will also
see the "ALTER" 
or "CREATE" portion of the syntax because that is a part of the syntax of
the SP. It isn't a "template", which I'm thinking may be one of the places
you need to make a conceptual shift.

Don't get discouraged, because a vast number of things that you learned in
Access will be useful when working with SQL Server, but usually only in that
it makes things familiar not because there is a direct correlation on the
nitty gritty details. 

Ron




> That makes complete sense, but it doesn't work :(  I read somewhere 
> that the Query Analyzer in previous versions of SQL Server is no 
> longer a part of SQL Server 2005.  I am not sure, but have a feeling, 
> that this missing Query Analyzer is the reason I can't do what I want 
> to do. Apparently, unless you use T-SQL to edit stored procedures, the

> only other way they can be edited is through Visual Studio.  It can't 
> be done directly in what is now called SQL Server Management Studio.
> It appears I need to learn how to navigate Visual Studio 2005 as well 
> as SQL Server 2005.
> 

> >
> >Thanks Robert.  It is sinking in that this is the way it works in SQL 
> >Server.  Even if I just want to see the stored procedure so that I
can 
> >understand what it does (since I inherited this database), I have to 
> >generate this ALTER PROC template and then close the window without 
> >saving.  Seems strange that I just can't take a look at the stored 
> >procedure code, but I guess that's the way it is.
_______________________________________________

 

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



From jengross at gte.net  Wed Jun 27 15:48:48 2007
From: jengross at gte.net (Jennifer Gross)
Date: Wed, 27 Jun 2007 13:48:48 -0700
Subject: [dba-SQLServer] Viewing and Modifying stored procedures
In-Reply-To: <20070627203552.37FA8BD37@smtp-auth.no-ip.com>
Message-ID: <013701c7b8fc$939e6850$6501a8c0@jefferson>

Stepping outside my comfort zone certainly has some growing pains.  But
I need to grow . . . so here we go . . .

Jennifer

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Wednesday, June 27, 2007 1:36 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures


I have been watching this thread with amusement.  I still have a very
poor handle on this stuff and likely will for quite some time.  SQL
Server is for REAL MEN (and WOMEN).  Wooses need not apply.  We edit our
SQL statements with notepad, and that only because they took away our
copy of Edit (go to the command prompt and type Edit).  We don't need no
steenkin mouse!


John W. Colby
Colby Consulting
www.ColbyConsulting.com 
-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Eric
Barro
Sent: Wednesday, June 27, 2007 4:24 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures

Jennifer,

What you are seeing is the script that will allow you to make
modifications and when you run it, it will save your mods to the
existing sproc. When you create a new sproc it will say CREATE instead
of ALTER. 

The general format is..

CREATE objectype objectname objectparameters AS

<everything in between is your SQL code>

END 

If you simply want to look at the code that's how you do it. If you
don't click the execute icon it will simply stay as it is. SQL server's
user interface takes a while getting used to as it was the case when
Microsoft Access first came out. A paradigm shift into object-oriented,
event-driven, point and click from the usual UI was necessary. In
essence, don't count too much on point and click operations in SQL
server because you will be expected to know and learn SQL syntax.

Just ask John Colby...he knows what's involved...LOL.

Eric

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of
Jennifer Gross
Sent: Wednesday, June 27, 2007 1:13 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures

Hi Ron,

Thanks for this.  In SQL Server 2005 Management Studio right click
Properties on a SP brings up a different kind of window - similar to the
Properties window of the database itself, showing permissions,
encryption info, etc.  It is the right click > Modify option that brings
up the SP with an ALTER key word - an example is a right click > Modify
on the SP dbo.addUserQueue will bring up a query editor window
containing the
following:

ALTER  PROC [dbo].[addUserQueue] @userid varchar(12),
  @Queueuserid varchar(12)
  as

    if (select count(UserID) from UserQueues where userID        
           = @UserID and QueueUserID = @QueueUserID) = 0
	Begin
  	 Insert into UserQueues (UserID,  QueueUserID)
  		  values (@UserID, @QueueUserID)
	End

I may be wrong, but I don't think that ALTER is a part of this SP, but
is there so that you can make any modifications to the SP and then
Execute the script (if that is the right word for it), in order to make
the changes necessary to the SP.

It is a conceptual shift that I need to make.  I was not looking for a
QBE grid, but more of how a module is edited in Access - in an editing
window with a Save command.  I now think I've got it that for SQL Server
SPs I need to Execute an ALTER command to modify the stored procedure,
and if I just want to take a look at the SP's functionality I have to
right click > Modify which brings up the SP along with this ALTER key
word, ready to be modified and executed.  When I am done looking I just
close the window without saving.

Thanks for the help,

Jennifer



-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Ron
Allen
Sent: Wednesday, June 27, 2007 12:49 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures


Hi Jennifer,

I am still on SQL Server 2000, using Enterprise Manager and Query
Analyzer, but understand that all of that functionality is built into
2005 just named differently.

You are correct that the way to edit stored procedures in SQL server is
through T-SQL using the CREATE or ALTER syntax. There is no Access-like
query builder that lets you build a query visually. Whether this is good
or bad or right or wrong can be debated endlessly, and there are what I
consider valid arguments on both sides. 

That said, in SQL Server 2000 there are at least two ways to simply see
the SP code. You can edit the SP in Query Analyzer or you can select
"properties" for the SP in Enterprise Manager. In either case, you will
also see the "ALTER" 
or "CREATE" portion of the syntax because that is a part of the syntax
of the SP. It isn't a "template", which I'm thinking may be one of the
places you need to make a conceptual shift.

Don't get discouraged, because a vast number of things that you learned
in Access will be useful when working with SQL Server, but usually only
in that it makes things familiar not because there is a direct
correlation on the nitty gritty details. 

Ron




> That makes complete sense, but it doesn't work :(  I read somewhere
> that the Query Analyzer in previous versions of SQL Server is no 
> longer a part of SQL Server 2005.  I am not sure, but have a feeling, 
> that this missing Query Analyzer is the reason I can't do what I want 
> to do. Apparently, unless you use T-SQL to edit stored procedures, the

> only other way they can be edited is through Visual Studio.  It can't
> be done directly in what is now called SQL Server Management Studio.
> It appears I need to learn how to navigate Visual Studio 2005 as well 
> as SQL Server 2005.
> 

> >
> >Thanks Robert.  It is sinking in that this is the way it works in SQL

> >Server.  Even if I just want to see the stored procedure so that I
can 
> >understand what it does (since I inherited this database), I have to 
> >generate this ALTER PROC template and then close the window without 
> >saving.  Seems strange that I just can't take a look at the stored 
> >procedure code, but I guess that's the way it is.
_______________________________________________

 

_______________________________________________
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 rl_stewart at highstream.net  Wed Jun 27 15:39:37 2007
From: rl_stewart at highstream.net (Robert)
Date: Wed, 27 Jun 2007 15:39:37 -0500
Subject: [dba-SQLServer] Viewing and Modifying stored procedures
In-Reply-To: <mailman.1553.1182975915.5399.dba-sqlserver@databaseadvisor s.com>
References: <mailman.1553.1182975915.5399.dba-sqlserver@databaseadvisors.com>
Message-ID: <200706272054.l5RKsi2I003456@databaseadvisors.com>

Jennifer,

It was not meant as animosity.  I am trying to lay
out the facts of it to you. Yet, you keep trying
to find a way to do it the way you want it to
work.  It simply does not do it. I learned a
long time ago to not beat my head against the
Microsoft Brick Wall. It is the way they do it.
I prefer not to get a bloody forehead and headaches.
So, I walk around the barriers they throw up and
use it without complaining. It simply is a waste of
time and effort to complain.  There is too much to
do to keep up as it is without wasting the time and
effort on things that I cannot change. And, yes
it was direct criticism. I am trying to save you
from banging your head against that wall. Concentrate
your efforts on learning, not complaining. You will
get much further and have much better code and
programs in general if you will do that.

I apologize for the perception you got that my words
carried animosity toward you.  Again, none was intended.

I read through the other answers to your last post and
I think that you have it.  Except for one minor thing.
When you save an SP, it will bring up a dialog box asking
you where you want to save it to.  It then will save it as
a script that can then be put into a version control system
or used at a later date to synchronize changes made in a
development system to a production system.  Because of this,
moving changes, it will also be very good if you learn the
DDL (data definition language) portion of T-SQL so you can
also script changes to the tables, indexes, constraints
and such.

The only way a change is made to the SP once it is created
is through the ALTER PROCEDURE portion of the statement.
Similarly,you can only create one using the CREATE
PROCEDURE portion of the statement.  Once you get accustomed
to it, it really does make sense.

Access shields us from a lot of things.  It is actually more
difficult, I think, to create an SP in an Access ADP program
than in Management Studio. And, there are limits to how Access
can handle SPs as well.  It does not like the use of temporary
tables at all.

Robert

At 03:25 PM 6/27/2007, you wrote:
>Date: Wed, 27 Jun 2007 11:54:04 -0700
>From: "Jennifer Gross" <jengross at gte.net>
>Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures
>To: <dba-sqlserver at databaseadvisors.com>
>Message-ID: <010301c7b8ec$8bcf9be0$6501a8c0 at jefferson>
>Content-Type: text/plain; charset=us-ascii
>
>Hi Robert,
>
>Wow.  I never expected or received such animosity and direct criticism
>from a request for help from this list or any other I belong to.
>
>Jennifer




From ebarro at verizon.net  Wed Jun 27 16:02:13 2007
From: ebarro at verizon.net (Eric Barro)
Date: Wed, 27 Jun 2007 14:02:13 -0700
Subject: [dba-SQLServer] Viewing and Modifying stored procedures
In-Reply-To: <200706272054.l5RKsi2I003456@databaseadvisors.com>
Message-ID: <0JKB000RFBT1RDK0@vms048.mailsrvcs.net>

Robert,

Don't be scaring these people away with such talk about temporary
tables...hehehehehehe. ;)

Actually though, Access ADPs handling of sprocs were a pre-cursor to the SQL
management studio interface. I remember the ALTER and CREATE statements when
you worked via the ADP interface. 

Eric

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Robert
Sent: Wednesday, June 27, 2007 1:40 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures

<snipped the rest>  And, there are limits to how Access can handle SPs as
well.  It does not like the use of temporary tables at all.

Robert

At 03:25 PM 6/27/2007, you wrote:
>Date: Wed, 27 Jun 2007 11:54:04 -0700
>From: "Jennifer Gross" <jengross at gte.net>
>Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures
>To: <dba-sqlserver at databaseadvisors.com>
>Message-ID: <010301c7b8ec$8bcf9be0$6501a8c0 at jefferson>
>Content-Type: text/plain; charset=us-ascii
>
>Hi Robert,
>
>Wow.  I never expected or received such animosity and direct criticism 
>from a request for help from this list or any other I belong to.
>
>Jennifer


 



From jengross at gte.net  Wed Jun 27 16:22:45 2007
From: jengross at gte.net (Jennifer Gross)
Date: Wed, 27 Jun 2007 14:22:45 -0700
Subject: [dba-SQLServer] Viewing and Modifying stored procedures
Message-ID: <013c01c7b901$510c3990$6501a8c0@jefferson>

To keep the thread complete, here is some more helpful information from
David Lewis: (thanks David)

If you open the sproc (right click, modify, or generate script to
clipboard or to new query window or any other method as previously
noted) an ALTER PROC script is automatically generated, as you noted.

You can comment out the autogenerated parts using /*          */ tags,
then play around with the sql script to your heart's content.  To
execute all or part of the sql highlight it and press F5.  If the ALTER
PROC lines have been deleted or commented out, then you don't need to
highlight the sql to execute -- you can simply press F5 and the entire
screen will execute.  If you don't comment out the ALTER PROC portion
before pressing F5 and you HAVE altered the sql script, then the old
procedure will be replaced with the new one.

If you have a long script, or a screen full of many scripts that are
related and are perhaps a work in progress, you can save them in two
ways.  1) File>>Save As   will save it as an .sql file, which is pretty
much just a text file of the sql.  You can also create a sproc with the
mess of scripts and codes just as they are.  I often do that, knowing
that it is a work in progress that I want to come back to, and although
it may be listed under Stored Procedures by EM, it is a sproc in name
only and will not 'work' if executed.

Sometimes when I know there is a piece of code from a sproc that I could
use to base a new query on, I'll open it, copy the section I want to the
clipboard, CTRL-N for a new query window, paste the snippet in there and
go to work on it.  When it is done and I want to turn it into a new view
or sproc, I just add CREATE VIEW or CREATE PROC to the heading along
with anything else needed, and hit F5.  I shut down the other query
window without executing it and the original sproc will remain
unchanged.

HTH.  D. Lewis




From mwp.reid at qub.ac.uk  Wed Jun 27 16:23:45 2007
From: mwp.reid at qub.ac.uk (Martin W Reid)
Date: Wed, 27 Jun 2007 22:23:45 +0100
Subject: [dba-SQLServer] Viewing and Modifying stored procedures
In-Reply-To: <011901c7b8f7$8d3d0d90$6501a8c0@jefferson>
References: <062720071949.22770.4682BF43000AFE3E000058F2219791280203010CD2079C080C03BF969B019607080C@mchsi.com>,
	<011901c7b8f7$8d3d0d90$6501a8c0@jefferson>
Message-ID: <E59F7B6A13672C408C58831FF0622B3198B8968C@EX2K7-VIRT-1.ads.qub.ac.uk>

If you right click in the text editor you can use a QBE for basic SQL etc.

Martin


Martin Reid
Telephone: 02890974465



From jengross at gte.net  Wed Jun 27 16:33:09 2007
From: jengross at gte.net (Jennifer Gross)
Date: Wed, 27 Jun 2007 14:33:09 -0700
Subject: [dba-SQLServer] Viewing and Modifying stored procedures
In-Reply-To: <0JKB00654BFFJAI1@vms169131.mailsrvcs.net>
Message-ID: <013f01c7b902$c4f19bb0$6501a8c0@jefferson>

Robert,

It is interesting that you thought I was complaining, because in my mind
that is not what was happening.  I was asking for help, trying to grasp
a concept, thinking that I am not explaining myself well, so I try to
restate my question to be more clear.  When, yes, it is me who is not
understanding.  Now I think I do, thanks to everyone's help.

Jennifer

-----Original Message-----
From: Robert [mailto:rl_stewart at highstream.net] 
Sent: Wednesday, June 27, 2007 1:40 PM
To: dba-sqlserver at databaseadvisors.com
Cc: jengross at gte.net
Subject: Re: Viewing and Modifying stored procedures


Jennifer,

It was not meant as animosity.  I am trying to lay
out the facts of it to you. Yet, you keep trying
to find a way to do it the way you want it to
work.  It simply does not do it. I learned a
long time ago to not beat my head against the
Microsoft Brick Wall. It is the way they do it.
I prefer not to get a bloody forehead and headaches.
So, I walk around the barriers they throw up and
use it without complaining. It simply is a waste of
time and effort to complain.  There is too much to
do to keep up as it is without wasting the time and
effort on things that I cannot change. And, yes
it was direct criticism. I am trying to save you
from banging your head against that wall. Concentrate
your efforts on learning, not complaining. You will
get much further and have much better code and
programs in general if you will do that.

I apologize for the perception you got that my words
carried animosity toward you.  Again, none was intended.

I read through the other answers to your last post and
I think that you have it.  Except for one minor thing.
When you save an SP, it will bring up a dialog box asking
you where you want to save it to.  It then will save it as
a script that can then be put into a version control system
or used at a later date to synchronize changes made in a development
system to a production system.  Because of this, moving changes, it will
also be very good if you learn the DDL (data definition language)
portion of T-SQL so you can also script changes to the tables, indexes,
constraints and such.

The only way a change is made to the SP once it is created
is through the ALTER PROCEDURE portion of the statement. Similarly,you
can only create one using the CREATE PROCEDURE portion of the statement.
Once you get accustomed to it, it really does make sense.

Access shields us from a lot of things.  It is actually more difficult,
I think, to create an SP in an Access ADP program than in Management
Studio. And, there are limits to how Access can handle SPs as well.  It
does not like the use of temporary tables at all.

Robert

At 03:25 PM 6/27/2007, you wrote:
>Date: Wed, 27 Jun 2007 11:54:04 -0700
>From: "Jennifer Gross" <jengross at gte.net>
>Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures
>To: <dba-sqlserver at databaseadvisors.com>
>Message-ID: <010301c7b8ec$8bcf9be0$6501a8c0 at jefferson>
>Content-Type: text/plain; charset=us-ascii
>
>Hi Robert,
>
>Wow.  I never expected or received such animosity and direct criticism 
>from a request for help from this list or any other I belong to.
>
>Jennifer






From chizotz at mchsi.com  Wed Jun 27 16:35:47 2007
From: chizotz at mchsi.com (Ron Allen)
Date: Wed, 27 Jun 2007 21:35:47 +0000
Subject: [dba-SQLServer] Viewing and Modifying stored procedures
Message-ID: <062720072135.23620.4682D833000400AA00005C44219791336303010CD2079C080C03BF969B019607080C@mchsi.com>

Yes, this is *exactly* how I work too. 

Jennifer, you may be correct that the ALTER syntax is not technically a part 
of the SP at some lower level. Conceptually, when I made the transition from 
Access to SQL Server I personally found it easier to think of it that way; I 
was hoping to help you over that "hump".

Ron


----------------------  Original Message:  ---------------------
From:    "Jennifer Gross" <jengross at gte.net>
To:      "SQL Server List" <dba-sqlserver at databaseadvisors.com>
Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures
Date:    Wed, 27 Jun 2007 21:26:45 +0000

> To keep the thread complete, here is some more helpful information from
> David Lewis: (thanks David)
> 
> If you open the sproc (right click, modify, or generate script to
> clipboard or to new query window or any other method as previously
> noted) an ALTER PROC script is automatically generated, as you noted.
> 
> You can comment out the autogenerated parts using /*          */ tags,
> then play around with the sql script to your heart's content.  To
> execute all or part of the sql highlight it and press F5.  If the ALTER
> PROC lines have been deleted or commented out, then you don't need to
> highlight the sql to execute -- you can simply press F5 and the entire
> screen will execute.  If you don't comment out the ALTER PROC portion
> before pressing F5 and you HAVE altered the sql script, then the old
> procedure will be replaced with the new one.
> 
> If you have a long script, or a screen full of many scripts that are
> related and are perhaps a work in progress, you can save them in two
> ways.  1) File>>Save As   will save it as an .sql file, which is pretty
> much just a text file of the sql.  You can also create a sproc with the
> mess of scripts and codes just as they are.  I often do that, knowing
> that it is a work in progress that I want to come back to, and although
> it may be listed under Stored Procedures by EM, it is a sproc in name
> only and will not 'work' if executed.
> 
> Sometimes when I know there is a piece of code from a sproc that I could
> use to base a new query on, I'll open it, copy the section I want to the
> clipboard, CTRL-N for a new query window, paste the snippet in there and
> go to work on it.  When it is done and I want to turn it into a new view
> or sproc, I just add CREATE VIEW or CREATE PROC to the heading along
> with anything else needed, and hit F5.  I shut down the other query
> window without executing it and the original sproc will remain
> unchanged.
> 
> HTH.  D. Lewis
> 
> 
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
> 


From jengross at gte.net  Wed Jun 27 16:54:51 2007
From: jengross at gte.net (Jennifer Gross)
Date: Wed, 27 Jun 2007 14:54:51 -0700
Subject: [dba-SQLServer] Viewing and Modifying stored procedures
In-Reply-To: <062720072135.23620.4682D833000400AA00005C44219791336303010CD2079C080C03BF969B019607080C@mchsi.com>
Message-ID: <014201c7b905$ccf0b2d0$6501a8c0@jefferson>

It's all coming together and starting to jell and take shape in my mind.
I appreciate the feedback.

Jennifer

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Ron
Allen
Sent: Wednesday, June 27, 2007 2:36 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures


Yes, this is *exactly* how I work too. 

Jennifer, you may be correct that the ALTER syntax is not technically a
part 
of the SP at some lower level. Conceptually, when I made the transition
from 
Access to SQL Server I personally found it easier to think of it that
way; I 
was hoping to help you over that "hump".

Ron


----------------------  Original Message:  ---------------------
From:    "Jennifer Gross" <jengross at gte.net>
To:      "SQL Server List" <dba-sqlserver at databaseadvisors.com>
Subject: Re: [dba-SQLServer] Viewing and Modifying stored procedures
Date:    Wed, 27 Jun 2007 21:26:45 +0000

> To keep the thread complete, here is some more helpful information 
> from David Lewis: (thanks David)
> 
> If you open the sproc (right click, modify, or generate script to 
> clipboard or to new query window or any other method as previously
> noted) an ALTER PROC script is automatically generated, as you noted.
> 
> You can comment out the autogenerated parts using /*          */ tags,
> then play around with the sql script to your heart's content.  To 
> execute all or part of the sql highlight it and press F5.  If the 
> ALTER PROC lines have been deleted or commented out, then you don't 
> need to highlight the sql to execute -- you can simply press F5 and 
> the entire screen will execute.  If you don't comment out the ALTER 
> PROC portion before pressing F5 and you HAVE altered the sql script, 
> then the old procedure will be replaced with the new one.
> 
> If you have a long script, or a screen full of many scripts that are 
> related and are perhaps a work in progress, you can save them in two
> ways.  1) File>>Save As   will save it as an .sql file, which is
pretty
> much just a text file of the sql.  You can also create a sproc with 
> the mess of scripts and codes just as they are.  I often do that, 
> knowing that it is a work in progress that I want to come back to, and

> although it may be listed under Stored Procedures by EM, it is a sproc

> in name only and will not 'work' if executed.
> 
> Sometimes when I know there is a piece of code from a sproc that I 
> could use to base a new query on, I'll open it, copy the section I 
> want to the clipboard, CTRL-N for a new query window, paste the 
> snippet in there and go to work on it.  When it is done and I want to 
> turn it into a new view or sproc, I just add CREATE VIEW or CREATE 
> PROC to the heading along with anything else needed, and hit F5.  I 
> shut down the other query window without executing it and the original

> sproc will remain unchanged.
> 
> HTH.  D. Lewis
> 
> 
> _______________________________________________
> 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 jwcolby at colbyconsulting.com  Fri Jun 29 12:28:08 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Fri, 29 Jun 2007 13:28:08 -0400
Subject: [dba-SQLServer] Move table between databases
Message-ID: <20070629172813.5884BBE72@smtp-auth.no-ip.com>

I need to move a "raw data" table out into it's own separate database file.
One way I could do this is to copy the database file, then go in and delete
all the other tables in that database.  What I would prefer is to somehow
copy the table itself, INCLUDING ALL INDEXES, out to another database.  Is
that possible?  If so how?

John W. Colby
Colby Consulting
www.ColbyConsulting.com 



From mikedorism at verizon.net  Fri Jun 29 14:10:33 2007
From: mikedorism at verizon.net (Doris Manning)
Date: Fri, 29 Jun 2007 15:10:33 -0400
Subject: [dba-SQLServer] Move table between databases
In-Reply-To: <20070629172813.5884BBE72@smtp-auth.no-ip.com>
References: <20070629172813.5884BBE72@smtp-auth.no-ip.com>
Message-ID: <001001c7ba81$2b742d10$2f01a8c0@Kermit>

You can transfer the table to the new database using the DTS Export Wizard.

Doris Manning
Database Administrator
Hargrove Inc.

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Friday, June 29, 2007 1:28 PM
To: dba-sqlserver at databaseadvisors.com
Subject: [dba-SQLServer] Move table between databases

I need to move a "raw data" table out into it's own separate database file.
One way I could do this is to copy the database file, then go in and delete
all the other tables in that database.  What I would prefer is to somehow
copy the table itself, INCLUDING ALL INDEXES, out to another database.  Is
that possible?  If so how?

John W. Colby
Colby Consulting
www.ColbyConsulting.com 

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





From ebarro at verizon.net  Fri Jun 29 14:24:28 2007
From: ebarro at verizon.net (Eric Barro)
Date: Fri, 29 Jun 2007 12:24:28 -0700
Subject: [dba-SQLServer] Move table between databases
In-Reply-To: <20070629172813.5884BBE72@smtp-auth.no-ip.com>
Message-ID: <0JKE00GIYWL1NF95@vms042.mailsrvcs.net>

1. Script the table including indexes.
2. Import the data to the other database.

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Friday, June 29, 2007 10:28 AM
To: dba-sqlserver at databaseadvisors.com
Subject: [dba-SQLServer] Move table between databases

I need to move a "raw data" table out into it's own separate database file.
One way I could do this is to copy the database file, then go in and delete
all the other tables in that database.  What I would prefer is to somehow
copy the table itself, INCLUDING ALL INDEXES, out to another database.  Is
that possible?  If so how?

John W. Colby
Colby Consulting
www.ColbyConsulting.com 

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


 



From JRojas at tnco-inc.com  Fri Jun 29 15:29:20 2007
From: JRojas at tnco-inc.com (Joe Rojas)
Date: Fri, 29 Jun 2007 16:29:20 -0400
Subject: [dba-SQLServer] SQL 2005 - Moving System Databases to Another Drive
References: <0JKE00GIYWL1NF95@vms042.mailsrvcs.net>
Message-ID: <758E92433C4F3740B67BE4DD369AF5775C4F26@ex2k3.corp.tnco-inc.com>

Hello,

I recently install SQL Server 2005, for the first time, and I apparently
miss the step where you can change the location where the databases are
stored.
Right now, all the system databases are on my C drive and I want to move
them to my E drive.

How is this accomplished in SQL 2005?

Joe Rojas
Information Technology Manager
Symmetry Medical TNCO
15 Colebrook Blvd
Whitman MA 02382
781-447-6661 x7506
jrojas at tnco-inc.com



From jwcolby at colbyconsulting.com  Fri Jun 29 15:45:02 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Fri, 29 Jun 2007 16:45:02 -0400
Subject: [dba-SQLServer] 64 bit MYSql on 64 bit linux
Message-ID: <20070629204507.1CB9EBF80@smtp-auth.no-ip.com>

Is anyone using 64 bit database / OS software?  My databases are so large
that having 2 mb memory constraints are killing me (gut feeling here).  But
once I start looking at x64 versions of Windows Server and in particular x64
versions of SQL Server the prices skyrocket.  I will be paying more for the
licenses for those two things (for EACH processor chip) than I will for the
entire machine hardware, and it is pretty heavy duty hardware.

Thus I need to at least examine Linux / MySQL assuming that I can get 64 bit
versions.

John W. Colby
Colby Consulting
www.ColbyConsulting.com 



From jwcolby at colbyconsulting.com  Sat Jun 30 08:28:02 2007
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Sat, 30 Jun 2007 09:28:02 -0400
Subject: [dba-SQLServer] Temp Tables
Message-ID: <20070630132808.2BC00BC79@smtp-auth.no-ip.com>

It just occurred to me that perhaps I need to be working with temp tables
more.  

I have queries against 65 million record tables with WHERE clauses with
anywhere from 4 to 20 fields.  If I broke my queries against my huge tables
into base query that pulled a data set into a temp table based on one of
those fields, and then ran the remainder of my where clause against the
smaller temp table I think I might get a speed bump.

Any thoughts on that?

John W. Colby
Colby Consulting
www.ColbyConsulting.com