From subs1847 at solution-providers.ie  Tue Jun  1 07:47:22 2004
From: subs1847 at solution-providers.ie (Mark L. Breen)
Date: Tue, 1 Jun 2004 13:47:22 +0100
Subject: [dba-SQLServer] Error Trapping and temp tables
References: <000a01c446e4$dc0b6a80$0101a8c0@D8TZHN0J>
	<40BB6DBE.2030909@shaw.ca>
Message-ID: <004a01c447d6$d0609320$0101a8c0@D8TZHN0J>

Hello Marty,

I love what he is doing, a great idea, I heard about the same concept a few
years ago when I worked on a project with the Honourable Mr Colby.

However, what I omitted to mention was that it was VB and SQL not Access,
although as the question was in the SQL group, I may possible be excused.

In the end, I read one article that suggested that temp tables in SQL server
are resource intensive, especially on RAM, so I decided to use standard
tables as these temp tables will be having large throughput of data, even
though they will hold very little data, 1 million records per month roughly.

Thanks again for the help,

Mark


----- Original Message ----- 
From: "MartyConnelly" <martyconnelly at shaw.ca>
To: <dba-sqlserver at databaseadvisors.com>
Sent: Monday, May 31, 2004 6:39 PM
Subject: Re: [dba-SQLServer] Error Trapping and temp tables


> You should create temp tables in a temp mdb. Saves on bloat among other
> things.
> See Tony Toews method
>
> http://www.granite.ab.ca/access/temptables.htm
>
> Mark L. Breen wrote:
>
> >Hello All,
> >
> >I am developing a db and intend to use a temp table. Before use I create
it and after use I drop it.
> >
> >However, because I fear it may somehow remain in the system, I would
prefer to do a
> >
> >If exists (table name) drop table name
> >
> >But it is not that easy with temp tables, as you know, so I was
considering using a vb function that attempts to drop the table, I can catch
the error in vb, I hope, and ignore it.
> >
> >Have you guys any better suggestions how to do this.
> >
> >Basically, I want to check for the existence of a temp table and drop it
if it exists.
> >
> >Thanks in advance,
> >
> >Mark
> >_______________________________________________
> >dba-SQLServer mailing list
> >dba-SQLServer at databaseadvisors.com
> >http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> >http://www.databaseadvisors.com
> >
> >
> >
> >
>
> -- 
> Marty Connelly
> Victoria, B.C.
> Canada
>
>
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>



From michael.broesdorf at web.de  Thu Jun  3 02:44:53 2004
From: michael.broesdorf at web.de (=?us-ascii?Q?Michael_Brosdorf?=)
Date: Thu, 3 Jun 2004 09:44:53 +0200
Subject: [dba-SQLServer] DTS question
In-Reply-To: <037c01c44578$f4033720$6601a8c0@rock>
Message-ID: <NEBBIILOPOPJBCLJIJHHOELMFIAA.michael.broesdorf@web.de>

Hi all

I am a little confused about where exactly DTS packages run.

Do they run on the SQL Server machine or do they run on the machine where I
use EM?
And does it make a difference, if I use EM or call the packages from within
my Access FE (using the DTS Package library)?


Michael




From mikedorism at adelphia.net  Thu Jun  3 06:10:49 2004
From: mikedorism at adelphia.net (Mike & Doris Manning)
Date: Thu, 3 Jun 2004 07:10:49 -0400
Subject: [dba-SQLServer] DTS question
In-Reply-To: <NEBBIILOPOPJBCLJIJHHOELMFIAA.michael.broesdorf@web.de>
Message-ID: <000201c4495b$6d4ed130$cc0aa845@hargrove.internal>

DTS packages run on the machine where you use EM.  Basically they make
activity requests of SQL Server just as if you were asking it to run a
stored procedure or view.

The only time I have noticed it making a difference where the DTS package
was run from is in the case of a process that needs to use a file in a
particular drive.

Doris Manning
Database Administrator
Hargrove Inc.
www.hargroveinc.com


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Michael
Brosdorf
Sent: Thursday, June 03, 2004 3:45 AM
To: dba-sqlserver at databaseadvisors.com
Subject: [dba-SQLServer] DTS question


Hi all

I am a little confused about where exactly DTS packages run.

Do they run on the SQL Server machine or do they run on the machine where I
use EM? And does it make a difference, if I use EM or call the packages from
within my Access FE (using the DTS Package library)?


Michael


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




From John.Maxwell2 at ntl.com  Thu Jun  3 06:20:16 2004
From: John.Maxwell2 at ntl.com (John Maxwell @ London City)
Date: Thu, 3 Jun 2004 12:20:16 +0100
Subject: [dba-SQLServer] DTS question
Message-ID: <D7114154CB8DD2118F030008C70D52FC065C9A89@mast-ln0-se01.private.ntl.com>

I think that Network Traffic - ie.Speed of transfer may be an issue.

Only noticed this when EM was on lap top using dial up. - Transformation was
not too speedy to say the least.
Presume files were going via my dial up connection.

Very new to DTS so only more than willing to be corrected.


john

-----Original Message-----
From: Mike & Doris Manning [mailto:mikedorism at adelphia.net]
Sent: 03 June 2004 12:11
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] DTS question


DTS packages run on the machine where you use EM.  Basically they make
activity requests of SQL Server just as if you were asking it to run a
stored procedure or view.

The only time I have noticed it making a difference where the DTS package
was run from is in the case of a process that needs to use a file in a
particular drive.

Doris Manning
Database Administrator
Hargrove Inc.
www.hargroveinc.com


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Michael
Brosdorf
Sent: Thursday, June 03, 2004 3:45 AM
To: dba-sqlserver at databaseadvisors.com
Subject: [dba-SQLServer] DTS question


Hi all

I am a little confused about where exactly DTS packages run.

Do they run on the SQL Server machine or do they run on the machine where I
use EM? And does it make a difference, if I use EM or call the packages from
within my Access FE (using the DTS Package library)?


Michael


_______________________________________________
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


The contents of this email and any attachments are sent for the personal attention
of the addressee(s) only and may be confidential.  If you are not the intended
addressee, any use, disclosure or copying of this email and any attachments is
unauthorised - please notify the sender by return and delete the message.  Any
representations or commitments expressed in this email are subject to contract. 
 
ntl Group Limited



From DElam at jenkens.com  Thu Jun  3 16:40:15 2004
From: DElam at jenkens.com (Elam, Debbie)
Date: Thu, 3 Jun 2004 16:40:15 -0500 
Subject: [dba-SQLServer] DTS question
Message-ID: <7B1961ED924D1A459E378C9B1BB22B4C02485038@natexch.jenkens.com>

I have run DTS packacges both from my desktop and on the server.  I do not
think that DTS packages are set to run a particular place.  Most people
schedule them using the scheduler in SQL and in that case, they are running
on the server.

Debbie

-----Original Message-----
From: Michael Brosdorf [mailto:michael.broesdorf at web.de] 
Sent: Thursday, June 03, 2004 2:45 AM
To: dba-sqlserver at databaseadvisors.com
Subject: [dba-SQLServer] DTS question


Hi all

I am a little confused about where exactly DTS packages run.

Do they run on the SQL Server machine or do they run on the machine where I
use EM? And does it make a difference, if I use EM or call the packages from
within my Access FE (using the DTS Package library)?


Michael


_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com
- JENKENS & GILCHRIST E-MAIL NOTICE - This transmission may be: (1) subject
to the Attorney-Client Privilege, (2) an attorney work product, or (3)
strictly confidential. If you are not the intended recipient of this
message, you may not disclose, print, copy or disseminate this information.
If you have received this in error, please reply and notify the sender
(only) and delete the message. Unauthorized interception of this e-mail is a
violation of federal criminal law. 
This communication does not reflect an intention by the sender or the
sender's client or principal to conduct a transaction or make any agreement
by electronic means.  Nothing contained in this message or in any attachment
shall satisfy the requirements for a writing, and nothing contained herein
shall constitute a contract or electronic signature under the Electronic
Signatures in Global and National Commerce Act, any version of the Uniform
Electronic Transactions Act or any other statute governing electronic
transactions.


From davide at dalyn.co.nz  Thu Jun  3 21:49:09 2004
From: davide at dalyn.co.nz (David Emerson)
Date: Fri, 04 Jun 2004 14:49:09 +1200
Subject: [dba-SQLServer] Finding current user role
Message-ID: <5.2.0.9.0.20040604143400.00b2ba00@mail.dalyn.co.nz>

SQL2000  AXP ade

I am using Windows NT Integrated security.  The users will be members of NT 
Groups (specifically set up for the SQL databases), and the NT Groups will 
be members of SQL Roles.  SQL permissions are then applied to the roles.

However, within the ade I would like to know what role the current user 
belongs to so I can make the form changes.  Is there a system command that 
will give me this info?

Regards

David Emerson
Dalyn Software Ltd
25 Cunliffe St, Churton Park
Wellington, New Zealand
Ph/Fax (04) 478-7456
Mobile 027-280-9348 



From stuart at lexacorp.com.pg  Thu Jun  3 22:56:37 2004
From: stuart at lexacorp.com.pg (Stuart McLachlan)
Date: Fri, 04 Jun 2004 13:56:37 +1000
Subject: [dba-SQLServer] Finding current user role
In-Reply-To: <5.2.0.9.0.20040604143400.00b2ba00@mail.dalyn.co.nz>
Message-ID: <40C07F95.32150.944AE@localhost>

On 4 Jun 2004 at 14:49, David Emerson wrote:

> SQL2000  AXP ade
> 
> I am using Windows NT Integrated security.  The users will be members of NT 
> Groups (specifically set up for the SQL databases), and the NT Groups will 
> be members of SQL Roles.  SQL permissions are then applied to the roles.
> 
> However, within the ade I would like to know what role the current user 
> belongs to so I can make the form changes.  Is there a system command that 
> will give me this info?
> 


Take a look at sp_helpuser and current_user

 
-- 
Lexacorp Ltd
http://www.lexacorp.com.pg
Information Technology Consultancy, Software Development,System Support.





From chris at denverdb.com  Thu Jun  3 23:04:07 2004
From: chris at denverdb.com (Chris Mackin)
Date: Thu, 3 Jun 2004 22:04:07 -0600
Subject: [dba-SQLServer] Finding current user role
In-Reply-To: <5.2.0.9.0.20040604143400.00b2ba00@mail.dalyn.co.nz>
Message-ID: <GGENIBBECLOHCDNANHMOAENHEKAA.chris@denverdb.com>

Look in BOL at "sp_helprolemember", I use that to find what roles each user
is in.

-Chris Mackin

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of David
Emerson
Sent: Thursday, June 03, 2004 8:49 PM
To: dba-SQLServer at databaseadvisors.com
Subject: [dba-SQLServer] Finding current user role


SQL2000  AXP ade

I am using Windows NT Integrated security.  The users will be members of NT
Groups (specifically set up for the SQL databases), and the NT Groups will
be members of SQL Roles.  SQL permissions are then applied to the roles.

However, within the ade I would like to know what role the current user
belongs to so I can make the form changes.  Is there a system command that
will give me this info?

Regards

David Emerson
Dalyn Software Ltd
25 Cunliffe St, Churton Park
Wellington, New Zealand
Ph/Fax (04) 478-7456
Mobile 027-280-9348

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







From davide at dalyn.co.nz  Thu Jun  3 23:18:30 2004
From: davide at dalyn.co.nz (David Emerson)
Date: Fri, 04 Jun 2004 16:18:30 +1200
Subject: [dba-SQLServer] Finding current user role
In-Reply-To: <40C07F95.32150.944AE@localhost>
References: <5.2.0.9.0.20040604143400.00b2ba00@mail.dalyn.co.nz>
Message-ID: <5.2.0.9.0.20040604161815.00b2bbb0@mail.dalyn.co.nz>

Thanks Stuart (and Chris)

David

At 4/06/2004, you wrote:
>On 4 Jun 2004 at 14:49, David Emerson wrote:
>
> > SQL2000  AXP ade
> >
> > I am using Windows NT Integrated security.  The users will be members 
> of NT
> > Groups (specifically set up for the SQL databases), and the NT Groups will
> > be members of SQL Roles.  SQL permissions are then applied to the roles.
> >
> > However, within the ade I would like to know what role the current user
> > belongs to so I can make the form changes.  Is there a system command that
> > will give me this info?
> >
>
>
>Take a look at sp_helpuser and current_user
>
>
>--
>Lexacorp Ltd
>http://www.lexacorp.com.pg
>Information Technology Consultancy, Software Development,System Support.
>
>
>
>_______________________________________________
>dba-SQLServer mailing list
>dba-SQLServer at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>http://www.databaseadvisors.com



From michael.broesdorf at web.de  Mon Jun  7 03:28:40 2004
From: michael.broesdorf at web.de (=?US-ASCII?Q?Michael_Brosdorf?=)
Date: Mon, 7 Jun 2004 10:28:40 +0200
Subject: AW: [dba-SQLServer] DTS question
In-Reply-To: <000201c4495b$6d4ed130$cc0aa845@hargrove.internal>
Message-ID: <NEBBIILOPOPJBCLJIJHHCEOOFIAA.michael.broesdorf@web.de>

Does that mean that the SQL contained in an Execute SQL Task is sent to the
server and processed there?
How about Transfer Data Tasks? Is all data read over the network to the
client machine?

Michael

-----Ursprungliche Nachricht-----
Von: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]Im Auftrag von Mike &
Doris Manning
Gesendet: Donnerstag, 3. Juni 2004 13:11
An: dba-sqlserver at databaseadvisors.com
Betreff: RE: [dba-SQLServer] DTS question


DTS packages run on the machine where you use EM.  Basically they make
activity requests of SQL Server just as if you were asking it to run a
stored procedure or view.

The only time I have noticed it making a difference where the DTS package
was run from is in the case of a process that needs to use a file in a
particular drive.

Doris Manning
Database Administrator
Hargrove Inc.
www.hargroveinc.com


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Michael
Brosdorf
Sent: Thursday, June 03, 2004 3:45 AM
To: dba-sqlserver at databaseadvisors.com
Subject: [dba-SQLServer] DTS question


Hi all

I am a little confused about where exactly DTS packages run.

Do they run on the SQL Server machine or do they run on the machine where I
use EM? And does it make a difference, if I use EM or call the packages from
within my Access FE (using the DTS Package library)?


Michael


_______________________________________________
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 mikedorism at adelphia.net  Mon Jun  7 04:57:28 2004
From: mikedorism at adelphia.net (Mike & Doris Manning)
Date: Mon, 7 Jun 2004 05:57:28 -0400
Subject: [dba-SQLServer] DTS question
In-Reply-To: <NEBBIILOPOPJBCLJIJHHCEOOFIAA.michael.broesdorf@web.de>
Message-ID: <000201c44c75$d7cb3540$cc0aa845@hargrove.internal>

If you are using EM on a client machine, then the DTS package is executing
on the client machine and not the server.  I discovered this because I have
some packages that open an Access database and process a report.  The
packages fail if I'm not on the server itself because I hardcode the path to
the database using the server's drive mappings.

I believe that SQL contained in an Execute SQL Task is sent the server and
processed there just like any other sproc or view.  I believe a Transfer
Data Task is reading all the data over the network to the client and then
being processed.

If my beliefs are incorrect, someone please speak up because I'd be very
happy to be corrected on this.

Doris Manning
Database Administrator
Hargrove Inc.
www.hargroveinc.com


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Michael
Brosdorf
Sent: Monday, June 07, 2004 4:29 AM
To: dba-sqlserver at databaseadvisors.com
Subject: AW: [dba-SQLServer] DTS question


Does that mean that the SQL contained in an Execute SQL Task is sent to the
server and processed there? How about Transfer Data Tasks? Is all data read
over the network to the client machine?

Michael

-----Ursprungliche Nachricht-----
Von: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]Im Auftrag von Mike &
Doris Manning
Gesendet: Donnerstag, 3. Juni 2004 13:11
An: dba-sqlserver at databaseadvisors.com
Betreff: RE: [dba-SQLServer] DTS question


DTS packages run on the machine where you use EM.  Basically they make
activity requests of SQL Server just as if you were asking it to run a
stored procedure or view.

The only time I have noticed it making a difference where the DTS package
was run from is in the case of a process that needs to use a file in a
particular drive.

Doris Manning
Database Administrator
Hargrove Inc.
www.hargroveinc.com


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Michael
Brosdorf
Sent: Thursday, June 03, 2004 3:45 AM
To: dba-sqlserver at databaseadvisors.com
Subject: [dba-SQLServer] DTS question


Hi all

I am a little confused about where exactly DTS packages run.

Do they run on the SQL Server machine or do they run on the machine where I
use EM? And does it make a difference, if I use EM or call the packages from
within my Access FE (using the DTS Package library)?


Michael


_______________________________________________
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 michael.broesdorf at web.de  Mon Jun  7 05:19:25 2004
From: michael.broesdorf at web.de (=?US-ASCII?Q?Michael_Brosdorf?=)
Date: Mon, 7 Jun 2004 12:19:25 +0200
Subject: [dba-SQLServer] DTS question
In-Reply-To: <000201c44c75$d7cb3540$cc0aa845@hargrove.internal>
Message-ID: <NEBBIILOPOPJBCLJIJHHOEPAFIAA.michael.broesdorf@web.de>

Thank your for the insight!
If I have the time during the week I will use SQL Profile to find out what
happens with
data transfer tasks.

Michael

-----Ursprungliche Nachricht-----
Von: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]Im Auftrag von Mike &
Doris Manning
Gesendet: Montag, 7. Juni 2004 11:57
An: dba-sqlserver at databaseadvisors.com
Betreff: RE: [dba-SQLServer] DTS question


If you are using EM on a client machine, then the DTS package is executing
on the client machine and not the server.  I discovered this because I have
some packages that open an Access database and process a report.  The
packages fail if I'm not on the server itself because I hardcode the path to
the database using the server's drive mappings.

I believe that SQL contained in an Execute SQL Task is sent the server and
processed there just like any other sproc or view.  I believe a Transfer
Data Task is reading all the data over the network to the client and then
being processed.

If my beliefs are incorrect, someone please speak up because I'd be very
happy to be corrected on this.

Doris Manning
Database Administrator
Hargrove Inc.
www.hargroveinc.com


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Michael
Brosdorf
Sent: Monday, June 07, 2004 4:29 AM
To: dba-sqlserver at databaseadvisors.com
Subject: AW: [dba-SQLServer] DTS question


Does that mean that the SQL contained in an Execute SQL Task is sent to the
server and processed there? How about Transfer Data Tasks? Is all data read
over the network to the client machine?

Michael

-----Ursprungliche Nachricht-----
Von: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]Im Auftrag von Mike &
Doris Manning
Gesendet: Donnerstag, 3. Juni 2004 13:11
An: dba-sqlserver at databaseadvisors.com
Betreff: RE: [dba-SQLServer] DTS question


DTS packages run on the machine where you use EM.  Basically they make
activity requests of SQL Server just as if you were asking it to run a
stored procedure or view.

The only time I have noticed it making a difference where the DTS package
was run from is in the case of a process that needs to use a file in a
particular drive.

Doris Manning
Database Administrator
Hargrove Inc.
www.hargroveinc.com


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Michael
Brosdorf
Sent: Thursday, June 03, 2004 3:45 AM
To: dba-sqlserver at databaseadvisors.com
Subject: [dba-SQLServer] DTS question


Hi all

I am a little confused about where exactly DTS packages run.

Do they run on the SQL Server machine or do they run on the machine where I
use EM? And does it make a difference, if I use EM or call the packages from
within my Access FE (using the DTS Package library)?


Michael


_______________________________________________
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 michael.broesdorf at web.de  Mon Jun  7 11:14:00 2004
From: michael.broesdorf at web.de (=?US-ASCII?Q?Michael_Brosdorf?=)
Date: Mon, 7 Jun 2004 18:14:00 +0200
Subject: [dba-SQLServer] How to add a new job category
In-Reply-To: <NEBBIILOPOPJBCLJIJHHOEPAFIAA.michael.broesdorf@web.de>
Message-ID: <NEBBIILOPOPJBCLJIJHHAEPGFIAA.michael.broesdorf@web.de>

Dear group,

is it possible to add new job categories for the SQL Agent scheduler?
The '...'-button next to the drop down list only display other jobs in 
the selected category, but does not allow adding new categories.

Michael


From cfoust at infostatsystems.com  Tue Jun  8 10:21:39 2004
From: cfoust at infostatsystems.com (Charlotte Foust)
Date: Tue, 8 Jun 2004 08:21:39 -0700
Subject: [dba-SQLServer] Can't Register Server
Message-ID: <E61FC1D4B1918244905B113C680BEA86312844@infoserver01.infostat.local>

I reinstalled SQL 2000 last night, but I can't register the blasted
server.  When I try, it comes back and says it fails because the
connection is open.  This is developer edition on a stand-alone laptop.
I've run into this with every installation of SQL Server on this
machine, although one upon a time I had it working ... Pre-DSL.  My DSL
modem (now replaced with a router) broke SQL on my laptop, so I
uninstalled SQL and have never since been able to get it reinstalled and
working.  Any suggestions?

Charlotte Foust


From prosoft6 at hotmail.com  Tue Jun  8 11:03:52 2004
From: prosoft6 at hotmail.com (Julie Reardon-Taylor)
Date: Tue, 08 Jun 2004 12:03:52 -0400
Subject: [dba-SQLServer] Can't Register Server
Message-ID: <BAY19-F3sINIyzaH8uO00020e0c@hotmail.com>

Charlotte,

Make sure that you don't have an alias sitting out there somewhere.



Julie Reardon-Taylor
PRO-SOFT OF NY, INC.
108 Franklin Street
Watertown, NY 13601
(315) 785-0319
www.pro-soft.net




From cfoust at infostatsystems.com  Tue Jun  8 11:34:25 2004
From: cfoust at infostatsystems.com (Charlotte Foust)
Date: Tue, 8 Jun 2004 09:34:25 -0700
Subject: [dba-SQLServer] Can't Register Server
Message-ID: <E61FC1D4B1918244905B113C680BEA86312845@infoserver01.infostat.local>

I am *NOT* a dba.  I just need the darn thing to program against.
'Splain to me "alias" and how I deal with it.

Charlotte Foust

-----Original Message-----
From: Julie Reardon-Taylor [mailto:prosoft6 at hotmail.com] 
Sent: Tuesday, June 08, 2004 8:04 AM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Can't Register Server


Charlotte,

Make sure that you don't have an alias sitting out there somewhere.



Julie Reardon-Taylor
PRO-SOFT OF NY, INC.
108 Franklin Street
Watertown, NY 13601
(315) 785-0319
www.pro-soft.net


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



From prosoft6 at hotmail.com  Tue Jun  8 11:55:25 2004
From: prosoft6 at hotmail.com (Julie Reardon-Taylor)
Date: Tue, 08 Jun 2004 12:55:25 -0400
Subject: [dba-SQLServer] Can't Register Server
Message-ID: <BAY19-F91Jb887fyE8e0005f057@hotmail.com>

Sorry, deleted your original question.  Have you performed the server 
registration?



Julie Reardon-Taylor
PRO-SOFT OF NY, INC.
108 Franklin Street
Watertown, NY 13601
(315) 785-0319
www.pro-soft.net




From my.lists at verizon.net  Tue Jun  8 11:57:38 2004
From: my.lists at verizon.net (Francisco H Tapia)
Date: Tue, 08 Jun 2004 09:57:38 -0700
Subject: [dba-SQLServer] Can't Register Server
In-Reply-To: <E61FC1D4B1918244905B113C680BEA86312844@infoserver01.infostat.local>
References: <E61FC1D4B1918244905B113C680BEA86312844@infoserver01.infostat.local>
Message-ID: <40C5F002.5030808@verizon.net>

Charlotte,
   Excuse me but how exactly does DSL break SQL Server???
I have the developer version on my Windows 2000 PRO SP4 at home and it 
runs fine and even when I got a router all I did was litterally power 
down the pc, install the router and then power it back up... I 
litterally had not configuration issues.

Did you load any software because of your DSL?


Charlotte Foust wrote On 6/8/2004 8:21 AM:

>I reinstalled SQL 2000 last night, but I can't register the blasted
>server.  When I try, it comes back and says it fails because the
>connection is open.  This is developer edition on a stand-alone laptop.
>I've run into this with every installation of SQL Server on this
>machine, although one upon a time I had it working ... Pre-DSL.  My DSL
>modem (now replaced with a router) broke SQL on my laptop, so I
>uninstalled SQL and have never since been able to get it reinstalled and
>working.  Any suggestions?
>
>Charlotte Foust
>  
>


-- 
-Francisco




From my.lists at verizon.net  Tue Jun  8 11:58:16 2004
From: my.lists at verizon.net (Francisco H Tapia)
Date: Tue, 08 Jun 2004 09:58:16 -0700
Subject: [dba-SQLServer] Can't Register Server
In-Reply-To: <E61FC1D4B1918244905B113C680BEA86312844@infoserver01.infostat.local>
References: <E61FC1D4B1918244905B113C680BEA86312844@infoserver01.infostat.local>
Message-ID: <40C5F028.6080702@verizon.net>

Are you trying to register it as a Windows Authentication or via the SA 
account?

Charlotte Foust wrote On 6/8/2004 8:21 AM:

>I reinstalled SQL 2000 last night, but I can't register the blasted
>server.  When I try, it comes back and says it fails because the
>connection is open.  This is developer edition on a stand-alone laptop.
>I've run into this with every installation of SQL Server on this
>machine, although one upon a time I had it working ... Pre-DSL.  My DSL
>modem (now replaced with a router) broke SQL on my laptop, so I
>uninstalled SQL and have never since been able to get it reinstalled and
>working.  Any suggestions?
>  
>


-- 
-Francisco




From shamil-users at mns.ru  Tue Jun  8 13:04:18 2004
From: shamil-users at mns.ru (Shamil Salakhetdinov)
Date: Tue, 8 Jun 2004 22:04:18 +0400
Subject: [dba-SQLServer] How to add a new job category
References: <NEBBIILOPOPJBCLJIJHHAEPGFIAA.michael.broesdorf@web.de>
Message-ID: <007501c44d83$0aacd550$0201a8c0@PARIS>

<YourSQLServer> -> Management->SQL Server Agent->
Jobs->RightClick->Manage Job Categories -> Add...

select * from msdb..syscategories -- list all available categories

EXEC sp_help_category @class = 'JOB' -- list job class categories

See BO for more inforation...

HTH,
Shamil

----- Original Message ----- 
From: "Michael Brosdorf" <michael.broesdorf at web.de>
To: <dba-sqlserver at databaseadvisors.com>
Sent: Monday, June 07, 2004 8:14 PM
Subject: [dba-SQLServer] How to add a new job category


> Dear group,
>
> is it possible to add new job categories for the SQL Agent scheduler?
> The '...'-button next to the drop down list only display other jobs in
> the selected category, but does not allow adding new categories.
>
> Michael
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>



From tuxedo_man at hotmail.com  Tue Jun  8 14:09:27 2004
From: tuxedo_man at hotmail.com (Billy Pang)
Date: Tue, 08 Jun 2004 19:09:27 +0000
Subject: [dba-SQLServer] Can't Register Server
Message-ID: <BAY1-F154fb81IfpT8v0000f9b1@hotmail.com>

Alias is like a nickname you give to remote sql server that tells your sql 
server client how to connect to remote sql server.

You can manage aliases via the Client Network Utility:

START --> PROGRAMS --> SQL SERVER --> CLIENT NETWORK UTILITY

>From there, click on the Alias tab and select your network protocol and 
related settings.

Billy


>From: "Charlotte Foust" <cfoust at infostatsystems.com>
>Reply-To: dba-sqlserver at databaseadvisors.com
>To: <dba-sqlserver at databaseadvisors.com>
>Subject: RE: [dba-SQLServer] Can't Register Server
>Date: Tue, 8 Jun 2004 09:34:25 -0700
>
>I am *NOT* a dba.  I just need the darn thing to program against.
>'Splain to me "alias" and how I deal with it.
>
>Charlotte Foust
>
>-----Original Message-----
>From: Julie Reardon-Taylor [mailto:prosoft6 at hotmail.com]
>Sent: Tuesday, June 08, 2004 8:04 AM
>To: dba-sqlserver at databaseadvisors.com
>Subject: RE: [dba-SQLServer] Can't Register Server
>
>
>Charlotte,
>
>Make sure that you don't have an alias sitting out there somewhere.
>
>
>
>Julie Reardon-Taylor
>PRO-SOFT OF NY, INC.
>108 Franklin Street
>Watertown, NY 13601
>(315) 785-0319
>www.pro-soft.net
>
>
>_______________________________________________
>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
>

_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN Premium   
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines



From cfoust at infostatsystems.com  Tue Jun  8 14:55:35 2004
From: cfoust at infostatsystems.com (Charlotte Foust)
Date: Tue, 8 Jun 2004 12:55:35 -0700
Subject: [dba-SQLServer] Can't Register Server
Message-ID: <E61FC1D4B1918244905B113C680BEA86312847@infoserver01.infostat.local>

Windows Authentication.  It's been years since I had to do this, so my
memory fails me.

Charlotte Foust

-----Original Message-----
From: Francisco H Tapia [mailto:my.lists at verizon.net] 
Sent: Tuesday, June 08, 2004 8:58 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Can't Register Server


Are you trying to register it as a Windows Authentication or via the SA 
account?

Charlotte Foust wrote On 6/8/2004 8:21 AM:

>I reinstalled SQL 2000 last night, but I can't register the blasted 
>server.  When I try, it comes back and says it fails because the 
>connection is open.  This is developer edition on a stand-alone laptop.

>I've run into this with every installation of SQL Server on this 
>machine, although one upon a time I had it working ... Pre-DSL.  My DSL

>modem (now replaced with a router) broke SQL on my laptop, so I 
>uninstalled SQL and have never since been able to get it reinstalled 
>and working.  Any suggestions?
>  
>


-- 
-Francisco


_______________________________________________
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  8 14:58:08 2004
From: cfoust at infostatsystems.com (Charlotte Foust)
Date: Tue, 8 Jun 2004 12:58:08 -0700
Subject: [dba-SQLServer] Can't Register Server
Message-ID: <E61FC1D4B1918244905B113C680BEA86312848@infoserver01.infostat.local>

Yes, I did originally, not voluntarily, but because it loaded
automatically.  After I removed it, SQL Server would never reinstall
properly.  EM ran, but even though I had databases, I couldn't connect
to them.  My ISP implicated the modem, which gave me other fits.  After
I got fed up and got the router, I never tried to reinstall ... Until
last night.

Charlotte Foust

-----Original Message-----
From: Francisco H Tapia [mailto:my.lists at verizon.net] 
Sent: Tuesday, June 08, 2004 8:58 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Can't Register Server


Charlotte,
   Excuse me but how exactly does DSL break SQL Server???
I have the developer version on my Windows 2000 PRO SP4 at home and it 
runs fine and even when I got a router all I did was litterally power 
down the pc, install the router and then power it back up... I 
litterally had not configuration issues.

Did you load any software because of your DSL?


Charlotte Foust wrote On 6/8/2004 8:21 AM:

>I reinstalled SQL 2000 last night, but I can't register the blasted 
>server.  When I try, it comes back and says it fails because the 
>connection is open.  This is developer edition on a stand-alone laptop.

>I've run into this with every installation of SQL Server on this 
>machine, although one upon a time I had it working ... Pre-DSL.  My DSL

>modem (now replaced with a router) broke SQL on my laptop, so I 
>uninstalled SQL and have never since been able to get it reinstalled 
>and working.  Any suggestions?
>
>Charlotte Foust
>  
>


-- 
-Francisco


_______________________________________________
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  8 14:59:12 2004
From: cfoust at infostatsystems.com (Charlotte Foust)
Date: Tue, 8 Jun 2004 12:59:12 -0700
Subject: [dba-SQLServer] Can't Register Server
Message-ID: <E61FC1D4B1918244905B113C680BEA86312849@infoserver01.infostat.local>

But it isn't remote.  This is standalone on my laptop.  I'll look at it
anyhow just in case.

Charlotte Foust

-----Original Message-----
From: Billy Pang [mailto:tuxedo_man at hotmail.com] 
Sent: Tuesday, June 08, 2004 11:09 AM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Can't Register Server


Alias is like a nickname you give to remote sql server that tells your
sql 
server client how to connect to remote sql server.

You can manage aliases via the Client Network Utility:

START --> PROGRAMS --> SQL SERVER --> CLIENT NETWORK UTILITY

>From there, click on the Alias tab and select your network protocol and
related settings.

Billy


>From: "Charlotte Foust" <cfoust at infostatsystems.com>
>Reply-To: dba-sqlserver at databaseadvisors.com
>To: <dba-sqlserver at databaseadvisors.com>
>Subject: RE: [dba-SQLServer] Can't Register Server
>Date: Tue, 8 Jun 2004 09:34:25 -0700
>
>I am *NOT* a dba.  I just need the darn thing to program against.
>'Splain to me "alias" and how I deal with it.
>
>Charlotte Foust
>
>-----Original Message-----
>From: Julie Reardon-Taylor [mailto:prosoft6 at hotmail.com]
>Sent: Tuesday, June 08, 2004 8:04 AM
>To: dba-sqlserver at databaseadvisors.com
>Subject: RE: [dba-SQLServer] Can't Register Server
>
>
>Charlotte,
>
>Make sure that you don't have an alias sitting out there somewhere.
>
>
>
>Julie Reardon-Taylor
>PRO-SOFT OF NY, INC.
>108 Franklin Street
>Watertown, NY 13601
>(315) 785-0319
>www.pro-soft.net
>
>
>_______________________________________________
>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
>

_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN Premium   
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU
=http://hotmail.com/enca&HL=Market_MSNIS_Taglines

_______________________________________________
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  8 15:00:25 2004
From: cfoust at infostatsystems.com (Charlotte Foust)
Date: Tue, 8 Jun 2004 13:00:25 -0700
Subject: [dba-SQLServer] Can't Register Server
Message-ID: <E61FC1D4B1918244905B113C680BEA8631284A@infoserver01.infostat.local>

No, that's the problem.  I can't register the server because it errors
saying the connection is open.

Charlotte Foust

-----Original Message-----
From: Julie Reardon-Taylor [mailto:prosoft6 at hotmail.com] 
Sent: Tuesday, June 08, 2004 8:55 AM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Can't Register Server


Sorry, deleted your original question.  Have you performed the server 
registration?



Julie Reardon-Taylor
PRO-SOFT OF NY, INC.
108 Franklin Street
Watertown, NY 13601
(315) 785-0319
www.pro-soft.net


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



From my.lists at verizon.net  Tue Jun  8 15:46:07 2004
From: my.lists at verizon.net (Francisco H Tapia)
Date: Tue, 08 Jun 2004 13:46:07 -0700
Subject: [dba-SQLServer] Can't Register Server
In-Reply-To: <E61FC1D4B1918244905B113C680BEA8631284A@infoserver01.infostat.local>
References: <E61FC1D4B1918244905B113C680BEA8631284A@infoserver01.infostat.local>
Message-ID: <40C6258F.5020507@verizon.net>

Charlotte,
  Please humor me for a bit, what MDAC is currently isntalled on your 
system? you can download the component checker from MS, then just run it 
and it'll tell you you're running either 2.5 - 2.8

I have found that MDAC 2.6 SP1 is generally the best combo of all, 
although 2.7 is good too.
also you probably have a server icon in your system tray, what name does 
it say for your local server?


Charlotte Foust wrote On 6/8/2004 1:00 PM:

>No, that's the problem.  I can't register the server because it errors
>saying the connection is open.
>
>Charlotte Foust
>

-- 
-Francisco




From michael.broesdorf at web.de  Tue Jun  8 15:55:06 2004
From: michael.broesdorf at web.de (=?iso-8859-1?Q?Michael_Br=F6sdorf?=)
Date: Tue, 8 Jun 2004 22:55:06 +0200
Subject: AW: [dba-SQLServer] How to add a new job category
In-Reply-To: <007501c44d83$0aacd550$0201a8c0@PARIS>
Message-ID: <NEBBIILOPOPJBCLJIJHHCEACFJAA.michael.broesdorf@web.de>

Thanks Shamil,

found the right-click on the SQL Server Agent - I didn't expect it to be
there!
Searching BOL I only found the topic telling me how to add new categories
using DMO...

Michael


-----Urspr?ngliche Nachricht-----
Von: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]Im Auftrag von Shamil
Salakhetdinov
Gesendet: Dienstag, 8. Juni 2004 20:04
An: dba-sqlserver at databaseadvisors.com
Betreff: Re: [dba-SQLServer] How to add a new job category


<YourSQLServer> -> Management->SQL Server Agent->
Jobs->RightClick->Manage Job Categories -> Add...

select * from msdb..syscategories -- list all available categories

EXEC sp_help_category @class = 'JOB' -- list job class categories

See BO for more inforation...

HTH,
Shamil

----- Original Message -----
From: "Michael Brosdorf" <michael.broesdorf at web.de>
To: <dba-sqlserver at databaseadvisors.com>
Sent: Monday, June 07, 2004 8:14 PM
Subject: [dba-SQLServer] How to add a new job category


> Dear group,
>
> is it possible to add new job categories for the SQL Agent scheduler?
> The '...'-button next to the drop down list only display other jobs in
> the selected category, but does not allow adding new categories.
>
> Michael
> _______________________________________________
> 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 cfoust at infostatsystems.com  Tue Jun  8 17:20:05 2004
From: cfoust at infostatsystems.com (Charlotte Foust)
Date: Tue, 8 Jun 2004 15:20:05 -0700
Subject: [dba-SQLServer] Can't Register Server
Message-ID: <E61FC1D4B1918244905B113C680BEA8631284C@infoserver01.infostat.local>

MDAC is 2.7 and has been since 2.7 came out.  I've kept it upgraded
until 2.7.  I won't put 2.8 on until I install the VB.Net stuff.  It
comes up as NEWBOOK.

Charlotte Foust

-----Original Message-----
From: Francisco H Tapia [mailto:my.lists at verizon.net] 
Sent: Tuesday, June 08, 2004 12:46 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Can't Register Server


Charlotte,
  Please humor me for a bit, what MDAC is currently isntalled on your 
system? you can download the component checker from MS, then just run it

and it'll tell you you're running either 2.5 - 2.8

I have found that MDAC 2.6 SP1 is generally the best combo of all, 
although 2.7 is good too.
also you probably have a server icon in your system tray, what name does

it say for your local server?


Charlotte Foust wrote On 6/8/2004 1:00 PM:

>No, that's the problem.  I can't register the server because it errors 
>saying the connection is open.
>
>Charlotte Foust
>

-- 
-Francisco


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



From CMackin at Quiznos.com  Tue Jun  8 17:28:29 2004
From: CMackin at Quiznos.com (Mackin, Christopher)
Date: Tue, 8 Jun 2004 16:28:29 -0600 
Subject: [dba-SQLServer] xp_smtp_sendmail
Message-ID: <19F28F0B4284C04FB90CAA380451FFD94128EA@bross.quiznos.net>

Does anyone have any experience working with the extended stored procedure
xp_smtp_sendmail?

The following has detailed info on it:
http://www.sqldev.net/xp/xpsmtp.htm

I'm thinking I'm OK to run it with all the specs listed, but didn't know if
anyone knew of any surprises that may accompany the use of the .dll and
procedure, specifically any surprises related to security.

-Chris Mackin


From my.lists at verizon.net  Tue Jun  8 18:20:38 2004
From: my.lists at verizon.net (Francisco H Tapia)
Date: Tue, 08 Jun 2004 16:20:38 -0700
Subject: [dba-SQLServer] Can't Register Server
In-Reply-To: <E61FC1D4B1918244905B113C680BEA8631284C@infoserver01.infostat.local>
References: <E61FC1D4B1918244905B113C680BEA8631284C@infoserver01.infostat.local>
Message-ID: <40C649C6.5000306@verizon.net>

k, so assuming the connectivity library is intact...

when you open EM and click on register new server and you get the 
wizard(assuming you use the wizard here). Do you have an empty list for 
available servers?  If so is your sqlserver started before you begin the 
server registration?

you also mentioned you had problems installing sql server on this pc.  
When you refer to your install problems do you mean only registering 
errors or errors along the way when installing?

and lastly... What is the hardware configuration on the pc including OS?



Charlotte Foust wrote On 6/8/2004 3:20 PM:

>MDAC is 2.7 and has been since 2.7 came out.  I've kept it upgraded
>until 2.7.  I won't put 2.8 on until I install the VB.Net stuff.  It
>comes up as NEWBOOK.
>
>Charlotte Foust
>
>-----Original Message-----
>From: Francisco H Tapia [mailto:my.lists at verizon.net] 
>Sent: Tuesday, June 08, 2004 12:46 PM
>To: dba-sqlserver at databaseadvisors.com
>Subject: Re: [dba-SQLServer] Can't Register Server
>
>
>Charlotte,
>  Please humor me for a bit, what MDAC is currently isntalled on your 
>system? you can download the component checker from MS, then just run it
>
>and it'll tell you you're running either 2.5 - 2.8
>
>I have found that MDAC 2.6 SP1 is generally the best combo of all, 
>although 2.7 is good too.
>also you probably have a server icon in your system tray, what name does
>
>it say for your local server?
>
>
>Charlotte Foust wrote On 6/8/2004 1:00 PM:
>
>  
>
>>No, that's the problem.  I can't register the server because it errors 
>>saying the connection is open.
>>
>>Charlotte Foust
>>
>>    
>>
>
>  
>


-- 
-Francisco




From my.lists at verizon.net  Tue Jun  8 18:25:10 2004
From: my.lists at verizon.net (Francisco H Tapia)
Date: Tue, 08 Jun 2004 16:25:10 -0700
Subject: [dba-SQLServer] xp_smtp_sendmail
In-Reply-To: <19F28F0B4284C04FB90CAA380451FFD94128EA@bross.quiznos.net>
References: <19F28F0B4284C04FB90CAA380451FFD94128EA@bross.quiznos.net>
Message-ID: <40C64AD6.9060302@verizon.net>

haven't used it... I've been using a variant w/ BLAT, where my sproc 
calls blat instead, tho this method look comprehensive enough.


Mackin, Christopher wrote On 6/8/2004 3:28 PM:

>Does anyone have any experience working with the extended stored procedure
>xp_smtp_sendmail?
>
>The following has detailed info on it:
>http://www.sqldev.net/xp/xpsmtp.htm
>
>I'm thinking I'm OK to run it with all the specs listed, but didn't know if
>anyone knew of any surprises that may accompany the use of the .dll and
>procedure, specifically any surprises related to security.
>
>-Chris Mackin
>_
>


-- 
-Francisco




From cfoust at infostatsystems.com  Tue Jun  8 18:31:12 2004
From: cfoust at infostatsystems.com (Charlotte Foust)
Date: Tue, 8 Jun 2004 16:31:12 -0700
Subject: [dba-SQLServer] Can't Register Server
Message-ID: <E61FC1D4B1918244905B113C680BEA8631284D@infoserver01.infostat.local>

No, I see NewBook, but it won't let me register it and I can't add a
database because it isn't registered properly.  It apparently installls
OK, but that's as far as it goes.  EM works (sort of), QA launches, but
you can't create or restore or anything else with a SQL database.  I
must be missing something, but I'll be blitzed if I know what it is!

Charlotte Foust

-----Original Message-----
From: Francisco H Tapia [mailto:my.lists at verizon.net] 
Sent: Tuesday, June 08, 2004 3:21 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Can't Register Server


k, so assuming the connectivity library is intact...

when you open EM and click on register new server and you get the 
wizard(assuming you use the wizard here). Do you have an empty list for 
available servers?  If so is your sqlserver started before you begin the

server registration?

you also mentioned you had problems installing sql server on this pc.  
When you refer to your install problems do you mean only registering 
errors or errors along the way when installing?

and lastly... What is the hardware configuration on the pc including OS?



Charlotte Foust wrote On 6/8/2004 3:20 PM:

>MDAC is 2.7 and has been since 2.7 came out.  I've kept it upgraded 
>until 2.7.  I won't put 2.8 on until I install the VB.Net stuff.  It 
>comes up as NEWBOOK.
>
>Charlotte Foust
>
>-----Original Message-----
>From: Francisco H Tapia [mailto:my.lists at verizon.net]
>Sent: Tuesday, June 08, 2004 12:46 PM
>To: dba-sqlserver at databaseadvisors.com
>Subject: Re: [dba-SQLServer] Can't Register Server
>
>
>Charlotte,
>  Please humor me for a bit, what MDAC is currently isntalled on your
>system? you can download the component checker from MS, then just run
it
>
>and it'll tell you you're running either 2.5 - 2.8
>
>I have found that MDAC 2.6 SP1 is generally the best combo of all,
>although 2.7 is good too.
>also you probably have a server icon in your system tray, what name
does
>
>it say for your local server?
>
>
>Charlotte Foust wrote On 6/8/2004 1:00 PM:
>
>  
>
>>No, that's the problem.  I can't register the server because it errors
>>saying the connection is open.
>>
>>Charlotte Foust
>>
>>    
>>
>
>  
>


-- 
-Francisco


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



From my.lists at verizon.net  Tue Jun  8 18:50:52 2004
From: my.lists at verizon.net (Francisco H Tapia)
Date: Tue, 08 Jun 2004 16:50:52 -0700
Subject: [dba-SQLServer] Can't Register Server
In-Reply-To: <E61FC1D4B1918244905B113C680BEA8631284D@infoserver01.infostat.local>
References: <E61FC1D4B1918244905B113C680BEA8631284D@infoserver01.infostat.local>
Message-ID: <40C650DC.8030105@verizon.net>

Back up a bit... when you say QA launches but won't create or restore, 
you mean it won't accept your scripts? what is the error message it is 
giving you?

Charlotte Foust wrote On 6/8/2004 4:31 PM:

>No, I see NewBook, but it won't let me register it and I can't add a
>database because it isn't registered properly.  It apparently installls
>OK, but that's as far as it goes.  EM works (sort of), QA launches, but
>you can't create or restore or anything else with a SQL database.  I
>must be missing something, but I'll be blitzed if I know what it is!
>
>Charlotte Foust
>
>  
>
-- 
-Francisco




From cfoust at infostatsystems.com  Tue Jun  8 19:16:42 2004
From: cfoust at infostatsystems.com (Charlotte Foust)
Date: Tue, 8 Jun 2004 17:16:42 -0700
Subject: [dba-SQLServer] Can't Register Server
Message-ID: <E61FC1D4B1918244905B113C680BEA8631284F@infoserver01.infostat.local>

I'll have to try it again tonight.  Last night I was just pounding on EM
trying to get a server registered.  I'll have to rummage around for the
Northwind script and try to run it on QA.

Charlotte Foust

-----Original Message-----
From: Francisco H Tapia [mailto:my.lists at verizon.net] 
Sent: Tuesday, June 08, 2004 3:51 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Can't Register Server


Back up a bit... when you say QA launches but won't create or restore, 
you mean it won't accept your scripts? what is the error message it is 
giving you?

Charlotte Foust wrote On 6/8/2004 4:31 PM:

>No, I see NewBook, but it won't let me register it and I can't add a 
>database because it isn't registered properly.  It apparently installls

>OK, but that's as far as it goes.  EM works (sort of), QA launches, but

>you can't create or restore or anything else with a SQL database.  I 
>must be missing something, but I'll be blitzed if I know what it is!
>
>Charlotte Foust
>
>  
>
-- 
-Francisco


_______________________________________________
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  Wed Jun  9 10:59:39 2004
From: cfoust at infostatsystems.com (Charlotte Foust)
Date: Wed, 9 Jun 2004 08:59:39 -0700
Subject: [dba-SQLServer] Can't Register Server - FINALLY
Message-ID: <E61FC1D4B1918244905B113C680BEA8632C675@infoserver01.infostat.local>

Well, after 3 uninstalls and reinstalls, SQL Server finally allowed me
to register a server!  That pounding you heard last night was my head
beating on the wall. :-{  I could get EM up and I could even get QA up,
although of course neither of them really worked since they couldn't
connect to an active server, but I couldn't register a server until that
last install.  Nothing changed in between except my frustration level
and the name of the server, but suddenly there it was.  

Charlotte Foust

-----Original Message-----
From: Charlotte Foust 
Sent: Tuesday, June 08, 2004 2:20 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Can't Register Server


MDAC is 2.7 and has been since 2.7 came out.  I've kept it upgraded
until 2.7.  I won't put 2.8 on until I install the VB.Net stuff.  It
comes up as NEWBOOK.

Charlotte Foust

-----Original Message-----
From: Francisco H Tapia [mailto:my.lists at verizon.net] 
Sent: Tuesday, June 08, 2004 12:46 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Can't Register Server


Charlotte,
  Please humor me for a bit, what MDAC is currently isntalled on your 
system? you can download the component checker from MS, then just run it

and it'll tell you you're running either 2.5 - 2.8

I have found that MDAC 2.6 SP1 is generally the best combo of all, 
although 2.7 is good too.
also you probably have a server icon in your system tray, what name does

it say for your local server?


Charlotte Foust wrote On 6/8/2004 1:00 PM:

>No, that's the problem.  I can't register the server because it errors
>saying the connection is open.
>
>Charlotte Foust
>

-- 
-Francisco


_______________________________________________
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 afsweb.com  Wed Jun  9 11:35:59 2004
From: ebarro at afsweb.com (Eric Barro)
Date: Wed, 9 Jun 2004 09:35:59 -0700
Subject: [dba-SQLServer] Can't Register Server - FINALLY
In-Reply-To: <E61FC1D4B1918244905B113C680BEA8632C675@infoserver01.infostat.local>
Message-ID: <DPEGIFJOAFKLEDNNDGHCMEANGNAA.ebarro@afsweb.com>

This is what worked for me whenever I could not get SQL server to register a server...

In your HOSTS file add an entry for the SQL server with its IP address like so...

192.168.1.254	mySQLServer

Of course if the IP address of the sql server changes you will have to make manual adjustments. In my experience SQL server boxes rarely have their IP addresses changed. This approach also assumes that the SQL server has a static IP address.

---
Eric Barro
Senior Systems Analyst
Advanced Field Services
(208) 772-7060
http://www.afsweb.com 

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of
Charlotte Foust
Sent: Wednesday, June 09, 2004 9:00 AM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Can't Register Server - FINALLY


Well, after 3 uninstalls and reinstalls, SQL Server finally allowed me
to register a server!  That pounding you heard last night was my head
beating on the wall. :-{  I could get EM up and I could even get QA up,
although of course neither of them really worked since they couldn't
connect to an active server, but I couldn't register a server until that
last install.  Nothing changed in between except my frustration level
and the name of the server, but suddenly there it was.  

Charlotte Foust

-----Original Message-----
From: Charlotte Foust 
Sent: Tuesday, June 08, 2004 2:20 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Can't Register Server


MDAC is 2.7 and has been since 2.7 came out.  I've kept it upgraded
until 2.7.  I won't put 2.8 on until I install the VB.Net stuff.  It
comes up as NEWBOOK.

Charlotte Foust

-----Original Message-----
From: Francisco H Tapia [mailto:my.lists at verizon.net] 
Sent: Tuesday, June 08, 2004 12:46 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Can't Register Server


Charlotte,
  Please humor me for a bit, what MDAC is currently isntalled on your 
system? you can download the component checker from MS, then just run it

and it'll tell you you're running either 2.5 - 2.8

I have found that MDAC 2.6 SP1 is generally the best combo of all, 
although 2.7 is good too.
also you probably have a server icon in your system tray, what name does

it say for your local server?


Charlotte Foust wrote On 6/8/2004 1:00 PM:

>No, that's the problem.  I can't register the server because it errors
>saying the connection is open.
>
>Charlotte Foust
>

-- 
-Francisco


_______________________________________________
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


---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.700 / Virus Database: 457 - Release Date: 6/6/2004

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.700 / Virus Database: 457 - Release Date: 6/6/2004




From jwcolby at colbyconsulting.com  Wed Jun  9 11:39:53 2004
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Wed, 9 Jun 2004 12:39:53 -0400
Subject: [dba-SQLServer] Can't Register Server - FINALLY
In-Reply-To: <E61FC1D4B1918244905B113C680BEA8632C675@infoserver01.infostat.local>
Message-ID: <000f01c44e40$63ecbff0$7e01a8c0@colbyws>

Jumps to his feet cheering wildly!!!!  The audience roars.  A standing
ovation for the raw StickToItiveness that separates the women from the
girls.

;-)

John W. Colby 
www.ColbyConsulting.com

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Charlotte
Foust
Sent: Wednesday, June 09, 2004 12:00 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Can't Register Server - FINALLY


Well, after 3 uninstalls and reinstalls, SQL Server finally allowed me to
register a server!  That pounding you heard last night was my head beating
on the wall. :-{  I could get EM up and I could even get QA up, although of
course neither of them really worked since they couldn't connect to an
active server, but I couldn't register a server until that last install.
Nothing changed in between except my frustration level and the name of the
server, but suddenly there it was.  

Charlotte Foust

-----Original Message-----
From: Charlotte Foust 
Sent: Tuesday, June 08, 2004 2:20 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Can't Register Server


MDAC is 2.7 and has been since 2.7 came out.  I've kept it upgraded until
2.7.  I won't put 2.8 on until I install the VB.Net stuff.  It comes up as
NEWBOOK.

Charlotte Foust

-----Original Message-----
From: Francisco H Tapia [mailto:my.lists at verizon.net] 
Sent: Tuesday, June 08, 2004 12:46 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Can't Register Server


Charlotte,
  Please humor me for a bit, what MDAC is currently isntalled on your 
system? you can download the component checker from MS, then just run it

and it'll tell you you're running either 2.5 - 2.8

I have found that MDAC 2.6 SP1 is generally the best combo of all, 
although 2.7 is good too.
also you probably have a server icon in your system tray, what name does

it say for your local server?


Charlotte Foust wrote On 6/8/2004 1:00 PM:

>No, that's the problem.  I can't register the server because it errors 
>saying the connection is open.
>
>Charlotte Foust
>

-- 
-Francisco


_______________________________________________
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 cfoust at infostatsystems.com  Wed Jun  9 12:15:02 2004
From: cfoust at infostatsystems.com (Charlotte Foust)
Date: Wed, 9 Jun 2004 10:15:02 -0700
Subject: [dba-SQLServer] Can't Register Server - FINALLY
Message-ID: <E61FC1D4B1918244905B113C680BEA86312854@infoserver01.infostat.local>

Bows grandly and graciously to the cheering throng !!! <VBG>

Charlotte Foust

-----Original Message-----
From: jwcolby [mailto:jwcolby at colbyconsulting.com] 
Sent: Wednesday, June 09, 2004 8:40 AM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Can't Register Server - FINALLY


Jumps to his feet cheering wildly!!!!  The audience roars.  A standing
ovation for the raw StickToItiveness that separates the women from the
girls.

;-)

John W. Colby 
www.ColbyConsulting.com

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of
Charlotte Foust
Sent: Wednesday, June 09, 2004 12:00 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Can't Register Server - FINALLY


Well, after 3 uninstalls and reinstalls, SQL Server finally allowed me
to register a server!  That pounding you heard last night was my head
beating on the wall. :-{  I could get EM up and I could even get QA up,
although of course neither of them really worked since they couldn't
connect to an active server, but I couldn't register a server until that
last install. Nothing changed in between except my frustration level and
the name of the server, but suddenly there it was.  

Charlotte Foust

-----Original Message-----
From: Charlotte Foust 
Sent: Tuesday, June 08, 2004 2:20 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Can't Register Server


MDAC is 2.7 and has been since 2.7 came out.  I've kept it upgraded
until 2.7.  I won't put 2.8 on until I install the VB.Net stuff.  It
comes up as NEWBOOK.

Charlotte Foust

-----Original Message-----
From: Francisco H Tapia [mailto:my.lists at verizon.net] 
Sent: Tuesday, June 08, 2004 12:46 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Can't Register Server


Charlotte,
  Please humor me for a bit, what MDAC is currently isntalled on your 
system? you can download the component checker from MS, then just run it

and it'll tell you you're running either 2.5 - 2.8

I have found that MDAC 2.6 SP1 is generally the best combo of all, 
although 2.7 is good too.
also you probably have a server icon in your system tray, what name does

it say for your local server?


Charlotte Foust wrote On 6/8/2004 1:00 PM:

>No, that's the problem.  I can't register the server because it errors
>saying the connection is open.
>
>Charlotte Foust
>

-- 
-Francisco


_______________________________________________
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 cfoust at infostatsystems.com  Wed Jun  9 12:16:16 2004
From: cfoust at infostatsystems.com (Charlotte Foust)
Date: Wed, 9 Jun 2004 10:16:16 -0700
Subject: [dba-SQLServer] Can't Register Server - FINALLY
Message-ID: <E61FC1D4B1918244905B113C680BEA86312855@infoserver01.infostat.local>

It's on my laptop, which is running Win2k Pro.  I haven't even looked
for a HOSTS file.

Charlotte Foust

-----Original Message-----
From: Eric Barro [mailto:ebarro at afsweb.com] 
Sent: Wednesday, June 09, 2004 8:36 AM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Can't Register Server - FINALLY


This is what worked for me whenever I could not get SQL server to
register a server...

In your HOSTS file add an entry for the SQL server with its IP address
like so...

192.168.1.254	mySQLServer

Of course if the IP address of the sql server changes you will have to
make manual adjustments. In my experience SQL server boxes rarely have
their IP addresses changed. This approach also assumes that the SQL
server has a static IP address.

---
Eric Barro
Senior Systems Analyst
Advanced Field Services
(208) 772-7060
http://www.afsweb.com 

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of
Charlotte Foust
Sent: Wednesday, June 09, 2004 9:00 AM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Can't Register Server - FINALLY


Well, after 3 uninstalls and reinstalls, SQL Server finally allowed me
to register a server!  That pounding you heard last night was my head
beating on the wall. :-{  I could get EM up and I could even get QA up,
although of course neither of them really worked since they couldn't
connect to an active server, but I couldn't register a server until that
last install.  Nothing changed in between except my frustration level
and the name of the server, but suddenly there it was.  

Charlotte Foust

-----Original Message-----
From: Charlotte Foust 
Sent: Tuesday, June 08, 2004 2:20 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Can't Register Server


MDAC is 2.7 and has been since 2.7 came out.  I've kept it upgraded
until 2.7.  I won't put 2.8 on until I install the VB.Net stuff.  It
comes up as NEWBOOK.

Charlotte Foust

-----Original Message-----
From: Francisco H Tapia [mailto:my.lists at verizon.net] 
Sent: Tuesday, June 08, 2004 12:46 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Can't Register Server


Charlotte,
  Please humor me for a bit, what MDAC is currently isntalled on your 
system? you can download the component checker from MS, then just run it

and it'll tell you you're running either 2.5 - 2.8

I have found that MDAC 2.6 SP1 is generally the best combo of all, 
although 2.7 is good too.
also you probably have a server icon in your system tray, what name does

it say for your local server?


Charlotte Foust wrote On 6/8/2004 1:00 PM:

>No, that's the problem.  I can't register the server because it errors 
>saying the connection is open.
>
>Charlotte Foust
>

-- 
-Francisco


_______________________________________________
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


---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.700 / Virus Database: 457 - Release Date: 6/6/2004

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.700 / Virus Database: 457 - Release Date: 6/6/2004


_______________________________________________
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  9 13:03:37 2004
From: accessd at shaw.ca (Jim Lawrence (AccessD))
Date: Wed, 09 Jun 2004 11:03:37 -0700
Subject: [dba-SQLServer] Can't Register Server - FINALLY
In-Reply-To: <E61FC1D4B1918244905B113C680BEA8632C675@infoserver01.infostat.local>
Message-ID: <FJEJLIPOMCGJALMGLLLIOEHICDAA.accessd@shaw.ca>

Hi Charlotte:

Now I wonder what you did or did not do differently? I still have a server
that when SQL2000 is installed and it runs super-slow. It all works but 2
minutes between refreshes is too painful. Installed on another server it is
working fine so have just abandoned the other one. (Mind you at $375.00 from
M$, a helpdesk call could resolve it all..., yeh.)

I am very glad to hear you have everything up and running. :-)

Jim

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of
Charlotte Foust
Sent: Wednesday, June 09, 2004 9:00 AM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Can't Register Server - FINALLY


Well, after 3 uninstalls and reinstalls, SQL Server finally allowed me
to register a server!  That pounding you heard last night was my head
beating on the wall. :-{  I could get EM up and I could even get QA up,
although of course neither of them really worked since they couldn't
connect to an active server, but I couldn't register a server until that
last install.  Nothing changed in between except my frustration level
and the name of the server, but suddenly there it was.

Charlotte Foust

-----Original Message-----
From: Charlotte Foust
Sent: Tuesday, June 08, 2004 2:20 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Can't Register Server


MDAC is 2.7 and has been since 2.7 came out.  I've kept it upgraded
until 2.7.  I won't put 2.8 on until I install the VB.Net stuff.  It
comes up as NEWBOOK.

Charlotte Foust

-----Original Message-----
From: Francisco H Tapia [mailto:my.lists at verizon.net]
Sent: Tuesday, June 08, 2004 12:46 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Can't Register Server


Charlotte,
  Please humor me for a bit, what MDAC is currently isntalled on your
system? you can download the component checker from MS, then just run it

and it'll tell you you're running either 2.5 - 2.8

I have found that MDAC 2.6 SP1 is generally the best combo of all,
although 2.7 is good too.
also you probably have a server icon in your system tray, what name does

it say for your local server?


Charlotte Foust wrote On 6/8/2004 1:00 PM:

>No, that's the problem.  I can't register the server because it errors
>saying the connection is open.
>
>Charlotte Foust
>

--
-Francisco


_______________________________________________
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 cfoust at infostatsystems.com  Wed Jun  9 14:29:51 2004
From: cfoust at infostatsystems.com (Charlotte Foust)
Date: Wed, 9 Jun 2004 12:29:51 -0700
Subject: [dba-SQLServer] Can't Register Server - FINALLY
Message-ID: <E61FC1D4B1918244905B113C680BEA86312858@infoserver01.infostat.local>

The last time, I did a full install, let it use the default locations
and generally stood back and watched.  The only thing I can think of is
that perhaps one of the uninstalls got rid of some garbage, either in
the registry or on the hard drive.  Interestingly, though, I still have
folders for the unsuccessful server attempts in the SQL Server folder,
so it at least got that far on the earlier attempts.

Charlotte Foust

-----Original Message-----
From: Jim Lawrence (AccessD) [mailto:accessd at shaw.ca] 
Sent: Wednesday, June 09, 2004 10:04 AM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Can't Register Server - FINALLY


Hi Charlotte:

Now I wonder what you did or did not do differently? I still have a
server that when SQL2000 is installed and it runs super-slow. It all
works but 2 minutes between refreshes is too painful. Installed on
another server it is working fine so have just abandoned the other one.
(Mind you at $375.00 from M$, a helpdesk call could resolve it all...,
yeh.)

I am very glad to hear you have everything up and running. :-)

Jim

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of
Charlotte Foust
Sent: Wednesday, June 09, 2004 9:00 AM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Can't Register Server - FINALLY


Well, after 3 uninstalls and reinstalls, SQL Server finally allowed me
to register a server!  That pounding you heard last night was my head
beating on the wall. :-{  I could get EM up and I could even get QA up,
although of course neither of them really worked since they couldn't
connect to an active server, but I couldn't register a server until that
last install.  Nothing changed in between except my frustration level
and the name of the server, but suddenly there it was.

Charlotte Foust

-----Original Message-----
From: Charlotte Foust
Sent: Tuesday, June 08, 2004 2:20 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Can't Register Server


MDAC is 2.7 and has been since 2.7 came out.  I've kept it upgraded
until 2.7.  I won't put 2.8 on until I install the VB.Net stuff.  It
comes up as NEWBOOK.

Charlotte Foust

-----Original Message-----
From: Francisco H Tapia [mailto:my.lists at verizon.net]
Sent: Tuesday, June 08, 2004 12:46 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Can't Register Server


Charlotte,
  Please humor me for a bit, what MDAC is currently isntalled on your
system? you can download the component checker from MS, then just run it

and it'll tell you you're running either 2.5 - 2.8

I have found that MDAC 2.6 SP1 is generally the best combo of all,
although 2.7 is good too. also you probably have a server icon in your
system tray, what name does

it say for your local server?


Charlotte Foust wrote On 6/8/2004 1:00 PM:

>No, that's the problem.  I can't register the server because it errors 
>saying the connection is open.
>
>Charlotte Foust
>

--
-Francisco


_______________________________________________
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  Thu Jun 10 11:33:22 2004
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Thu, 10 Jun 2004 12:33:22 -0400
Subject: [dba-SQLServer] Difference between views and queries
Message-ID: <001c01c44f08$a5d922a0$7e01a8c0@colbyws>

Can anyone explain the difference between a view and a query?  Views use a
query, plus the view keyword.  I have a couple of books that I have read the
chapter on Views, but I so far haven't managed to "get" why you wouldn't
just use the query itself instead of turning it into a view.


John W. Colby 
www.ColbyConsulting.com




From rl_stewart at highstream.net  Thu Jun 10 12:09:15 2004
From: rl_stewart at highstream.net (Robert L. Stewart)
Date: Thu, 10 Jun 2004 12:09:15 -0500
Subject: [dba-SQLServer] Re: Difference between views and queries
In-Reply-To: <200406101700.i5AH0gQ06813@databaseadvisors.com>
Message-ID: <5.1.0.14.2.20040610120727.017d1858@pop3.highstream.net>

John,

Because views are run on the server side unlike queries.
And, they use a SQL statement like a query, but they do
not use a query.  The server can optimize them since they
are stored also.

Robert

At 12:00 PM 6/10/2004 -0500, you wrote:
>Date: Thu, 10 Jun 2004 12:33:22 -0400
>From: "jwcolby" <jwcolby at colbyconsulting.com>
>Subject: [dba-SQLServer] Difference between views and queries
>To: "SQLServer" <dba-sqlserver at databaseadvisors.com>
>Message-ID: <001c01c44f08$a5d922a0$7e01a8c0 at colbyws>
>Content-Type: text/plain;       charset="us-ascii"
>
>Can anyone explain the difference between a view and a query?  Views use a
>query, plus the view keyword.  I have a couple of books that I have read the
>chapter on Views, but I so far haven't managed to "get" why you wouldn't
>just use the query itself instead of turning it into a view.
>
>
>John W. Colby
>www.ColbyConsulting.com




From cfoust at infostatsystems.com  Thu Jun 10 12:25:55 2004
From: cfoust at infostatsystems.com (Charlotte Foust)
Date: Thu, 10 Jun 2004 10:25:55 -0700
Subject: [dba-SQLServer] Difference between views and queries
Message-ID: <E61FC1D4B1918244905B113C680BEA8631285C@infoserver01.infostat.local>

When you say queries, are you referring to the SQL used or to
client-side queries as opposed to server-side views?

Charlotte Foust

-----Original Message-----
From: jwcolby [mailto:jwcolby at colbyconsulting.com] 
Sent: Thursday, June 10, 2004 8:33 AM
To: SQLServer
Subject: [dba-SQLServer] Difference between views and queries


Can anyone explain the difference between a view and a query?  Views use
a query, plus the view keyword.  I have a couple of books that I have
read the chapter on Views, but I so far haven't managed to "get" why you
wouldn't just use the query itself instead of turning it into a view.


John W. Colby 
www.ColbyConsulting.com


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



From my.lists at verizon.net  Thu Jun 10 14:58:00 2004
From: my.lists at verizon.net (Francisco H Tapia)
Date: Thu, 10 Jun 2004 12:58:00 -0700
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <001c01c44f08$a5d922a0$7e01a8c0@colbyws>
References: <001c01c44f08$a5d922a0$7e01a8c0@colbyws>
Message-ID: <40C8BD48.9050905@verizon.net>

jwcolby wrote On 6/10/2004 9:33 AM:

>Can anyone explain the difference between a view and a query?  Views use a
>query, plus the view keyword.  I have a couple of books that I have read the
>chapter on Views, but I so far haven't managed to "get" why you wouldn't
>just use the query itself instead of turning it into a view.
>  
>
A query is a request for an Access Database, however for Sql Server you 
would either use a View or Stored Procedure to return the data you 
wanted... you are also able to use dynamic SQL to retrieve the 
information you need.  ANY request given to the SQL Server engine is 
managed by the engine, unless you are running Remote servers (iirc).

In Sql Server, it is TABOO, nay, GENERALLY bad practice to use dynamic 
sql because of the implication of SQL INJECTION attacks, this poses a 
"real" security threat to your database. and your server.

another reason to use a VIEW over dynamic sql is that it is 
pre-optimized by the SQL Server Engine and thus runs faster and more 
efficient.  Additionally if you use Dynamic SQL then your individual 
users who access the server will need EXPLICIT "SELECT" permissions by 
you, which is another 'bad' practice.  In SQL Server you make data 
available to your users via VIEWs and Stored Procedures or some other 
secure way in order to protect your tables and it's data.

ya get wot I mean?

-- 
-Francisco




From knicholson at gpsx.net  Thu Jun 10 15:03:19 2004
From: knicholson at gpsx.net (Nicholson, Karen)
Date: Thu, 10 Jun 2004 16:03:19 -0400
Subject: [dba-SQLServer] Difference between views and queries
Message-ID: <74169B16EF9024458197A72AF4643B7403A87DC3@agoc-pabu-16.agoc_nt5.agoc.com>

So what do you think of having tons of Crystal Reports that hit against the
sql server (odbc) tables?  I prefer to create views for the Crystal Reports
to read,
but everyone in this corporation likes to hit against the tables and write
the
groupings, calculations, etc in Crystal.

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of
Francisco H Tapia
Sent: Thursday, June 10, 2004 3:58 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Difference between views and queries


jwcolby wrote On 6/10/2004 9:33 AM:

>Can anyone explain the difference between a view and a query?  Views use a
>query, plus the view keyword.  I have a couple of books that I have read
the
>chapter on Views, but I so far haven't managed to "get" why you wouldn't
>just use the query itself instead of turning it into a view.
>  
>
A query is a request for an Access Database, however for Sql Server you 
would either use a View or Stored Procedure to return the data you 
wanted... you are also able to use dynamic SQL to retrieve the 
information you need.  ANY request given to the SQL Server engine is 
managed by the engine, unless you are running Remote servers (iirc).

In Sql Server, it is TABOO, nay, GENERALLY bad practice to use dynamic 
sql because of the implication of SQL INJECTION attacks, this poses a 
"real" security threat to your database. and your server.

another reason to use a VIEW over dynamic sql is that it is 
pre-optimized by the SQL Server Engine and thus runs faster and more 
efficient.  Additionally if you use Dynamic SQL then your individual 
users who access the server will need EXPLICIT "SELECT" permissions by 
you, which is another 'bad' practice.  In SQL Server you make data 
available to your users via VIEWs and Stored Procedures or some other 
secure way in order to protect your tables and it's data.

ya get wot I mean?

-- 
-Francisco


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


From andy at minstersystems.co.uk  Thu Jun 10 15:27:45 2004
From: andy at minstersystems.co.uk (Andy Lacey)
Date: Thu, 10 Jun 2004 21:27:45 +0100
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <40C8BD48.9050905@verizon.net>
Message-ID: <000801c44f29$63ef0a00$b274d0d5@minster33c3r25>

But, Francisco, if I was porting to SQL Server my Access app which builds
SELECT statements dynamically all of the time for many and various
situations are you saying I couldn't, or shouldn't or something?

-- Andy Lacey
http://www.minstersystems.co.uk 

> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com 
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf 
> Of Francisco H Tapia
> Sent: 10 June 2004 20:58
> To: dba-sqlserver at databaseadvisors.com
> Subject: Re: [dba-SQLServer] Difference between views and queries
> 
> 
> jwcolby wrote On 6/10/2004 9:33 AM:
> 
> >Can anyone explain the difference between a view and a query?  Views 
> >use a query, plus the view keyword.  I have a couple of books that I 
> >have read the chapter on Views, but I so far haven't managed 
> to "get" 
> >why you wouldn't just use the query itself instead of 
> turning it into a 
> >view.
> >  
> >
> A query is a request for an Access Database, however for Sql 
> Server you 
> would either use a View or Stored Procedure to return the data you 
> wanted... you are also able to use dynamic SQL to retrieve the 
> information you need.  ANY request given to the SQL Server engine is 
> managed by the engine, unless you are running Remote servers (iirc).
> 
> In Sql Server, it is TABOO, nay, GENERALLY bad practice to 
> use dynamic 
> sql because of the implication of SQL INJECTION attacks, this poses a 
> "real" security threat to your database. and your server.
> 
> another reason to use a VIEW over dynamic sql is that it is 
> pre-optimized by the SQL Server Engine and thus runs faster and more 
> efficient.  Additionally if you use Dynamic SQL then your individual 
> users who access the server will need EXPLICIT "SELECT" 
> permissions by 
> you, which is another 'bad' practice.  In SQL Server you make data 
> available to your users via VIEWs and Stored Procedures or some other 
> secure way in order to protect your tables and it's data.
> 
> ya get wot I mean?
> 
> -- 
> -Francisco
> 
> 
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
> 
> 
> 



From dmart06 at emory.edu  Thu Jun 10 15:35:44 2004
From: dmart06 at emory.edu (Donna Martin)
Date: Thu, 10 Jun 2004 16:35:44 -0400
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <40C8BD48.9050905@verizon.net>
References: <001c01c44f08$a5d922a0$7e01a8c0@colbyws>
	<40C8BD48.9050905@verizon.net>
Message-ID: <1086899744.40c8c62017a00@webmail.service.emory.edu>

Regarding SQL Injection:  Sorry to get into this, but I use ColdFusion and cfc's
to query the database.  Then I wrap my passed values in Val() so that no SQL
injection can be performed.  I've been told that this works well, and have had
my code checked by others far better than I.  They have confirmed.

Do you agree?

Thanks.

Donna

Quoting Francisco H Tapia <my.lists at verizon.net>:

> jwcolby wrote On 6/10/2004 9:33 AM:
>
> >Can anyone explain the difference between a view and a query?  Views use a
> >query, plus the view keyword.  I have a couple of books that I have read the
> >chapter on Views, but I so far haven't managed to "get" why you wouldn't
> >just use the query itself instead of turning it into a view.
> >
> >
> A query is a request for an Access Database, however for Sql Server you
> would either use a View or Stored Procedure to return the data you
> wanted... you are also able to use dynamic SQL to retrieve the
> information you need.  ANY request given to the SQL Server engine is
> managed by the engine, unless you are running Remote servers (iirc).
>
> In Sql Server, it is TABOO, nay, GENERALLY bad practice to use dynamic
> sql because of the implication of SQL INJECTION attacks, this poses a
> "real" security threat to your database. and your server.
>
> another reason to use a VIEW over dynamic sql is that it is
> pre-optimized by the SQL Server Engine and thus runs faster and more
> efficient.  Additionally if you use Dynamic SQL then your individual
> users who access the server will need EXPLICIT "SELECT" permissions by
> you, which is another 'bad' practice.  In SQL Server you make data
> available to your users via VIEWs and Stored Procedures or some other
> secure way in order to protect your tables and it's data.
>
> ya get wot I mean?
>
> --
> -Francisco
>
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>


--
Donna M. Martin
Applications Dev/Analyst, Sr
Pathology & Laboratory Medicine
Emory University
N251 EUH Educational Annex
404 727-5918 Phone
404 686-5500 x15657 Pager


From my.lists at verizon.net  Thu Jun 10 15:38:11 2004
From: my.lists at verizon.net (Francisco H Tapia)
Date: Thu, 10 Jun 2004 13:38:11 -0700
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <74169B16EF9024458197A72AF4643B7403A87DC3@agoc-pabu-16.agoc_nt5.agoc.com>
References: <74169B16EF9024458197A72AF4643B7403A87DC3@agoc-pabu-16.agoc_nt5.agoc.com>
Message-ID: <40C8C6B3.3050108@verizon.net>

SUCH developers need to be dragged out to the street to be tarred and 
feathered... ;o) j/k
no...

A lot of times I find that my boss will request that he wants a new 
table w/ a join to another table and somehow magically come up w/ some 
solution for some third criteria.  The fact remains that "HE" is not a 
developer.  that's why he hired me.  I know that sounds arrogant, but 
let's consider the performance of your SQL Server, if you have adequate 
RAM, CPU and a marginally good IO subsystem; well then your performance 
may even be acceptable.  I have no idea how long it takes to run "any" 
of your reports, but the ones we've written so far in Access whose 
recordsources are stored procedures, well, the result has been < 20 
seconds for reports that used to take well over 5 minutes in Access.  In 
fact just about all report run in the 2-3 seconds timespan which has 
helped make our new Access.ADP system shine.

One thing that they've been missing is the ODBC access to tables to 
create their own reports. Many other SQL Developers often find a 
combination of VIEWS that are interpreted to the End Users as tables to 
help fill this gap, thus you'd have ODBC views which the users would 
think are "TABLES".  This will satisfy direct linking to tables and 
possibly promote better access time (tho not guarnateed, because as we 
all know, it is definatly easy enough to write a poorly joined SQL 
statement).

another solution some developers use is to have another SERVER, 
generally known as a reporting server for processing CUBES of data.  In 
this scenario, data is replicated TO it by the LIVE system in generally 
a delayed Transactional method.  Many times the data is flattened out 
and de-normalized.  This helps hide ID's that are meaningless to 
endusers, and for them to have direct "table" access to such system.  
These systems often have to be guarded and monitored.


so in your scenario the answer really is, "it depends" :).  If Views are 
a possiblity and your system is Not just for datawarehousing, then 
definitly I'd push in that direction.  If it were my system, I wouldn't 
want to be considered responsible for lack of availablity should people 
mis-construct their reports.


Nicholson, Karen wrote On 6/10/2004 1:03 PM:

>So what do you think of having tons of Crystal Reports that hit against the
>sql server (odbc) tables?  I prefer to create views for the Crystal Reports
>to read,
>but everyone in this corporation likes to hit against the tables and write
>the
>groupings, calculations, etc in Crystal.
>
>-----Original Message-----
>From: dba-sqlserver-bounces at databaseadvisors.com
>[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of
>Francisco H Tapia
>Sent: Thursday, June 10, 2004 3:58 PM
>To: dba-sqlserver at databaseadvisors.com
>Subject: Re: [dba-SQLServer] Difference between views and queries
>
>
>jwcolby wrote On 6/10/2004 9:33 AM:
>
>  
>
>>Can anyone explain the difference between a view and a query?  Views use a
>>query, plus the view keyword.  I have a couple of books that I have read
>>    
>>
>the
>  
>
>>chapter on Views, but I so far haven't managed to "get" why you wouldn't
>>just use the query itself instead of turning it into a view.
>> 
>>
>>    
>>
>A query is a request for an Access Database, however for Sql Server you 
>would either use a View or Stored Procedure to return the data you 
>wanted... you are also able to use dynamic SQL to retrieve the 
>information you need.  ANY request given to the SQL Server engine is 
>managed by the engine, unless you are running Remote servers (iirc).
>
>In Sql Server, it is TABOO, nay, GENERALLY bad practice to use dynamic 
>sql because of the implication of SQL INJECTION attacks, this poses a 
>"real" security threat to your database. and your server.
>
>another reason to use a VIEW over dynamic sql is that it is 
>pre-optimized by the SQL Server Engine and thus runs faster and more 
>efficient.  Additionally if you use Dynamic SQL then your individual 
>users who access the server will need EXPLICIT "SELECT" permissions by 
>you, which is another 'bad' practice.  In SQL Server you make data 
>available to your users via VIEWs and Stored Procedures or some other 
>secure way in order to protect your tables and it's data.
>
>ya get wot I mean?
>
>  
>


-- 
-Francisco




From mwp.reid at qub.ac.uk  Thu Jun 10 15:42:44 2004
From: mwp.reid at qub.ac.uk (Martin Reid)
Date: Thu, 10 Jun 2004 21:42:44 +0100
Subject: [dba-SQLServer] Difference between views and queries
References: <74169B16EF9024458197A72AF4643B7403A87DC3@agoc-pabu-16.agoc_nt5.agoc.com>
	<40C8C6B3.3050108@verizon.net>
Message-ID: <000b01c44f2b$7d2ebea0$1b02a8c0@MARTINREID>

Thats how we do it. We copy the live data out to another server and database
and the users report aganist that one. But then the data they use will only
change slightly over the academic year. I have never seen reporting tools
used on a live database anywhere I have worked. Thats not to say it dosnt
happen or is bad I just havnt seen it.

Martin

----- Original Message ----- 
From: "Francisco H Tapia" <my.lists at verizon.net>
To: <dba-sqlserver at databaseadvisors.com>
Sent: Thursday, June 10, 2004 9:38 PM
Subject: Re: [dba-SQLServer] Difference between views and queries


> SUCH developers need to be dragged out to the street to be tarred and
> feathered... ;o) j/k
> no...
>
> A lot of times I find that my boss will request that he wants a new
> table w/ a join to another table and somehow magically come up w/ some
> solution for some third criteria.  The fact remains that "HE" is not a
> developer.  that's why he hired me.  I know that sounds arrogant, but
> let's consider the performance of your SQL Server, if you have adequate
> RAM, CPU and a marginally good IO subsystem; well then your performance
> may even be acceptable.  I have no idea how long it takes to run "any"
> of your reports, but the ones we've written so far in Access whose
> recordsources are stored procedures, well, the result has been < 20
> seconds for reports that used to take well over 5 minutes in Access.  In
> fact just about all report run in the 2-3 seconds timespan which has
> helped make our new Access.ADP system shine.
>
> One thing that they've been missing is the ODBC access to tables to
> create their own reports. Many other SQL Developers often find a
> combination of VIEWS that are interpreted to the End Users as tables to
> help fill this gap, thus you'd have ODBC views which the users would
> think are "TABLES".  This will satisfy direct linking to tables and
> possibly promote better access time (tho not guarnateed, because as we
> all know, it is definatly easy enough to write a poorly joined SQL
> statement).
>
> another solution some developers use is to have another SERVER,
> generally known as a reporting server for processing CUBES of data.  In
> this scenario, data is replicated TO it by the LIVE system in generally
> a delayed Transactional method.  Many times the data is flattened out
> and de-normalized.  This helps hide ID's that are meaningless to
> endusers, and for them to have direct "table" access to such system.
> These systems often have to be guarded and monitored.
>
>
> so in your scenario the answer really is, "it depends" :).  If Views are
> a possiblity and your system is Not just for datawarehousing, then
> definitly I'd push in that direction.  If it were my system, I wouldn't
> want to be considered responsible for lack of availablity should people
> mis-construct their reports.
>
>
> Nicholson, Karen wrote On 6/10/2004 1:03 PM:
>
> >So what do you think of having tons of Crystal Reports that hit against
the
> >sql server (odbc) tables?  I prefer to create views for the Crystal
Reports
> >to read,
> >but everyone in this corporation likes to hit against the tables and
write
> >the
> >groupings, calculations, etc in Crystal.
> >
> >-----Original Message-----
> >From: dba-sqlserver-bounces at databaseadvisors.com
> >[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of
> >Francisco H Tapia
> >Sent: Thursday, June 10, 2004 3:58 PM
> >To: dba-sqlserver at databaseadvisors.com
> >Subject: Re: [dba-SQLServer] Difference between views and queries
> >
> >
> >jwcolby wrote On 6/10/2004 9:33 AM:
> >
> >
> >
> >>Can anyone explain the difference between a view and a query?  Views use
a
> >>query, plus the view keyword.  I have a couple of books that I have read
> >>
> >>
> >the
> >
> >
> >>chapter on Views, but I so far haven't managed to "get" why you wouldn't
> >>just use the query itself instead of turning it into a view.
> >>
> >>
> >>
> >>
> >A query is a request for an Access Database, however for Sql Server you
> >would either use a View or Stored Procedure to return the data you
> >wanted... you are also able to use dynamic SQL to retrieve the
> >information you need.  ANY request given to the SQL Server engine is
> >managed by the engine, unless you are running Remote servers (iirc).
> >
> >In Sql Server, it is TABOO, nay, GENERALLY bad practice to use dynamic
> >sql because of the implication of SQL INJECTION attacks, this poses a
> >"real" security threat to your database. and your server.
> >
> >another reason to use a VIEW over dynamic sql is that it is
> >pre-optimized by the SQL Server Engine and thus runs faster and more
> >efficient.  Additionally if you use Dynamic SQL then your individual
> >users who access the server will need EXPLICIT "SELECT" permissions by
> >you, which is another 'bad' practice.  In SQL Server you make data
> >available to your users via VIEWs and Stored Procedures or some other
> >secure way in order to protect your tables and it's data.
> >
> >ya get wot I mean?
> >
> >
> >
>
>
> -- 
> -Francisco
>
>
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
>
>



From knicholson at gpsx.net  Thu Jun 10 15:52:52 2004
From: knicholson at gpsx.net (Nicholson, Karen)
Date: Thu, 10 Jun 2004 16:52:52 -0400
Subject: [dba-SQLServer] Difference between views and queries
Message-ID: <74169B16EF9024458197A72AF4643B7403A87E06@agoc-pabu-16.agoc_nt5.agoc.com>

I am fighting against some dinosaurs; we have so many Crystal reports that
they take 16 hours to process per day.  One example is our sales commission
reports; 26 versions of the same data, just presented and grouped
differently.  175 Crystal formulas in each report - make a change and all 26
reports need to be changed.  I just wrote a file extract so that it changes
in one place.  I get the hair on their necks to stand up, but my blood
pressure is low.

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of Martin
Reid
Sent: Thursday, June 10, 2004 4:43 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Difference between views and queries


Thats how we do it. We copy the live data out to another server and database
and the users report aganist that one. But then the data they use will only
change slightly over the academic year. I have never seen reporting tools
used on a live database anywhere I have worked. Thats not to say it dosnt
happen or is bad I just havnt seen it.

Martin

----- Original Message ----- 
From: "Francisco H Tapia" <my.lists at verizon.net>
To: <dba-sqlserver at databaseadvisors.com>
Sent: Thursday, June 10, 2004 9:38 PM
Subject: Re: [dba-SQLServer] Difference between views and queries


> SUCH developers need to be dragged out to the street to be tarred and
> feathered... ;o) j/k
> no...
>
> A lot of times I find that my boss will request that he wants a new
> table w/ a join to another table and somehow magically come up w/ some
> solution for some third criteria.  The fact remains that "HE" is not a
> developer.  that's why he hired me.  I know that sounds arrogant, but
> let's consider the performance of your SQL Server, if you have adequate
> RAM, CPU and a marginally good IO subsystem; well then your performance
> may even be acceptable.  I have no idea how long it takes to run "any"
> of your reports, but the ones we've written so far in Access whose
> recordsources are stored procedures, well, the result has been < 20
> seconds for reports that used to take well over 5 minutes in Access.  In
> fact just about all report run in the 2-3 seconds timespan which has
> helped make our new Access.ADP system shine.
>
> One thing that they've been missing is the ODBC access to tables to
> create their own reports. Many other SQL Developers often find a
> combination of VIEWS that are interpreted to the End Users as tables to
> help fill this gap, thus you'd have ODBC views which the users would
> think are "TABLES".  This will satisfy direct linking to tables and
> possibly promote better access time (tho not guarnateed, because as we
> all know, it is definatly easy enough to write a poorly joined SQL
> statement).
>
> another solution some developers use is to have another SERVER,
> generally known as a reporting server for processing CUBES of data.  In
> this scenario, data is replicated TO it by the LIVE system in generally
> a delayed Transactional method.  Many times the data is flattened out
> and de-normalized.  This helps hide ID's that are meaningless to
> endusers, and for them to have direct "table" access to such system.
> These systems often have to be guarded and monitored.
>
>
> so in your scenario the answer really is, "it depends" :).  If Views are
> a possiblity and your system is Not just for datawarehousing, then
> definitly I'd push in that direction.  If it were my system, I wouldn't
> want to be considered responsible for lack of availablity should people
> mis-construct their reports.
>
>
> Nicholson, Karen wrote On 6/10/2004 1:03 PM:
>
> >So what do you think of having tons of Crystal Reports that hit against
the
> >sql server (odbc) tables?  I prefer to create views for the Crystal
Reports
> >to read,
> >but everyone in this corporation likes to hit against the tables and
write
> >the
> >groupings, calculations, etc in Crystal.
> >
> >-----Original Message-----
> >From: dba-sqlserver-bounces at databaseadvisors.com
> >[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of
> >Francisco H Tapia
> >Sent: Thursday, June 10, 2004 3:58 PM
> >To: dba-sqlserver at databaseadvisors.com
> >Subject: Re: [dba-SQLServer] Difference between views and queries
> >
> >
> >jwcolby wrote On 6/10/2004 9:33 AM:
> >
> >
> >
> >>Can anyone explain the difference between a view and a query?  Views use
a
> >>query, plus the view keyword.  I have a couple of books that I have read
> >>
> >>
> >the
> >
> >
> >>chapter on Views, but I so far haven't managed to "get" why you wouldn't
> >>just use the query itself instead of turning it into a view.
> >>
> >>
> >>
> >>
> >A query is a request for an Access Database, however for Sql Server you
> >would either use a View or Stored Procedure to return the data you
> >wanted... you are also able to use dynamic SQL to retrieve the
> >information you need.  ANY request given to the SQL Server engine is
> >managed by the engine, unless you are running Remote servers (iirc).
> >
> >In Sql Server, it is TABOO, nay, GENERALLY bad practice to use dynamic
> >sql because of the implication of SQL INJECTION attacks, this poses a
> >"real" security threat to your database. and your server.
> >
> >another reason to use a VIEW over dynamic sql is that it is
> >pre-optimized by the SQL Server Engine and thus runs faster and more
> >efficient.  Additionally if you use Dynamic SQL then your individual
> >users who access the server will need EXPLICIT "SELECT" permissions by
> >you, which is another 'bad' practice.  In SQL Server you make data
> >available to your users via VIEWs and Stored Procedures or some other
> >secure way in order to protect your tables and it's data.
> >
> >ya get wot I mean?
> >
> >
> >
>
>
> -- 
> -Francisco
>
>
> _______________________________________________
> 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 my.lists at verizon.net  Thu Jun 10 15:55:25 2004
From: my.lists at verizon.net (Francisco H Tapia)
Date: Thu, 10 Jun 2004 13:55:25 -0700
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <000801c44f29$63ef0a00$b274d0d5@minster33c3r25>
References: <000801c44f29$63ef0a00$b274d0d5@minster33c3r25>
Message-ID: <40C8CABD.1060002@verizon.net>

Andy,
  SQL Server is not Access on steriods, it's a diffrent engine, and thus 
requires a new level of thinking towards your database engine.  It's NOT 
that you couldn't, you can do anything, heck if you wanted to you can 
set up your SQL Server with a blank SA password or SA as the password.  
For all that matters, and avoiding all SQL Server authentication, just 
use NT authentication and enable guest users :).

There have been quite a few white papers circulating on why you 
"wouldn't" use dynamic sql w/ your sql server (check out 
www.sqlservercentral.com, a fine resource) but the 2 very critical 
factors include performance and also quite possible damage to your data.

It is entirely possible for your sql statement to read in this manner, 
lets's say that you are Selecting Data from a table and you have a 
combobox to help choose data, so your SQL Statment looks like this:

"Select CompanyName, CompanyAttribute1, pKey FROM tblCompany WHERE 
CompanyAttribute1 = '" & me.cboMyBOX & "'", If I was a malicious user on 
your system and I have direct access to tables, and if you're doing 
statements like the above it is entirely plausible that you also have 
"INSERT" statements thus you are giving more than just simple SELECT 
access to these tables., thus with some malformed selection I can add 
this in the select

'; DELETE FROM tblCompany; SELECT '

your final statement would look like this

Select CompanyName, CompanyAttribute1, pKey FROM tblCompany WHERE 
CompanyAttribute1 = ''; DELETE FROM tblCompany; SELECT ''

Now your entire COMPANY table has been wiped out, while it is completely 
possible to restore your db up to the minute, you've still lost some 
downtime given that you had ONE bad apple in the bunch.

Besides the sql injection threats, you also suffer from a 
NON-pre-compiled statement, thus your data could conceptually be 
returned a lot faster if you let it, simply by creating a view or stored 
procedure.  By the way just because you are using a stored procedure 
does not make you completly excempt of sql injections, if you are using 
dynamic sql within that procedure you are still open to these kind of 
attacks and your stored procedure is always re-comiled and thus suffers 
from the same performance deficits.


Andy Lacey wrote On 6/10/2004 1:27 PM:

>But, Francisco, if I was porting to SQL Server my Access app which builds
>SELECT statements dynamically all of the time for many and various
>situations are you saying I couldn't, or shouldn't or something?
>
>-- Andy Lacey
>http://www.minstersystems.co.uk 
>
>  
>
>>-----Original Message-----
>>From: dba-sqlserver-bounces at databaseadvisors.com 
>>[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf 
>>Of Francisco H Tapia
>>Sent: 10 June 2004 20:58
>>To: dba-sqlserver at databaseadvisors.com
>>Subject: Re: [dba-SQLServer] Difference between views and queries
>>
>>
>>jwcolby wrote On 6/10/2004 9:33 AM:
>>
>>    
>>
>>>Can anyone explain the difference between a view and a query?  Views 
>>>use a query, plus the view keyword.  I have a couple of books that I 
>>>have read the chapter on Views, but I so far haven't managed 
>>>      
>>>
>>to "get" 
>>    
>>
>>>why you wouldn't just use the query itself instead of 
>>>      
>>>
>>turning it into a 
>>    
>>
>>>view.
>>> 
>>>
>>>      
>>>
>>A query is a request for an Access Database, however for Sql 
>>Server you 
>>would either use a View or Stored Procedure to return the data you 
>>wanted... you are also able to use dynamic SQL to retrieve the 
>>information you need.  ANY request given to the SQL Server engine is 
>>managed by the engine, unless you are running Remote servers (iirc).
>>
>>In Sql Server, it is TABOO, nay, GENERALLY bad practice to 
>>use dynamic 
>>sql because of the implication of SQL INJECTION attacks, this poses a 
>>"real" security threat to your database. and your server.
>>
>>another reason to use a VIEW over dynamic sql is that it is 
>>pre-optimized by the SQL Server Engine and thus runs faster and more 
>>efficient.  Additionally if you use Dynamic SQL then your individual 
>>users who access the server will need EXPLICIT "SELECT" 
>>permissions by 
>>you, which is another 'bad' practice.  In SQL Server you make data 
>>available to your users via VIEWs and Stored Procedures or some other 
>>secure way in order to protect your tables and it's data.
>>
>>ya get wot I mean?
>>
>>-- 
>>-Francisco
>>
>>
>>_______________________________________________
>>dba-SQLServer mailing list
>>dba-SQLServer at databaseadvisors.com
>>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>>http://www.databaseadvisors.com
>>
>>
>>
>>    
>>
>
>_______________________________________________
>dba-SQLServer mailing list
>dba-SQLServer at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>http://www.databaseadvisors.com
>
>
>  
>


-- 
-Francisco




From my.lists at verizon.net  Thu Jun 10 16:02:37 2004
From: my.lists at verizon.net (Francisco H Tapia)
Date: Thu, 10 Jun 2004 14:02:37 -0700
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <1086899744.40c8c62017a00@webmail.service.emory.edu>
References: <001c01c44f08$a5d922a0$7e01a8c0@colbyws>	<40C8BD48.9050905@verizon.net>
	<1086899744.40c8c62017a00@webmail.service.emory.edu>
Message-ID: <40C8CC6D.6090202@verizon.net>

so long as you validate any data that will be surrounded in the dynamic 
sql you will lessen your risk for SQL Injections... from reading your 
post I understand this to be something like

Select CompanyName, CoAttr1, pKEY From TblCompany WHERE CoAttr1 = 1

by running a val on that entry, you prevent possible injections of 
things such as "1; TRUNCATE TABLE tblCompany"

this works fine for any values that are number based.  Depending on how 
many people are hitting your application, you may stand to benifit from 
using stored procedures where you PASS an interger value accross the 
wire, this improves 2 things, bandwidth (especially for really long SQL 
statements, really if you're on a 100mbit lan this is negligable, but 
consider hundereds or thousands of users, while the performance can be 
dismissed, you may guage some benifits. I'd run a test on some sample 
data if it were at all possible.)


Donna Martin wrote On 6/10/2004 1:35 PM:

>Regarding SQL Injection:  Sorry to get into this, but I use ColdFusion and cfc's
>to query the database.  Then I wrap my passed values in Val() so that no SQL
>injection can be performed.  I've been told that this works well, and have had
>my code checked by others far better than I.  They have confirmed.
>
>Do you agree?
>
>Thanks.
>
>Donna
>
>Quoting Francisco H Tapia <my.lists at verizon.net>:
>
>  
>
>>jwcolby wrote On 6/10/2004 9:33 AM:
>>
>>    
>>
>>>Can anyone explain the difference between a view and a query?  Views use a
>>>query, plus the view keyword.  I have a couple of books that I have read the
>>>chapter on Views, but I so far haven't managed to "get" why you wouldn't
>>>just use the query itself instead of turning it into a view.
>>>
>>>
>>>      
>>>
>>A query is a request for an Access Database, however for Sql Server you
>>would either use a View or Stored Procedure to return the data you
>>wanted... you are also able to use dynamic SQL to retrieve the
>>information you need.  ANY request given to the SQL Server engine is
>>managed by the engine, unless you are running Remote servers (iirc).
>>
>>In Sql Server, it is TABOO, nay, GENERALLY bad practice to use dynamic
>>sql because of the implication of SQL INJECTION attacks, this poses a
>>"real" security threat to your database. and your server.
>>
>>another reason to use a VIEW over dynamic sql is that it is
>>pre-optimized by the SQL Server Engine and thus runs faster and more
>>efficient.  Additionally if you use Dynamic SQL then your individual
>>users who access the server will need EXPLICIT "SELECT" permissions by
>>you, which is another 'bad' practice.  In SQL Server you make data
>>available to your users via VIEWs and Stored Procedures or some other
>>secure way in order to protect your tables and it's data.
>>
>>ya get wot I mean?
>>
>>
>>    
>>
>
>  
>


-- 
-Francisco




From my.lists at verizon.net  Thu Jun 10 16:04:57 2004
From: my.lists at verizon.net (Francisco H Tapia)
Date: Thu, 10 Jun 2004 14:04:57 -0700
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <74169B16EF9024458197A72AF4643B7403A87E06@agoc-pabu-16.agoc_nt5.agoc.com>
References: <74169B16EF9024458197A72AF4643B7403A87E06@agoc-pabu-16.agoc_nt5.agoc.com>
Message-ID: <40C8CCF9.7050103@verizon.net>

OOOOUUUUCHHH!!! :O
Well keep fighting the good fight.  We have a base stored procedure that 
feeds about 4 diffrent final reports... in the Access report they are 
just grouped and displayed diffrently, but make one change in one place 
and it is less headaches for us.  I like building on the principel of 
easy to maintain. That's my job security, making it easier....

Nicholson, Karen wrote On 6/10/2004 1:52 PM:

>I am fighting against some dinosaurs; we have so many Crystal reports that
>they take 16 hours to process per day.  One example is our sales commission
>reports; 26 versions of the same data, just presented and grouped
>differently.  175 Crystal formulas in each report - make a change and all 26
>reports need to be changed.  I just wrote a file extract so that it changes
>in one place.  I get the hair on their necks to stand up, but my blood
>pressure is low.
>
>-----Original Message-----
>From: dba-sqlserver-bounces at databaseadvisors.com
>[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of Martin
>Reid
>Sent: Thursday, June 10, 2004 4:43 PM
>To: dba-sqlserver at databaseadvisors.com
>Subject: Re: [dba-SQLServer] Difference between views and queries
>
>
>Thats how we do it. We copy the live data out to another server and database
>and the users report aganist that one. But then the data they use will only
>change slightly over the academic year. I have never seen reporting tools
>used on a live database anywhere I have worked. Thats not to say it dosnt
>happen or is bad I just havnt seen it.
>
>Martin
>
>----- Original Message ----- 
>From: "Francisco H Tapia" <my.lists at verizon.net>
>To: <dba-sqlserver at databaseadvisors.com>
>Sent: Thursday, June 10, 2004 9:38 PM
>Subject: Re: [dba-SQLServer] Difference between views and queries
>
>
>  
>
>>SUCH developers need to be dragged out to the street to be tarred and
>>feathered... ;o) j/k
>>no...
>>
>>A lot of times I find that my boss will request that he wants a new
>>table w/ a join to another table and somehow magically come up w/ some
>>solution for some third criteria.  The fact remains that "HE" is not a
>>developer.  that's why he hired me.  I know that sounds arrogant, but
>>let's consider the performance of your SQL Server, if you have adequate
>>RAM, CPU and a marginally good IO subsystem; well then your performance
>>may even be acceptable.  I have no idea how long it takes to run "any"
>>of your reports, but the ones we've written so far in Access whose
>>recordsources are stored procedures, well, the result has been < 20
>>seconds for reports that used to take well over 5 minutes in Access.  In
>>fact just about all report run in the 2-3 seconds timespan which has
>>helped make our new Access.ADP system shine.
>>
>>One thing that they've been missing is the ODBC access to tables to
>>create their own reports. Many other SQL Developers often find a
>>combination of VIEWS that are interpreted to the End Users as tables to
>>help fill this gap, thus you'd have ODBC views which the users would
>>think are "TABLES".  This will satisfy direct linking to tables and
>>possibly promote better access time (tho not guarnateed, because as we
>>all know, it is definatly easy enough to write a poorly joined SQL
>>statement).
>>
>>another solution some developers use is to have another SERVER,
>>generally known as a reporting server for processing CUBES of data.  In
>>this scenario, data is replicated TO it by the LIVE system in generally
>>a delayed Transactional method.  Many times the data is flattened out
>>and de-normalized.  This helps hide ID's that are meaningless to
>>endusers, and for them to have direct "table" access to such system.
>>These systems often have to be guarded and monitored.
>>
>>
>>so in your scenario the answer really is, "it depends" :).  If Views are
>>a possiblity and your system is Not just for datawarehousing, then
>>definitly I'd push in that direction.  If it were my system, I wouldn't
>>want to be considered responsible for lack of availablity should people
>>mis-construct their reports.
>>
>>
>>Nicholson, Karen wrote On 6/10/2004 1:03 PM:
>>
>>    
>>
>>>So what do you think of having tons of Crystal Reports that hit against
>>>      
>>>
>the
>  
>
>>>sql server (odbc) tables?  I prefer to create views for the Crystal
>>>      
>>>
>Reports
>  
>
>>>to read,
>>>but everyone in this corporation likes to hit against the tables and
>>>      
>>>
>write
>  
>
>>>the
>>>groupings, calculations, etc in Crystal.
>>>
>>>-----Original Message-----
>>>From: dba-sqlserver-bounces at databaseadvisors.com
>>>[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of
>>>Francisco H Tapia
>>>Sent: Thursday, June 10, 2004 3:58 PM
>>>To: dba-sqlserver at databaseadvisors.com
>>>Subject: Re: [dba-SQLServer] Difference between views and queries
>>>
>>>
>>>jwcolby wrote On 6/10/2004 9:33 AM:
>>>
>>>
>>>
>>>      
>>>
>>>>Can anyone explain the difference between a view and a query?  Views use
>>>>        
>>>>
>a
>  
>
>>>>query, plus the view keyword.  I have a couple of books that I have read
>>>>
>>>>
>>>>        
>>>>
>>>the
>>>
>>>
>>>      
>>>
>>>>chapter on Views, but I so far haven't managed to "get" why you wouldn't
>>>>just use the query itself instead of turning it into a view.
>>>>
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>A query is a request for an Access Database, however for Sql Server you
>>>would either use a View or Stored Procedure to return the data you
>>>wanted... you are also able to use dynamic SQL to retrieve the
>>>information you need.  ANY request given to the SQL Server engine is
>>>managed by the engine, unless you are running Remote servers (iirc).
>>>
>>>In Sql Server, it is TABOO, nay, GENERALLY bad practice to use dynamic
>>>sql because of the implication of SQL INJECTION attacks, this poses a
>>>"real" security threat to your database. and your server.
>>>
>>>another reason to use a VIEW over dynamic sql is that it is
>>>pre-optimized by the SQL Server Engine and thus runs faster and more
>>>efficient.  Additionally if you use Dynamic SQL then your individual
>>>users who access the server will need EXPLICIT "SELECT" permissions by
>>>you, which is another 'bad' practice.  In SQL Server you make data
>>>available to your users via VIEWs and Stored Procedures or some other
>>>secure way in order to protect your tables and it's data.
>>>
>>>ya get wot I mean?
>>>
>>>
>>>
>>>      
>>>
>>-- 
>>-Francisco
>>
>>
>>_______________________________________________
>>dba-SQLServer mailing list
>>dba-SQLServer at databaseadvisors.com
>>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>>http://www.databaseadvisors.com
>>
>>
>>    
>>
>
>_______________________________________________
>dba-SQLServer mailing list
>dba-SQLServer at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>http://www.databaseadvisors.com
>_______________________________________________
>dba-SQLServer mailing list
>dba-SQLServer at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>http://www.databaseadvisors.com
>
>
>  
>


-- 
-Francisco




From andy at minstersystems.co.uk  Thu Jun 10 16:15:40 2004
From: andy at minstersystems.co.uk (Andy Lacey)
Date: Thu, 10 Jun 2004 22:15:40 +0100
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <40C8CABD.1060002@verizon.net>
Message-ID: <000d01c44f30$16a03880$b274d0d5@minster33c3r25>

Thanks for the explanation.

Andy

> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com 
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf 
> Of Francisco H Tapia
> Sent: 10 June 2004 21:55
> To: dba-sqlserver at databaseadvisors.com
> Subject: Re: [dba-SQLServer] Difference between views and queries
> 
> 
> Andy,
>   SQL Server is not Access on steriods, it's a diffrent 
> engine, and thus 
> requires a new level of thinking towards your database 
> engine.  It's NOT 
> that you couldn't, you can do anything, heck if you wanted to you can 
> set up your SQL Server with a blank SA password or SA as the 
> password.  
> For all that matters, and avoiding all SQL Server 
> authentication, just 
> use NT authentication and enable guest users :).
> 
> There have been quite a few white papers circulating on why you 
> "wouldn't" use dynamic sql w/ your sql server (check out 
> www.sqlservercentral.com, a fine resource) but the 2 very critical 
> factors include performance and also quite possible damage to 
> your data.
> 
> It is entirely possible for your sql statement to read in 
> this manner, 
> lets's say that you are Selecting Data from a table and you have a 
> combobox to help choose data, so your SQL Statment looks like this:
> 
> "Select CompanyName, CompanyAttribute1, pKey FROM tblCompany WHERE 
> CompanyAttribute1 = '" & me.cboMyBOX & "'", If I was a 
> malicious user on 
> your system and I have direct access to tables, and if you're doing 
> statements like the above it is entirely plausible that you also have 
> "INSERT" statements thus you are giving more than just simple SELECT 
> access to these tables., thus with some malformed selection I can add 
> this in the select
> 
> '; DELETE FROM tblCompany; SELECT '
> 
> your final statement would look like this
> 
> Select CompanyName, CompanyAttribute1, pKey FROM tblCompany WHERE 
> CompanyAttribute1 = ''; DELETE FROM tblCompany; SELECT ''
> 
> Now your entire COMPANY table has been wiped out, while it is 
> completely 
> possible to restore your db up to the minute, you've still lost some 
> downtime given that you had ONE bad apple in the bunch.
> 
> Besides the sql injection threats, you also suffer from a 
> NON-pre-compiled statement, thus your data could conceptually be 
> returned a lot faster if you let it, simply by creating a 
> view or stored 
> procedure.  By the way just because you are using a stored procedure 
> does not make you completly excempt of sql injections, if you 
> are using 
> dynamic sql within that procedure you are still open to these kind of 
> attacks and your stored procedure is always re-comiled and 
> thus suffers 
> from the same performance deficits.
> 
> 
> Andy Lacey wrote On 6/10/2004 1:27 PM:
> 
> >But, Francisco, if I was porting to SQL Server my Access app which 
> >builds SELECT statements dynamically all of the time for many and 
> >various situations are you saying I couldn't, or shouldn't or 
> >something?
> >
> >-- Andy Lacey
> >http://www.minstersystems.co.uk
> >
> >  
> >
> >>-----Original Message-----
> >>From: dba-sqlserver-bounces at databaseadvisors.com
> >>[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf 
> >>Of Francisco H Tapia
> >>Sent: 10 June 2004 20:58
> >>To: dba-sqlserver at databaseadvisors.com
> >>Subject: Re: [dba-SQLServer] Difference between views and queries
> >>
> >>
> >>jwcolby wrote On 6/10/2004 9:33 AM:
> >>
> >>    
> >>
> >>>Can anyone explain the difference between a view and a 
> query?  Views
> >>>use a query, plus the view keyword.  I have a couple of 
> books that I 
> >>>have read the chapter on Views, but I so far haven't managed 
> >>>      
> >>>
> >>to "get"
> >>    
> >>
> >>>why you wouldn't just use the query itself instead of
> >>>      
> >>>
> >>turning it into a
> >>    
> >>
> >>>view.
> >>> 
> >>>
> >>>      
> >>>
> >>A query is a request for an Access Database, however for Sql
> >>Server you 
> >>would either use a View or Stored Procedure to return the data you 
> >>wanted... you are also able to use dynamic SQL to retrieve the 
> >>information you need.  ANY request given to the SQL Server 
> engine is 
> >>managed by the engine, unless you are running Remote servers (iirc).
> >>
> >>In Sql Server, it is TABOO, nay, GENERALLY bad practice to
> >>use dynamic 
> >>sql because of the implication of SQL INJECTION attacks, 
> this poses a 
> >>"real" security threat to your database. and your server.
> >>
> >>another reason to use a VIEW over dynamic sql is that it is
> >>pre-optimized by the SQL Server Engine and thus runs faster 
> and more 
> >>efficient.  Additionally if you use Dynamic SQL then your 
> individual 
> >>users who access the server will need EXPLICIT "SELECT" 
> >>permissions by 
> >>you, which is another 'bad' practice.  In SQL Server you make data 
> >>available to your users via VIEWs and Stored Procedures or 
> some other 
> >>secure way in order to protect your tables and it's data.
> >>
> >>ya get wot I mean?
> >>
> >>--
> >>-Francisco
> >>
> >>
> >>_______________________________________________
> >>dba-SQLServer mailing list
> >>dba-SQLServer at databaseadvisors.com
> >>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> >>http://www.databaseadvisors.com
> >>
> >>
> >>
> >>    
> >>
> >
> >_______________________________________________
> >dba-SQLServer mailing list
> >dba-SQLServer at databaseadvisors.com
> >http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> >http://www.databaseadvisors.com
> >
> >
> >  
> >
> 
> 
> -- 
> -Francisco
> 
> 
> _______________________________________________
> 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  Thu Jun 10 17:46:16 2004
From: accessd at shaw.ca (Jim Lawrence (AccessD))
Date: Thu, 10 Jun 2004 15:46:16 -0700
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <40C8CABD.1060002@verizon.net>
Message-ID: <FJEJLIPOMCGJALMGLLLIOEIHCDAA.accessd@shaw.ca>

Hi All:

As to all these issues I would like to dump some of my own comments. At the
risk of saying 'I told you so', I firmly believe that users should:

1. Always (or should I say only), use windows authentication and judiciously
distribute security access, to your SQLxx, to only those who need it.
Appropriate passwords and time limits.
1. Never allow access to the data except through your program. That means NO
to ODBC drivers only ADO-OLE.
2. In 99% of cases, control is handled through SPs.
3. And the biggy never, never use bound forms to access SQLxx data. I have
been whining about that for years, a position that M$ has also fully
supported.
4. You, as the programmer, should design your program to carefully validate
all requests and data before they are posted.

I may be already talking to the converted so you can ignore this; if
not..Get on the program.

Seeing we at in the midst of an election campaign, a good stump, political
speech is the expected.
Jim


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of
Francisco H Tapia
Sent: Thursday, June 10, 2004 1:55 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Difference between views and queries


Andy,
  SQL Server is not Access on steriods, it's a diffrent engine, and thus
requires a new level of thinking towards your database engine.  It's NOT
that you couldn't, you can do anything, heck if you wanted to you can
set up your SQL Server with a blank SA password or SA as the password.
For all that matters, and avoiding all SQL Server authentication, just
use NT authentication and enable guest users :).

There have been quite a few white papers circulating on why you
"wouldn't" use dynamic sql w/ your sql server (check out
www.sqlservercentral.com, a fine resource) but the 2 very critical
factors include performance and also quite possible damage to your data.

It is entirely possible for your sql statement to read in this manner,
lets's say that you are Selecting Data from a table and you have a
combobox to help choose data, so your SQL Statment looks like this:

"Select CompanyName, CompanyAttribute1, pKey FROM tblCompany WHERE
CompanyAttribute1 = '" & me.cboMyBOX & "'", If I was a malicious user on
your system and I have direct access to tables, and if you're doing
statements like the above it is entirely plausible that you also have
"INSERT" statements thus you are giving more than just simple SELECT
access to these tables., thus with some malformed selection I can add
this in the select

'; DELETE FROM tblCompany; SELECT '

your final statement would look like this

Select CompanyName, CompanyAttribute1, pKey FROM tblCompany WHERE
CompanyAttribute1 = ''; DELETE FROM tblCompany; SELECT ''

Now your entire COMPANY table has been wiped out, while it is completely
possible to restore your db up to the minute, you've still lost some
downtime given that you had ONE bad apple in the bunch.

Besides the sql injection threats, you also suffer from a
NON-pre-compiled statement, thus your data could conceptually be
returned a lot faster if you let it, simply by creating a view or stored
procedure.  By the way just because you are using a stored procedure
does not make you completly excempt of sql injections, if you are using
dynamic sql within that procedure you are still open to these kind of
attacks and your stored procedure is always re-comiled and thus suffers
from the same performance deficits.


Andy Lacey wrote On 6/10/2004 1:27 PM:

>But, Francisco, if I was porting to SQL Server my Access app which builds
>SELECT statements dynamically all of the time for many and various
>situations are you saying I couldn't, or shouldn't or something?
>
>-- Andy Lacey
>http://www.minstersystems.co.uk
>
>
>
>>-----Original Message-----
>>From: dba-sqlserver-bounces at databaseadvisors.com
>>[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf
>>Of Francisco H Tapia
>>Sent: 10 June 2004 20:58
>>To: dba-sqlserver at databaseadvisors.com
>>Subject: Re: [dba-SQLServer] Difference between views and queries
>>
>>
>>jwcolby wrote On 6/10/2004 9:33 AM:
>>
>>
>>
>>>Can anyone explain the difference between a view and a query?  Views
>>>use a query, plus the view keyword.  I have a couple of books that I
>>>have read the chapter on Views, but I so far haven't managed
>>>
>>>
>>to "get"
>>
>>
>>>why you wouldn't just use the query itself instead of
>>>
>>>
>>turning it into a
>>
>>
>>>view.
>>>
>>>
>>>
>>>
>>A query is a request for an Access Database, however for Sql
>>Server you
>>would either use a View or Stored Procedure to return the data you
>>wanted... you are also able to use dynamic SQL to retrieve the
>>information you need.  ANY request given to the SQL Server engine is
>>managed by the engine, unless you are running Remote servers (iirc).
>>
>>In Sql Server, it is TABOO, nay, GENERALLY bad practice to
>>use dynamic
>>sql because of the implication of SQL INJECTION attacks, this poses a
>>"real" security threat to your database. and your server.
>>
>>another reason to use a VIEW over dynamic sql is that it is
>>pre-optimized by the SQL Server Engine and thus runs faster and more
>>efficient.  Additionally if you use Dynamic SQL then your individual
>>users who access the server will need EXPLICIT "SELECT"
>>permissions by
>>you, which is another 'bad' practice.  In SQL Server you make data
>>available to your users via VIEWs and Stored Procedures or some other
>>secure way in order to protect your tables and it's data.
>>
>>ya get wot I mean?
>>
>>--
>>-Francisco
>>
>>
>>_______________________________________________
>>dba-SQLServer mailing list
>>dba-SQLServer at databaseadvisors.com
>>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>>http://www.databaseadvisors.com
>>
>>
>>
>>
>>
>
>_______________________________________________
>dba-SQLServer mailing list
>dba-SQLServer at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>http://www.databaseadvisors.com
>
>
>
>


--
-Francisco


_______________________________________________
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  Thu Jun 10 14:07:25 2004
From: accessd at shaw.ca (Jim Lawrence (AccessD))
Date: Thu, 10 Jun 2004 12:07:25 -0700
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <001c01c44f08$a5d922a0$7e01a8c0@colbyws>
Message-ID: <FJEJLIPOMCGJALMGLLLIOEIDCDAA.accessd@shaw.ca>

Hi John:

Personally, I see little reason to run views as their creation is spawned at
the server side and any hit on the server I try to avoid. The concept of
distributive computing has always appealed to me. Queries, run at the client
side.

There might be better performance with views, if there are limited people
accessing the server. Views limit, not that the client can see it anyway,
access to/display of the real table and present a pseudo table. Security?

HTH
Jim

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of jwcolby
Sent: Thursday, June 10, 2004 9:33 AM
To: SQLServer
Subject: [dba-SQLServer] Difference between views and queries


Can anyone explain the difference between a view and a query?  Views use a
query, plus the view keyword.  I have a couple of books that I have read the
chapter on Views, but I so far haven't managed to "get" why you wouldn't
just use the query itself instead of turning it into a view.


John W. Colby
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  Fri Jun 11 06:38:41 2004
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Fri, 11 Jun 2004 07:38:41 -0400
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <FJEJLIPOMCGJALMGLLLIOEIDCDAA.accessd@shaw.ca>
Message-ID: <000a01c44fa8$a59ac460$0501a8c0@colbyws>

I think the answer to my question is that views ARE what we in Access think
of as stored queries.

John W. Colby 
www.ColbyConsulting.com

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Jim
Lawrence (AccessD)
Sent: Thursday, June 10, 2004 3:07 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


Hi John:

Personally, I see little reason to run views as their creation is spawned at
the server side and any hit on the server I try to avoid. The concept of
distributive computing has always appealed to me. Queries, run at the client
side.

There might be better performance with views, if there are limited people
accessing the server. Views limit, not that the client can see it anyway,
access to/display of the real table and present a pseudo table. Security?

HTH
Jim

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of jwcolby
Sent: Thursday, June 10, 2004 9:33 AM
To: SQLServer
Subject: [dba-SQLServer] Difference between views and queries


Can anyone explain the difference between a view and a query?  Views use a
query, plus the view keyword.  I have a couple of books that I have read the
chapter on Views, but I so far haven't managed to "get" why you wouldn't
just use the query itself instead of turning it into a view.


John W. Colby
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 JRojas at tnco-inc.com  Fri Jun 11 07:38:03 2004
From: JRojas at tnco-inc.com (Joe Rojas)
Date: Fri, 11 Jun 2004 08:38:03 -0400
Subject: [dba-SQLServer] Difference between views and queries
Message-ID: <0CC84C9461AE6445AD5A602001C41C4B059D29@mercury.tnco-inc.com>

Hi Jim,

What is the argument for not using bound forms?

JR

-----Original Message-----
From: Jim Lawrence (AccessD) [mailto:accessd at shaw.ca]
Sent: Thursday, June 10, 2004 6:46 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries

Hi All:

As to all these issues I would like to dump some of my own comments. At the
risk of saying 'I told you so', I firmly believe that users should:

1. Always (or should I say only), use windows authentication and judiciously
distribute security access, to your SQLxx, to only those who need it.
Appropriate passwords and time limits.
1. Never allow access to the data except through your program. That means NO
to ODBC drivers only ADO-OLE.
2. In 99% of cases, control is handled through SPs.
3. And the biggy never, never use bound forms to access SQLxx data. I have
been whining about that for years, a position that M$ has also fully
supported.
4. You, as the programmer, should design your program to carefully validate
all requests and data before they are posted.

I may be already talking to the converted so you can ignore this; if
not..Get on the program.

Seeing we at in the midst of an election campaign, a good stump, political
speech is the expected.
Jim


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of
Francisco H Tapia
Sent: Thursday, June 10, 2004 1:55 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Difference between views and queries


Andy,
  SQL Server is not Access on steriods, it's a diffrent engine, and thus
requires a new level of thinking towards your database engine.  It's NOT
that you couldn't, you can do anything, heck if you wanted to you can
set up your SQL Server with a blank SA password or SA as the password.
For all that matters, and avoiding all SQL Server authentication, just
use NT authentication and enable guest users :).

There have been quite a few white papers circulating on why you
"wouldn't" use dynamic sql w/ your sql server (check out
www.sqlservercentral.com, a fine resource) but the 2 very critical
factors include performance and also quite possible damage to your data.

It is entirely possible for your sql statement to read in this manner,
lets's say that you are Selecting Data from a table and you have a
combobox to help choose data, so your SQL Statment looks like this:

"Select CompanyName, CompanyAttribute1, pKey FROM tblCompany WHERE
CompanyAttribute1 = '" & me.cboMyBOX & "'", If I was a malicious user on
your system and I have direct access to tables, and if you're doing
statements like the above it is entirely plausible that you also have
"INSERT" statements thus you are giving more than just simple SELECT
access to these tables., thus with some malformed selection I can add
this in the select

'; DELETE FROM tblCompany; SELECT '

your final statement would look like this

Select CompanyName, CompanyAttribute1, pKey FROM tblCompany WHERE
CompanyAttribute1 = ''; DELETE FROM tblCompany; SELECT ''

Now your entire COMPANY table has been wiped out, while it is completely
possible to restore your db up to the minute, you've still lost some
downtime given that you had ONE bad apple in the bunch.

Besides the sql injection threats, you also suffer from a
NON-pre-compiled statement, thus your data could conceptually be
returned a lot faster if you let it, simply by creating a view or stored
procedure.  By the way just because you are using a stored procedure
does not make you completly excempt of sql injections, if you are using
dynamic sql within that procedure you are still open to these kind of
attacks and your stored procedure is always re-comiled and thus suffers
from the same performance deficits.


Andy Lacey wrote On 6/10/2004 1:27 PM:

>But, Francisco, if I was porting to SQL Server my Access app which builds
>SELECT statements dynamically all of the time for many and various
>situations are you saying I couldn't, or shouldn't or something?
>
>-- Andy Lacey
>http://www.minstersystems.co.uk
>
>
>
>>-----Original Message-----
>>From: dba-sqlserver-bounces at databaseadvisors.com
>>[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf
>>Of Francisco H Tapia
>>Sent: 10 June 2004 20:58
>>To: dba-sqlserver at databaseadvisors.com
>>Subject: Re: [dba-SQLServer] Difference between views and queries
>>
>>
>>jwcolby wrote On 6/10/2004 9:33 AM:
>>
>>
>>
>>>Can anyone explain the difference between a view and a query?  Views
>>>use a query, plus the view keyword.  I have a couple of books that I
>>>have read the chapter on Views, but I so far haven't managed
>>>
>>>
>>to "get"
>>
>>
>>>why you wouldn't just use the query itself instead of
>>>
>>>
>>turning it into a
>>
>>
>>>view.
>>>
>>>
>>>
>>>
>>A query is a request for an Access Database, however for Sql
>>Server you
>>would either use a View or Stored Procedure to return the data you
>>wanted... you are also able to use dynamic SQL to retrieve the
>>information you need.  ANY request given to the SQL Server engine is
>>managed by the engine, unless you are running Remote servers (iirc).
>>
>>In Sql Server, it is TABOO, nay, GENERALLY bad practice to
>>use dynamic
>>sql because of the implication of SQL INJECTION attacks, this poses a
>>"real" security threat to your database. and your server.
>>
>>another reason to use a VIEW over dynamic sql is that it is
>>pre-optimized by the SQL Server Engine and thus runs faster and more
>>efficient.  Additionally if you use Dynamic SQL then your individual
>>users who access the server will need EXPLICIT "SELECT"
>>permissions by
>>you, which is another 'bad' practice.  In SQL Server you make data
>>available to your users via VIEWs and Stored Procedures or some other
>>secure way in order to protect your tables and it's data.
>>
>>ya get wot I mean?
>>
>>--
>>-Francisco
>>
>>
>>_______________________________________________
>>dba-SQLServer mailing list
>>dba-SQLServer at databaseadvisors.com
>>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>>http://www.databaseadvisors.com
>>
>>
>>
>>
>>
>
>_______________________________________________
>dba-SQLServer mailing list
>dba-SQLServer at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>http://www.databaseadvisors.com
>
>
>
>


--
-Francisco


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

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



This electronic transmission is strictly confidential to TNCO, Inc. and
intended solely for the addressee. It may contain information which is
covered by legal, professional, or other privileges. If you are not the
intended addressee, or someone authorized by the intended addressee to
receive transmissions on behalf of the addressee, you must not retain,
disclose in any form, copy, or take any action in reliance on this
transmission. If you have received this transmission in error, please notify
the sender as soon as possible and destroy this message. While TNCO, Inc.
uses virus protection, the recipient should check this email and any
attachments for the presence of viruses. TNCO, Inc. accepts no liability for
any damage caused by any virus transmitted by this email.


From DElam at jenkens.com  Fri Jun 11 08:13:04 2004
From: DElam at jenkens.com (Elam, Debbie)
Date: Fri, 11 Jun 2004 08:13:04 -0500
Subject: [dba-SQLServer] Difference between views and queries
Message-ID: <7B1961ED924D1A459E378C9B1BB22B4C02485089@natexch.jenkens.com>

Just the opposite, I have always tried to harness the greater computing
power on the server and drag less data across the wire which is a
performance plus.  Views also have security independent of tables.  I have a
much better control of what data is editable and when by what view I use.

Debbie

-----Original Message-----
From: Jim Lawrence (AccessD) [mailto:accessd at shaw.ca] 
Sent: Thursday, June 10, 2004 2:07 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


Hi John:

Personally, I see little reason to run views as their creation is spawned at
the server side and any hit on the server I try to avoid. The concept of
distributive computing has always appealed to me. Queries, run at the client
side.

There might be better performance with views, if there are limited people
accessing the server. Views limit, not that the client can see it anyway,
access to/display of the real table and present a pseudo table. Security?

HTH
Jim

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of jwcolby
Sent: Thursday, June 10, 2004 9:33 AM
To: SQLServer
Subject: [dba-SQLServer] Difference between views and queries


Can anyone explain the difference between a view and a query?  Views use a
query, plus the view keyword.  I have a couple of books that I have read the
chapter on Views, but I so far haven't managed to "get" why you wouldn't
just use the query itself instead of turning it into a view.


John W. Colby
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
- JENKENS & GILCHRIST E-MAIL NOTICE - This transmission may be: (1) subject
to the Attorney-Client Privilege, (2) an attorney work product, or (3)
strictly confidential. If you are not the intended recipient of this
message, you may not disclose, print, copy or disseminate this information.
If you have received this in error, please reply and notify the sender
(only) and delete the message. Unauthorized interception of this e-mail is a
violation of federal criminal law. 
This communication does not reflect an intention by the sender or the
sender's client or principal to conduct a transaction or make any agreement
by electronic means.  Nothing contained in this message or in any attachment
shall satisfy the requirements for a writing, and nothing contained herein
shall constitute a contract or electronic signature under the Electronic
Signatures in Global and National Commerce Act, any version of the Uniform
Electronic Transactions Act or any other statute governing electronic
transactions.


From stuart at lexacorp.com.pg  Fri Jun 11 08:20:39 2004
From: stuart at lexacorp.com.pg (Stuart McLachlan)
Date: Fri, 11 Jun 2004 23:20:39 +1000
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <FJEJLIPOMCGJALMGLLLIOEIDCDAA.accessd@shaw.ca>
References: <001c01c44f08$a5d922a0$7e01a8c0@colbyws>
Message-ID: <40CA3E47.31022.352D48F@localhost>

On 10 Jun 2004 at 12:07, Jim Lawrence (AccessD) wrote:

> Hi John:
> 
> Personally, I see little reason to run views as their creation is spawned at
> the server side and any hit on the server I try to avoid. The concept of
> distributive computing has always appealed to me. Queries, run at the client
> side.
> 

But surely not when it means pulling unnecessary data and indexes across the 
network. The whole point of server side computation is to reduce the network 
traffic bottleneck.  I'd much rather let the server sort throuygh a million 
rows and feed the workstation with a thousand, rather than pass all million 
across the network and filter then client side.

> There might be better performance with views, if there are limited people
> accessing the server. 

The more people hitting the server the better, you gain more from caching :-)

Views limit, not that the client can see it anyway,
> access to/display of the real table and present a pseudo table. Security?
> 

That enhances security, not dimishes it.


 
-- 
Lexacorp Ltd
http://www.lexacorp.com.pg
Information Technology Consultancy, Software Development,System Support.





From rl_stewart at highstream.net  Fri Jun 11 08:38:29 2004
From: rl_stewart at highstream.net (Robert L. Stewart)
Date: Fri, 11 Jun 2004 08:38:29 -0500
Subject: [dba-SQLServer] Re:  Difference between views and queries
In-Reply-To: <200406111320.i5BDKxQ30653@databaseadvisors.com>
Message-ID: <5.1.0.14.2.20040611083741.017e5810@pop3.highstream.net>

Jim,

I am glad I am not one of your customers.  I prefer performance.

Robert

At 08:20 AM 6/11/2004 -0500, you wrote:
>From: Jim Lawrence (AccessD) [mailto:accessd at shaw.ca]
>Sent: Thursday, June 10, 2004 2:07 PM
>To: dba-sqlserver at databaseadvisors.com
>Subject: RE: [dba-SQLServer] Difference between views and queries
>
>
>Hi John:
>
>Personally, I see little reason to run views as their creation is spawned at
>the server side and any hit on the server I try to avoid. The concept of
>distributive computing has always appealed to me. Queries, run at the client
>side.
>
>There might be better performance with views, if there are limited people
>accessing the server. Views limit, not that the client can see it anyway,
>access to/display of the real table and present a pseudo table. Security?
>
>HTH
>Jim




From jwcolby at colbyconsulting.com  Fri Jun 11 08:47:09 2004
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Fri, 11 Jun 2004 09:47:09 -0400
Subject: [dba-SQLServer] Re:  Difference between views and queries
In-Reply-To: <5.1.0.14.2.20040611083741.017e5810@pop3.highstream.net>
Message-ID: <000801c44fba$97d8b690$0501a8c0@colbyws>

>I am glad I am not one of your customers.  I prefer performance.

LOL.  Be nice Robert.

John W. Colby 
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: Friday, June 11, 2004 9:38 AM
To: dba-sqlserver at databaseadvisors.com
Subject: [dba-SQLServer] Re: Difference between views and queries


Jim,

I am glad I am not one of your customers.  I prefer performance.

Robert

At 08:20 AM 6/11/2004 -0500, you wrote:
>From: Jim Lawrence (AccessD) [mailto:accessd at shaw.ca]
>Sent: Thursday, June 10, 2004 2:07 PM
>To: dba-sqlserver at databaseadvisors.com
>Subject: RE: [dba-SQLServer] Difference between views and queries
>
>
>Hi John:
>
>Personally, I see little reason to run views as their creation is 
>spawned at the server side and any hit on the server I try to avoid. 
>The concept of distributive computing has always appealed to me. 
>Queries, run at the client side.
>
>There might be better performance with views, if there are limited 
>people accessing the server. Views limit, not that the client can see 
>it anyway, access to/display of the real table and present a pseudo 
>table. Security?
>
>HTH
>Jim


_______________________________________________
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  Fri Jun 11 10:16:29 2004
From: cfoust at infostatsystems.com (Charlotte Foust)
Date: Fri, 11 Jun 2004 08:16:29 -0700
Subject: [dba-SQLServer] Difference between views and queries
Message-ID: <E61FC1D4B1918244905B113C680BEA8631285F@infoserver01.infostat.local>

Bound forms require ODBC links to be editable.  Forms (in Access MDBs)
bound to ADO recordsets are not updatable, and ADO is the only option
that avoids ODBC links to return a recordset.

Charlotte Foust

-----Original Message-----
From: Joe Rojas [mailto:JRojas at tnco-inc.com] 
Sent: Friday, June 11, 2004 4:38 AM
To: 'dba-sqlserver at databaseadvisors.com'
Subject: RE: [dba-SQLServer] Difference between views and queries


Hi Jim,

What is the argument for not using bound forms?

JR

-----Original Message-----
From: Jim Lawrence (AccessD) [mailto:accessd at shaw.ca]
Sent: Thursday, June 10, 2004 6:46 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries

Hi All:

As to all these issues I would like to dump some of my own comments. At
the risk of saying 'I told you so', I firmly believe that users should:

1. Always (or should I say only), use windows authentication and
judiciously distribute security access, to your SQLxx, to only those who
need it. Appropriate passwords and time limits. 1. Never allow access to
the data except through your program. That means NO to ODBC drivers only
ADO-OLE. 2. In 99% of cases, control is handled through SPs. 3. And the
biggy never, never use bound forms to access SQLxx data. I have been
whining about that for years, a position that M$ has also fully
supported. 4. You, as the programmer, should design your program to
carefully validate all requests and data before they are posted.

I may be already talking to the converted so you can ignore this; if
not..Get on the program.

Seeing we at in the midst of an election campaign, a good stump,
political speech is the expected. Jim


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of
Francisco H Tapia
Sent: Thursday, June 10, 2004 1:55 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Difference between views and queries


Andy,
  SQL Server is not Access on steriods, it's a diffrent engine, and thus
requires a new level of thinking towards your database engine.  It's NOT
that you couldn't, you can do anything, heck if you wanted to you can
set up your SQL Server with a blank SA password or SA as the password.
For all that matters, and avoiding all SQL Server authentication, just
use NT authentication and enable guest users :).

There have been quite a few white papers circulating on why you
"wouldn't" use dynamic sql w/ your sql server (check out
www.sqlservercentral.com, a fine resource) but the 2 very critical
factors include performance and also quite possible damage to your data.

It is entirely possible for your sql statement to read in this manner,
lets's say that you are Selecting Data from a table and you have a
combobox to help choose data, so your SQL Statment looks like this:

"Select CompanyName, CompanyAttribute1, pKey FROM tblCompany WHERE
CompanyAttribute1 = '" & me.cboMyBOX & "'", If I was a malicious user on
your system and I have direct access to tables, and if you're doing
statements like the above it is entirely plausible that you also have
"INSERT" statements thus you are giving more than just simple SELECT
access to these tables., thus with some malformed selection I can add
this in the select

'; DELETE FROM tblCompany; SELECT '

your final statement would look like this

Select CompanyName, CompanyAttribute1, pKey FROM tblCompany WHERE
CompanyAttribute1 = ''; DELETE FROM tblCompany; SELECT ''

Now your entire COMPANY table has been wiped out, while it is completely
possible to restore your db up to the minute, you've still lost some
downtime given that you had ONE bad apple in the bunch.

Besides the sql injection threats, you also suffer from a
NON-pre-compiled statement, thus your data could conceptually be
returned a lot faster if you let it, simply by creating a view or stored
procedure.  By the way just because you are using a stored procedure
does not make you completly excempt of sql injections, if you are using
dynamic sql within that procedure you are still open to these kind of
attacks and your stored procedure is always re-comiled and thus suffers
from the same performance deficits.


Andy Lacey wrote On 6/10/2004 1:27 PM:

>But, Francisco, if I was porting to SQL Server my Access app which 
>builds SELECT statements dynamically all of the time for many and 
>various situations are you saying I couldn't, or shouldn't or 
>something?
>
>-- Andy Lacey
>http://www.minstersystems.co.uk
>
>
>
>>-----Original Message-----
>>From: dba-sqlserver-bounces at databaseadvisors.com
>>[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of 
>>Francisco H Tapia
>>Sent: 10 June 2004 20:58
>>To: dba-sqlserver at databaseadvisors.com
>>Subject: Re: [dba-SQLServer] Difference between views and queries
>>
>>
>>jwcolby wrote On 6/10/2004 9:33 AM:
>>
>>
>>
>>>Can anyone explain the difference between a view and a query?  Views 
>>>use a query, plus the view keyword.  I have a couple of books that I 
>>>have read the chapter on Views, but I so far haven't managed
>>>
>>>
>>to "get"
>>
>>
>>>why you wouldn't just use the query itself instead of
>>>
>>>
>>turning it into a
>>
>>
>>>view.
>>>
>>>
>>>
>>>
>>A query is a request for an Access Database, however for Sql Server 
>>you would either use a View or Stored Procedure to return the data you
>>wanted... you are also able to use dynamic SQL to retrieve the
>>information you need.  ANY request given to the SQL Server engine is
>>managed by the engine, unless you are running Remote servers (iirc).
>>
>>In Sql Server, it is TABOO, nay, GENERALLY bad practice to use dynamic
>>sql because of the implication of SQL INJECTION attacks, this poses a
>>"real" security threat to your database. and your server.
>>
>>another reason to use a VIEW over dynamic sql is that it is 
>>pre-optimized by the SQL Server Engine and thus runs faster and more 
>>efficient.  Additionally if you use Dynamic SQL then your individual 
>>users who access the server will need EXPLICIT "SELECT" permissions by
>>you, which is another 'bad' practice.  In SQL Server you make data
>>available to your users via VIEWs and Stored Procedures or some other
>>secure way in order to protect your tables and it's data.
>>
>>ya get wot I mean?
>>
>>--
>>-Francisco
>>
>>
>>_______________________________________________
>>dba-SQLServer mailing list
>>dba-SQLServer at databaseadvisors.com
>>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>>http://www.databaseadvisors.com
>>
>>
>>
>>
>>
>
>_______________________________________________
>dba-SQLServer mailing list
>dba-SQLServer at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>http://www.databaseadvisors.com
>
>
>
>


--
-Francisco


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

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



This electronic transmission is strictly confidential to TNCO, Inc. and
intended solely for the addressee. It may contain information which is
covered by legal, professional, or other privileges. If you are not the
intended addressee, or someone authorized by the intended addressee to
receive transmissions on behalf of the addressee, you must not retain,
disclose in any form, copy, or take any action in reliance on this
transmission. If you have received this transmission in error, please
notify the sender as soon as possible and destroy this message. While
TNCO, Inc. uses virus protection, the recipient should check this email
and any attachments for the presence of viruses. TNCO, Inc. accepts no
liability for any damage caused by any virus transmitted by this email.
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com



From CMackin at Quiznos.com  Fri Jun 11 10:20:53 2004
From: CMackin at Quiznos.com (Mackin, Christopher)
Date: Fri, 11 Jun 2004 09:20:53 -0600
Subject: [dba-SQLServer] Difference between views and queries
Message-ID: <19F28F0B4284C04FB90CAA380451FFD941291B@bross.quiznos.net>

Not so for an .adp though, where you can bind a form directly to SQL data
without ODBC.

-Chris Mackin

-----Original Message-----
From: Charlotte Foust [mailto:cfoust at infostatsystems.com]
Sent: Friday, June 11, 2004 9:16 AM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


Bound forms require ODBC links to be editable.  Forms (in Access MDBs)
bound to ADO recordsets are not updatable, and ADO is the only option
that avoids ODBC links to return a recordset.

Charlotte Foust

-----Original Message-----
From: Joe Rojas [mailto:JRojas at tnco-inc.com] 
Sent: Friday, June 11, 2004 4:38 AM
To: 'dba-sqlserver at databaseadvisors.com'
Subject: RE: [dba-SQLServer] Difference between views and queries


Hi Jim,

What is the argument for not using bound forms?

JR

-----Original Message-----
From: Jim Lawrence (AccessD) [mailto:accessd at shaw.ca]
Sent: Thursday, June 10, 2004 6:46 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries

Hi All:

As to all these issues I would like to dump some of my own comments. At
the risk of saying 'I told you so', I firmly believe that users should:

1. Always (or should I say only), use windows authentication and
judiciously distribute security access, to your SQLxx, to only those who
need it. Appropriate passwords and time limits. 1. Never allow access to
the data except through your program. That means NO to ODBC drivers only
ADO-OLE. 2. In 99% of cases, control is handled through SPs. 3. And the
biggy never, never use bound forms to access SQLxx data. I have been
whining about that for years, a position that M$ has also fully
supported. 4. You, as the programmer, should design your program to
carefully validate all requests and data before they are posted.

I may be already talking to the converted so you can ignore this; if
not..Get on the program.

Seeing we at in the midst of an election campaign, a good stump,
political speech is the expected. Jim


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of
Francisco H Tapia
Sent: Thursday, June 10, 2004 1:55 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Difference between views and queries


Andy,
  SQL Server is not Access on steriods, it's a diffrent engine, and thus
requires a new level of thinking towards your database engine.  It's NOT
that you couldn't, you can do anything, heck if you wanted to you can
set up your SQL Server with a blank SA password or SA as the password.
For all that matters, and avoiding all SQL Server authentication, just
use NT authentication and enable guest users :).

There have been quite a few white papers circulating on why you
"wouldn't" use dynamic sql w/ your sql server (check out
www.sqlservercentral.com, a fine resource) but the 2 very critical
factors include performance and also quite possible damage to your data.

It is entirely possible for your sql statement to read in this manner,
lets's say that you are Selecting Data from a table and you have a
combobox to help choose data, so your SQL Statment looks like this:

"Select CompanyName, CompanyAttribute1, pKey FROM tblCompany WHERE
CompanyAttribute1 = '" & me.cboMyBOX & "'", If I was a malicious user on
your system and I have direct access to tables, and if you're doing
statements like the above it is entirely plausible that you also have
"INSERT" statements thus you are giving more than just simple SELECT
access to these tables., thus with some malformed selection I can add
this in the select

'; DELETE FROM tblCompany; SELECT '

your final statement would look like this

Select CompanyName, CompanyAttribute1, pKey FROM tblCompany WHERE
CompanyAttribute1 = ''; DELETE FROM tblCompany; SELECT ''

Now your entire COMPANY table has been wiped out, while it is completely
possible to restore your db up to the minute, you've still lost some
downtime given that you had ONE bad apple in the bunch.

Besides the sql injection threats, you also suffer from a
NON-pre-compiled statement, thus your data could conceptually be
returned a lot faster if you let it, simply by creating a view or stored
procedure.  By the way just because you are using a stored procedure
does not make you completly excempt of sql injections, if you are using
dynamic sql within that procedure you are still open to these kind of
attacks and your stored procedure is always re-comiled and thus suffers
from the same performance deficits.


Andy Lacey wrote On 6/10/2004 1:27 PM:

>But, Francisco, if I was porting to SQL Server my Access app which 
>builds SELECT statements dynamically all of the time for many and 
>various situations are you saying I couldn't, or shouldn't or 
>something?
>
>-- Andy Lacey
>http://www.minstersystems.co.uk
>
>
>
>>-----Original Message-----
>>From: dba-sqlserver-bounces at databaseadvisors.com
>>[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of 
>>Francisco H Tapia
>>Sent: 10 June 2004 20:58
>>To: dba-sqlserver at databaseadvisors.com
>>Subject: Re: [dba-SQLServer] Difference between views and queries
>>
>>
>>jwcolby wrote On 6/10/2004 9:33 AM:
>>
>>
>>
>>>Can anyone explain the difference between a view and a query?  Views 
>>>use a query, plus the view keyword.  I have a couple of books that I 
>>>have read the chapter on Views, but I so far haven't managed
>>>
>>>
>>to "get"
>>
>>
>>>why you wouldn't just use the query itself instead of
>>>
>>>
>>turning it into a
>>
>>
>>>view.
>>>
>>>
>>>
>>>
>>A query is a request for an Access Database, however for Sql Server 
>>you would either use a View or Stored Procedure to return the data you
>>wanted... you are also able to use dynamic SQL to retrieve the
>>information you need.  ANY request given to the SQL Server engine is
>>managed by the engine, unless you are running Remote servers (iirc).
>>
>>In Sql Server, it is TABOO, nay, GENERALLY bad practice to use dynamic
>>sql because of the implication of SQL INJECTION attacks, this poses a
>>"real" security threat to your database. and your server.
>>
>>another reason to use a VIEW over dynamic sql is that it is 
>>pre-optimized by the SQL Server Engine and thus runs faster and more 
>>efficient.  Additionally if you use Dynamic SQL then your individual 
>>users who access the server will need EXPLICIT "SELECT" permissions by
>>you, which is another 'bad' practice.  In SQL Server you make data
>>available to your users via VIEWs and Stored Procedures or some other
>>secure way in order to protect your tables and it's data.
>>
>>ya get wot I mean?
>>
>>--
>>-Francisco
>>
>>
>>_______________________________________________
>>dba-SQLServer mailing list
>>dba-SQLServer at databaseadvisors.com
>>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>>http://www.databaseadvisors.com
>>
>>
>>
>>
>>
>
>_______________________________________________
>dba-SQLServer mailing list
>dba-SQLServer at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>http://www.databaseadvisors.com
>
>
>
>


--
-Francisco


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

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



This electronic transmission is strictly confidential to TNCO, Inc. and
intended solely for the addressee. It may contain information which is
covered by legal, professional, or other privileges. If you are not the
intended addressee, or someone authorized by the intended addressee to
receive transmissions on behalf of the addressee, you must not retain,
disclose in any form, copy, or take any action in reliance on this
transmission. If you have received this transmission in error, please
notify the sender as soon as possible and destroy this message. While
TNCO, Inc. uses virus protection, the recipient should check this email
and any attachments for the presence of viruses. TNCO, Inc. accepts no
liability for any damage caused by any virus transmitted by this email.
_______________________________________________
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 cfoust at infostatsystems.com  Fri Jun 11 11:42:06 2004
From: cfoust at infostatsystems.com (Charlotte Foust)
Date: Fri, 11 Jun 2004 09:42:06 -0700
Subject: [dba-SQLServer] Difference between views and queries
Message-ID: <E61FC1D4B1918244905B113C680BEA86312861@infoserver01.infostat.local>

Right.  That's why I specified MDBs.  

Charlotte Foust

-----Original Message-----
From: Mackin, Christopher [mailto:CMackin at quiznos.com] 
Sent: Friday, June 11, 2004 7:21 AM
To: 'dba-sqlserver at databaseadvisors.com'
Subject: RE: [dba-SQLServer] Difference between views and queries


Not so for an .adp though, where you can bind a form directly to SQL
data without ODBC.

-Chris Mackin

-----Original Message-----
From: Charlotte Foust [mailto:cfoust at infostatsystems.com]
Sent: Friday, June 11, 2004 9:16 AM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


Bound forms require ODBC links to be editable.  Forms (in Access MDBs)
bound to ADO recordsets are not updatable, and ADO is the only option
that avoids ODBC links to return a recordset.

Charlotte Foust

-----Original Message-----
From: Joe Rojas [mailto:JRojas at tnco-inc.com] 
Sent: Friday, June 11, 2004 4:38 AM
To: 'dba-sqlserver at databaseadvisors.com'
Subject: RE: [dba-SQLServer] Difference between views and queries


Hi Jim,

What is the argument for not using bound forms?

JR

-----Original Message-----
From: Jim Lawrence (AccessD) [mailto:accessd at shaw.ca]
Sent: Thursday, June 10, 2004 6:46 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries

Hi All:

As to all these issues I would like to dump some of my own comments. At
the risk of saying 'I told you so', I firmly believe that users should:

1. Always (or should I say only), use windows authentication and
judiciously distribute security access, to your SQLxx, to only those who
need it. Appropriate passwords and time limits. 1. Never allow access to
the data except through your program. That means NO to ODBC drivers only
ADO-OLE. 2. In 99% of cases, control is handled through SPs. 3. And the
biggy never, never use bound forms to access SQLxx data. I have been
whining about that for years, a position that M$ has also fully
supported. 4. You, as the programmer, should design your program to
carefully validate all requests and data before they are posted.

I may be already talking to the converted so you can ignore this; if
not..Get on the program.

Seeing we at in the midst of an election campaign, a good stump,
political speech is the expected. Jim


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of
Francisco H Tapia
Sent: Thursday, June 10, 2004 1:55 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Difference between views and queries


Andy,
  SQL Server is not Access on steriods, it's a diffrent engine, and thus
requires a new level of thinking towards your database engine.  It's NOT
that you couldn't, you can do anything, heck if you wanted to you can
set up your SQL Server with a blank SA password or SA as the password.
For all that matters, and avoiding all SQL Server authentication, just
use NT authentication and enable guest users :).

There have been quite a few white papers circulating on why you
"wouldn't" use dynamic sql w/ your sql server (check out
www.sqlservercentral.com, a fine resource) but the 2 very critical
factors include performance and also quite possible damage to your data.

It is entirely possible for your sql statement to read in this manner,
lets's say that you are Selecting Data from a table and you have a
combobox to help choose data, so your SQL Statment looks like this:

"Select CompanyName, CompanyAttribute1, pKey FROM tblCompany WHERE
CompanyAttribute1 = '" & me.cboMyBOX & "'", If I was a malicious user on
your system and I have direct access to tables, and if you're doing
statements like the above it is entirely plausible that you also have
"INSERT" statements thus you are giving more than just simple SELECT
access to these tables., thus with some malformed selection I can add
this in the select

'; DELETE FROM tblCompany; SELECT '

your final statement would look like this

Select CompanyName, CompanyAttribute1, pKey FROM tblCompany WHERE
CompanyAttribute1 = ''; DELETE FROM tblCompany; SELECT ''

Now your entire COMPANY table has been wiped out, while it is completely
possible to restore your db up to the minute, you've still lost some
downtime given that you had ONE bad apple in the bunch.

Besides the sql injection threats, you also suffer from a
NON-pre-compiled statement, thus your data could conceptually be
returned a lot faster if you let it, simply by creating a view or stored
procedure.  By the way just because you are using a stored procedure
does not make you completly excempt of sql injections, if you are using
dynamic sql within that procedure you are still open to these kind of
attacks and your stored procedure is always re-comiled and thus suffers
from the same performance deficits.


Andy Lacey wrote On 6/10/2004 1:27 PM:

>But, Francisco, if I was porting to SQL Server my Access app which
>builds SELECT statements dynamically all of the time for many and 
>various situations are you saying I couldn't, or shouldn't or 
>something?
>
>-- Andy Lacey
>http://www.minstersystems.co.uk
>
>
>
>>-----Original Message-----
>>From: dba-sqlserver-bounces at databaseadvisors.com
>>[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of
>>Francisco H Tapia
>>Sent: 10 June 2004 20:58
>>To: dba-sqlserver at databaseadvisors.com
>>Subject: Re: [dba-SQLServer] Difference between views and queries
>>
>>
>>jwcolby wrote On 6/10/2004 9:33 AM:
>>
>>
>>
>>>Can anyone explain the difference between a view and a query?  Views
>>>use a query, plus the view keyword.  I have a couple of books that I 
>>>have read the chapter on Views, but I so far haven't managed
>>>
>>>
>>to "get"
>>
>>
>>>why you wouldn't just use the query itself instead of
>>>
>>>
>>turning it into a
>>
>>
>>>view.
>>>
>>>
>>>
>>>
>>A query is a request for an Access Database, however for Sql Server
>>you would either use a View or Stored Procedure to return the data you
>>wanted... you are also able to use dynamic SQL to retrieve the
>>information you need.  ANY request given to the SQL Server engine is
>>managed by the engine, unless you are running Remote servers (iirc).
>>
>>In Sql Server, it is TABOO, nay, GENERALLY bad practice to use dynamic

>>sql because of the implication of SQL INJECTION attacks, this poses a 
>>"real" security threat to your database. and your server.
>>
>>another reason to use a VIEW over dynamic sql is that it is
>>pre-optimized by the SQL Server Engine and thus runs faster and more 
>>efficient.  Additionally if you use Dynamic SQL then your individual 
>>users who access the server will need EXPLICIT "SELECT" permissions by
>>you, which is another 'bad' practice.  In SQL Server you make data
>>available to your users via VIEWs and Stored Procedures or some other
>>secure way in order to protect your tables and it's data.
>>
>>ya get wot I mean?
>>
>>--
>>-Francisco
>>
>>
>>_______________________________________________
>>dba-SQLServer mailing list
>>dba-SQLServer at databaseadvisors.com
>>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>>http://www.databaseadvisors.com
>>
>>
>>
>>
>>
>
>_______________________________________________
>dba-SQLServer mailing list
>dba-SQLServer at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>http://www.databaseadvisors.com
>
>
>
>


--
-Francisco


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

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



This electronic transmission is strictly confidential to TNCO, Inc. and
intended solely for the addressee. It may contain information which is
covered by legal, professional, or other privileges. If you are not the
intended addressee, or someone authorized by the intended addressee to
receive transmissions on behalf of the addressee, you must not retain,
disclose in any form, copy, or take any action in reliance on this
transmission. If you have received this transmission in error, please
notify the sender as soon as possible and destroy this message. While
TNCO, Inc. uses virus protection, the recipient should check this email
and any attachments for the presence of viruses. TNCO, Inc. accepts no
liability for any damage caused by any virus transmitted by this email.
_______________________________________________
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 my.lists at verizon.net  Fri Jun 11 11:42:33 2004
From: my.lists at verizon.net (Francisco H Tapia)
Date: Fri, 11 Jun 2004 09:42:33 -0700
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <40CA3E47.31022.352D48F@localhost>
References: <001c01c44f08$a5d922a0$7e01a8c0@colbyws>
	<40CA3E47.31022.352D48F@localhost>
Message-ID: <40C9E0F9.70806@verizon.net>

Stuart McLachlan wrote On 6/11/2004 6:20 AM:

>On 10 Jun 2004 at 12:07, Jim Lawrence (AccessD) wrote:
>
>  
>
>>Hi John:
>>
>>Personally, I see little reason to run views as their creation is spawned at
>>the server side and any hit on the server I try to avoid. The concept of
>>distributive computing has always appealed to me. Queries, run at the client
>>side.
>>
>>    
>>
>
>But surely not when it means pulling unnecessary data and indexes across the 
>network. The whole point of server side computation is to reduce the network 
>traffic bottleneck.  I'd much rather let the server sort throuygh a million 
>rows and feed the workstation with a thousand, rather than pass all million 
>across the network and filter then client side.
>  
>
Views are useful when a parameter is not needed.  Server Sided queries 
run faster than those on clients because as a general rule, the Server 
is a much more powerful box than that of the clients.  The purpose of 
keeping views and stored procedures on the server is to help provide 
"faster" access to those 10,100, 1000 or millions of rows.

>  
>
>>There might be better performance with views, if there are limited people
>>accessing the server. 
>>    
>>
>
>The more people hitting the server the better, you gain more from caching :-)
>
>Views limit, not that the client can see it anyway,
>  
>
Right, If your server is underpowered, well maybe it's time to get a 
better server :)

>>access to/display of the real table and present a pseudo table. Security?
>>
>>    
>>
>
>That enhances security, not dimishes it.
> 
>  
>
Yes it is security because you are capable of segmenting data that the 
end user "should" not be viewing.. and you also enhance data (that is 
provide it faster) and join and provide values that the end user is used 
to using, not ID's (be it autonumber, GUID or COMBs).

-- 
-Francisco




From my.lists at verizon.net  Fri Jun 11 11:56:18 2004
From: my.lists at verizon.net (Francisco H Tapia)
Date: Fri, 11 Jun 2004 09:56:18 -0700
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <FJEJLIPOMCGJALMGLLLIOEIHCDAA.accessd@shaw.ca>
References: <FJEJLIPOMCGJALMGLLLIOEIHCDAA.accessd@shaw.ca>
Message-ID: <40C9E432.2080700@verizon.net>

Jim Lawrence (AccessD) wrote On 6/10/2004 3:46 PM:

>Hi All:
>
>As to all these issues I would like to dump some of my own comments. At the
>risk of saying 'I told you so', I firmly believe that users should:
>
>1. Always (or should I say only), use windows authentication and judiciously
>distribute security access, to your SQLxx, to only those who need it.
>Appropriate passwords and time limits.
>  
>
Both Windows Authentication and Sql Server Authentication are viable 
platforms.  If either pwd is weak, neither authentication will protect 
against dictionary attacks.  I find that Auditing is a good tool to use 
for helping to protect such systems.

>1. Never allow access to the data except through your program. That means NO
>to ODBC drivers only ADO-OLE.
>  
>
Unrealistic.  When working in an Enterprise network, data must be 
shared.  Our system which went from an Access Database to a Sql Server 
database is undergoing this transition, where the servers are sharing 
data.  This is increasingly painful to monitor because you must "trust" 
your other dba's but that's why the dba must take the responsibility to 
always keep eye on their servers.

>2. In 99% of cases, control is handled through SPs.
>  
>
there's SPs, Triggers and Functions

>3. And the biggy never, never use bound forms to access SQLxx data. I have
>been whining about that for years, a position that M$ has also fully
>supported.
>  
>
bound forms have their place.  unfortunately, I don't really like the 
way ADP's handle the 3 connection pooling to the server, that and the 
fact that any report that can possibly run over 30 seconds times out :|

>4. You, as the programmer, should design your program to carefully validate
>all requests and data before they are posted.
>  
>
:|, no, your input devices (SPs, Triggers, and Functions) must help 
validate data too, otherwise when someone needs to hook into your 
database, data will not be in par w/ what is expected.

>I may be already talking to the converted so you can ignore this; if
>not..Get on the program.
>
>Seeing we at in the midst of an election campaign, a good stump, political
>speech is the expected.
>Jim
>
>
>-----Original Message-----
>From: dba-sqlserver-bounces at databaseadvisors.com
>[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of
>Francisco H Tapia
>Sent: Thursday, June 10, 2004 1:55 PM
>To: dba-sqlserver at databaseadvisors.com
>Subject: Re: [dba-SQLServer] Difference between views and queries
>
>
>Andy,
>  SQL Server is not Access on steriods, it's a diffrent engine, and thus
>requires a new level of thinking towards your database engine.  It's NOT
>that you couldn't, you can do anything, heck if you wanted to you can
>set up your SQL Server with a blank SA password or SA as the password.
>For all that matters, and avoiding all SQL Server authentication, just
>use NT authentication and enable guest users :).
>
>There have been quite a few white papers circulating on why you
>"wouldn't" use dynamic sql w/ your sql server (check out
>www.sqlservercentral.com, a fine resource) but the 2 very critical
>factors include performance and also quite possible damage to your data.
>
>It is entirely possible for your sql statement to read in this manner,
>lets's say that you are Selecting Data from a table and you have a
>combobox to help choose data, so your SQL Statment looks like this:
>
>"Select CompanyName, CompanyAttribute1, pKey FROM tblCompany WHERE
>CompanyAttribute1 = '" & me.cboMyBOX & "'", If I was a malicious user on
>your system and I have direct access to tables, and if you're doing
>statements like the above it is entirely plausible that you also have
>"INSERT" statements thus you are giving more than just simple SELECT
>access to these tables., thus with some malformed selection I can add
>this in the select
>
>'; DELETE FROM tblCompany; SELECT '
>
>your final statement would look like this
>
>Select CompanyName, CompanyAttribute1, pKey FROM tblCompany WHERE
>CompanyAttribute1 = ''; DELETE FROM tblCompany; SELECT ''
>
>Now your entire COMPANY table has been wiped out, while it is completely
>possible to restore your db up to the minute, you've still lost some
>downtime given that you had ONE bad apple in the bunch.
>
>Besides the sql injection threats, you also suffer from a
>NON-pre-compiled statement, thus your data could conceptually be
>returned a lot faster if you let it, simply by creating a view or stored
>procedure.  By the way just because you are using a stored procedure
>does not make you completly excempt of sql injections, if you are using
>dynamic sql within that procedure you are still open to these kind of
>attacks and your stored procedure is always re-comiled and thus suffers
>from the same performance deficits.
>
>
>Andy Lacey wrote On 6/10/2004 1:27 PM:
>
>  
>
>>But, Francisco, if I was porting to SQL Server my Access app which builds
>>SELECT statements dynamically all of the time for many and various
>>situations are you saying I couldn't, or shouldn't or something?
>>
>>-- Andy Lacey
>>http://www.minstersystems.co.uk
>>
>>
>>
>>    
>>
>>>-----Original Message-----
>>>From: dba-sqlserver-bounces at databaseadvisors.com
>>>[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf
>>>Of Francisco H Tapia
>>>Sent: 10 June 2004 20:58
>>>To: dba-sqlserver at databaseadvisors.com
>>>Subject: Re: [dba-SQLServer] Difference between views and queries
>>>
>>>
>>>jwcolby wrote On 6/10/2004 9:33 AM:
>>>
>>>
>>>
>>>      
>>>
>>>>Can anyone explain the difference between a view and a query?  Views
>>>>use a query, plus the view keyword.  I have a couple of books that I
>>>>have read the chapter on Views, but I so far haven't managed
>>>>
>>>>
>>>>        
>>>>
>>>to "get"
>>>
>>>
>>>      
>>>
>>>>why you wouldn't just use the query itself instead of
>>>>
>>>>
>>>>        
>>>>
>>>turning it into a
>>>
>>>
>>>      
>>>
>>>>view.
>>>>
>>>>
>>>>
>>>>
>>>>        
>>>>
>>>A query is a request for an Access Database, however for Sql
>>>Server you
>>>would either use a View or Stored Procedure to return the data you
>>>wanted... you are also able to use dynamic SQL to retrieve the
>>>information you need.  ANY request given to the SQL Server engine is
>>>managed by the engine, unless you are running Remote servers (iirc).
>>>
>>>In Sql Server, it is TABOO, nay, GENERALLY bad practice to
>>>use dynamic
>>>sql because of the implication of SQL INJECTION attacks, this poses a
>>>"real" security threat to your database. and your server.
>>>
>>>another reason to use a VIEW over dynamic sql is that it is
>>>pre-optimized by the SQL Server Engine and thus runs faster and more
>>>efficient.  Additionally if you use Dynamic SQL then your individual
>>>users who access the server will need EXPLICIT "SELECT"
>>>permissions by
>>>you, which is another 'bad' practice.  In SQL Server you make data
>>>available to your users via VIEWs and Stored Procedures or some other
>>>secure way in order to protect your tables and it's data.
>>>
>>>ya get wot I mean?
>>>
>>>--
>>>-Francisco
>>>
>>>
>>>      
>>>
>  
>


-- 
-Francisco




From accessd at shaw.ca  Fri Jun 11 13:07:43 2004
From: accessd at shaw.ca (Jim Lawrence (AccessD))
Date: Fri, 11 Jun 2004 11:07:43 -0700
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <0CC84C9461AE6445AD5A602001C41C4B059D29@mercury.tnco-inc.com>
Message-ID: <FJEJLIPOMCGJALMGLLLIKEJECDAA.accessd@shaw.ca>

Joe:

You should know better than ask that question. It sort of stirs up things.
The following are my personnel guide-lines but they can be changed but there
has to be a very good reason.

1. Bound forms can be used on small Access projects but never on anything
major.

There are a host of pluses and minus on both side.

Facts as I see them:

Bound forms are much easier to implement. The existing operating system
handles access to records, locking, updates while multiple people are
working on a single record, populating the forms, sub-forms etc. When there
are a small number of people accessing a simple MDB database, for example,
performance can be superior.

Unbound forms are harder to implement...properly. All the above benefits,
you as the programmer, must provide. It takes longer to implement and test.
There are a whole range of programming issues that have to be addressed. It
is not for the faint-of-heart or first time developers.

On the plus side of unbound forms, is that you now have complete control
over every piece of data that is displayed on the form or stored in the
database.

1. You can provide an extensive set of business rules, on just a single
field, if required.
2. Now that you control the data-access layer, multiple data sources can be
accessed and easily integrated. For example; you can be using a SQL, Oracle
and MDB data sources simultaneously.
3. Data access can be merged deep within your code, so as to provide a layer
of security. (That is one of the reasons I do not like ODBC connection
because they can be easily used by any skilled client, to gain direct access
to protected data sources and because they are exposed and not imbedded in
your code.)
4. Much of the issues around record-locking, multi-user and the potential
data over-writing are managed through the bigger data engines like SQL and
Oracle. It is your responsibility to use proper transaction controls,
monitor return codes and take appropriate actions.
5. With you now managing the data connections, remote sites with unstable or
slow access, can be carefully handled, with virtual no data loss or database
corruption.
6. Because you now precisely handle data access, only the specific data sets
required, to populate the current form and sub-forms, are extracted. Static
data for controls can be pulled once at the beginning of a session and not
as each record is accessed. When it comes to the major sequel databases, the
raw data can be extracted, at the server end through, Stored Procedure and
functions calls. To provide better performance the raw data can then, at the
client side, be grouped and sorted which in some cases will provide up to a
seventy percent performance boost. (Distributive computing).
7. Complete access control of the data can leverage a small SQL system. For
example; given a SQL DB, only licensed with a dozen connections, sixty plus
people can have, as far as they are concerned, full access. More bang for
the buck.

In summary, the downside is that it requires a lot more work to implement an
unbound database, internal documentation and structured code lay-out has to
be very carefully done. I can not stress tidiness and organization enough.
Consider someone who has to go back in to update the code, that someone
might be you.

The upside, is that you, as a programmer, have absolute control, garner
superior performance (on larger systems), better stability and much better
security.

This is my quarter's worth, thank you
Jim


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of Joe
Rojas
Sent: Friday, June 11, 2004 5:38 AM
To: 'dba-sqlserver at databaseadvisors.com'
Subject: RE: [dba-SQLServer] Difference between views and queries


Hi Jim,

What is the argument for not using bound forms?

JR

-----Original Message-----
From: Jim Lawrence (AccessD) [mailto:accessd at shaw.ca]
Sent: Thursday, June 10, 2004 6:46 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries

Hi All:

As to all these issues I would like to dump some of my own comments. At the
risk of saying 'I told you so', I firmly believe that users should:

1. Always (or should I say only), use windows authentication and judiciously
distribute security access, to your SQLxx, to only those who need it.
Appropriate passwords and time limits.
1. Never allow access to the data except through your program. That means NO
to ODBC drivers only ADO-OLE.
2. In 99% of cases, control is handled through SPs.
3. And the biggy never, never use bound forms to access SQLxx data. I have
been whining about that for years, a position that M$ has also fully
supported.
4. You, as the programmer, should design your program to carefully validate
all requests and data before they are posted.

I may be already talking to the converted so you can ignore this; if
not..Get on the program.

Seeing we at in the midst of an election campaign, a good stump, political
speech is the expected.
Jim


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of
Francisco H Tapia
Sent: Thursday, June 10, 2004 1:55 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Difference between views and queries


Andy,
  SQL Server is not Access on steriods, it's a diffrent engine, and thus
requires a new level of thinking towards your database engine.  It's NOT
that you couldn't, you can do anything, heck if you wanted to you can
set up your SQL Server with a blank SA password or SA as the password.
For all that matters, and avoiding all SQL Server authentication, just
use NT authentication and enable guest users :).

There have been quite a few white papers circulating on why you
"wouldn't" use dynamic sql w/ your sql server (check out
www.sqlservercentral.com, a fine resource) but the 2 very critical
factors include performance and also quite possible damage to your data.

It is entirely possible for your sql statement to read in this manner,
lets's say that you are Selecting Data from a table and you have a
combobox to help choose data, so your SQL Statment looks like this:

"Select CompanyName, CompanyAttribute1, pKey FROM tblCompany WHERE
CompanyAttribute1 = '" & me.cboMyBOX & "'", If I was a malicious user on
your system and I have direct access to tables, and if you're doing
statements like the above it is entirely plausible that you also have
"INSERT" statements thus you are giving more than just simple SELECT
access to these tables., thus with some malformed selection I can add
this in the select

'; DELETE FROM tblCompany; SELECT '

your final statement would look like this

Select CompanyName, CompanyAttribute1, pKey FROM tblCompany WHERE
CompanyAttribute1 = ''; DELETE FROM tblCompany; SELECT ''

Now your entire COMPANY table has been wiped out, while it is completely
possible to restore your db up to the minute, you've still lost some
downtime given that you had ONE bad apple in the bunch.

Besides the sql injection threats, you also suffer from a
NON-pre-compiled statement, thus your data could conceptually be
returned a lot faster if you let it, simply by creating a view or stored
procedure.  By the way just because you are using a stored procedure
does not make you completly excempt of sql injections, if you are using
dynamic sql within that procedure you are still open to these kind of
attacks and your stored procedure is always re-comiled and thus suffers
from the same performance deficits.


Andy Lacey wrote On 6/10/2004 1:27 PM:

>But, Francisco, if I was porting to SQL Server my Access app which builds
>SELECT statements dynamically all of the time for many and various
>situations are you saying I couldn't, or shouldn't or something?
>
>-- Andy Lacey
>http://www.minstersystems.co.uk
>
>
>
>>-----Original Message-----
>>From: dba-sqlserver-bounces at databaseadvisors.com
>>[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf
>>Of Francisco H Tapia
>>Sent: 10 June 2004 20:58
>>To: dba-sqlserver at databaseadvisors.com
>>Subject: Re: [dba-SQLServer] Difference between views and queries
>>
>>
>>jwcolby wrote On 6/10/2004 9:33 AM:
>>
>>
>>
>>>Can anyone explain the difference between a view and a query?  Views
>>>use a query, plus the view keyword.  I have a couple of books that I
>>>have read the chapter on Views, but I so far haven't managed
>>>
>>>
>>to "get"
>>
>>
>>>why you wouldn't just use the query itself instead of
>>>
>>>
>>turning it into a
>>
>>
>>>view.
>>>
>>>
>>>
>>>
>>A query is a request for an Access Database, however for Sql
>>Server you
>>would either use a View or Stored Procedure to return the data you
>>wanted... you are also able to use dynamic SQL to retrieve the
>>information you need.  ANY request given to the SQL Server engine is
>>managed by the engine, unless you are running Remote servers (iirc).
>>
>>In Sql Server, it is TABOO, nay, GENERALLY bad practice to
>>use dynamic
>>sql because of the implication of SQL INJECTION attacks, this poses a
>>"real" security threat to your database. and your server.
>>
>>another reason to use a VIEW over dynamic sql is that it is
>>pre-optimized by the SQL Server Engine and thus runs faster and more
>>efficient.  Additionally if you use Dynamic SQL then your individual
>>users who access the server will need EXPLICIT "SELECT"
>>permissions by
>>you, which is another 'bad' practice.  In SQL Server you make data
>>available to your users via VIEWs and Stored Procedures or some other
>>secure way in order to protect your tables and it's data.
>>
>>ya get wot I mean?
>>
>>--
>>-Francisco
>>
>>
>>_______________________________________________
>>dba-SQLServer mailing list
>>dba-SQLServer at databaseadvisors.com
>>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>>http://www.databaseadvisors.com
>>
>>
>>
>>
>>
>
>_______________________________________________
>dba-SQLServer mailing list
>dba-SQLServer at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>http://www.databaseadvisors.com
>
>
>
>


--
-Francisco


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

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



This electronic transmission is strictly confidential to TNCO, Inc. and
intended solely for the addressee. It may contain information which is
covered by legal, professional, or other privileges. If you are not the
intended addressee, or someone authorized by the intended addressee to
receive transmissions on behalf of the addressee, you must not retain,
disclose in any form, copy, or take any action in reliance on this
transmission. If you have received this transmission in error, please notify
the sender as soon as possible and destroy this message. While TNCO, Inc.
uses virus protection, the recipient should check this email and any
attachments for the presence of viruses. TNCO, Inc. accepts no liability for
any damage caused by any virus transmitted by this email.
_______________________________________________
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  Fri Jun 11 13:48:38 2004
From: accessd at shaw.ca (Jim Lawrence (AccessD))
Date: Fri, 11 Jun 2004 11:48:38 -0700
Subject: [dba-SQLServer] Re:  Difference between views and queries
In-Reply-To: <5.1.0.14.2.20040611083741.017e5810@pop3.highstream.net>
Message-ID: <FJEJLIPOMCGJALMGLLLIEEJGCDAA.accessd@shaw.ca>

Robert:

Please refer to additional detail I provided, with other list comments. I
prefer performance too. :-)

Hope the additional comments clarify things.
Jim

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of Robert
L. Stewart
Sent: Friday, June 11, 2004 6:38 AM
To: dba-sqlserver at databaseadvisors.com
Subject: [dba-SQLServer] Re: Difference between views and queries


Jim,

I am glad I am not one of your customers.  I prefer performance.

Robert

At 08:20 AM 6/11/2004 -0500, you wrote:
>From: Jim Lawrence (AccessD) [mailto:accessd at shaw.ca]
>Sent: Thursday, June 10, 2004 2:07 PM
>To: dba-sqlserver at databaseadvisors.com
>Subject: RE: [dba-SQLServer] Difference between views and queries
>
>
>Hi John:
>
>Personally, I see little reason to run views as their creation is spawned
at
>the server side and any hit on the server I try to avoid. The concept of
>distributive computing has always appealed to me. Queries, run at the
client
>side.
>
>There might be better performance with views, if there are limited people
>accessing the server. Views limit, not that the client can see it anyway,
>access to/display of the real table and present a pseudo table. Security?
>
>HTH
>Jim


_______________________________________________
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  Fri Jun 11 13:38:32 2004
From: accessd at shaw.ca (Jim Lawrence (AccessD))
Date: Fri, 11 Jun 2004 11:38:32 -0700
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <7B1961ED924D1A459E378C9B1BB22B4C02485089@natexch.jenkens.com>
Message-ID: <FJEJLIPOMCGJALMGLLLIKEJFCDAA.accessd@shaw.ca>

Hi Debbie:

Good point. As soon as you start pulling more data down the wire the
performance suffers. What I have traditionally found is that, unless you
have complete control over the design of a specific view, they end up
pulling more data than required, link to a host of miscellaneous functions
and can have very complex grouping and sorting routines that may not even be
indexed properly. In many cases, I have been involved with, power-users had
requested these complex views with little knowledge or concern with the
impact, on the meager system resources. These views have just become pseudo
data cubes. (I have seen sites where it takes almost thirty minutes to
populate a specific view.)

I feel that the raw data, should be pulled at the server end, using as
little grouping or sorting there, as realistically possible and at the
client end, is where the processing should be implemented. I am not
suggesting to pull more data across the wire, just less processing at the
server end. This does mean that you would have to have a desktop application
to subsequently manage the data and not just a web interface. On one site, a
report that had been an over-nighter (four hours processing) was reduced to
around fifteen minutes with the proper balance of FE and BE loading.

I agree that there is a much better security level through views. My issue
is that users should never directly see that far into the system, anyways.

Thanks for your comments
Jim

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of Elam,
Debbie
Sent: Friday, June 11, 2004 6:13 AM
To: 'dba-sqlserver at databaseadvisors.com'
Subject: RE: [dba-SQLServer] Difference between views and queries


Just the opposite, I have always tried to harness the greater computing
power on the server and drag less data across the wire which is a
performance plus.  Views also have security independent of tables.  I have a
much better control of what data is editable and when by what view I use.

Debbie

-----Original Message-----
From: Jim Lawrence (AccessD) [mailto:accessd at shaw.ca]
Sent: Thursday, June 10, 2004 2:07 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


Hi John:

Personally, I see little reason to run views as their creation is spawned at
the server side and any hit on the server I try to avoid. The concept of
distributive computing has always appealed to me. Queries, run at the client
side.

There might be better performance with views, if there are limited people
accessing the server. Views limit, not that the client can see it anyway,
access to/display of the real table and present a pseudo table. Security?

HTH
Jim

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of jwcolby
Sent: Thursday, June 10, 2004 9:33 AM
To: SQLServer
Subject: [dba-SQLServer] Difference between views and queries


Can anyone explain the difference between a view and a query?  Views use a
query, plus the view keyword.  I have a couple of books that I have read the
chapter on Views, but I so far haven't managed to "get" why you wouldn't
just use the query itself instead of turning it into a view.


John W. Colby
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
- JENKENS & GILCHRIST E-MAIL NOTICE - This transmission may be: (1) subject
to the Attorney-Client Privilege, (2) an attorney work product, or (3)
strictly confidential. If you are not the intended recipient of this
message, you may not disclose, print, copy or disseminate this information.
If you have received this in error, please reply and notify the sender
(only) and delete the message. Unauthorized interception of this e-mail is a
violation of federal criminal law.
This communication does not reflect an intention by the sender or the
sender's client or principal to conduct a transaction or make any agreement
by electronic means.  Nothing contained in this message or in any attachment
shall satisfy the requirements for a writing, and nothing contained herein
shall constitute a contract or electronic signature under the Electronic
Signatures in Global and National Commerce Act, any version of the Uniform
Electronic Transactions Act or any other statute governing electronic
transactions.
_______________________________________________
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  Fri Jun 11 13:58:43 2004
From: accessd at shaw.ca (Jim Lawrence (AccessD))
Date: Fri, 11 Jun 2004 11:58:43 -0700
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <E61FC1D4B1918244905B113C680BEA8631285F@infoserver01.infostat.local>
Message-ID: <FJEJLIPOMCGJALMGLLLIOEJGCDAA.accessd@shaw.ca>

Hi Charlotte:

Simplistically, yes, you are right!... but I am not suggesting the use of
ODBC...direct ADO-OLE, is the for me, Sorry I was never much of a poet. I am
suggesting handling of the whole data management system not just changing
connection types.

I knew, I should not have got in to this.
Jim

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of
Charlotte Foust
Sent: Friday, June 11, 2004 8:16 AM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


Bound forms require ODBC links to be editable.  Forms (in Access MDBs)
bound to ADO recordsets are not updatable, and ADO is the only option
that avoids ODBC links to return a recordset.

Charlotte Foust

-----Original Message-----
From: Joe Rojas [mailto:JRojas at tnco-inc.com]
Sent: Friday, June 11, 2004 4:38 AM
To: 'dba-sqlserver at databaseadvisors.com'
Subject: RE: [dba-SQLServer] Difference between views and queries


Hi Jim,

What is the argument for not using bound forms?

JR

-----Original Message-----
From: Jim Lawrence (AccessD) [mailto:accessd at shaw.ca]
Sent: Thursday, June 10, 2004 6:46 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries

Hi All:

As to all these issues I would like to dump some of my own comments. At
the risk of saying 'I told you so', I firmly believe that users should:

1. Always (or should I say only), use windows authentication and
judiciously distribute security access, to your SQLxx, to only those who
need it. Appropriate passwords and time limits. 1. Never allow access to
the data except through your program. That means NO to ODBC drivers only
ADO-OLE. 2. In 99% of cases, control is handled through SPs. 3. And the
biggy never, never use bound forms to access SQLxx data. I have been
whining about that for years, a position that M$ has also fully
supported. 4. You, as the programmer, should design your program to
carefully validate all requests and data before they are posted.

I may be already talking to the converted so you can ignore this; if
not..Get on the program.

Seeing we at in the midst of an election campaign, a good stump,
political speech is the expected. Jim


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of
Francisco H Tapia
Sent: Thursday, June 10, 2004 1:55 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Difference between views and queries


Andy,
  SQL Server is not Access on steriods, it's a diffrent engine, and thus
requires a new level of thinking towards your database engine.  It's NOT
that you couldn't, you can do anything, heck if you wanted to you can
set up your SQL Server with a blank SA password or SA as the password.
For all that matters, and avoiding all SQL Server authentication, just
use NT authentication and enable guest users :).

There have been quite a few white papers circulating on why you
"wouldn't" use dynamic sql w/ your sql server (check out
www.sqlservercentral.com, a fine resource) but the 2 very critical
factors include performance and also quite possible damage to your data.

It is entirely possible for your sql statement to read in this manner,
lets's say that you are Selecting Data from a table and you have a
combobox to help choose data, so your SQL Statment looks like this:

"Select CompanyName, CompanyAttribute1, pKey FROM tblCompany WHERE
CompanyAttribute1 = '" & me.cboMyBOX & "'", If I was a malicious user on
your system and I have direct access to tables, and if you're doing
statements like the above it is entirely plausible that you also have
"INSERT" statements thus you are giving more than just simple SELECT
access to these tables., thus with some malformed selection I can add
this in the select

'; DELETE FROM tblCompany; SELECT '

your final statement would look like this

Select CompanyName, CompanyAttribute1, pKey FROM tblCompany WHERE
CompanyAttribute1 = ''; DELETE FROM tblCompany; SELECT ''

Now your entire COMPANY table has been wiped out, while it is completely
possible to restore your db up to the minute, you've still lost some
downtime given that you had ONE bad apple in the bunch.

Besides the sql injection threats, you also suffer from a
NON-pre-compiled statement, thus your data could conceptually be
returned a lot faster if you let it, simply by creating a view or stored
procedure.  By the way just because you are using a stored procedure
does not make you completly excempt of sql injections, if you are using
dynamic sql within that procedure you are still open to these kind of
attacks and your stored procedure is always re-comiled and thus suffers
from the same performance deficits.


Andy Lacey wrote On 6/10/2004 1:27 PM:

>But, Francisco, if I was porting to SQL Server my Access app which
>builds SELECT statements dynamically all of the time for many and
>various situations are you saying I couldn't, or shouldn't or
>something?
>
>-- Andy Lacey
>http://www.minstersystems.co.uk
>
>
>
>>-----Original Message-----
>>From: dba-sqlserver-bounces at databaseadvisors.com
>>[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of
>>Francisco H Tapia
>>Sent: 10 June 2004 20:58
>>To: dba-sqlserver at databaseadvisors.com
>>Subject: Re: [dba-SQLServer] Difference between views and queries
>>
>>
>>jwcolby wrote On 6/10/2004 9:33 AM:
>>
>>
>>
>>>Can anyone explain the difference between a view and a query?  Views
>>>use a query, plus the view keyword.  I have a couple of books that I
>>>have read the chapter on Views, but I so far haven't managed
>>>
>>>
>>to "get"
>>
>>
>>>why you wouldn't just use the query itself instead of
>>>
>>>
>>turning it into a
>>
>>
>>>view.
>>>
>>>
>>>
>>>
>>A query is a request for an Access Database, however for Sql Server
>>you would either use a View or Stored Procedure to return the data you
>>wanted... you are also able to use dynamic SQL to retrieve the
>>information you need.  ANY request given to the SQL Server engine is
>>managed by the engine, unless you are running Remote servers (iirc).
>>
>>In Sql Server, it is TABOO, nay, GENERALLY bad practice to use dynamic
>>sql because of the implication of SQL INJECTION attacks, this poses a
>>"real" security threat to your database. and your server.
>>
>>another reason to use a VIEW over dynamic sql is that it is
>>pre-optimized by the SQL Server Engine and thus runs faster and more
>>efficient.  Additionally if you use Dynamic SQL then your individual
>>users who access the server will need EXPLICIT "SELECT" permissions by
>>you, which is another 'bad' practice.  In SQL Server you make data
>>available to your users via VIEWs and Stored Procedures or some other
>>secure way in order to protect your tables and it's data.
>>
>>ya get wot I mean?
>>
>>--
>>-Francisco
>>
>>
>>_______________________________________________
>>dba-SQLServer mailing list
>>dba-SQLServer at databaseadvisors.com
>>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>>http://www.databaseadvisors.com
>>
>>
>>
>>
>>
>
>_______________________________________________
>dba-SQLServer mailing list
>dba-SQLServer at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>http://www.databaseadvisors.com
>
>
>
>


--
-Francisco


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

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



This electronic transmission is strictly confidential to TNCO, Inc. and
intended solely for the addressee. It may contain information which is
covered by legal, professional, or other privileges. If you are not the
intended addressee, or someone authorized by the intended addressee to
receive transmissions on behalf of the addressee, you must not retain,
disclose in any form, copy, or take any action in reliance on this
transmission. If you have received this transmission in error, please
notify the sender as soon as possible and destroy this message. While
TNCO, Inc. uses virus protection, the recipient should check this email
and any attachments for the presence of viruses. TNCO, Inc. accepts no
liability for any damage caused by any virus transmitted by this email.
_______________________________________________
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  Fri Jun 11 13:58:46 2004
From: accessd at shaw.ca (Jim Lawrence (AccessD))
Date: Fri, 11 Jun 2004 11:58:46 -0700
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <E61FC1D4B1918244905B113C680BEA86312861@infoserver01.infostat.local>
Message-ID: <FJEJLIPOMCGJALMGLLLIAEJHCDAA.accessd@shaw.ca>

Charlotte...I missed the word MDB.

This is the SQL list, I hope?

Jim

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of
Charlotte Foust
Sent: Friday, June 11, 2004 9:42 AM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


Right.  That's why I specified MDBs.  

Charlotte Foust

-----Original Message-----
From: Mackin, Christopher [mailto:CMackin at quiznos.com] 
Sent: Friday, June 11, 2004 7:21 AM
To: 'dba-sqlserver at databaseadvisors.com'
Subject: RE: [dba-SQLServer] Difference between views and queries


Not so for an .adp though, where you can bind a form directly to SQL
data without ODBC.

-Chris Mackin

-----Original Message-----
From: Charlotte Foust [mailto:cfoust at infostatsystems.com]
Sent: Friday, June 11, 2004 9:16 AM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


Bound forms require ODBC links to be editable.  Forms (in Access MDBs)
bound to ADO recordsets are not updatable, and ADO is the only option
that avoids ODBC links to return a recordset.

Charlotte Foust

-----Original Message-----
From: Joe Rojas [mailto:JRojas at tnco-inc.com] 
Sent: Friday, June 11, 2004 4:38 AM
To: 'dba-sqlserver at databaseadvisors.com'
Subject: RE: [dba-SQLServer] Difference between views and queries


Hi Jim,

What is the argument for not using bound forms?

JR

-----Original Message-----
From: Jim Lawrence (AccessD) [mailto:accessd at shaw.ca]
Sent: Thursday, June 10, 2004 6:46 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries

Hi All:

As to all these issues I would like to dump some of my own comments. At
the risk of saying 'I told you so', I firmly believe that users should:

1. Always (or should I say only), use windows authentication and
judiciously distribute security access, to your SQLxx, to only those who
need it. Appropriate passwords and time limits. 1. Never allow access to
the data except through your program. That means NO to ODBC drivers only
ADO-OLE. 2. In 99% of cases, control is handled through SPs. 3. And the
biggy never, never use bound forms to access SQLxx data. I have been
whining about that for years, a position that M$ has also fully
supported. 4. You, as the programmer, should design your program to
carefully validate all requests and data before they are posted.

I may be already talking to the converted so you can ignore this; if
not..Get on the program.

Seeing we at in the midst of an election campaign, a good stump,
political speech is the expected. Jim


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of
Francisco H Tapia
Sent: Thursday, June 10, 2004 1:55 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Difference between views and queries


Andy,
  SQL Server is not Access on steriods, it's a diffrent engine, and thus
requires a new level of thinking towards your database engine.  It's NOT
that you couldn't, you can do anything, heck if you wanted to you can
set up your SQL Server with a blank SA password or SA as the password.
For all that matters, and avoiding all SQL Server authentication, just
use NT authentication and enable guest users :).

There have been quite a few white papers circulating on why you
"wouldn't" use dynamic sql w/ your sql server (check out
www.sqlservercentral.com, a fine resource) but the 2 very critical
factors include performance and also quite possible damage to your data.

It is entirely possible for your sql statement to read in this manner,
lets's say that you are Selecting Data from a table and you have a
combobox to help choose data, so your SQL Statment looks like this:

"Select CompanyName, CompanyAttribute1, pKey FROM tblCompany WHERE
CompanyAttribute1 = '" & me.cboMyBOX & "'", If I was a malicious user on
your system and I have direct access to tables, and if you're doing
statements like the above it is entirely plausible that you also have
"INSERT" statements thus you are giving more than just simple SELECT
access to these tables., thus with some malformed selection I can add
this in the select

'; DELETE FROM tblCompany; SELECT '

your final statement would look like this

Select CompanyName, CompanyAttribute1, pKey FROM tblCompany WHERE
CompanyAttribute1 = ''; DELETE FROM tblCompany; SELECT ''

Now your entire COMPANY table has been wiped out, while it is completely
possible to restore your db up to the minute, you've still lost some
downtime given that you had ONE bad apple in the bunch.

Besides the sql injection threats, you also suffer from a
NON-pre-compiled statement, thus your data could conceptually be
returned a lot faster if you let it, simply by creating a view or stored
procedure.  By the way just because you are using a stored procedure
does not make you completly excempt of sql injections, if you are using
dynamic sql within that procedure you are still open to these kind of
attacks and your stored procedure is always re-comiled and thus suffers
from the same performance deficits.


Andy Lacey wrote On 6/10/2004 1:27 PM:

>But, Francisco, if I was porting to SQL Server my Access app which
>builds SELECT statements dynamically all of the time for many and 
>various situations are you saying I couldn't, or shouldn't or 
>something?
>
>-- Andy Lacey
>http://www.minstersystems.co.uk
>
>
>
>>-----Original Message-----
>>From: dba-sqlserver-bounces at databaseadvisors.com
>>[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of
>>Francisco H Tapia
>>Sent: 10 June 2004 20:58
>>To: dba-sqlserver at databaseadvisors.com
>>Subject: Re: [dba-SQLServer] Difference between views and queries
>>
>>
>>jwcolby wrote On 6/10/2004 9:33 AM:
>>
>>
>>
>>>Can anyone explain the difference between a view and a query?  Views
>>>use a query, plus the view keyword.  I have a couple of books that I 
>>>have read the chapter on Views, but I so far haven't managed
>>>
>>>
>>to "get"
>>
>>
>>>why you wouldn't just use the query itself instead of
>>>
>>>
>>turning it into a
>>
>>
>>>view.
>>>
>>>
>>>
>>>
>>A query is a request for an Access Database, however for Sql Server
>>you would either use a View or Stored Procedure to return the data you
>>wanted... you are also able to use dynamic SQL to retrieve the
>>information you need.  ANY request given to the SQL Server engine is
>>managed by the engine, unless you are running Remote servers (iirc).
>>
>>In Sql Server, it is TABOO, nay, GENERALLY bad practice to use dynamic

>>sql because of the implication of SQL INJECTION attacks, this poses a 
>>"real" security threat to your database. and your server.
>>
>>another reason to use a VIEW over dynamic sql is that it is
>>pre-optimized by the SQL Server Engine and thus runs faster and more 
>>efficient.  Additionally if you use Dynamic SQL then your individual 
>>users who access the server will need EXPLICIT "SELECT" permissions by
>>you, which is another 'bad' practice.  In SQL Server you make data
>>available to your users via VIEWs and Stored Procedures or some other
>>secure way in order to protect your tables and it's data.
>>
>>ya get wot I mean?
>>
>>--
>>-Francisco
>>
>>
>>_______________________________________________
>>dba-SQLServer mailing list
>>dba-SQLServer at databaseadvisors.com
>>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>>http://www.databaseadvisors.com
>>
>>
>>
>>
>>
>
>_______________________________________________
>dba-SQLServer mailing list
>dba-SQLServer at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>http://www.databaseadvisors.com
>
>
>
>


--
-Francisco


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

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



This electronic transmission is strictly confidential to TNCO, Inc. and
intended solely for the addressee. It may contain information which is
covered by legal, professional, or other privileges. If you are not the
intended addressee, or someone authorized by the intended addressee to
receive transmissions on behalf of the addressee, you must not retain,
disclose in any form, copy, or take any action in reliance on this
transmission. If you have received this transmission in error, please
notify the sender as soon as possible and destroy this message. While
TNCO, Inc. uses virus protection, the recipient should check this email
and any attachments for the presence of viruses. TNCO, Inc. accepts no
liability for any damage caused by any virus transmitted by this email.
_______________________________________________
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 accessd at shaw.ca  Fri Jun 11 13:58:47 2004
From: accessd at shaw.ca (Jim Lawrence (AccessD))
Date: Fri, 11 Jun 2004 11:58:47 -0700
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <40C9E0F9.70806@verizon.net>
Message-ID: <FJEJLIPOMCGJALMGLLLICEJHCDAA.accessd@shaw.ca>

Francisco:

You are right of course. I did not qualify my initial statement, enough.

...now I am doomed to qualify at length.
Jim

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of
Francisco H Tapia
Sent: Friday, June 11, 2004 9:43 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Difference between views and queries


Stuart McLachlan wrote On 6/11/2004 6:20 AM:

>On 10 Jun 2004 at 12:07, Jim Lawrence (AccessD) wrote:
>
>
>
>>Hi John:
>>
>>Personally, I see little reason to run views as their creation is spawned
at
>>the server side and any hit on the server I try to avoid. The concept of
>>distributive computing has always appealed to me. Queries, run at the
client
>>side.
>>
>>
>>
>
>But surely not when it means pulling unnecessary data and indexes across
the
>network. The whole point of server side computation is to reduce the
network
>traffic bottleneck.  I'd much rather let the server sort throuygh a million
>rows and feed the workstation with a thousand, rather than pass all million
>across the network and filter then client side.
>
>
Views are useful when a parameter is not needed.  Server Sided queries
run faster than those on clients because as a general rule, the Server
is a much more powerful box than that of the clients.  The purpose of
keeping views and stored procedures on the server is to help provide
"faster" access to those 10,100, 1000 or millions of rows.

>
>
>>There might be better performance with views, if there are limited people
>>accessing the server.
>>
>>
>
>The more people hitting the server the better, you gain more from caching
:-)
>
>Views limit, not that the client can see it anyway,
>
>
Right, If your server is underpowered, well maybe it's time to get a
better server :)

>>access to/display of the real table and present a pseudo table. Security?
>>
>>
>>
>
>That enhances security, not dimishes it.
>
>
>
Yes it is security because you are capable of segmenting data that the
end user "should" not be viewing.. and you also enhance data (that is
provide it faster) and join and provide values that the end user is used
to using, not ID's (be it autonumber, GUID or COMBs).

--
-Francisco


_______________________________________________
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  Fri Jun 11 14:16:50 2004
From: accessd at shaw.ca (Jim Lawrence (AccessD))
Date: Fri, 11 Jun 2004 12:16:50 -0700
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <40C9E432.2080700@verizon.net>
Message-ID: <FJEJLIPOMCGJALMGLLLIOEJHCDAA.accessd@shaw.ca>

Hi Franciso:

Password: As to criteria; minimum of 6 characters, mixed upper and lower
case, at least one number, at least one special character and a maximum of
two month duration.

I always try to limit the use of 'triggers'. They can be problematic when
trying to fix data. Of course they are only doing what they are suppose to
do. Note: I did say SPs and eluded to their smaller brothers-sisters,
functions.

Transitional periods can be very awkward and sometimes can open up a number
of security risks. Ideally, the data access would be strictly controlled
through the programmers and systems people and the effort would be
completely coordinated..ha ha ha.

I agree with you on the issues of ADP.

Hope this clarifies some of my comment.
Jim

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of
Francisco H Tapia
Sent: Friday, June 11, 2004 9:56 AM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Difference between views and queries


Jim Lawrence (AccessD) wrote On 6/10/2004 3:46 PM:

>Hi All:
>
>As to all these issues I would like to dump some of my own comments. At the
>risk of saying 'I told you so', I firmly believe that users should:
>
>1. Always (or should I say only), use windows authentication and
judiciously
>distribute security access, to your SQLxx, to only those who need it.
>Appropriate passwords and time limits.
>
>
Both Windows Authentication and Sql Server Authentication are viable
platforms.  If either pwd is weak, neither authentication will protect
against dictionary attacks.  I find that Auditing is a good tool to use
for helping to protect such systems.

>1. Never allow access to the data except through your program. That means
NO
>to ODBC drivers only ADO-OLE.
>
>
Unrealistic.  When working in an Enterprise network, data must be
shared.  Our system which went from an Access Database to a Sql Server
database is undergoing this transition, where the servers are sharing
data.  This is increasingly painful to monitor because you must "trust"
your other dba's but that's why the dba must take the responsibility to
always keep eye on their servers.

>2. In 99% of cases, control is handled through SPs.
>
>
there's SPs, Triggers and Functions

>3. And the biggy never, never use bound forms to access SQLxx data. I have
>been whining about that for years, a position that M$ has also fully
>supported.
>
>
bound forms have their place.  unfortunately, I don't really like the
way ADP's handle the 3 connection pooling to the server, that and the
fact that any report that can possibly run over 30 seconds times out :|

>4. You, as the programmer, should design your program to carefully validate
>all requests and data before they are posted.
>
>
:|, no, your input devices (SPs, Triggers, and Functions) must help
validate data too, otherwise when someone needs to hook into your
database, data will not be in par w/ what is expected.

>I may be already talking to the converted so you can ignore this; if
>not..Get on the program.
>
>Seeing we at in the midst of an election campaign, a good stump, political
>speech is the expected.
>Jim
>
>
>-----Original Message-----
>From: dba-sqlserver-bounces at databaseadvisors.com
>[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of
>Francisco H Tapia
>Sent: Thursday, June 10, 2004 1:55 PM
>To: dba-sqlserver at databaseadvisors.com
>Subject: Re: [dba-SQLServer] Difference between views and queries
>
>
>Andy,
>  SQL Server is not Access on steriods, it's a diffrent engine, and thus
>requires a new level of thinking towards your database engine.  It's NOT
>that you couldn't, you can do anything, heck if you wanted to you can
>set up your SQL Server with a blank SA password or SA as the password.
>For all that matters, and avoiding all SQL Server authentication, just
>use NT authentication and enable guest users :).
>
>There have been quite a few white papers circulating on why you
>"wouldn't" use dynamic sql w/ your sql server (check out
>www.sqlservercentral.com, a fine resource) but the 2 very critical
>factors include performance and also quite possible damage to your data.
>
>It is entirely possible for your sql statement to read in this manner,
>lets's say that you are Selecting Data from a table and you have a
>combobox to help choose data, so your SQL Statment looks like this:
>
>"Select CompanyName, CompanyAttribute1, pKey FROM tblCompany WHERE
>CompanyAttribute1 = '" & me.cboMyBOX & "'", If I was a malicious user on
>your system and I have direct access to tables, and if you're doing
>statements like the above it is entirely plausible that you also have
>"INSERT" statements thus you are giving more than just simple SELECT
>access to these tables., thus with some malformed selection I can add
>this in the select
>
>'; DELETE FROM tblCompany; SELECT '
>
>your final statement would look like this
>
>Select CompanyName, CompanyAttribute1, pKey FROM tblCompany WHERE
>CompanyAttribute1 = ''; DELETE FROM tblCompany; SELECT ''
>
>Now your entire COMPANY table has been wiped out, while it is completely
>possible to restore your db up to the minute, you've still lost some
>downtime given that you had ONE bad apple in the bunch.
>
>Besides the sql injection threats, you also suffer from a
>NON-pre-compiled statement, thus your data could conceptually be
>returned a lot faster if you let it, simply by creating a view or stored
>procedure.  By the way just because you are using a stored procedure
>does not make you completly excempt of sql injections, if you are using
>dynamic sql within that procedure you are still open to these kind of
>attacks and your stored procedure is always re-comiled and thus suffers
>from the same performance deficits.
>
>
>Andy Lacey wrote On 6/10/2004 1:27 PM:
>
>
>
>>But, Francisco, if I was porting to SQL Server my Access app which builds
>>SELECT statements dynamically all of the time for many and various
>>situations are you saying I couldn't, or shouldn't or something?
>>
>>-- Andy Lacey
>>http://www.minstersystems.co.uk
>>
>>
>>
>>
>>
>>>-----Original Message-----
>>>From: dba-sqlserver-bounces at databaseadvisors.com
>>>[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf
>>>Of Francisco H Tapia
>>>Sent: 10 June 2004 20:58
>>>To: dba-sqlserver at databaseadvisors.com
>>>Subject: Re: [dba-SQLServer] Difference between views and queries
>>>
>>>
>>>jwcolby wrote On 6/10/2004 9:33 AM:
>>>
>>>
>>>
>>>
>>>
>>>>Can anyone explain the difference between a view and a query?  Views
>>>>use a query, plus the view keyword.  I have a couple of books that I
>>>>have read the chapter on Views, but I so far haven't managed
>>>>
>>>>
>>>>
>>>>
>>>to "get"
>>>
>>>
>>>
>>>
>>>>why you wouldn't just use the query itself instead of
>>>>
>>>>
>>>>
>>>>
>>>turning it into a
>>>
>>>
>>>
>>>
>>>>view.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>A query is a request for an Access Database, however for Sql
>>>Server you
>>>would either use a View or Stored Procedure to return the data you
>>>wanted... you are also able to use dynamic SQL to retrieve the
>>>information you need.  ANY request given to the SQL Server engine is
>>>managed by the engine, unless you are running Remote servers (iirc).
>>>
>>>In Sql Server, it is TABOO, nay, GENERALLY bad practice to
>>>use dynamic
>>>sql because of the implication of SQL INJECTION attacks, this poses a
>>>"real" security threat to your database. and your server.
>>>
>>>another reason to use a VIEW over dynamic sql is that it is
>>>pre-optimized by the SQL Server Engine and thus runs faster and more
>>>efficient.  Additionally if you use Dynamic SQL then your individual
>>>users who access the server will need EXPLICIT "SELECT"
>>>permissions by
>>>you, which is another 'bad' practice.  In SQL Server you make data
>>>available to your users via VIEWs and Stored Procedures or some other
>>>secure way in order to protect your tables and it's data.
>>>
>>>ya get wot I mean?
>>>
>>>--
>>>-Francisco
>>>
>>>
>>>
>>>
>
>


--
-Francisco


_______________________________________________
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  Fri Jun 11 14:51:48 2004
From: cfoust at infostatsystems.com (Charlotte Foust)
Date: Fri, 11 Jun 2004 12:51:48 -0700
Subject: [dba-SQLServer] Difference between views and queries
Message-ID: <E61FC1D4B1918244905B113C680BEA86312867@infoserver01.infostat.local>

Yes, but since SQL doesn't have it's own FE tool, we tend to wind up
talking Access.  :-}

Charlotte Foust

-----Original Message-----
From: Jim Lawrence (AccessD) [mailto:accessd at shaw.ca] 
Sent: Friday, June 11, 2004 10:59 AM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


Charlotte...I missed the word MDB.

This is the SQL list, I hope?

Jim

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of
Charlotte Foust
Sent: Friday, June 11, 2004 9:42 AM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


Right.  That's why I specified MDBs.  

Charlotte Foust

-----Original Message-----
From: Mackin, Christopher [mailto:CMackin at quiznos.com] 
Sent: Friday, June 11, 2004 7:21 AM
To: 'dba-sqlserver at databaseadvisors.com'
Subject: RE: [dba-SQLServer] Difference between views and queries


Not so for an .adp though, where you can bind a form directly to SQL
data without ODBC.

-Chris Mackin

-----Original Message-----
From: Charlotte Foust [mailto:cfoust at infostatsystems.com]
Sent: Friday, June 11, 2004 9:16 AM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


Bound forms require ODBC links to be editable.  Forms (in Access MDBs)
bound to ADO recordsets are not updatable, and ADO is the only option
that avoids ODBC links to return a recordset.

Charlotte Foust

-----Original Message-----
From: Joe Rojas [mailto:JRojas at tnco-inc.com] 
Sent: Friday, June 11, 2004 4:38 AM
To: 'dba-sqlserver at databaseadvisors.com'
Subject: RE: [dba-SQLServer] Difference between views and queries


Hi Jim,

What is the argument for not using bound forms?

JR

-----Original Message-----
From: Jim Lawrence (AccessD) [mailto:accessd at shaw.ca]
Sent: Thursday, June 10, 2004 6:46 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries

Hi All:

As to all these issues I would like to dump some of my own comments. At
the risk of saying 'I told you so', I firmly believe that users should:

1. Always (or should I say only), use windows authentication and
judiciously distribute security access, to your SQLxx, to only those who
need it. Appropriate passwords and time limits. 1. Never allow access to
the data except through your program. That means NO to ODBC drivers only
ADO-OLE. 2. In 99% of cases, control is handled through SPs. 3. And the
biggy never, never use bound forms to access SQLxx data. I have been
whining about that for years, a position that M$ has also fully
supported. 4. You, as the programmer, should design your program to
carefully validate all requests and data before they are posted.

I may be already talking to the converted so you can ignore this; if
not..Get on the program.

Seeing we at in the midst of an election campaign, a good stump,
political speech is the expected. Jim


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of
Francisco H Tapia
Sent: Thursday, June 10, 2004 1:55 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Difference between views and queries


Andy,
  SQL Server is not Access on steriods, it's a diffrent engine, and thus
requires a new level of thinking towards your database engine.  It's NOT
that you couldn't, you can do anything, heck if you wanted to you can
set up your SQL Server with a blank SA password or SA as the password.
For all that matters, and avoiding all SQL Server authentication, just
use NT authentication and enable guest users :).

There have been quite a few white papers circulating on why you
"wouldn't" use dynamic sql w/ your sql server (check out
www.sqlservercentral.com, a fine resource) but the 2 very critical
factors include performance and also quite possible damage to your data.

It is entirely possible for your sql statement to read in this manner,
lets's say that you are Selecting Data from a table and you have a
combobox to help choose data, so your SQL Statment looks like this:

"Select CompanyName, CompanyAttribute1, pKey FROM tblCompany WHERE
CompanyAttribute1 = '" & me.cboMyBOX & "'", If I was a malicious user on
your system and I have direct access to tables, and if you're doing
statements like the above it is entirely plausible that you also have
"INSERT" statements thus you are giving more than just simple SELECT
access to these tables., thus with some malformed selection I can add
this in the select

'; DELETE FROM tblCompany; SELECT '

your final statement would look like this

Select CompanyName, CompanyAttribute1, pKey FROM tblCompany WHERE
CompanyAttribute1 = ''; DELETE FROM tblCompany; SELECT ''

Now your entire COMPANY table has been wiped out, while it is completely
possible to restore your db up to the minute, you've still lost some
downtime given that you had ONE bad apple in the bunch.

Besides the sql injection threats, you also suffer from a
NON-pre-compiled statement, thus your data could conceptually be
returned a lot faster if you let it, simply by creating a view or stored
procedure.  By the way just because you are using a stored procedure
does not make you completly excempt of sql injections, if you are using
dynamic sql within that procedure you are still open to these kind of
attacks and your stored procedure is always re-comiled and thus suffers
from the same performance deficits.


Andy Lacey wrote On 6/10/2004 1:27 PM:

>But, Francisco, if I was porting to SQL Server my Access app which 
>builds SELECT statements dynamically all of the time for many and 
>various situations are you saying I couldn't, or shouldn't or 
>something?
>
>-- Andy Lacey
>http://www.minstersystems.co.uk
>
>
>
>>-----Original Message-----
>>From: dba-sqlserver-bounces at databaseadvisors.com
>>[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of 
>>Francisco H Tapia
>>Sent: 10 June 2004 20:58
>>To: dba-sqlserver at databaseadvisors.com
>>Subject: Re: [dba-SQLServer] Difference between views and queries
>>
>>
>>jwcolby wrote On 6/10/2004 9:33 AM:
>>
>>
>>
>>>Can anyone explain the difference between a view and a query?  Views 
>>>use a query, plus the view keyword.  I have a couple of books that I 
>>>have read the chapter on Views, but I so far haven't managed
>>>
>>>
>>to "get"
>>
>>
>>>why you wouldn't just use the query itself instead of
>>>
>>>
>>turning it into a
>>
>>
>>>view.
>>>
>>>
>>>
>>>
>>A query is a request for an Access Database, however for Sql Server 
>>you would either use a View or Stored Procedure to return the data you

>>wanted... you are also able to use dynamic SQL to retrieve the 
>>information you need.  ANY request given to the SQL Server engine is 
>>managed by the engine, unless you are running Remote servers (iirc).
>>
>>In Sql Server, it is TABOO, nay, GENERALLY bad practice to use dynamic

>>sql because of the implication of SQL INJECTION attacks, this poses a
>>"real" security threat to your database. and your server.
>>
>>another reason to use a VIEW over dynamic sql is that it is 
>>pre-optimized by the SQL Server Engine and thus runs faster and more 
>>efficient.  Additionally if you use Dynamic SQL then your individual 
>>users who access the server will need EXPLICIT "SELECT" permissions by

>>you, which is another 'bad' practice.  In SQL Server you make data 
>>available to your users via VIEWs and Stored Procedures or some other 
>>secure way in order to protect your tables and it's data.
>>
>>ya get wot I mean?
>>
>>--
>>-Francisco
>>
>>
>>_______________________________________________
>>dba-SQLServer mailing list
>>dba-SQLServer at databaseadvisors.com
>>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>>http://www.databaseadvisors.com
>>
>>
>>
>>
>>
>
>_______________________________________________
>dba-SQLServer mailing list
>dba-SQLServer at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>http://www.databaseadvisors.com
>
>
>
>


--
-Francisco


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

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



This electronic transmission is strictly confidential to TNCO, Inc. and
intended solely for the addressee. It may contain information which is
covered by legal, professional, or other privileges. If you are not the
intended addressee, or someone authorized by the intended addressee to
receive transmissions on behalf of the addressee, you must not retain,
disclose in any form, copy, or take any action in reliance on this
transmission. If you have received this transmission in error, please
notify the sender as soon as possible and destroy this message. While
TNCO, Inc. uses virus protection, the recipient should check this email
and any attachments for the presence of viruses. TNCO, Inc. accepts no
liability for any damage caused by any virus transmitted by this email.
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com

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

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

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



From accessd at shaw.ca  Fri Jun 11 16:26:47 2004
From: accessd at shaw.ca (Jim Lawrence (AccessD))
Date: Fri, 11 Jun 2004 14:26:47 -0700
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <E61FC1D4B1918244905B113C680BEA86312867@infoserver01.infostat.local>
Message-ID: <FJEJLIPOMCGJALMGLLLIEEJKCDAA.accessd@shaw.ca>

Hi Charlotte:

I tend to view Access as three distinct layers.

1. The presentation layer. (love it!)
2. The data-access layer. (so flexible...)
3. The data layer. (use judiciously)

In most of my major applications, I extensively use the presentation layer,
roll my own data-access layer and use the data layer, strictly for temporary
files.

I use MSSQL's EM to design, build and test (SP, functions, tables,
relationships, security, roles and yes, even views and triggers.) :-)...and
then combine it all, nice and pretty with Access.

So the point being, is when I am discussing data I am probably not
discussing Access.

Jim

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of
Charlotte Foust
Sent: Friday, June 11, 2004 12:52 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


Yes, but since SQL doesn't have it's own FE tool, we tend to wind up
talking Access.  :-}

Charlotte Foust

-----Original Message-----
From: Jim Lawrence (AccessD) [mailto:accessd at shaw.ca]
Sent: Friday, June 11, 2004 10:59 AM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


Charlotte...I missed the word MDB.

This is the SQL list, I hope?

Jim

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of
Charlotte Foust
Sent: Friday, June 11, 2004 9:42 AM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


Right.  That's why I specified MDBs.

Charlotte Foust

-----Original Message-----
From: Mackin, Christopher [mailto:CMackin at quiznos.com]
Sent: Friday, June 11, 2004 7:21 AM
To: 'dba-sqlserver at databaseadvisors.com'
Subject: RE: [dba-SQLServer] Difference between views and queries


Not so for an .adp though, where you can bind a form directly to SQL
data without ODBC.

-Chris Mackin

-----Original Message-----
From: Charlotte Foust [mailto:cfoust at infostatsystems.com]
Sent: Friday, June 11, 2004 9:16 AM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


Bound forms require ODBC links to be editable.  Forms (in Access MDBs)
bound to ADO recordsets are not updatable, and ADO is the only option
that avoids ODBC links to return a recordset.

Charlotte Foust

-----Original Message-----
From: Joe Rojas [mailto:JRojas at tnco-inc.com]
Sent: Friday, June 11, 2004 4:38 AM
To: 'dba-sqlserver at databaseadvisors.com'
Subject: RE: [dba-SQLServer] Difference between views and queries


Hi Jim,

What is the argument for not using bound forms?

JR

-----Original Message-----
From: Jim Lawrence (AccessD) [mailto:accessd at shaw.ca]
Sent: Thursday, June 10, 2004 6:46 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries

Hi All:

As to all these issues I would like to dump some of my own comments. At
the risk of saying 'I told you so', I firmly believe that users should:

1. Always (or should I say only), use windows authentication and
judiciously distribute security access, to your SQLxx, to only those who
need it. Appropriate passwords and time limits. 1. Never allow access to
the data except through your program. That means NO to ODBC drivers only
ADO-OLE. 2. In 99% of cases, control is handled through SPs. 3. And the
biggy never, never use bound forms to access SQLxx data. I have been
whining about that for years, a position that M$ has also fully
supported. 4. You, as the programmer, should design your program to
carefully validate all requests and data before they are posted.

I may be already talking to the converted so you can ignore this; if
not..Get on the program.

Seeing we at in the midst of an election campaign, a good stump,
political speech is the expected. Jim


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of
Francisco H Tapia
Sent: Thursday, June 10, 2004 1:55 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Difference between views and queries


Andy,
  SQL Server is not Access on steriods, it's a diffrent engine, and thus
requires a new level of thinking towards your database engine.  It's NOT
that you couldn't, you can do anything, heck if you wanted to you can
set up your SQL Server with a blank SA password or SA as the password.
For all that matters, and avoiding all SQL Server authentication, just
use NT authentication and enable guest users :).

There have been quite a few white papers circulating on why you
"wouldn't" use dynamic sql w/ your sql server (check out
www.sqlservercentral.com, a fine resource) but the 2 very critical
factors include performance and also quite possible damage to your data.

It is entirely possible for your sql statement to read in this manner,
lets's say that you are Selecting Data from a table and you have a
combobox to help choose data, so your SQL Statment looks like this:

"Select CompanyName, CompanyAttribute1, pKey FROM tblCompany WHERE
CompanyAttribute1 = '" & me.cboMyBOX & "'", If I was a malicious user on
your system and I have direct access to tables, and if you're doing
statements like the above it is entirely plausible that you also have
"INSERT" statements thus you are giving more than just simple SELECT
access to these tables., thus with some malformed selection I can add
this in the select

'; DELETE FROM tblCompany; SELECT '

your final statement would look like this

Select CompanyName, CompanyAttribute1, pKey FROM tblCompany WHERE
CompanyAttribute1 = ''; DELETE FROM tblCompany; SELECT ''

Now your entire COMPANY table has been wiped out, while it is completely
possible to restore your db up to the minute, you've still lost some
downtime given that you had ONE bad apple in the bunch.

Besides the sql injection threats, you also suffer from a
NON-pre-compiled statement, thus your data could conceptually be
returned a lot faster if you let it, simply by creating a view or stored
procedure.  By the way just because you are using a stored procedure
does not make you completly excempt of sql injections, if you are using
dynamic sql within that procedure you are still open to these kind of
attacks and your stored procedure is always re-comiled and thus suffers
from the same performance deficits.


Andy Lacey wrote On 6/10/2004 1:27 PM:

>But, Francisco, if I was porting to SQL Server my Access app which
>builds SELECT statements dynamically all of the time for many and
>various situations are you saying I couldn't, or shouldn't or
>something?
>
>-- Andy Lacey
>http://www.minstersystems.co.uk
>
>
>
>>-----Original Message-----
>>From: dba-sqlserver-bounces at databaseadvisors.com
>>[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of
>>Francisco H Tapia
>>Sent: 10 June 2004 20:58
>>To: dba-sqlserver at databaseadvisors.com
>>Subject: Re: [dba-SQLServer] Difference between views and queries
>>
>>
>>jwcolby wrote On 6/10/2004 9:33 AM:
>>
>>
>>
>>>Can anyone explain the difference between a view and a query?  Views
>>>use a query, plus the view keyword.  I have a couple of books that I
>>>have read the chapter on Views, but I so far haven't managed
>>>
>>>
>>to "get"
>>
>>
>>>why you wouldn't just use the query itself instead of
>>>
>>>
>>turning it into a
>>
>>
>>>view.
>>>
>>>
>>>
>>>
>>A query is a request for an Access Database, however for Sql Server
>>you would either use a View or Stored Procedure to return the data you

>>wanted... you are also able to use dynamic SQL to retrieve the
>>information you need.  ANY request given to the SQL Server engine is
>>managed by the engine, unless you are running Remote servers (iirc).
>>
>>In Sql Server, it is TABOO, nay, GENERALLY bad practice to use dynamic

>>sql because of the implication of SQL INJECTION attacks, this poses a
>>"real" security threat to your database. and your server.
>>
>>another reason to use a VIEW over dynamic sql is that it is
>>pre-optimized by the SQL Server Engine and thus runs faster and more
>>efficient.  Additionally if you use Dynamic SQL then your individual
>>users who access the server will need EXPLICIT "SELECT" permissions by

>>you, which is another 'bad' practice.  In SQL Server you make data
>>available to your users via VIEWs and Stored Procedures or some other
>>secure way in order to protect your tables and it's data.
>>
>>ya get wot I mean?
>>
>>--
>>-Francisco
>>
>>
>>_______________________________________________
>>dba-SQLServer mailing list
>>dba-SQLServer at databaseadvisors.com
>>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>>http://www.databaseadvisors.com
>>
>>
>>
>>
>>
>
>_______________________________________________
>dba-SQLServer mailing list
>dba-SQLServer at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>http://www.databaseadvisors.com
>
>
>
>


--
-Francisco


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

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



This electronic transmission is strictly confidential to TNCO, Inc. and
intended solely for the addressee. It may contain information which is
covered by legal, professional, or other privileges. If you are not the
intended addressee, or someone authorized by the intended addressee to
receive transmissions on behalf of the addressee, you must not retain,
disclose in any form, copy, or take any action in reliance on this
transmission. If you have received this transmission in error, please
notify the sender as soon as possible and destroy this message. While
TNCO, Inc. uses virus protection, the recipient should check this email
and any attachments for the presence of viruses. TNCO, Inc. accepts no
liability for any damage caused by any virus transmitted by this email.
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com

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

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

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

_______________________________________________
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  Sat Jun 12 22:46:24 2004
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Sat, 12 Jun 2004 23:46:24 -0400
Subject: [dba-SQLServer] Date syntax in SQL Server
Message-ID: <000201c450f9$002b6820$0501a8c0@colbyws>

What is the syntax for dates in SQL Server?

WHERE     (DateOfBirth >= CONVERT(DATETIME, '1970-01-01', 102))

I need to get rid of the convert.  Bracketing in ## doesn't work.

John W. Colby 
www.ColbyConsulting.com




From accessd at shaw.ca  Sun Jun 13 01:30:59 2004
From: accessd at shaw.ca (Jim Lawrence (AccessD))
Date: Sat, 12 Jun 2004 23:30:59 -0700
Subject: [dba-SQLServer] Date syntax in SQL Server
In-Reply-To: <000201c450f9$002b6820$0501a8c0@colbyws>
Message-ID: <FJEJLIPOMCGJALMGLLLIAEKCCDAA.accessd@shaw.ca>

Hi John:

In my SP, I would probably create a variable like:

Declare @CheckDate Datetime
Select @CheckDate = convert(datetime,'1970-01-01',102))

...and then use the variable in the Where clause:

WHERE (DateOfBirth >= @CheckDate

...or when you put dates directly into the query:

WHERE (DateOfBirth between '01-Apr-2003' and '31-mar-2004'

HTH
Jim

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of jwcolby
Sent: Saturday, June 12, 2004 8:46 PM
To: 'Access Developers discussion and problem solving'; SQLServer
Subject: [dba-SQLServer] Date syntax in SQL Server


What is the syntax for dates in SQL Server?

WHERE     (DateOfBirth >= CONVERT(DATETIME, '1970-01-01', 102))

I need to get rid of the convert.  Bracketing in ## doesn't work.

John W. Colby 
www.ColbyConsulting.com


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



From mmaddison at optusnet.com.au  Sun Jun 13 09:56:57 2004
From: mmaddison at optusnet.com.au (Michael Maddison)
Date: Mon, 14 Jun 2004 00:56:57 +1000
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <40C8BD48.9050905@verizon.net>
Message-ID: <JIELLFDJKMAGJJMDIMIIGEFCBCAB.mmaddison@optusnet.com.au>

jwcolby wrote On 6/10/2004 9:33 AM:

>Can anyone explain the difference between a view and a query?  Views use a
>query, plus the view keyword.  I have a couple of books that I have read
the
>chapter on Views, but I so far haven't managed to "get" why you wouldn't
>just use the query itself instead of turning it into a view.
>
>
A query is a request for an Access Database, however for Sql Server you
would either use a View or Stored Procedure to return the data you
wanted... you are also able to use dynamic SQL to retrieve the
information you need.  ANY request given to the SQL Server engine is
managed by the engine, unless you are running Remote servers (iirc).

In Sql Server, it is TABOO, nay, GENERALLY bad practice to use dynamic
sql because of the implication of SQL INJECTION attacks, this poses a
"real" security threat to your database. and your server.


another reason to use a VIEW over dynamic sql is that it is
pre-optimized by the SQL Server Engine and thus runs faster and more
efficient.

>>>Sorry, this is not true.  SQL creates an execution plan the 1st
time a SQL statement is run, whether it is a view, sproc or dynamic makes
no difference.

Additionally if you use Dynamic SQL then your individual
users who access the server will need EXPLICIT "SELECT" permissions by
you, which is another 'bad' practice.

>>>Not if you use roles, now if you don't use roles thats just making work
for the dba.  You could give select permissions and deny insert + update +
delete.

In SQL Server you make data
available to your users via VIEWs and Stored Procedures or some other
secure way in order to protect your tables and it's data.

>>>I would lose little sleep over developers executing sql in a compiled
application.  I'd be more concerned if it was a web app because of the
injection
threat, but even then you can take measures to defeat attacks (or so I
believe,
I don't do much SQL + WWW).

Sometimes you have to use dynamic SQL, be extra careful on the web, use a
sproc
so you can test the string passed or even better build the string inside
the sproc.  There is no performance penalty...

cheers

Michael M

PS In case I've given the wrong impression I favour using sprocs where
possible,
views are all but useless IMO.  Use them to present joined tables for
reports etc.

ya get wot I mean?

--
-Francisco


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



From HARVEYF1 at WESTAT.com  Sun Jun 13 12:46:05 2004
From: HARVEYF1 at WESTAT.com (Francis Harvey)
Date: Sun, 13 Jun 2004 13:46:05 -0400
Subject: [dba-SQLServer] RE: [AccessD] Date syntax in SQL Server
Message-ID: <446DDE75CFC7E1438061462F85557B0F0BFEE0@remail2.westat.com>

Why bother doing any conversion at all? You already have an
internationalized date value and I would assume your DateOfBirth field
is a datetime field. Conversion would be automatic, so just use:

WHERE     (DateOfBirth >= '1970-01-01')

Francis R Harvey III
WB 303, (301)294-3952
harveyf1 at westat.com


> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com 
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
> Sent: Saturday, June 12, 2004 11:46 PM
> To: 'Access Developers discussion and problem solving'; SQLServer
> Subject: [AccessD] Date syntax in SQL Server
> 
> 
> What is the syntax for dates in SQL Server?
> 
> WHERE     (DateOfBirth >= CONVERT(DATETIME, '1970-01-01', 102))
> 
> I need to get rid of the convert.  Bracketing in ## doesn't work.
> 
> John W. Colby 
> www.ColbyConsulting.com
> 
> 
> -- 
> _______________________________________________
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> 


From jwcolby at colbyconsulting.com  Sun Jun 13 14:36:30 2004
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Sun, 13 Jun 2004 15:36:30 -0400
Subject: [dba-SQLServer] RE: [AccessD] Date syntax in SQL Server
In-Reply-To: <446DDE75CFC7E1438061462F85557B0F0BFEE0@remail2.westat.com>
Message-ID: <002401c4517d$ba7b6f70$0501a8c0@colbyws>

I didn't do the convert, SQL Server threw that in and I was trying to get
rid of it.

John W. Colby 
www.ColbyConsulting.com

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Francis
Harvey
Sent: Sunday, June 13, 2004 1:46 PM
To: SQLServer
Subject: [dba-SQLServer] RE: [AccessD] Date syntax in SQL Server


Why bother doing any conversion at all? You already have an
internationalized date value and I would assume your DateOfBirth field is a
datetime field. Conversion would be automatic, so just use:

WHERE     (DateOfBirth >= '1970-01-01')

Francis R Harvey III
WB 303, (301)294-3952
harveyf1 at westat.com


> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
> Sent: Saturday, June 12, 2004 11:46 PM
> To: 'Access Developers discussion and problem solving'; SQLServer
> Subject: [AccessD] Date syntax in SQL Server
> 
> 
> What is the syntax for dates in SQL Server?
> 
> WHERE     (DateOfBirth >= CONVERT(DATETIME, '1970-01-01', 102))
> 
> I need to get rid of the convert.  Bracketing in ## doesn't work.
> 
> John W. Colby
> www.ColbyConsulting.com
> 
> 
> --
> _______________________________________________
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: 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 mwp.reid at qub.ac.uk  Tue Jun 15 15:15:31 2004
From: mwp.reid at qub.ac.uk (Martin Reid)
Date: Tue, 15 Jun 2004 21:15:31 +0100
Subject: [dba-SQLServer] Connections
References: <5.1.0.14.2.20040527140143.01752430@pop3.highstream.net>
	<40B64FDB.9090805@verizon.net>
Message-ID: <004501c45315$82ed1290$1b02a8c0@MARTINREID>

I have a global connection set up in an Access front end to SQL Server. When
this goes out to the clients it will run on many different client servers
and we will not know the server name or security model in use before it is
installed.

How do you folks handle this?

SQL Server 2000
Access 2000, 2002 and 2003 as the front end.


Martin



From Jeff at OUTBAKTech.com  Wed Jun 16 07:55:27 2004
From: Jeff at OUTBAKTech.com (Jeff Barrows)
Date: Wed, 16 Jun 2004 07:55:27 -0500
Subject: [dba-SQLServer] Data Types
Message-ID: <8DA8776D2F418E46A2A464AC6CE63050032688@outbaksrv1.outbaktech.com>

What is the best way to create an auto numbering field for SQL?  I am upsizing an Access 97 database to SQL and need to keep some fields as autonumbers.
 
Jeff B


From my.lists at verizon.net  Wed Jun 16 10:43:52 2004
From: my.lists at verizon.net (Francisco H Tapia)
Date: Wed, 16 Jun 2004 08:43:52 -0700
Subject: [dba-SQLServer] Data Types
In-Reply-To: <8DA8776D2F418E46A2A464AC6CE63050032688@outbaksrv1.outbaktech.com>
References: <8DA8776D2F418E46A2A464AC6CE63050032688@outbaksrv1.outbaktech.com>
Message-ID: <40D06AB8.3050700@verizon.net>

It's the Integer field and you set it to have seed value of (whatever 
value you want to start at) and an Identity increment of 1 (or whatever 
you see fit).

Jeff Barrows wrote On 6/16/2004 5:55 AM:

>What is the best way to create an auto numbering field for SQL?  I am upsizing an Access 97 database to SQL and need to keep some fields as autonumbers.
> 
>Jeff B
>  
>


-- 
-Francisco




From my.lists at verizon.net  Wed Jun 16 10:49:35 2004
From: my.lists at verizon.net (Francisco H Tapia)
Date: Wed, 16 Jun 2004 08:49:35 -0700
Subject: [dba-SQLServer] Connections
Message-ID: <40D06C0F.70700@verizon.net>

One scenario I set up for a customer was to bring up the UDL connection 
property window before the app would fully load whenever the connection 
string was pointing to my home server.

On the app I am working on today, the app may connect locally, or 
remotely to a company server or switch to a fully Web driven 
application.  In order to do this I have planned to use an ini to store 
the connection strings, but then I'm going to encrypt them w/ 256bit 
encryption.  This will guarantee that no casual snooping will connect to 
the server.  the 256 bit encryption is based off some code I found on 
planet source code, it works remarkably well, tho I've never put it 
under any stress test.

I hope this answers part of your question...


Martin Reid wrote On 6/15/2004 1:15 PM:

I have a global connection set up in an Access front end to SQL Server. When
this goes out to the clients it will run on many different client servers
and we will not know the server name or security model in use before it is
installed.

How do you folks handle this?

SQL Server 2000
Access 2000, 2002 and 2003 as the front end.

-- 
-Francisco




From Jeff at OUTBAKTech.com  Wed Jun 16 11:05:27 2004
From: Jeff at OUTBAKTech.com (Jeff Barrows)
Date: Wed, 16 Jun 2004 11:05:27 -0500
Subject: [dba-SQLServer] Data Types
Message-ID: <8DA8776D2F418E46A2A464AC6CE63050032689@outbaksrv1.outbaktech.com>

Thanks, looks like that will do it for me!!!!

	-----Original Message----- 
	From: Francisco H Tapia [mailto:my.lists at verizon.net] 
	Sent: Wed 6/16/2004 10:43 AM 
	To: dba-sqlserver at databaseadvisors.com 
	Cc: 
	Subject: Re: [dba-SQLServer] Data Types
	
	

	It's the Integer field and you set it to have seed value of (whatever
	value you want to start at) and an Identity increment of 1 (or whatever
	you see fit).
	
	Jeff Barrows wrote On 6/16/2004 5:55 AM:
	
	>What is the best way to create an auto numbering field for SQL?  I am upsizing an Access 97 database to SQL and need to keep some fields as autonumbers.
	>
	>Jeff B
	> 
	>
	
	
	--
	-Francisco
	
	
	_______________________________________________
	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 16 12:17:35 2004
From: rl_stewart at highstream.net (Robert L. Stewart)
Date: Wed, 16 Jun 2004 12:17:35 -0500
Subject: [dba-SQLServer] Re: Data Types
In-Reply-To: <200406161701.i5GH1QQ18879@databaseadvisors.com>
Message-ID: <5.1.0.14.2.20040616121633.01797218@pop3.highstream.net>

You also have to set it as an Identity type
integer as well as set the seed and increment
values.

At 12:01 PM 6/16/2004 -0500, you wrote:
>Date: Wed, 16 Jun 2004 11:05:27 -0500
>From: "Jeff Barrows" <Jeff at OUTBAKTech.com>
>Subject: RE: [dba-SQLServer] Data Types
>To: <dba-sqlserver at databaseadvisors.com>
>Message-ID:
>         <8DA8776D2F418E46A2A464AC6CE63050032689 at outbaksrv1.outbaktech.com>
>Content-Type: text/plain; charset="utf-8"
>
>Thanks, looks like that will do it for me!!!!




From jwcolby at colbyconsulting.com  Thu Jun 17 07:55:48 2004
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Thu, 17 Jun 2004 08:55:48 -0400
Subject: [dba-SQLServer] Getting pictures into a blob in SQL Server
Message-ID: <001801c4546a$69da7e90$0501a8c0@colbyws>

I got a call from someone yesterday needing to get 25000 pictures into a
blob field in SQL Server.  The program he is attempting to use apparently
stores the pictures it uses in such a field.  These pictures are currently
stored as GIFs (I believe) on the hard drive.

I can write a program to cycle through a dir on the disk, but would I just
read the text into a string and dump it into the field, save and move on?
Has anyone ever done this?  

I included AccessD in this request as I am guessing I'll just do it through
VBA in AccessD.

John W. Colby 
www.ColbyConsulting.com




From James at fcidms.com  Thu Jun 17 08:22:19 2004
From: James at fcidms.com (James Barash)
Date: Thu, 17 Jun 2004 09:22:19 -0400
Subject: [dba-SQLServer] Getting pictures into a blob in SQL Server
In-Reply-To: <001801c4546a$69da7e90$0501a8c0@colbyws>
Message-ID: <200406171321.JAA23458@jake.bcentralhost.com>

John:

Here is the Microsoft knowledgebase article on doing just that using ADO.

http://support.microsoft.com/default.aspx?scid=kb;[LN];Q258038 

Hope it helps.

James Barash

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Thursday, June 17, 2004 8:56 AM
To: SQLServer; 'Access Developers discussion and problem solving'
Subject: [dba-SQLServer] Getting pictures into a blob in SQL Server

I got a call from someone yesterday needing to get 25000 pictures into a
blob field in SQL Server.  The program he is attempting to use apparently
stores the pictures it uses in such a field.  These pictures are currently
stored as GIFs (I believe) on the hard drive.

I can write a program to cycle through a dir on the disk, but would I just
read the text into a string and dump it into the field, save and move on?
Has anyone ever done this?  

I included AccessD in this request as I am guessing I'll just do it through
VBA in AccessD.

John W. Colby 
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  Thu Jun 17 09:13:42 2004
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Thu, 17 Jun 2004 10:13:42 -0400
Subject: [dba-SQLServer] Getting pictures into a blob in SQL Server
In-Reply-To: <200406171321.JAA23458@jake.bcentralhost.com>
Message-ID: <001a01c45475$4c06aff0$0501a8c0@colbyws>

Thanks!

John W. Colby 
www.ColbyConsulting.com

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of James
Barash
Sent: Thursday, June 17, 2004 9:22 AM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Getting pictures into a blob in SQL Server


John:

Here is the Microsoft knowledgebase article on doing just that using ADO.

http://support.microsoft.com/default.aspx?scid=kb;[LN];Q258038 

Hope it helps.

James Barash

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Thursday, June 17, 2004 8:56 AM
To: SQLServer; 'Access Developers discussion and problem solving'
Subject: [dba-SQLServer] Getting pictures into a blob in SQL Server

I got a call from someone yesterday needing to get 25000 pictures into a
blob field in SQL Server.  The program he is attempting to use apparently
stores the pictures it uses in such a field.  These pictures are currently
stored as GIFs (I believe) on the hard drive.

I can write a program to cycle through a dir on the disk, but would I just
read the text into a string and dump it into the field, save and move on?
Has anyone ever done this?  

I included AccessD in this request as I am guessing I'll just do it through
VBA in AccessD.

John W. Colby 
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  Thu Jun 17 10:32:18 2004
From: accessd at shaw.ca (Jim Lawrence (AccessD))
Date: Thu, 17 Jun 2004 08:32:18 -0700
Subject: [dba-SQLServer] Getting pictures into a blob in SQL Server
In-Reply-To: <001801c4546a$69da7e90$0501a8c0@colbyws>
Message-ID: <FJEJLIPOMCGJALMGLLLIIEMBCDAA.accessd@shaw.ca>

Hi John:

Access or SQL (Oracle for that matter) bloat and display (extract) too
slowly. The fastest method that handles imbedded graphic files is using ADO
stream method. (If you are interested I will post the code.)

The only really good method, that avoids bloat and is by far the fastest, is
to store the graphic file externally and just uses the tables to track the
file locations.

HTH
Jim


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of jwcolby
Sent: Thursday, June 17, 2004 5:56 AM
To: SQLServer; 'Access Developers discussion and problem solving'
Subject: [dba-SQLServer] Getting pictures into a blob in SQL Server


I got a call from someone yesterday needing to get 25000 pictures into a
blob field in SQL Server.  The program he is attempting to use apparently
stores the pictures it uses in such a field.  These pictures are currently
stored as GIFs (I believe) on the hard drive.

I can write a program to cycle through a dir on the disk, but would I just
read the text into a string and dump it into the field, save and move on?
Has anyone ever done this?

I included AccessD in this request as I am guessing I'll just do it through
VBA in AccessD.

John W. Colby
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  Thu Jun 17 15:56:28 2004
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Thu, 17 Jun 2004 16:56:28 -0400
Subject: [dba-SQLServer] Getting pictures into a blob in SQL Server
In-Reply-To: <FJEJLIPOMCGJALMGLLLIIEMBCDAA.accessd@shaw.ca>
Message-ID: <000801c454ad$8f737380$0501a8c0@colbyws>

Unfortunately the program the gentleman purchased embeds them in the db.  He
contacted them and they said they would not change that so...

John W. Colby 
www.ColbyConsulting.com

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Jim
Lawrence (AccessD)
Sent: Thursday, June 17, 2004 11:32 AM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Getting pictures into a blob in SQL Server


Hi John:

Access or SQL (Oracle for that matter) bloat and display (extract) too
slowly. The fastest method that handles imbedded graphic files is using ADO
stream method. (If you are interested I will post the code.)

The only really good method, that avoids bloat and is by far the fastest, is
to store the graphic file externally and just uses the tables to track the
file locations.

HTH
Jim


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of jwcolby
Sent: Thursday, June 17, 2004 5:56 AM
To: SQLServer; 'Access Developers discussion and problem solving'
Subject: [dba-SQLServer] Getting pictures into a blob in SQL Server


I got a call from someone yesterday needing to get 25000 pictures into a
blob field in SQL Server.  The program he is attempting to use apparently
stores the pictures it uses in such a field.  These pictures are currently
stored as GIFs (I believe) on the hard drive.

I can write a program to cycle through a dir on the disk, but would I just
read the text into a string and dump it into the field, save and move on?
Has anyone ever done this?

I included AccessD in this request as I am guessing I'll just do it through
VBA in AccessD.

John W. Colby
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  Fri Jun 18 00:15:45 2004
From: accessd at shaw.ca (Jim Lawrence (AccessD))
Date: Thu, 17 Jun 2004 22:15:45 -0700
Subject: [dba-SQLServer] Getting pictures into a blob in SQL Server
In-Reply-To: <000801c454ad$8f737380$0501a8c0@colbyws>
Message-ID: <FJEJLIPOMCGJALMGLLLICEMJCDAA.accessd@shaw.ca>

Hi John:

What type of program is it anyway? Once the graphics have been embedded they
can be difficult to extact again. Depending on the embedding method, a
Access DB can be completely swamped before you can say over-the-2-GB-limit.
I had a corrupted MDB that had to have the embedded graphics files released
and the patient made a complete recovery. It was not a difficult procedure
but the extraction program ran for almost sixteen hours.

Jim

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of jwcolby
Sent: Thursday, June 17, 2004 1:56 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Getting pictures into a blob in SQL Server


Unfortunately the program the gentleman purchased embeds them in the db.  He
contacted them and they said they would not change that so...

John W. Colby
www.ColbyConsulting.com

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Jim
Lawrence (AccessD)
Sent: Thursday, June 17, 2004 11:32 AM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Getting pictures into a blob in SQL Server


Hi John:

Access or SQL (Oracle for that matter) bloat and display (extract) too
slowly. The fastest method that handles imbedded graphic files is using ADO
stream method. (If you are interested I will post the code.)

The only really good method, that avoids bloat and is by far the fastest, is
to store the graphic file externally and just uses the tables to track the
file locations.

HTH
Jim


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of jwcolby
Sent: Thursday, June 17, 2004 5:56 AM
To: SQLServer; 'Access Developers discussion and problem solving'
Subject: [dba-SQLServer] Getting pictures into a blob in SQL Server


I got a call from someone yesterday needing to get 25000 pictures into a
blob field in SQL Server.  The program he is attempting to use apparently
stores the pictures it uses in such a field.  These pictures are currently
stored as GIFs (I believe) on the hard drive.

I can write a program to cycle through a dir on the disk, but would I just
read the text into a string and dump it into the field, save and move on?
Has anyone ever done this?

I included AccessD in this request as I am guessing I'll just do it through
VBA in AccessD.

John W. Colby
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  Fri Jun 18 19:04:49 2004
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Fri, 18 Jun 2004 20:04:49 -0400
Subject: [dba-SQLServer] Getting pictures into a blob in SQL Server
In-Reply-To: <FJEJLIPOMCGJALMGLLLICEMJCDAA.accessd@shaw.ca>
Message-ID: <002401c45591$0a1edc30$0501a8c0@colbyws>

This is going into SQL Server.  And I'm not sure what kind of program except
it's something security related.  Pictures of people I am guessing.

John W. Colby 
www.ColbyConsulting.com

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Jim
Lawrence (AccessD)
Sent: Friday, June 18, 2004 1:16 AM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Getting pictures into a blob in SQL Server


Hi John:

What type of program is it anyway? Once the graphics have been embedded they
can be difficult to extact again. Depending on the embedding method, a
Access DB can be completely swamped before you can say over-the-2-GB-limit.
I had a corrupted MDB that had to have the embedded graphics files released
and the patient made a complete recovery. It was not a difficult procedure
but the extraction program ran for almost sixteen hours.

Jim

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of jwcolby
Sent: Thursday, June 17, 2004 1:56 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Getting pictures into a blob in SQL Server


Unfortunately the program the gentleman purchased embeds them in the db.  He
contacted them and they said they would not change that so...

John W. Colby
www.ColbyConsulting.com

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Jim
Lawrence (AccessD)
Sent: Thursday, June 17, 2004 11:32 AM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Getting pictures into a blob in SQL Server


Hi John:

Access or SQL (Oracle for that matter) bloat and display (extract) too
slowly. The fastest method that handles imbedded graphic files is using ADO
stream method. (If you are interested I will post the code.)

The only really good method, that avoids bloat and is by far the fastest, is
to store the graphic file externally and just uses the tables to track the
file locations.

HTH
Jim


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of jwcolby
Sent: Thursday, June 17, 2004 5:56 AM
To: SQLServer; 'Access Developers discussion and problem solving'
Subject: [dba-SQLServer] Getting pictures into a blob in SQL Server


I got a call from someone yesterday needing to get 25000 pictures into a
blob field in SQL Server.  The program he is attempting to use apparently
stores the pictures it uses in such a field.  These pictures are currently
stored as GIFs (I believe) on the hard drive.

I can write a program to cycle through a dir on the disk, but would I just
read the text into a string and dump it into the field, save and move on?
Has anyone ever done this?

I included AccessD in this request as I am guessing I'll just do it through
VBA in AccessD.

John W. Colby
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 Clay.Passick at minneapolis.edu  Fri Jun 18 19:05:37 2004
From: Clay.Passick at minneapolis.edu (Clay Passick)
Date: Fri, 18 Jun 2004 19:05:37 -0500
Subject: [dba-SQLServer] Getting pictures into a blob in SQL Server
Message-ID: <s0d33d16.073@mail.mctc.mnscu.edu>

I am out of the office until Monday, June 28..   I will get back to you
as soon as possible upon my return.    If you need immediate assistance
please contact the Help Desk at 612-659-6600 or helpdesk at mctc.mnscu.edu.
 

				Clay


From accessd at shaw.ca  Fri Jun 18 20:20:16 2004
From: accessd at shaw.ca (Jim Lawrence (AccessD))
Date: Fri, 18 Jun 2004 18:20:16 -0700
Subject: [dba-SQLServer] Getting pictures into a blob in SQL Server
In-Reply-To: <002401c45591$0a1edc30$0501a8c0@colbyws>
Message-ID: <FJEJLIPOMCGJALMGLLLICENACDAA.accessd@shaw.ca>

Hi John:

The application I was using, with the previously mentioned method of
handling pictures was a worker registration and investigation system, for
the government. The security handling was considered sufficient but there
was no external access and the pictures without detail mean nothing.

If you need any code snippets on a specific subject just ask.

HTH
Jim

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of jwcolby
Sent: Friday, June 18, 2004 5:05 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Getting pictures into a blob in SQL Server


This is going into SQL Server.  And I'm not sure what kind of program except
it's something security related.  Pictures of people I am guessing.

John W. Colby
www.ColbyConsulting.com

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Jim
Lawrence (AccessD)
Sent: Friday, June 18, 2004 1:16 AM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Getting pictures into a blob in SQL Server


Hi John:

What type of program is it anyway? Once the graphics have been embedded they
can be difficult to extact again. Depending on the embedding method, a
Access DB can be completely swamped before you can say over-the-2-GB-limit.
I had a corrupted MDB that had to have the embedded graphics files released
and the patient made a complete recovery. It was not a difficult procedure
but the extraction program ran for almost sixteen hours.

Jim

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of jwcolby
Sent: Thursday, June 17, 2004 1:56 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Getting pictures into a blob in SQL Server


Unfortunately the program the gentleman purchased embeds them in the db.  He
contacted them and they said they would not change that so...

John W. Colby
www.ColbyConsulting.com

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Jim
Lawrence (AccessD)
Sent: Thursday, June 17, 2004 11:32 AM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Getting pictures into a blob in SQL Server


Hi John:

Access or SQL (Oracle for that matter) bloat and display (extract) too
slowly. The fastest method that handles imbedded graphic files is using ADO
stream method. (If you are interested I will post the code.)

The only really good method, that avoids bloat and is by far the fastest, is
to store the graphic file externally and just uses the tables to track the
file locations.

HTH
Jim


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of jwcolby
Sent: Thursday, June 17, 2004 5:56 AM
To: SQLServer; 'Access Developers discussion and problem solving'
Subject: [dba-SQLServer] Getting pictures into a blob in SQL Server


I got a call from someone yesterday needing to get 25000 pictures into a
blob field in SQL Server.  The program he is attempting to use apparently
stores the pictures it uses in such a field.  These pictures are currently
stored as GIFs (I believe) on the hard drive.

I can write a program to cycle through a dir on the disk, but would I just
read the text into a string and dump it into the field, save and move on?
Has anyone ever done this?

I included AccessD in this request as I am guessing I'll just do it through
VBA in AccessD.

John W. Colby
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




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



From martyconnelly at shaw.ca  Sat Jun 19 16:53:29 2004
From: martyconnelly at shaw.ca (MartyConnelly)
Date: Sat, 19 Jun 2004 14:53:29 -0700
Subject: [dba-SQLServer] Getting pictures into a blob in SQL Server
References: <FJEJLIPOMCGJALMGLLLICENACDAA.accessd@shaw.ca>
Message-ID: <40D4B5D9.9080103@shaw.ca>

Here is a complete VB project that puts pictures into Access OLE Fields 
(non-embeded), heck you could put xml files in here, using get chunk 
methods.
It would be same to SQL Blob fields.
Store then Retrieve a File from a Jet Database Field - October 2000
http://www.buygold.net/tips/

Jim Lawrence (AccessD) wrote:

>Hi John:
>
>The application I was using, with the previously mentioned method of
>handling pictures was a worker registration and investigation system, for
>the government. The security handling was considered sufficient but there
>was no external access and the pictures without detail mean nothing.
>
>If you need any code snippets on a specific subject just ask.
>
>HTH
>Jim
>
>-----Original Message-----
>From: dba-sqlserver-bounces at databaseadvisors.com
>[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of jwcolby
>Sent: Friday, June 18, 2004 5:05 PM
>To: dba-sqlserver at databaseadvisors.com
>Subject: RE: [dba-SQLServer] Getting pictures into a blob in SQL Server
>
>
>This is going into SQL Server.  And I'm not sure what kind of program except
>it's something security related.  Pictures of people I am guessing.
>
>John W. Colby
>www.ColbyConsulting.com
>
>-----Original Message-----
>From: dba-sqlserver-bounces at databaseadvisors.com
>[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Jim
>Lawrence (AccessD)
>Sent: Friday, June 18, 2004 1:16 AM
>To: dba-sqlserver at databaseadvisors.com
>Subject: RE: [dba-SQLServer] Getting pictures into a blob in SQL Server
>
>
>Hi John:
>
>What type of program is it anyway? Once the graphics have been embedded they
>can be difficult to extact again. Depending on the embedding method, a
>Access DB can be completely swamped before you can say over-the-2-GB-limit.
>I had a corrupted MDB that had to have the embedded graphics files released
>and the patient made a complete recovery. It was not a difficult procedure
>but the extraction program ran for almost sixteen hours.
>
>Jim
>
>-----Original Message-----
>From: dba-sqlserver-bounces at databaseadvisors.com
>[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of jwcolby
>Sent: Thursday, June 17, 2004 1:56 PM
>To: dba-sqlserver at databaseadvisors.com
>Subject: RE: [dba-SQLServer] Getting pictures into a blob in SQL Server
>
>
>Unfortunately the program the gentleman purchased embeds them in the db.  He
>contacted them and they said they would not change that so...
>
>John W. Colby
>www.ColbyConsulting.com
>
>-----Original Message-----
>From: dba-sqlserver-bounces at databaseadvisors.com
>[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Jim
>Lawrence (AccessD)
>Sent: Thursday, June 17, 2004 11:32 AM
>To: dba-sqlserver at databaseadvisors.com
>Subject: RE: [dba-SQLServer] Getting pictures into a blob in SQL Server
>
>
>Hi John:
>
>Access or SQL (Oracle for that matter) bloat and display (extract) too
>slowly. The fastest method that handles imbedded graphic files is using ADO
>stream method. (If you are interested I will post the code.)
>
>The only really good method, that avoids bloat and is by far the fastest, is
>to store the graphic file externally and just uses the tables to track the
>file locations.
>
>HTH
>Jim
>
>
>-----Original Message-----
>From: dba-sqlserver-bounces at databaseadvisors.com
>[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of jwcolby
>Sent: Thursday, June 17, 2004 5:56 AM
>To: SQLServer; 'Access Developers discussion and problem solving'
>Subject: [dba-SQLServer] Getting pictures into a blob in SQL Server
>
>
>I got a call from someone yesterday needing to get 25000 pictures into a
>blob field in SQL Server.  The program he is attempting to use apparently
>stores the pictures it uses in such a field.  These pictures are currently
>stored as GIFs (I believe) on the hard drive.
>
>I can write a program to cycle through a dir on the disk, but would I just
>read the text into a string and dump it into the field, save and move on?
>Has anyone ever done this?
>
>I included AccessD in this request as I am guessing I'll just do it through
>VBA in AccessD.
>
>John W. Colby
>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
>
>
>
>
>_______________________________________________
>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
>
>
>  
>

-- 
Marty Connelly
Victoria, B.C.
Canada





From chizotz at mchsi.com  Mon Jun 21 17:43:13 2004
From: chizotz at mchsi.com (Ron Allen)
Date: Mon, 21 Jun 2004 17:43:13 -0500
Subject: [dba-SQLServer] SQL Server 2000 Developer Edition
In-Reply-To: <002401c45591$0a1edc30$0501a8c0@colbyws>
References: <FJEJLIPOMCGJALMGLLLICEMJCDAA.accessd@shaw.ca>
	<002401c45591$0a1edc30$0501a8c0@colbyws>
Message-ID: <1928050335.20040621174313@mchsi.com>

Does anyone have any experience with this? It's about $50 on
Amazon. The Microsoft web page says that it is compatible with Windows
XP, but the Amazon specs say no and one review said no. Who to
believe? Also, does anyone know if this includes the Query Analyzer,
Enterprise Manager, and visual DTS tools? That's what I would be
buying it for, mostly. Amazon says "get a taste of SQL Server
Enterprise before buying it", but I can't seem to find a list of the
"restrictions" on this edition. Any information appreciated.

Ron




From my.lists at verizon.net  Mon Jun 21 17:58:55 2004
From: my.lists at verizon.net (Francisco H Tapia)
Date: Mon, 21 Jun 2004 15:58:55 -0700
Subject: [dba-SQLServer] SQL Server 2000 Developer Edition
In-Reply-To: <1928050335.20040621174313@mchsi.com>
References: <FJEJLIPOMCGJALMGLLLICEMJCDAA.accessd@shaw.ca>	<002401c45591$0a1edc30$0501a8c0@colbyws>
	<1928050335.20040621174313@mchsi.com>
Message-ID: <40D7682F.8030309@verizon.net>

AFAIK, the Developer edition is $50 bucks plain n simple you should be 
able to purchase it at this price straight from MS, and yes it does have 
EM and QA.

Ron Allen wrote On 6/21/2004 3:43 PM:

>Does anyone have any experience with this? It's about $50 on
>Amazon. The Microsoft web page says that it is compatible with Windows
>XP, but the Amazon specs say no and one review said no. Who to
>believe? Also, does anyone know if this includes the Query Analyzer,
>Enterprise Manager, and visual DTS tools? That's what I would be
>buying it for, mostly. Amazon says "get a taste of SQL Server
>Enterprise before buying it", but I can't seem to find a list of the
>"restrictions" on this edition. Any information appreciated.
>
>Ron
>  
>
-- 
-Francisco




From cfoust at infostatsystems.com  Mon Jun 21 18:05:39 2004
From: cfoust at infostatsystems.com (Charlotte Foust)
Date: Mon, 21 Jun 2004 16:05:39 -0700
Subject: [dba-SQLServer] SQL Server 2000 Developer Edition
Message-ID: <E61FC1D4B1918244905B113C680BEA86312892@infoserver01.infostat.local>

Developer Edition is what comes with Office XP Developer, and I have
installed it on WinXP and Win2k without problems.  You do need to patch
it with the latest SQL 2000 service pack, of course.  Yes, it does have
the tools.  As far as I've ever been able to tell, it works perfectly
well but only on a local machine.  I've had no problems restoring a
device to get a backup from a server restored to my own laptop.

Charlotte Foust

-----Original Message-----
From: Ron Allen [mailto:chizotz at mchsi.com] 
Sent: Monday, June 21, 2004 2:43 PM
To: dba-sqlserver at databaseadvisors.com
Subject: [dba-SQLServer] SQL Server 2000 Developer Edition


Does anyone have any experience with this? It's about $50 on Amazon. The
Microsoft web page says that it is compatible with Windows XP, but the
Amazon specs say no and one review said no. Who to believe? Also, does
anyone know if this includes the Query Analyzer, Enterprise Manager, and
visual DTS tools? That's what I would be buying it for, mostly. Amazon
says "get a taste of SQL Server Enterprise before buying it", but I
can't seem to find a list of the "restrictions" on this edition. Any
information appreciated.

Ron


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



From chizotz at mchsi.com  Mon Jun 21 19:44:08 2004
From: chizotz at mchsi.com (Ron Allen)
Date: Mon, 21 Jun 2004 19:44:08 -0500
Subject: [dba-SQLServer] SQL Server 2000 Developer Edition
In-Reply-To: <40D7682F.8030309@verizon.net>
References: <FJEJLIPOMCGJALMGLLLICEMJCDAA.accessd@shaw.ca>
	<002401c45591$0a1edc30$0501a8c0@colbyws>
	<1928050335.20040621174313@mchsi.com>
	<40D7682F.8030309@verizon.net>
Message-ID: <19110333965.20040621194408@mchsi.com>

Hello Francisco,

Thanks for the information.

Yeah, I realize that isn't a discount. Sometimes Amazon is pretty good, other
times not quite as good.

Ron


Monday, June 21, 2004, 5:58:55 PM, you wrote:
FHT> AFAIK, the Developer edition is $50 bucks plain n simple you should be
FHT> able to purchase it at this price straight from MS, and yes it does have
FHT> EM and QA.




From chizotz at mchsi.com  Mon Jun 21 19:44:43 2004
From: chizotz at mchsi.com (Ron Allen)
Date: Mon, 21 Jun 2004 19:44:43 -0500
Subject: [dba-SQLServer] SQL Server 2000 Developer Edition
In-Reply-To: <E61FC1D4B1918244905B113C680BEA86312892@infoserver01.infostat.local>
References: <E61FC1D4B1918244905B113C680BEA86312892@infoserver01.infostat.local>
Message-ID: <178468692.20040621194443@mchsi.com>

Hello Charlotte,

Thanks! That's what I needed to know. I'm going to give it a try.

Ron



Monday, June 21, 2004, 6:05:39 PM, you wrote:
CF> Developer Edition is what comes with Office XP Developer, and I have
CF> installed it on WinXP and Win2k without problems.  You do need to patch
CF> it with the latest SQL 2000 service pack, of course.  Yes, it does have
CF> the tools.  As far as I've ever been able to tell, it works perfectly
CF> well but only on a local machine.  I've had no problems restoring a
CF> device to get a backup from a server restored to my own laptop.




From rl_stewart at highstream.net  Tue Jun 22 12:44:15 2004
From: rl_stewart at highstream.net (Robert L. Stewart)
Date: Tue, 22 Jun 2004 12:44:15 -0500
Subject: [dba-SQLServer] Re: SQL Server 2000 Developer Edition
In-Reply-To: <200406221700.i5MH0kQ29094@databaseadvisors.com>
Message-ID: <5.1.0.14.2.20040622123850.017d4c28@pop3.highstream.net>

Ron,

It has all the tools, plus you can register other SQL servers (MSDE and 
full) in the tools and administer them also.  DTS is fully functional.

The limit is something like 10 connections (not 10 users).  There are some 
features that would be available in the full versions, like SQL Agent for 
scheduling tasks, but you will not need to worry about them for development 
purposes.

I have my SIG (Special interest group) members that I teach use it for all 
the samples and learning for the group.  It works fine on Win 2000, XP Pro 
(Not sure about home), and 2003.

Robert

At 12:00 PM 22/06/2004 -0500, you wrote:
>Date: Mon, 21 Jun 2004 17:43:13 -0500
>From: Ron Allen <chizotz at mchsi.com>
>Subject: [dba-SQLServer] SQL Server 2000 Developer Edition
>To: dba-sqlserver at databaseadvisors.com
>Message-ID: <1928050335.20040621174313 at mchsi.com>
>Content-Type: text/plain; charset=us-ascii
>
>Does anyone have any experience with this? It's about $50 on
>Amazon. The Microsoft web page says that it is compatible with Windows
>XP, but the Amazon specs say no and one review said no. Who to
>believe? Also, does anyone know if this includes the Query Analyzer,
>Enterprise Manager, and visual DTS tools? That's what I would be
>buying it for, mostly. Amazon says "get a taste of SQL Server
>Enterprise before buying it", but I can't seem to find a list of the
>"restrictions" on this edition. Any information appreciated.
>
>Ron




From sqlserver667 at yahoo.com  Wed Jun 23 02:23:31 2004
From: sqlserver667 at yahoo.com (S D)
Date: Wed, 23 Jun 2004 00:23:31 -0700 (PDT)
Subject: [dba-SQLServer] 'manipulate' DTS package outcome
Message-ID: <20040623072331.43623.qmail@web53310.mail.yahoo.com>

Hi group,

I've got a dts package in SQL Server2K.
All steps are linked via Workflow.
Somewhere an Excel sheet is filled using a query. If
the query doesn't return any data (very often) the DTS
package 'flows' to the failed workflow.

Is it possible to change the outcome of the DTS
package to Success?

If not, how can I catch the error (no data found) and
make the the outcome of the DTS package to Success?

If you need more data please ask me for it.

TIA

Sander


	
		
__________________________________
Do you Yahoo!?
New and Improved Yahoo! Mail - 100MB free storage!
http://promotions.yahoo.com/new_mail 


From sqlserver667 at yahoo.com  Wed Jun 23 02:29:12 2004
From: sqlserver667 at yahoo.com (S D)
Date: Wed, 23 Jun 2004 00:29:12 -0700 (PDT)
Subject: [dba-SQLServer] DTS question
In-Reply-To: <NEBBIILOPOPJBCLJIJHHOEPAFIAA.michael.broesdorf@web.de>
Message-ID: <20040623072912.28970.qmail@web53304.mail.yahoo.com>

Hi,

I'm not sure if it's clear now but:
Client side => if you start a DTS package via EM the
DTS runs on the client
Server side => if you SCHEDULE a DTS package then the
DTS runs on the server!

Very easy to test: try reading/exporting to/from a
file on the server. If you start the dts via EM
Execute Package it cannot find the file!

HTH

Sander
--- Michael_Brosdorf <michael.broesdorf at web.de> wrote:
> Thank your for the insight!
> If I have the time during the week I will use SQL
> Profile to find out what
> happens with
> data transfer tasks.
> 
> Michael
> 
> -----Ursprungliche Nachricht-----
> Von: dba-sqlserver-bounces at databaseadvisors.com
>
[mailto:dba-sqlserver-bounces at databaseadvisors.com]Im
> Auftrag von Mike &
> Doris Manning
> Gesendet: Montag, 7. Juni 2004 11:57
> An: dba-sqlserver at databaseadvisors.com
> Betreff: RE: [dba-SQLServer] DTS question
> 
> 
> If you are using EM on a client machine, then the
> DTS package is executing
> on the client machine and not the server.  I
> discovered this because I have
> some packages that open an Access database and
> process a report.  The
> packages fail if I'm not on the server itself
> because I hardcode the path to
> the database using the server's drive mappings.
> 
> I believe that SQL contained in an Execute SQL Task
> is sent the server and
> processed there just like any other sproc or view. 
> I believe a Transfer
> Data Task is reading all the data over the network
> to the client and then
> being processed.
> 
> If my beliefs are incorrect, someone please speak up
> because I'd be very
> happy to be corrected on this.
> 
> Doris Manning
> Database Administrator
> Hargrove Inc.
> www.hargroveinc.com
> 
> 
> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com]
> On Behalf Of Michael
> Brosdorf
> Sent: Monday, June 07, 2004 4:29 AM
> To: dba-sqlserver at databaseadvisors.com
> Subject: AW: [dba-SQLServer] DTS question
> 
> 
> Does that mean that the SQL contained in an Execute
> SQL Task is sent to the
> server and processed there? How about Transfer Data
> Tasks? Is all data read
> over the network to the client machine?
> 
> Michael
> 
> -----Ursprungliche Nachricht-----
> Von: dba-sqlserver-bounces at databaseadvisors.com
>
[mailto:dba-sqlserver-bounces at databaseadvisors.com]Im
> Auftrag von Mike &
> Doris Manning
> Gesendet: Donnerstag, 3. Juni 2004 13:11
> An: dba-sqlserver at databaseadvisors.com
> Betreff: RE: [dba-SQLServer] DTS question
> 
> 
> DTS packages run on the machine where you use EM. 
> Basically they make
> activity requests of SQL Server just as if you were
> asking it to run a
> stored procedure or view.
> 
> The only time I have noticed it making a difference
> where the DTS package
> was run from is in the case of a process that needs
> to use a file in a
> particular drive.
> 
> Doris Manning
> Database Administrator
> Hargrove Inc.
> www.hargroveinc.com
> 
> 
> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com]
> On Behalf Of Michael
> Brosdorf
> Sent: Thursday, June 03, 2004 3:45 AM
> To: dba-sqlserver at databaseadvisors.com
> Subject: [dba-SQLServer] DTS question
> 
> 
> Hi all
> 
> I am a little confused about where exactly DTS
> packages run.
> 
> Do they run on the SQL Server machine or do they run
> on the machine where I
> use EM? And does it make a difference, if I use EM
> or call the packages from
> within my Access FE (using the DTS Package library)?
> 
> 
> Michael
> 
> 
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
>
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
> 
> 
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
>
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
> 
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
>
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
> 
> 
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
>
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
> 
> _______________________________________________
> dba-SQLServer mailing list
> dba-SQLServer at databaseadvisors.com
>
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
> http://www.databaseadvisors.com
> 



		
__________________________________
Do you Yahoo!?
Yahoo! Mail - 50x more storage than other providers!
http://promotions.yahoo.com/new_mail


From artful at rogers.com  Thu Jun 24 14:52:36 2004
From: artful at rogers.com (Arthur Fuller)
Date: Thu, 24 Jun 2004 15:52:36 -0400
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <000801c44f29$63ef0a00$b274d0d5@minster33c3r25>
Message-ID: <092301c45a24$cc6b40c0$6601a8c0@rock>

I think I wrote it in an earlier message, but lest you missed it...

Dynamic SQL is NOT the way to go once you port to SQL Server. You need
to rethink all these parts of your app and replace them with sprocs that
can handle all the parms you might pass to your SQL-construction code.

I have a simple and foolproof way of translating this stuff into good
SQL, but it's a forthcoming tip at SQL Tips at builder.com, so if I tell
you now I'll have to kill you. Sorry. But I will give you a hint:

Test the parms against themselves, i.e. WHERE ColumnOfInterest = @parm1
OR @parm1 IS NULL.

That's all I can tell you before the piece is published. Sorry if that's
not enough.

Arthur

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Andy
Lacey
Sent: Thursday, June 10, 2004 4:28 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


But, Francisco, if I was porting to SQL Server my Access app which
builds SELECT statements dynamically all of the time for many and
various situations are you saying I couldn't, or shouldn't or something?

-- Andy Lacey
http://www.minstersystems.co.uk 

> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf 
> Of Francisco H Tapia
> Sent: 10 June 2004 20:58
> To: dba-sqlserver at databaseadvisors.com
> Subject: Re: [dba-SQLServer] Difference between views and queries
> 
> 
> jwcolby wrote On 6/10/2004 9:33 AM:
> 
> >Can anyone explain the difference between a view and a query?  Views
> >use a query, plus the view keyword.  I have a couple of books that I 
> >have read the chapter on Views, but I so far haven't managed 
> to "get"
> >why you wouldn't just use the query itself instead of
> turning it into a
> >view.
> >  
> >
> A query is a request for an Access Database, however for Sql
> Server you 
> would either use a View or Stored Procedure to return the data you 
> wanted... you are also able to use dynamic SQL to retrieve the 
> information you need.  ANY request given to the SQL Server engine is 
> managed by the engine, unless you are running Remote servers (iirc).
> 
> In Sql Server, it is TABOO, nay, GENERALLY bad practice to
> use dynamic 
> sql because of the implication of SQL INJECTION attacks, this poses a 
> "real" security threat to your database. and your server.
> 
> another reason to use a VIEW over dynamic sql is that it is
> pre-optimized by the SQL Server Engine and thus runs faster and more 
> efficient.  Additionally if you use Dynamic SQL then your individual 
> users who access the server will need EXPLICIT "SELECT" 
> permissions by 
> you, which is another 'bad' practice.  In SQL Server you make data 
> available to your users via VIEWs and Stored Procedures or some other 
> secure way in order to protect your tables and it's data.
> 
> ya get wot I mean?
> 
> --
> -Francisco
> 
> 
> _______________________________________________
> 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 artful at rogers.com  Thu Jun 24 14:56:52 2004
From: artful at rogers.com (Arthur Fuller)
Date: Thu, 24 Jun 2004 15:56:52 -0400
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <000a01c44fa8$a59ac460$0501a8c0@colbyws>
Message-ID: <092501c45a25$652a5760$6601a8c0@rock>

Exactly, with the small exception that Access stored queries can invoke
Access UDFs... Which may require serious rethinking to get the same
behaviour in views. Alternatively, you can write SQL UDFs which return
tables, and then you can do anything you want with said return values
(tables), such as join.

Arthur

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Friday, June 11, 2004 7:39 AM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


I think the answer to my question is that views ARE what we in Access
think of as stored queries.

John W. Colby 
www.ColbyConsulting.com

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Jim
Lawrence (AccessD)
Sent: Thursday, June 10, 2004 3:07 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


Hi John:

Personally, I see little reason to run views as their creation is
spawned at the server side and any hit on the server I try to avoid. The
concept of distributive computing has always appealed to me. Queries,
run at the client side.

There might be better performance with views, if there are limited
people accessing the server. Views limit, not that the client can see it
anyway, access to/display of the real table and present a pseudo table.
Security?

HTH
Jim

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of jwcolby
Sent: Thursday, June 10, 2004 9:33 AM
To: SQLServer
Subject: [dba-SQLServer] Difference between views and queries


Can anyone explain the difference between a view and a query?  Views use
a query, plus the view keyword.  I have a couple of books that I have
read the chapter on Views, but I so far haven't managed to "get" why you
wouldn't just use the query itself instead of turning it into a view.


John W. Colby
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 artful at rogers.com  Thu Jun 24 15:04:37 2004
From: artful at rogers.com (Arthur Fuller)
Date: Thu, 24 Jun 2004 16:04:37 -0400
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <7B1961ED924D1A459E378C9B1BB22B4C02485089@natexch.jenkens.com>
Message-ID: <092801c45a26$7a23f350$6601a8c0@rock>

Excellent point, Debbie. And in case it's not clear to readers of this
list, let me emphasize it:

NO users except sa (and possibly developers) should have access to any
SQL table. Everything should be done with views or sprocs or UDFs. No
exceptions. 

Access to said objects should be governed by roles, and users should be
assigned to roles; this can be done additively. I.e. suppose you have 3
levels of access, a, b and c. Everyone in level B can do everything that
everyone in level A can. So just role B as a user in level A; then you
"inherit" everything permitted for level A. Similarly, add role C as a
user in level B, and inherit both B and A. This is a simplistic example;
it may arise in the real world that level C should be able to do
anything A can but nothing that B can. In that case it's a little more
difficult, but the underlying principle is the same. IMO, as always, and
I could be wrong, and it wouldn't be the first time.

Arthur

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Elam,
Debbie
Sent: Friday, June 11, 2004 9:13 AM
To: 'dba-sqlserver at databaseadvisors.com'
Subject: RE: [dba-SQLServer] Difference between views and queries


Just the opposite, I have always tried to harness the greater computing
power on the server and drag less data across the wire which is a
performance plus.  Views also have security independent of tables.  I
have a much better control of what data is editable and when by what
view I use.

Debbie

-----Original Message-----
From: Jim Lawrence (AccessD) [mailto:accessd at shaw.ca] 
Sent: Thursday, June 10, 2004 2:07 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


Hi John:

Personally, I see little reason to run views as their creation is
spawned at the server side and any hit on the server I try to avoid. The
concept of distributive computing has always appealed to me. Queries,
run at the client side.

There might be better performance with views, if there are limited
people accessing the server. Views limit, not that the client can see it
anyway, access to/display of the real table and present a pseudo table.
Security?

HTH
Jim

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of jwcolby
Sent: Thursday, June 10, 2004 9:33 AM
To: SQLServer
Subject: [dba-SQLServer] Difference between views and queries


Can anyone explain the difference between a view and a query?  Views use
a query, plus the view keyword.  I have a couple of books that I have
read the chapter on Views, but I so far haven't managed to "get" why you
wouldn't just use the query itself instead of turning it into a view.


John W. Colby
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
- JENKENS & GILCHRIST E-MAIL NOTICE - This transmission may be: (1)
subject to the Attorney-Client Privilege, (2) an attorney work product,
or (3) strictly confidential. If you are not the intended recipient of
this message, you may not disclose, print, copy or disseminate this
information. If you have received this in error, please reply and notify
the sender
(only) and delete the message. Unauthorized interception of this e-mail
is a violation of federal criminal law. 
This communication does not reflect an intention by the sender or the
sender's client or principal to conduct a transaction or make any
agreement by electronic means.  Nothing contained in this message or in
any attachment shall satisfy the requirements for a writing, and nothing
contained herein shall constitute a contract or electronic signature
under the Electronic Signatures in Global and National Commerce Act, any
version of the Uniform Electronic Transactions Act or any other statute
governing electronic transactions.
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com



From artful at rogers.com  Thu Jun 24 15:17:56 2004
From: artful at rogers.com (Arthur Fuller)
Date: Thu, 24 Jun 2004 16:17:56 -0400
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <FJEJLIPOMCGJALMGLLLIKEJECDAA.accessd@shaw.ca>
Message-ID: <093201c45a28$56797a90$6601a8c0@rock>

We have serious differences of opinion here, Jim.

1. I have experimented with bound and unbound forms against SQL Server
and I firmly dispute MS's recommendation that bound forms should not be
used. I have several "major" apps running using bound forms and we're
experiencing no problems at all.

2. In a SQL environment, the concept "bound" is not quite the same as in
Access. For example, I could have a form bound to a multi-table view
(which is therefore not updateable), but that simply means that I write
some code to perform the multi-table updates. It's still a bound form.

3. I have complete control over every piece of data displayed in a bound
form. All I need to to is create the underlying view/sproc/UDF which for
example retrieves all the relevant fields from all the related tables,
then present them. This is a no-brainer once you understand how Access
will deal with it. You can create a very complex view and then AutoForm
it, and then add the update/insert code you need. Not as simple as a
one-table bound form talking to an Access table, but almost as simple.

4. Before concluding that the methods above were better than the
MS-recommended strategy, I did some benchmarks. I used a class-based
approach (i.e. a class with Get and Put methods). The performance
difference was significant. Once I saw this difference, I decided to put
my head against the grinder and deal with the issues of bound forms.
They're not perfect. Nothing is. But IMO they are WAY better than
unbound forms. It all depends on what you bind them to.

Arthur

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Jim
Lawrence (AccessD)
Sent: Friday, June 11, 2004 2:08 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


Joe:

You should know better than ask that question. It sort of stirs up
things. The following are my personnel guide-lines but they can be
changed but there has to be a very good reason.

1. Bound forms can be used on small Access projects but never on
anything major.

There are a host of pluses and minus on both side.

Facts as I see them:

Bound forms are much easier to implement. The existing operating system
handles access to records, locking, updates while multiple people are
working on a single record, populating the forms, sub-forms etc. When
there are a small number of people accessing a simple MDB database, for
example, performance can be superior.

Unbound forms are harder to implement...properly. All the above
benefits, you as the programmer, must provide. It takes longer to
implement and test. There are a whole range of programming issues that
have to be addressed. It is not for the faint-of-heart or first time
developers.

On the plus side of unbound forms, is that you now have complete control
over every piece of data that is displayed on the form or stored in the
database.

1. You can provide an extensive set of business rules, on just a single
field, if required. 2. Now that you control the data-access layer,
multiple data sources can be accessed and easily integrated. For
example; you can be using a SQL, Oracle and MDB data sources
simultaneously. 3. Data access can be merged deep within your code, so
as to provide a layer of security. (That is one of the reasons I do not
like ODBC connection because they can be easily used by any skilled
client, to gain direct access to protected data sources and because they
are exposed and not imbedded in your code.) 4. Much of the issues around
record-locking, multi-user and the potential data over-writing are
managed through the bigger data engines like SQL and Oracle. It is your
responsibility to use proper transaction controls, monitor return codes
and take appropriate actions. 5. With you now managing the data
connections, remote sites with unstable or slow access, can be carefully
handled, with virtual no data loss or database corruption. 6. Because
you now precisely handle data access, only the specific data sets
required, to populate the current form and sub-forms, are extracted.
Static data for controls can be pulled once at the beginning of a
session and not as each record is accessed. When it comes to the major
sequel databases, the raw data can be extracted, at the server end
through, Stored Procedure and functions calls. To provide better
performance the raw data can then, at the client side, be grouped and
sorted which in some cases will provide up to a seventy percent
performance boost. (Distributive computing). 7. Complete access control
of the data can leverage a small SQL system. For example; given a SQL
DB, only licensed with a dozen connections, sixty plus people can have,
as far as they are concerned, full access. More bang for the buck.

In summary, the downside is that it requires a lot more work to
implement an unbound database, internal documentation and structured
code lay-out has to be very carefully done. I can not stress tidiness
and organization enough. Consider someone who has to go back in to
update the code, that someone might be you.

The upside, is that you, as a programmer, have absolute control, garner
superior performance (on larger systems), better stability and much
better security.

This is my quarter's worth, thank you
Jim


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of Joe
Rojas
Sent: Friday, June 11, 2004 5:38 AM
To: 'dba-sqlserver at databaseadvisors.com'
Subject: RE: [dba-SQLServer] Difference between views and queries


Hi Jim,

What is the argument for not using bound forms?

JR

-----Original Message-----
From: Jim Lawrence (AccessD) [mailto:accessd at shaw.ca]
Sent: Thursday, June 10, 2004 6:46 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries

Hi All:

As to all these issues I would like to dump some of my own comments. At
the risk of saying 'I told you so', I firmly believe that users should:

1. Always (or should I say only), use windows authentication and
judiciously distribute security access, to your SQLxx, to only those who
need it. Appropriate passwords and time limits. 1. Never allow access to
the data except through your program. That means NO to ODBC drivers only
ADO-OLE. 2. In 99% of cases, control is handled through SPs. 3. And the
biggy never, never use bound forms to access SQLxx data. I have been
whining about that for years, a position that M$ has also fully
supported. 4. You, as the programmer, should design your program to
carefully validate all requests and data before they are posted.

I may be already talking to the converted so you can ignore this; if
not..Get on the program.

Seeing we at in the midst of an election campaign, a good stump,
political speech is the expected. Jim


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of
Francisco H Tapia
Sent: Thursday, June 10, 2004 1:55 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Difference between views and queries


Andy,
  SQL Server is not Access on steriods, it's a diffrent engine, and thus
requires a new level of thinking towards your database engine.  It's NOT
that you couldn't, you can do anything, heck if you wanted to you can
set up your SQL Server with a blank SA password or SA as the password.
For all that matters, and avoiding all SQL Server authentication, just
use NT authentication and enable guest users :).

There have been quite a few white papers circulating on why you
"wouldn't" use dynamic sql w/ your sql server (check out
www.sqlservercentral.com, a fine resource) but the 2 very critical
factors include performance and also quite possible damage to your data.

It is entirely possible for your sql statement to read in this manner,
lets's say that you are Selecting Data from a table and you have a
combobox to help choose data, so your SQL Statment looks like this:

"Select CompanyName, CompanyAttribute1, pKey FROM tblCompany WHERE
CompanyAttribute1 = '" & me.cboMyBOX & "'", If I was a malicious user on
your system and I have direct access to tables, and if you're doing
statements like the above it is entirely plausible that you also have
"INSERT" statements thus you are giving more than just simple SELECT
access to these tables., thus with some malformed selection I can add
this in the select

'; DELETE FROM tblCompany; SELECT '

your final statement would look like this

Select CompanyName, CompanyAttribute1, pKey FROM tblCompany WHERE
CompanyAttribute1 = ''; DELETE FROM tblCompany; SELECT ''

Now your entire COMPANY table has been wiped out, while it is completely
possible to restore your db up to the minute, you've still lost some
downtime given that you had ONE bad apple in the bunch.

Besides the sql injection threats, you also suffer from a
NON-pre-compiled statement, thus your data could conceptually be
returned a lot faster if you let it, simply by creating a view or stored
procedure.  By the way just because you are using a stored procedure
does not make you completly excempt of sql injections, if you are using
dynamic sql within that procedure you are still open to these kind of
attacks and your stored procedure is always re-comiled and thus suffers
from the same performance deficits.


Andy Lacey wrote On 6/10/2004 1:27 PM:

>But, Francisco, if I was porting to SQL Server my Access app which 
>builds SELECT statements dynamically all of the time for many and 
>various situations are you saying I couldn't, or shouldn't or 
>something?
>
>-- Andy Lacey
>http://www.minstersystems.co.uk
>
>
>
>>-----Original Message-----
>>From: dba-sqlserver-bounces at databaseadvisors.com
>>[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of 
>>Francisco H Tapia
>>Sent: 10 June 2004 20:58
>>To: dba-sqlserver at databaseadvisors.com
>>Subject: Re: [dba-SQLServer] Difference between views and queries
>>
>>
>>jwcolby wrote On 6/10/2004 9:33 AM:
>>
>>
>>
>>>Can anyone explain the difference between a view and a query?  Views 
>>>use a query, plus the view keyword.  I have a couple of books that I 
>>>have read the chapter on Views, but I so far haven't managed
>>>
>>>
>>to "get"
>>
>>
>>>why you wouldn't just use the query itself instead of
>>>
>>>
>>turning it into a
>>
>>
>>>view.
>>>
>>>
>>>
>>>
>>A query is a request for an Access Database, however for Sql Server 
>>you would either use a View or Stored Procedure to return the data you
>>wanted... you are also able to use dynamic SQL to retrieve the
>>information you need.  ANY request given to the SQL Server engine is
>>managed by the engine, unless you are running Remote servers (iirc).
>>
>>In Sql Server, it is TABOO, nay, GENERALLY bad practice to use dynamic
>>sql because of the implication of SQL INJECTION attacks, this poses a
>>"real" security threat to your database. and your server.
>>
>>another reason to use a VIEW over dynamic sql is that it is 
>>pre-optimized by the SQL Server Engine and thus runs faster and more 
>>efficient.  Additionally if you use Dynamic SQL then your individual 
>>users who access the server will need EXPLICIT "SELECT" permissions by
>>you, which is another 'bad' practice.  In SQL Server you make data
>>available to your users via VIEWs and Stored Procedures or some other
>>secure way in order to protect your tables and it's data.
>>
>>ya get wot I mean?
>>
>>--
>>-Francisco
>>
>>
>>_______________________________________________
>>dba-SQLServer mailing list
>>dba-SQLServer at databaseadvisors.com
>>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>>http://www.databaseadvisors.com
>>
>>
>>
>>
>>
>
>_______________________________________________
>dba-SQLServer mailing list
>dba-SQLServer at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>http://www.databaseadvisors.com
>
>
>
>


--
-Francisco


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

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



This electronic transmission is strictly confidential to TNCO, Inc. and
intended solely for the addressee. It may contain information which is
covered by legal, professional, or other privileges. If you are not the
intended addressee, or someone authorized by the intended addressee to
receive transmissions on behalf of the addressee, you must not retain,
disclose in any form, copy, or take any action in reliance on this
transmission. If you have received this transmission in error, please
notify the sender as soon as possible and destroy this message. While
TNCO, Inc. uses virus protection, the recipient should check this email
and any attachments for the presence of viruses. TNCO, Inc. accepts no
liability for any damage caused by any virus transmitted by this email.
_______________________________________________
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 artful at rogers.com  Thu Jun 24 15:21:00 2004
From: artful at rogers.com (Arthur Fuller)
Date: Thu, 24 Jun 2004 16:21:00 -0400
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <E61FC1D4B1918244905B113C680BEA86312867@infoserver01.infostat.local>
Message-ID: <093301c45a28$c41c30b0$6601a8c0@rock>

SQL has many FE tools, several included and many more available either
free or cheap or expensive. Included are Enterprise Manager and Query
Analyzer, to mention only two. 3P tools are too numerous to mention, so
I'll mention only 3: SQL Programmer (Sylvain Faust), PowerDesigner
(Sybase) and Erwin (Erwin). But there are many more.

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of
Charlotte Foust
Sent: Friday, June 11, 2004 3:52 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


Yes, but since SQL doesn't have it's own FE tool, we tend to wind up
talking Access.  :-}

Charlotte Foust

-----Original Message-----
From: Jim Lawrence (AccessD) [mailto:accessd at shaw.ca] 
Sent: Friday, June 11, 2004 10:59 AM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


Charlotte...I missed the word MDB.

This is the SQL list, I hope?

Jim

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of
Charlotte Foust
Sent: Friday, June 11, 2004 9:42 AM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


Right.  That's why I specified MDBs.  

Charlotte Foust

-----Original Message-----
From: Mackin, Christopher [mailto:CMackin at quiznos.com] 
Sent: Friday, June 11, 2004 7:21 AM
To: 'dba-sqlserver at databaseadvisors.com'
Subject: RE: [dba-SQLServer] Difference between views and queries


Not so for an .adp though, where you can bind a form directly to SQL
data without ODBC.

-Chris Mackin

-----Original Message-----
From: Charlotte Foust [mailto:cfoust at infostatsystems.com]
Sent: Friday, June 11, 2004 9:16 AM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


Bound forms require ODBC links to be editable.  Forms (in Access MDBs)
bound to ADO recordsets are not updatable, and ADO is the only option
that avoids ODBC links to return a recordset.

Charlotte Foust

-----Original Message-----
From: Joe Rojas [mailto:JRojas at tnco-inc.com] 
Sent: Friday, June 11, 2004 4:38 AM
To: 'dba-sqlserver at databaseadvisors.com'
Subject: RE: [dba-SQLServer] Difference between views and queries


Hi Jim,

What is the argument for not using bound forms?

JR

-----Original Message-----
From: Jim Lawrence (AccessD) [mailto:accessd at shaw.ca]
Sent: Thursday, June 10, 2004 6:46 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries

Hi All:

As to all these issues I would like to dump some of my own comments. At
the risk of saying 'I told you so', I firmly believe that users should:

1. Always (or should I say only), use windows authentication and
judiciously distribute security access, to your SQLxx, to only those who
need it. Appropriate passwords and time limits. 1. Never allow access to
the data except through your program. That means NO to ODBC drivers only
ADO-OLE. 2. In 99% of cases, control is handled through SPs. 3. And the
biggy never, never use bound forms to access SQLxx data. I have been
whining about that for years, a position that M$ has also fully
supported. 4. You, as the programmer, should design your program to
carefully validate all requests and data before they are posted.

I may be already talking to the converted so you can ignore this; if
not..Get on the program.

Seeing we at in the midst of an election campaign, a good stump,
political speech is the expected. Jim


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of
Francisco H Tapia
Sent: Thursday, June 10, 2004 1:55 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Difference between views and queries


Andy,
  SQL Server is not Access on steriods, it's a diffrent engine, and thus
requires a new level of thinking towards your database engine.  It's NOT
that you couldn't, you can do anything, heck if you wanted to you can
set up your SQL Server with a blank SA password or SA as the password.
For all that matters, and avoiding all SQL Server authentication, just
use NT authentication and enable guest users :).

There have been quite a few white papers circulating on why you
"wouldn't" use dynamic sql w/ your sql server (check out
www.sqlservercentral.com, a fine resource) but the 2 very critical
factors include performance and also quite possible damage to your data.

It is entirely possible for your sql statement to read in this manner,
lets's say that you are Selecting Data from a table and you have a
combobox to help choose data, so your SQL Statment looks like this:

"Select CompanyName, CompanyAttribute1, pKey FROM tblCompany WHERE
CompanyAttribute1 = '" & me.cboMyBOX & "'", If I was a malicious user on
your system and I have direct access to tables, and if you're doing
statements like the above it is entirely plausible that you also have
"INSERT" statements thus you are giving more than just simple SELECT
access to these tables., thus with some malformed selection I can add
this in the select

'; DELETE FROM tblCompany; SELECT '

your final statement would look like this

Select CompanyName, CompanyAttribute1, pKey FROM tblCompany WHERE
CompanyAttribute1 = ''; DELETE FROM tblCompany; SELECT ''

Now your entire COMPANY table has been wiped out, while it is completely
possible to restore your db up to the minute, you've still lost some
downtime given that you had ONE bad apple in the bunch.

Besides the sql injection threats, you also suffer from a
NON-pre-compiled statement, thus your data could conceptually be
returned a lot faster if you let it, simply by creating a view or stored
procedure.  By the way just because you are using a stored procedure
does not make you completly excempt of sql injections, if you are using
dynamic sql within that procedure you are still open to these kind of
attacks and your stored procedure is always re-comiled and thus suffers
from the same performance deficits.


Andy Lacey wrote On 6/10/2004 1:27 PM:

>But, Francisco, if I was porting to SQL Server my Access app which
>builds SELECT statements dynamically all of the time for many and 
>various situations are you saying I couldn't, or shouldn't or 
>something?
>
>-- Andy Lacey
>http://www.minstersystems.co.uk
>
>
>
>>-----Original Message-----
>>From: dba-sqlserver-bounces at databaseadvisors.com
>>[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of
>>Francisco H Tapia
>>Sent: 10 June 2004 20:58
>>To: dba-sqlserver at databaseadvisors.com
>>Subject: Re: [dba-SQLServer] Difference between views and queries
>>
>>
>>jwcolby wrote On 6/10/2004 9:33 AM:
>>
>>
>>
>>>Can anyone explain the difference between a view and a query?  Views
>>>use a query, plus the view keyword.  I have a couple of books that I 
>>>have read the chapter on Views, but I so far haven't managed
>>>
>>>
>>to "get"
>>
>>
>>>why you wouldn't just use the query itself instead of
>>>
>>>
>>turning it into a
>>
>>
>>>view.
>>>
>>>
>>>
>>>
>>A query is a request for an Access Database, however for Sql Server
>>you would either use a View or Stored Procedure to return the data you

>>wanted... you are also able to use dynamic SQL to retrieve the
>>information you need.  ANY request given to the SQL Server engine is 
>>managed by the engine, unless you are running Remote servers (iirc).
>>
>>In Sql Server, it is TABOO, nay, GENERALLY bad practice to use dynamic

>>sql because of the implication of SQL INJECTION attacks, this poses a 
>>"real" security threat to your database. and your server.
>>
>>another reason to use a VIEW over dynamic sql is that it is
>>pre-optimized by the SQL Server Engine and thus runs faster and more 
>>efficient.  Additionally if you use Dynamic SQL then your individual 
>>users who access the server will need EXPLICIT "SELECT" permissions by

>>you, which is another 'bad' practice.  In SQL Server you make data
>>available to your users via VIEWs and Stored Procedures or some other 
>>secure way in order to protect your tables and it's data.
>>
>>ya get wot I mean?
>>
>>--
>>-Francisco
>>
>>
>>_______________________________________________
>>dba-SQLServer mailing list
>>dba-SQLServer at databaseadvisors.com
>>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>>http://www.databaseadvisors.com
>>
>>
>>
>>
>>
>
>_______________________________________________
>dba-SQLServer mailing list
>dba-SQLServer at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>http://www.databaseadvisors.com
>
>
>
>


--
-Francisco


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

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



This electronic transmission is strictly confidential to TNCO, Inc. and
intended solely for the addressee. It may contain information which is
covered by legal, professional, or other privileges. If you are not the
intended addressee, or someone authorized by the intended addressee to
receive transmissions on behalf of the addressee, you must not retain,
disclose in any form, copy, or take any action in reliance on this
transmission. If you have received this transmission in error, please
notify the sender as soon as possible and destroy this message. While
TNCO, Inc. uses virus protection, the recipient should check this email
and any attachments for the presence of viruses. TNCO, Inc. accepts no
liability for any damage caused by any virus transmitted by this email.
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com

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

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

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

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



From HARVEYF1 at WESTAT.com  Thu Jun 24 15:27:59 2004
From: HARVEYF1 at WESTAT.com (Francis Harvey)
Date: Thu, 24 Jun 2004 16:27:59 -0400
Subject: [dba-SQLServer] Difference between views and queries
Message-ID: <446DDE75CFC7E1438061462F85557B0F0BFF1F@remail2.westat.com>

Arthur,

Two points:

1) Never say no exceptions. Currently, I need dynamic SQL,
and there is no comparable work around without it.

2) Permissions are not additive in that denied permissions always
take precedence. You cannot gain rights to an object by adding
adding additional roles if you have been denied rights at some
level.

Francis R Harvey III
WB 303, (301)294-3952
harveyf1 at westat.com


> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com 
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf 
> Of Arthur Fuller
> Sent: Thursday, June 24, 2004 4:05 PM
> To: dba-sqlserver at databaseadvisors.com
> Subject: RE: [dba-SQLServer] Difference between views and queries
> 
<snip>
> NO users except sa (and possibly developers) should have access to any
> SQL table. Everything should be done with views or sprocs or UDFs. No
> exceptions. 
> 
> Access to said objects should be governed by roles, and users 
> should be
> assigned to roles; this can be done additively. I.e. suppose 
> you have 3
> levels of access, a, b and c. Everyone in level B can do 
> everything that
> everyone in level A can. So just role B as a user in level A; then you
> "inherit" everything permitted for level A. Similarly, add role C as a
> user in level B, and inherit both B and A. This is a 
> simplistic example;
> it may arise in the real world that level C should be able to do
> anything A can but nothing that B can. In that case it's a little more
> difficult, but the underlying principle is the same. IMO, as 
> always, and
> I could be wrong, and it wouldn't be the first time.
> 
> Arthur
<snip>


From cfoust at infostatsystems.com  Thu Jun 24 15:32:11 2004
From: cfoust at infostatsystems.com (Charlotte Foust)
Date: Thu, 24 Jun 2004 13:32:11 -0700
Subject: [dba-SQLServer] Difference between views and queries
Message-ID: <E61FC1D4B1918244905B113C680BEA863128AA@infoserver01.infostat.local>

We aren't talking about the same kind of tools, Arthur.  I was talking
about client interface tools, not tools to manipulate SQL Server
directly.  I suppose you could consider EM an FE of sorts, but you don't
build a client interface in EM.

Charlotte Foust

-----Original Message-----
From: Arthur Fuller [mailto:artful at rogers.com] 
Sent: Thursday, June 24, 2004 12:21 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


SQL has many FE tools, several included and many more available either
free or cheap or expensive. Included are Enterprise Manager and Query
Analyzer, to mention only two. 3P tools are too numerous to mention, so
I'll mention only 3: SQL Programmer (Sylvain Faust), PowerDesigner
(Sybase) and Erwin (Erwin). But there are many more.

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of
Charlotte Foust
Sent: Friday, June 11, 2004 3:52 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


Yes, but since SQL doesn't have it's own FE tool, we tend to wind up
talking Access.  :-}

Charlotte Foust

-----Original Message-----
From: Jim Lawrence (AccessD) [mailto:accessd at shaw.ca] 
Sent: Friday, June 11, 2004 10:59 AM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


Charlotte...I missed the word MDB.

This is the SQL list, I hope?

Jim

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of
Charlotte Foust
Sent: Friday, June 11, 2004 9:42 AM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


Right.  That's why I specified MDBs.  

Charlotte Foust

-----Original Message-----
From: Mackin, Christopher [mailto:CMackin at quiznos.com] 
Sent: Friday, June 11, 2004 7:21 AM
To: 'dba-sqlserver at databaseadvisors.com'
Subject: RE: [dba-SQLServer] Difference between views and queries


Not so for an .adp though, where you can bind a form directly to SQL
data without ODBC.

-Chris Mackin

-----Original Message-----
From: Charlotte Foust [mailto:cfoust at infostatsystems.com]
Sent: Friday, June 11, 2004 9:16 AM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


Bound forms require ODBC links to be editable.  Forms (in Access MDBs)
bound to ADO recordsets are not updatable, and ADO is the only option
that avoids ODBC links to return a recordset.

Charlotte Foust

-----Original Message-----
From: Joe Rojas [mailto:JRojas at tnco-inc.com] 
Sent: Friday, June 11, 2004 4:38 AM
To: 'dba-sqlserver at databaseadvisors.com'
Subject: RE: [dba-SQLServer] Difference between views and queries


Hi Jim,

What is the argument for not using bound forms?

JR

-----Original Message-----
From: Jim Lawrence (AccessD) [mailto:accessd at shaw.ca]
Sent: Thursday, June 10, 2004 6:46 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries

Hi All:

As to all these issues I would like to dump some of my own comments. At
the risk of saying 'I told you so', I firmly believe that users should:

1. Always (or should I say only), use windows authentication and
judiciously distribute security access, to your SQLxx, to only those who
need it. Appropriate passwords and time limits. 1. Never allow access to
the data except through your program. That means NO to ODBC drivers only
ADO-OLE. 2. In 99% of cases, control is handled through SPs. 3. And the
biggy never, never use bound forms to access SQLxx data. I have been
whining about that for years, a position that M$ has also fully
supported. 4. You, as the programmer, should design your program to
carefully validate all requests and data before they are posted.

I may be already talking to the converted so you can ignore this; if
not..Get on the program.

Seeing we at in the midst of an election campaign, a good stump,
political speech is the expected. Jim


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of
Francisco H Tapia
Sent: Thursday, June 10, 2004 1:55 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Difference between views and queries


Andy,
  SQL Server is not Access on steriods, it's a diffrent engine, and thus
requires a new level of thinking towards your database engine.  It's NOT
that you couldn't, you can do anything, heck if you wanted to you can
set up your SQL Server with a blank SA password or SA as the password.
For all that matters, and avoiding all SQL Server authentication, just
use NT authentication and enable guest users :).

There have been quite a few white papers circulating on why you
"wouldn't" use dynamic sql w/ your sql server (check out
www.sqlservercentral.com, a fine resource) but the 2 very critical
factors include performance and also quite possible damage to your data.

It is entirely possible for your sql statement to read in this manner,
lets's say that you are Selecting Data from a table and you have a
combobox to help choose data, so your SQL Statment looks like this:

"Select CompanyName, CompanyAttribute1, pKey FROM tblCompany WHERE
CompanyAttribute1 = '" & me.cboMyBOX & "'", If I was a malicious user on
your system and I have direct access to tables, and if you're doing
statements like the above it is entirely plausible that you also have
"INSERT" statements thus you are giving more than just simple SELECT
access to these tables., thus with some malformed selection I can add
this in the select

'; DELETE FROM tblCompany; SELECT '

your final statement would look like this

Select CompanyName, CompanyAttribute1, pKey FROM tblCompany WHERE
CompanyAttribute1 = ''; DELETE FROM tblCompany; SELECT ''

Now your entire COMPANY table has been wiped out, while it is completely
possible to restore your db up to the minute, you've still lost some
downtime given that you had ONE bad apple in the bunch.

Besides the sql injection threats, you also suffer from a
NON-pre-compiled statement, thus your data could conceptually be
returned a lot faster if you let it, simply by creating a view or stored
procedure.  By the way just because you are using a stored procedure
does not make you completly excempt of sql injections, if you are using
dynamic sql within that procedure you are still open to these kind of
attacks and your stored procedure is always re-comiled and thus suffers
from the same performance deficits.


Andy Lacey wrote On 6/10/2004 1:27 PM:

>But, Francisco, if I was porting to SQL Server my Access app which 
>builds SELECT statements dynamically all of the time for many and 
>various situations are you saying I couldn't, or shouldn't or 
>something?
>
>-- Andy Lacey
>http://www.minstersystems.co.uk
>
>
>
>>-----Original Message-----
>>From: dba-sqlserver-bounces at databaseadvisors.com
>>[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of 
>>Francisco H Tapia
>>Sent: 10 June 2004 20:58
>>To: dba-sqlserver at databaseadvisors.com
>>Subject: Re: [dba-SQLServer] Difference between views and queries
>>
>>
>>jwcolby wrote On 6/10/2004 9:33 AM:
>>
>>
>>
>>>Can anyone explain the difference between a view and a query?  Views 
>>>use a query, plus the view keyword.  I have a couple of books that I 
>>>have read the chapter on Views, but I so far haven't managed
>>>
>>>
>>to "get"
>>
>>
>>>why you wouldn't just use the query itself instead of
>>>
>>>
>>turning it into a
>>
>>
>>>view.
>>>
>>>
>>>
>>>
>>A query is a request for an Access Database, however for Sql Server 
>>you would either use a View or Stored Procedure to return the data you

>>wanted... you are also able to use dynamic SQL to retrieve the 
>>information you need.  ANY request given to the SQL Server engine is 
>>managed by the engine, unless you are running Remote servers (iirc).
>>
>>In Sql Server, it is TABOO, nay, GENERALLY bad practice to use dynamic

>>sql because of the implication of SQL INJECTION attacks, this poses a
>>"real" security threat to your database. and your server.
>>
>>another reason to use a VIEW over dynamic sql is that it is 
>>pre-optimized by the SQL Server Engine and thus runs faster and more 
>>efficient.  Additionally if you use Dynamic SQL then your individual 
>>users who access the server will need EXPLICIT "SELECT" permissions by

>>you, which is another 'bad' practice.  In SQL Server you make data 
>>available to your users via VIEWs and Stored Procedures or some other 
>>secure way in order to protect your tables and it's data.
>>
>>ya get wot I mean?
>>
>>--
>>-Francisco
>>
>>
>>_______________________________________________
>>dba-SQLServer mailing list
>>dba-SQLServer at databaseadvisors.com
>>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>>http://www.databaseadvisors.com
>>
>>
>>
>>
>>
>
>_______________________________________________
>dba-SQLServer mailing list
>dba-SQLServer at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>http://www.databaseadvisors.com
>
>
>
>


--
-Francisco


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

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



This electronic transmission is strictly confidential to TNCO, Inc. and
intended solely for the addressee. It may contain information which is
covered by legal, professional, or other privileges. If you are not the
intended addressee, or someone authorized by the intended addressee to
receive transmissions on behalf of the addressee, you must not retain,
disclose in any form, copy, or take any action in reliance on this
transmission. If you have received this transmission in error, please
notify the sender as soon as possible and destroy this message. While
TNCO, Inc. uses virus protection, the recipient should check this email
and any attachments for the presence of viruses. TNCO, Inc. accepts no
liability for any damage caused by any virus transmitted by this email.
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com

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

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

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

_______________________________________________
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 artful at rogers.com  Thu Jun 24 16:06:05 2004
From: artful at rogers.com (Arthur Fuller)
Date: Thu, 24 Jun 2004 17:06:05 -0400
Subject: [dba-SQLServer] Connections
In-Reply-To: <004501c45315$82ed1290$1b02a8c0@MARTINREID>
Message-ID: <094601c45a2f$10575c60$6601a8c0@rock>

I have some DMO-based code that handles this issue. It's part of an app
that I wrote that assumes you don't have Enterprise Manager etc.
installed (i.e. you have an MSDE back end). SQL-DMO is pretty simple
once you inspect its methods and read (gasp) the docs. The code I wrote
is not rocket science.

Arthur

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Martin
Reid
Sent: Tuesday, June 15, 2004 4:16 PM
To: dba-sqlserver at databaseadvisors.com
Subject: [dba-SQLServer] Connections


I have a global connection set up in an Access front end to SQL Server.
When this goes out to the clients it will run on many different client
servers and we will not know the server name or security model in use
before it is installed.

How do you folks handle this?

SQL Server 2000
Access 2000, 2002 and 2003 as the front end.


Martin

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



From michael.broesdorf at web.de  Fri Jun 25 03:06:15 2004
From: michael.broesdorf at web.de (=?us-ascii?Q?Michael_Brosdorf?=)
Date: Fri, 25 Jun 2004 10:06:15 +0200
Subject: [dba-SQLServer] Run a sproc within a select statement
In-Reply-To: <094601c45a2f$10575c60$6601a8c0@rock>
Message-ID: <NEBBIILOPOPJBCLJIJHHGELEFJAA.michael.broesdorf@web.de>

Dear group,

within a trigger I need to run a stored procedure for every record in the
inserted/deleted tables.
I would like to avoid using a cursor to touch the records one by one. A
while ago I saw a pretty tricky solution
for that problem where the sproc was run from inside the select statement
(afair it looked almost like the
'select @intID=MyID from Mytable'-syntax for assigning a value to variable).
Unfortunately I cannot remember, where that was.

Any hints?

Michael




From artful at rogers.com  Fri Jun 25 15:22:54 2004
From: artful at rogers.com (Arthur Fuller)
Date: Fri, 25 Jun 2004 16:22:54 -0400
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <446DDE75CFC7E1438061462F85557B0F0BFF1F@remail2.westat.com>
Message-ID: <0a7501c45af2$32a3d640$6601a8c0@rock>

1. I haven't yet seen a case where dynamic SQL is necessary. All it
takes to avoid it is one or more well-constructed sprocs, IMO.

2. This is a good thing. But the point I was making is that you set up a
hierarchy of permissions by role, and then add roles to roles. This
works very well.

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Francis
Harvey
Sent: Thursday, June 24, 2004 4:28 PM
To: 'dba-sqlserver at databaseadvisors.com'
Subject: RE: [dba-SQLServer] Difference between views and queries


Arthur,

Two points:

1) Never say no exceptions. Currently, I need dynamic SQL,
and there is no comparable work around without it.

2) Permissions are not additive in that denied permissions always take
precedence. You cannot gain rights to an object by adding adding
additional roles if you have been denied rights at some level.

Francis R Harvey III
WB 303, (301)294-3952
harveyf1 at westat.com


> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf 
> Of Arthur Fuller
> Sent: Thursday, June 24, 2004 4:05 PM
> To: dba-sqlserver at databaseadvisors.com
> Subject: RE: [dba-SQLServer] Difference between views and queries
> 
<snip>
> NO users except sa (and possibly developers) should have access to any

> SQL table. Everything should be done with views or sprocs or UDFs. No 
> exceptions.
> 
> Access to said objects should be governed by roles, and users
> should be
> assigned to roles; this can be done additively. I.e. suppose 
> you have 3
> levels of access, a, b and c. Everyone in level B can do 
> everything that
> everyone in level A can. So just role B as a user in level A; then you
> "inherit" everything permitted for level A. Similarly, add role C as a
> user in level B, and inherit both B and A. This is a 
> simplistic example;
> it may arise in the real world that level C should be able to do
> anything A can but nothing that B can. In that case it's a little more
> difficult, but the underlying principle is the same. IMO, as 
> always, and
> I could be wrong, and it wouldn't be the first time.
> 
> Arthur
<snip>
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com



From HARVEYF1 at WESTAT.com  Fri Jun 25 16:24:30 2004
From: HARVEYF1 at WESTAT.com (Francis Harvey)
Date: Fri, 25 Jun 2004 17:24:30 -0400
Subject: [dba-SQLServer] Difference between views and queries
Message-ID: <446DDE75CFC7E1438061462F85557B0F0BFF21@remail2.westat.com>

Arthur,

Do some research on the basic solutions for SQL that has to adjust for
varying databases, conditions (dynamic search), or servers (different
SQL dialects). Some designs also call for encapsulating business logic
outside of the data tier. In these situations, dynamic SQL is often
the only logical choice. I have only had to deal with dynamic search
myself, but this is enough to convince me of its usefulness.

Describing permissions solely as additive in nature is incorrect. This
is the point I was making.

Francis R Harvey III
WB 303, (301)294-3952
harveyf1 at westat.com


> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com 
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf 
> Of Arthur Fuller
> Sent: Friday, June 25, 2004 4:23 PM
> To: dba-sqlserver at databaseadvisors.com
> Subject: RE: [dba-SQLServer] Difference between views and queries
> 
> 
> 1. I haven't yet seen a case where dynamic SQL is necessary. All it
> takes to avoid it is one or more well-constructed sprocs, IMO.
> 
> 2. This is a good thing. But the point I was making is that 
> you set up a
> hierarchy of permissions by role, and then add roles to roles. This
> works very well.
> 
> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf 
> Of Francis
> Harvey
> Sent: Thursday, June 24, 2004 4:28 PM
> To: 'dba-sqlserver at databaseadvisors.com'
> Subject: RE: [dba-SQLServer] Difference between views and queries
> 
> 
> Arthur,
> 
> Two points:
> 
> 1) Never say no exceptions. Currently, I need dynamic SQL,
> and there is no comparable work around without it.
> 
> 2) Permissions are not additive in that denied permissions always take
> precedence. You cannot gain rights to an object by adding adding
> additional roles if you have been denied rights at some level.
> 
> Francis R Harvey III
> WB 303, (301)294-3952
> harveyf1 at westat.com
> 
> 
> > -----Original Message-----
> > From: dba-sqlserver-bounces at databaseadvisors.com
> > [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf 
> > Of Arthur Fuller
> > Sent: Thursday, June 24, 2004 4:05 PM
> > To: dba-sqlserver at databaseadvisors.com
> > Subject: RE: [dba-SQLServer] Difference between views and queries
> > 
> <snip>
> > NO users except sa (and possibly developers) should have 
> access to any
> 
> > SQL table. Everything should be done with views or sprocs 
> or UDFs. No 
> > exceptions.
> > 
> > Access to said objects should be governed by roles, and users
> > should be
> > assigned to roles; this can be done additively. I.e. suppose 
> > you have 3
> > levels of access, a, b and c. Everyone in level B can do 
> > everything that
> > everyone in level A can. So just role B as a user in level 
> A; then you
> > "inherit" everything permitted for level A. Similarly, add 
> role C as a
> > user in level B, and inherit both B and A. This is a 
> > simplistic example;
> > it may arise in the real world that level C should be able to do
> > anything A can but nothing that B can. In that case it's a 
> little more
> > difficult, but the underlying principle is the same. IMO, as 
> > always, and
> > I could be wrong, and it wouldn't be the first time.
> > 
> > Arthur
> <snip>
<snip>


From martyconnelly at shaw.ca  Fri Jun 25 18:51:44 2004
From: martyconnelly at shaw.ca (MartyConnelly)
Date: Fri, 25 Jun 2004 16:51:44 -0700
Subject: [dba-SQLServer] Connections
References: <094601c45a2f$10575c60$6601a8c0@rock>
Message-ID: <40DCBA90.9020700@shaw.ca>

Here is an almost full EM written in VB6 with SQL-DMO. Versions for for 
MSDE 1 and 2000
Includes full source code useful for learning SQL-DMO

http://www.asql.biz/DbaMgr.shtm

Arthur Fuller wrote:

>I have some DMO-based code that handles this issue. It's part of an app
>that I wrote that assumes you don't have Enterprise Manager etc.
>installed (i.e. you have an MSDE back end). SQL-DMO is pretty simple
>once you inspect its methods and read (gasp) the docs. The code I wrote
>is not rocket science.
>
>Arthur
>
>-----Original Message-----
>From: dba-sqlserver-bounces at databaseadvisors.com
>[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Martin
>Reid
>Sent: Tuesday, June 15, 2004 4:16 PM
>To: dba-sqlserver at databaseadvisors.com
>Subject: [dba-SQLServer] Connections
>
>
>I have a global connection set up in an Access front end to SQL Server.
>When this goes out to the clients it will run on many different client
>servers and we will not know the server name or security model in use
>before it is installed.
>
>How do you folks handle this?
>
>SQL Server 2000
>Access 2000, 2002 and 2003 as the front end.
>
>
>Martin
>
>_______________________________________________
>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
>
>
>  
>

-- 
Marty Connelly
Victoria, B.C.
Canada





From accessd at shaw.ca  Sun Jun 27 12:27:42 2004
From: accessd at shaw.ca (Jim Lawrence (AccessD))
Date: Sun, 27 Jun 2004 10:27:42 -0700
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <093201c45a28$56797a90$6601a8c0@rock>
Message-ID: <FJEJLIPOMCGJALMGLLLIOEAGCEAA.accessd@shaw.ca>

Hi Arthur:

Can not let you get in the last word. Please find my comments inline.

Jim

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of Arthur
Fuller
Sent: Thursday, June 24, 2004 1:18 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


We have serious differences of opinion here, Jim.

1. I have experimented with bound and unbound forms against SQL Server
and I firmly dispute MS's recommendation that bound forms should not be
used. I have several "major" apps running using bound forms and we're
experiencing no problems at all.

<comment>
...and I have found no problems with unbound forms. In a stable environment
both techniques should be very 'problem free'.
</comment>

2. In a SQL environment, the concept "bound" is not quite the same as in
Access. For example, I could have a form bound to a multi-table view
(which is therefore not updateable), but that simply means that I write
some code to perform the multi-table updates. It's still a bound form.

<comment>
...with unbound forms this is never an issues as you are handling all the
access data anyways.
</comment>

3. I have complete control over every piece of data displayed in a bound
form. All I need to to is create the underlying view/sproc/UDF which for
example retrieves all the relevant fields from all the related tables,
then present them. This is a no-brainer once you understand how Access
will deal with it. You can create a very complex view and then AutoForm
it, and then add the update/insert code you need. Not as simple as a
one-table bound form talking to an Access table, but almost as simple.

<comment>
...I agree, that is a no-brainer.

But there are also other ways of retrieving and handling data, especially
within a 'unbound' format, that can not be fully taken advantage of within a
'bound' environment. Given one example, you can optimize data retrieval by
simply assembling a dynamic recordset list of various fields, that would be
used to link or find a specific form record. Once a form record is selected
from this list, the entire form can then be populated. This methodology can
be highly tuned to the given data set and to client's requirements.
</comment>

4. Before concluding that the methods above were better than the
MS-recommended strategy, I did some benchmarks. I used a class-based
approach (i.e. a class with Get and Put methods). The performance
difference was significant. Once I saw this difference, I decided to put
my head against the grinder and deal with the issues of bound forms.
They're not perfect. Nothing is. But IMO they are WAY better than
unbound forms. It all depends on what you bind them to.

<comment>
...My experience with connecting to SQL server with unbound forms did not
result in the same experience you had. On the other hand, I have not used
the 'Get' and 'Put' methods in any design. (Have you tried using the 'Getex'
and 'Putex' methods which always retrieve values in an array?) I have just
used the 'Insert' and 'Update' methods or passed the variable through
parameters and just allowed a SP to take care of multiple tables. Are you
using ODBC? I once used an ODBC connection to a SQL server and found it was
a dog. Direct ADO-OLE is more appropriate. I have found when attaching new
users performance remain consistent and flat.

Some of the areas and reasons for using unbound forms, you have not
mentioned. I assume you have only been in offices where there is unlimited
connection licenses and with a very stable and simple LAN environments.

1. Working with unlimited licenses and bound forms are not always an option.
Try sixty plus users and a SQL server with a dozen connection license. Not
every client can afford $10,000+, but $1,200.00+ is an easy swallow.

2. Mixed environments that are using Web and Desktop forms or multiple
databases or multiple database types say like SQL and Oracle, are relatively
easy to setup. I could not imagine the same (relative) ease of design in
bound forms.

In conclusion, I agree that you can use bound forms, it is probably more
simple to implement and it can be very functional but when it comes to
flexibility regarding licenses, data handling, data sources and data
delivery, unbound forms are unparalleled. Do not get me wrong. I do not
believe that bound forms do not have their place. Their implementation is
quicker for small contracts but within large complex environments unbound
forms, IMHO, are faster in creation and performance.
</comment>

Arthur

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Jim
Lawrence (AccessD)
Sent: Friday, June 11, 2004 2:08 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


Joe:

You should know better than ask that question. It sort of stirs up
things. The following are my personnel guide-lines but they can be
changed but there has to be a very good reason.

1. Bound forms can be used on small Access projects but never on
anything major.

There are a host of pluses and minus on both side.

Facts as I see them:

Bound forms are much easier to implement. The existing operating system
handles access to records, locking, updates while multiple people are
working on a single record, populating the forms, sub-forms etc. When
there are a small number of people accessing a simple MDB database, for
example, performance can be superior.

Unbound forms are harder to implement...properly. All the above
benefits, you as the programmer, must provide. It takes longer to
implement and test. There are a whole range of programming issues that
have to be addressed. It is not for the faint-of-heart or first time
developers.

On the plus side of unbound forms, is that you now have complete control
over every piece of data that is displayed on the form or stored in the
database.

1. You can provide an extensive set of business rules, on just a single
field, if required. 2. Now that you control the data-access layer,
multiple data sources can be accessed and easily integrated. For
example; you can be using a SQL, Oracle and MDB data sources
simultaneously. 3. Data access can be merged deep within your code, so
as to provide a layer of security. (That is one of the reasons I do not
like ODBC connection because they can be easily used by any skilled
client, to gain direct access to protected data sources and because they
are exposed and not imbedded in your code.) 4. Much of the issues around
record-locking, multi-user and the potential data over-writing are
managed through the bigger data engines like SQL and Oracle. It is your
responsibility to use proper transaction controls, monitor return codes
and take appropriate actions. 5. With you now managing the data
connections, remote sites with unstable or slow access, can be carefully
handled, with virtual no data loss or database corruption. 6. Because
you now precisely handle data access, only the specific data sets
required, to populate the current form and sub-forms, are extracted.
Static data for controls can be pulled once at the beginning of a
session and not as each record is accessed. When it comes to the major
sequel databases, the raw data can be extracted, at the server end
through, Stored Procedure and functions calls. To provide better
performance the raw data can then, at the client side, be grouped and
sorted which in some cases will provide up to a seventy percent
performance boost. (Distributive computing). 7. Complete access control
of the data can leverage a small SQL system. For example; given a SQL
DB, only licensed with a dozen connections, sixty plus people can have,
as far as they are concerned, full access. More bang for the buck.

In summary, the downside is that it requires a lot more work to
implement an unbound database, internal documentation and structured
code lay-out has to be very carefully done. I can not stress tidiness
and organization enough. Consider someone who has to go back in to
update the code, that someone might be you.

The upside, is that you, as a programmer, have absolute control, garner
superior performance (on larger systems), better stability and much
better security.

This is my quarter's worth, thank you
Jim


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of Joe
Rojas
Sent: Friday, June 11, 2004 5:38 AM
To: 'dba-sqlserver at databaseadvisors.com'
Subject: RE: [dba-SQLServer] Difference between views and queries


Hi Jim,

What is the argument for not using bound forms?

JR

-----Original Message-----
From: Jim Lawrence (AccessD) [mailto:accessd at shaw.ca]
Sent: Thursday, June 10, 2004 6:46 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries

Hi All:

As to all these issues I would like to dump some of my own comments. At
the risk of saying 'I told you so', I firmly believe that users should:

1. Always (or should I say only), use windows authentication and
judiciously distribute security access, to your SQLxx, to only those who
need it. Appropriate passwords and time limits. 1. Never allow access to
the data except through your program. That means NO to ODBC drivers only
ADO-OLE. 2. In 99% of cases, control is handled through SPs. 3. And the
biggy never, never use bound forms to access SQLxx data. I have been
whining about that for years, a position that M$ has also fully
supported. 4. You, as the programmer, should design your program to
carefully validate all requests and data before they are posted.

I may be already talking to the converted so you can ignore this; if
not..Get on the program.

Seeing we at in the midst of an election campaign, a good stump,
political speech is the expected. Jim


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of
Francisco H Tapia
Sent: Thursday, June 10, 2004 1:55 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Difference between views and queries


Andy,
  SQL Server is not Access on steriods, it's a diffrent engine, and thus
requires a new level of thinking towards your database engine.  It's NOT
that you couldn't, you can do anything, heck if you wanted to you can
set up your SQL Server with a blank SA password or SA as the password.
For all that matters, and avoiding all SQL Server authentication, just
use NT authentication and enable guest users :).

There have been quite a few white papers circulating on why you
"wouldn't" use dynamic sql w/ your sql server (check out
www.sqlservercentral.com, a fine resource) but the 2 very critical
factors include performance and also quite possible damage to your data.

It is entirely possible for your sql statement to read in this manner,
lets's say that you are Selecting Data from a table and you have a
combobox to help choose data, so your SQL Statment looks like this:

"Select CompanyName, CompanyAttribute1, pKey FROM tblCompany WHERE
CompanyAttribute1 = '" & me.cboMyBOX & "'", If I was a malicious user on
your system and I have direct access to tables, and if you're doing
statements like the above it is entirely plausible that you also have
"INSERT" statements thus you are giving more than just simple SELECT
access to these tables., thus with some malformed selection I can add
this in the select

'; DELETE FROM tblCompany; SELECT '

your final statement would look like this

Select CompanyName, CompanyAttribute1, pKey FROM tblCompany WHERE
CompanyAttribute1 = ''; DELETE FROM tblCompany; SELECT ''

Now your entire COMPANY table has been wiped out, while it is completely
possible to restore your db up to the minute, you've still lost some
downtime given that you had ONE bad apple in the bunch.

Besides the sql injection threats, you also suffer from a
NON-pre-compiled statement, thus your data could conceptually be
returned a lot faster if you let it, simply by creating a view or stored
procedure.  By the way just because you are using a stored procedure
does not make you completly excempt of sql injections, if you are using
dynamic sql within that procedure you are still open to these kind of
attacks and your stored procedure is always re-comiled and thus suffers
from the same performance deficits.


Andy Lacey wrote On 6/10/2004 1:27 PM:

>But, Francisco, if I was porting to SQL Server my Access app which
>builds SELECT statements dynamically all of the time for many and
>various situations are you saying I couldn't, or shouldn't or
>something?
>
>-- Andy Lacey
>http://www.minstersystems.co.uk
>
>
>
>>-----Original Message-----
>>From: dba-sqlserver-bounces at databaseadvisors.com
>>[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of
>>Francisco H Tapia
>>Sent: 10 June 2004 20:58
>>To: dba-sqlserver at databaseadvisors.com
>>Subject: Re: [dba-SQLServer] Difference between views and queries
>>
>>
>>jwcolby wrote On 6/10/2004 9:33 AM:
>>
>>
>>
>>>Can anyone explain the difference between a view and a query?  Views
>>>use a query, plus the view keyword.  I have a couple of books that I
>>>have read the chapter on Views, but I so far haven't managed
>>>
>>>
>>to "get"
>>
>>
>>>why you wouldn't just use the query itself instead of
>>>
>>>
>>turning it into a
>>
>>
>>>view.
>>>
>>>
>>>
>>>
>>A query is a request for an Access Database, however for Sql Server
>>you would either use a View or Stored Procedure to return the data you
>>wanted... you are also able to use dynamic SQL to retrieve the
>>information you need.  ANY request given to the SQL Server engine is
>>managed by the engine, unless you are running Remote servers (iirc).
>>
>>In Sql Server, it is TABOO, nay, GENERALLY bad practice to use dynamic
>>sql because of the implication of SQL INJECTION attacks, this poses a
>>"real" security threat to your database. and your server.
>>
>>another reason to use a VIEW over dynamic sql is that it is
>>pre-optimized by the SQL Server Engine and thus runs faster and more
>>efficient.  Additionally if you use Dynamic SQL then your individual
>>users who access the server will need EXPLICIT "SELECT" permissions by
>>you, which is another 'bad' practice.  In SQL Server you make data
>>available to your users via VIEWs and Stored Procedures or some other
>>secure way in order to protect your tables and it's data.
>>
>>ya get wot I mean?
>>
>>--
>>-Francisco
>>
>>
>>_______________________________________________
>>dba-SQLServer mailing list
>>dba-SQLServer at databaseadvisors.com
>>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>>http://www.databaseadvisors.com
>>
>>
>>
>>
>>
>
>_______________________________________________
>dba-SQLServer mailing list
>dba-SQLServer at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>http://www.databaseadvisors.com
>
>
>
>


--
-Francisco


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

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



This electronic transmission is strictly confidential to TNCO, Inc. and
intended solely for the addressee. It may contain information which is
covered by legal, professional, or other privileges. If you are not the
intended addressee, or someone authorized by the intended addressee to
receive transmissions on behalf of the addressee, you must not retain,
disclose in any form, copy, or take any action in reliance on this
transmission. If you have received this transmission in error, please
notify the sender as soon as possible and destroy this message. While
TNCO, Inc. uses virus protection, the recipient should check this email
and any attachments for the presence of viruses. TNCO, Inc. accepts no
liability for any damage caused by any virus transmitted by this email.
_______________________________________________
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  Sun Jun 27 19:08:16 2004
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Sun, 27 Jun 2004 20:08:16 -0400
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <FJEJLIPOMCGJALMGLLLIOEAGCEAA.accessd@shaw.ca>
Message-ID: <006c01c45ca4$03155c60$0501a8c0@colbyws>

> 1. Working with unlimited licenses and bound forms are not always an
option. Try sixty plus users and a SQL server with a dozen connection
license. Not every client can afford $10,000+, but $1,200.00+ is an easy
swallow.

How much did they pay to develop unbound forms and get it all working.  All
that "bound stuff" that just happens has to be recreated by someone!

John W. Colby 
www.ColbyConsulting.com

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Jim
Lawrence (AccessD)
Sent: Sunday, June 27, 2004 1:28 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


Hi Arthur:

Can not let you get in the last word. Please find my comments inline.

Jim

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of Arthur
Fuller
Sent: Thursday, June 24, 2004 1:18 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


We have serious differences of opinion here, Jim.

1. I have experimented with bound and unbound forms against SQL Server and I
firmly dispute MS's recommendation that bound forms should not be used. I
have several "major" apps running using bound forms and we're experiencing
no problems at all.

<comment>
...and I have found no problems with unbound forms. In a stable environment
both techniques should be very 'problem free'. </comment>

2. In a SQL environment, the concept "bound" is not quite the same as in
Access. For example, I could have a form bound to a multi-table view (which
is therefore not updateable), but that simply means that I write some code
to perform the multi-table updates. It's still a bound form.

<comment>
...with unbound forms this is never an issues as you are handling all the
access data anyways. </comment>

3. I have complete control over every piece of data displayed in a bound
form. All I need to to is create the underlying view/sproc/UDF which for
example retrieves all the relevant fields from all the related tables, then
present them. This is a no-brainer once you understand how Access will deal
with it. You can create a very complex view and then AutoForm it, and then
add the update/insert code you need. Not as simple as a one-table bound form
talking to an Access table, but almost as simple.

<comment>
...I agree, that is a no-brainer.

But there are also other ways of retrieving and handling data, especially
within a 'unbound' format, that can not be fully taken advantage of within a
'bound' environment. Given one example, you can optimize data retrieval by
simply assembling a dynamic recordset list of various fields, that would be
used to link or find a specific form record. Once a form record is selected
from this list, the entire form can then be populated. This methodology can
be highly tuned to the given data set and to client's requirements.
</comment>

4. Before concluding that the methods above were better than the
MS-recommended strategy, I did some benchmarks. I used a class-based
approach (i.e. a class with Get and Put methods). The performance difference
was significant. Once I saw this difference, I decided to put my head
against the grinder and deal with the issues of bound forms. They're not
perfect. Nothing is. But IMO they are WAY better than unbound forms. It all
depends on what you bind them to.

<comment>
...My experience with connecting to SQL server with unbound forms did not
result in the same experience you had. On the other hand, I have not used
the 'Get' and 'Put' methods in any design. (Have you tried using the 'Getex'
and 'Putex' methods which always retrieve values in an array?) I have just
used the 'Insert' and 'Update' methods or passed the variable through
parameters and just allowed a SP to take care of multiple tables. Are you
using ODBC? I once used an ODBC connection to a SQL server and found it was
a dog. Direct ADO-OLE is more appropriate. I have found when attaching new
users performance remain consistent and flat.

Some of the areas and reasons for using unbound forms, you have not
mentioned. I assume you have only been in offices where there is unlimited
connection licenses and with a very stable and simple LAN environments.

1. Working with unlimited licenses and bound forms are not always an option.
Try sixty plus users and a SQL server with a dozen connection license. Not
every client can afford $10,000+, but $1,200.00+ is an easy swallow.

2. Mixed environments that are using Web and Desktop forms or multiple
databases or multiple database types say like SQL and Oracle, are relatively
easy to setup. I could not imagine the same (relative) ease of design in
bound forms.

In conclusion, I agree that you can use bound forms, it is probably more
simple to implement and it can be very functional but when it comes to
flexibility regarding licenses, data handling, data sources and data
delivery, unbound forms are unparalleled. Do not get me wrong. I do not
believe that bound forms do not have their place. Their implementation is
quicker for small contracts but within large complex environments unbound
forms, IMHO, are faster in creation and performance. </comment>

Arthur

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Jim
Lawrence (AccessD)
Sent: Friday, June 11, 2004 2:08 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


Joe:

You should know better than ask that question. It sort of stirs up things.
The following are my personnel guide-lines but they can be changed but there
has to be a very good reason.

1. Bound forms can be used on small Access projects but never on anything
major.

There are a host of pluses and minus on both side.

Facts as I see them:

Bound forms are much easier to implement. The existing operating system
handles access to records, locking, updates while multiple people are
working on a single record, populating the forms, sub-forms etc. When there
are a small number of people accessing a simple MDB database, for example,
performance can be superior.

Unbound forms are harder to implement...properly. All the above benefits,
you as the programmer, must provide. It takes longer to implement and test.
There are a whole range of programming issues that have to be addressed. It
is not for the faint-of-heart or first time developers.

On the plus side of unbound forms, is that you now have complete control
over every piece of data that is displayed on the form or stored in the
database.

1. You can provide an extensive set of business rules, on just a single
field, if required. 2. Now that you control the data-access layer, multiple
data sources can be accessed and easily integrated. For example; you can be
using a SQL, Oracle and MDB data sources simultaneously. 3. Data access can
be merged deep within your code, so as to provide a layer of security. (That
is one of the reasons I do not like ODBC connection because they can be
easily used by any skilled client, to gain direct access to protected data
sources and because they are exposed and not imbedded in your code.) 4. Much
of the issues around record-locking, multi-user and the potential data
over-writing are managed through the bigger data engines like SQL and
Oracle. It is your responsibility to use proper transaction controls,
monitor return codes and take appropriate actions. 5. With you now managing
the data connections, remote sites with unstable or slow access, can be
carefully handled, with virtual no data loss or database corruption. 6.
Because you now precisely handle data access, only the specific data sets
required, to populate the current form and sub-forms, are extracted. Static
data for controls can be pulled once at the beginning of a session and not
as each record is accessed. When it comes to the major sequel databases, the
raw data can be extracted, at the server end through, Stored Procedure and
functions calls. To provide better performance the raw data can then, at the
client side, be grouped and sorted which in some cases will provide up to a
seventy percent performance boost. (Distributive computing). 7. Complete
access control of the data can leverage a small SQL system. For example;
given a SQL DB, only licensed with a dozen connections, sixty plus people
can have, as far as they are concerned, full access. More bang for the buck.

In summary, the downside is that it requires a lot more work to implement an
unbound database, internal documentation and structured code lay-out has to
be very carefully done. I can not stress tidiness and organization enough.
Consider someone who has to go back in to update the code, that someone
might be you.

The upside, is that you, as a programmer, have absolute control, garner
superior performance (on larger systems), better stability and much better
security.

This is my quarter's worth, thank you
Jim


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of Joe Rojas
Sent: Friday, June 11, 2004 5:38 AM
To: 'dba-sqlserver at databaseadvisors.com'
Subject: RE: [dba-SQLServer] Difference between views and queries


Hi Jim,

What is the argument for not using bound forms?

JR

-----Original Message-----
From: Jim Lawrence (AccessD) [mailto:accessd at shaw.ca]
Sent: Thursday, June 10, 2004 6:46 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries

Hi All:

As to all these issues I would like to dump some of my own comments. At the
risk of saying 'I told you so', I firmly believe that users should:

1. Always (or should I say only), use windows authentication and judiciously
distribute security access, to your SQLxx, to only those who need it.
Appropriate passwords and time limits. 1. Never allow access to the data
except through your program. That means NO to ODBC drivers only ADO-OLE. 2.
In 99% of cases, control is handled through SPs. 3. And the biggy never,
never use bound forms to access SQLxx data. I have been whining about that
for years, a position that M$ has also fully supported. 4. You, as the
programmer, should design your program to carefully validate all requests
and data before they are posted.

I may be already talking to the converted so you can ignore this; if
not..Get on the program.

Seeing we at in the midst of an election campaign, a good stump, political
speech is the expected. Jim


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of Francisco H
Tapia
Sent: Thursday, June 10, 2004 1:55 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Difference between views and queries


Andy,
  SQL Server is not Access on steriods, it's a diffrent engine, and thus
requires a new level of thinking towards your database engine.  It's NOT
that you couldn't, you can do anything, heck if you wanted to you can set up
your SQL Server with a blank SA password or SA as the password. For all that
matters, and avoiding all SQL Server authentication, just use NT
authentication and enable guest users :).

There have been quite a few white papers circulating on why you "wouldn't"
use dynamic sql w/ your sql server (check out www.sqlservercentral.com, a
fine resource) but the 2 very critical factors include performance and also
quite possible damage to your data.

It is entirely possible for your sql statement to read in this manner,
lets's say that you are Selecting Data from a table and you have a combobox
to help choose data, so your SQL Statment looks like this:

"Select CompanyName, CompanyAttribute1, pKey FROM tblCompany WHERE
CompanyAttribute1 = '" & me.cboMyBOX & "'", If I was a malicious user on
your system and I have direct access to tables, and if you're doing
statements like the above it is entirely plausible that you also have
"INSERT" statements thus you are giving more than just simple SELECT access
to these tables., thus with some malformed selection I can add this in the
select

'; DELETE FROM tblCompany; SELECT '

your final statement would look like this

Select CompanyName, CompanyAttribute1, pKey FROM tblCompany WHERE
CompanyAttribute1 = ''; DELETE FROM tblCompany; SELECT ''

Now your entire COMPANY table has been wiped out, while it is completely
possible to restore your db up to the minute, you've still lost some
downtime given that you had ONE bad apple in the bunch.

Besides the sql injection threats, you also suffer from a NON-pre-compiled
statement, thus your data could conceptually be returned a lot faster if you
let it, simply by creating a view or stored procedure.  By the way just
because you are using a stored procedure does not make you completly excempt
of sql injections, if you are using dynamic sql within that procedure you
are still open to these kind of attacks and your stored procedure is always
re-comiled and thus suffers from the same performance deficits.


Andy Lacey wrote On 6/10/2004 1:27 PM:

>But, Francisco, if I was porting to SQL Server my Access app which 
>builds SELECT statements dynamically all of the time for many and 
>various situations are you saying I couldn't, or shouldn't or 
>something?
>
>-- Andy Lacey
>http://www.minstersystems.co.uk
>
>
>
>>-----Original Message-----
>>From: dba-sqlserver-bounces at databaseadvisors.com
>>[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of 
>>Francisco H Tapia
>>Sent: 10 June 2004 20:58
>>To: dba-sqlserver at databaseadvisors.com
>>Subject: Re: [dba-SQLServer] Difference between views and queries
>>
>>
>>jwcolby wrote On 6/10/2004 9:33 AM:
>>
>>
>>
>>>Can anyone explain the difference between a view and a query?  Views 
>>>use a query, plus the view keyword.  I have a couple of books that I 
>>>have read the chapter on Views, but I so far haven't managed
>>>
>>>
>>to "get"
>>
>>
>>>why you wouldn't just use the query itself instead of
>>>
>>>
>>turning it into a
>>
>>
>>>view.
>>>
>>>
>>>
>>>
>>A query is a request for an Access Database, however for Sql Server 
>>you would either use a View or Stored Procedure to return the data you 
>>wanted... you are also able to use dynamic SQL to retrieve the 
>>information you need.  ANY request given to the SQL Server engine is 
>>managed by the engine, unless you are running Remote servers (iirc).
>>
>>In Sql Server, it is TABOO, nay, GENERALLY bad practice to use dynamic 
>>sql because of the implication of SQL INJECTION attacks, this poses a 
>>"real" security threat to your database. and your server.
>>
>>another reason to use a VIEW over dynamic sql is that it is 
>>pre-optimized by the SQL Server Engine and thus runs faster and more 
>>efficient.  Additionally if you use Dynamic SQL then your individual 
>>users who access the server will need EXPLICIT "SELECT" permissions by 
>>you, which is another 'bad' practice.  In SQL Server you make data 
>>available to your users via VIEWs and Stored Procedures or some other 
>>secure way in order to protect your tables and it's data.
>>
>>ya get wot I mean?
>>
>>--
>>-Francisco
>>
>>
>>_______________________________________________
>>dba-SQLServer mailing list
>>dba-SQLServer at databaseadvisors.com
>>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>>http://www.databaseadvisors.com
>>
>>
>>
>>
>>
>
>_______________________________________________
>dba-SQLServer mailing list
>dba-SQLServer at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>http://www.databaseadvisors.com
>
>
>
>


--
-Francisco


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

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



This electronic transmission is strictly confidential to TNCO, Inc. and
intended solely for the addressee. It may contain information which is
covered by legal, professional, or other privileges. If you are not the
intended addressee, or someone authorized by the intended addressee to
receive transmissions on behalf of the addressee, you must not retain,
disclose in any form, copy, or take any action in reliance on this
transmission. If you have received this transmission in error, please notify
the sender as soon as possible and destroy this message. While TNCO, Inc.
uses virus protection, the recipient should check this email and any
attachments for the presence of viruses. TNCO, Inc. accepts no liability for
any damage caused by any virus transmitted by this email.
_______________________________________________
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 accessd at shaw.ca  Sun Jun 27 22:31:13 2004
From: accessd at shaw.ca (Jim Lawrence (AccessD))
Date: Sun, 27 Jun 2004 20:31:13 -0700
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <006c01c45ca4$03155c60$0501a8c0@colbyws>
Message-ID: <FJEJLIPOMCGJALMGLLLIMEAICEAA.accessd@shaw.ca>

Hi John:

Good question. The actual difference, in cost and this is a WAG, was about
$6,000. Taken in perspective, that particular project extended over three
months and then there was a couple of years of support fees, the additional
costs were not a big percentage.

Consider the thing similar to your 'frame-work'. If you had to write the
whole thing from scratch, for ever contract, no one would be able to afford
it. Every subsequent client benefits from the frame-work by having a feature
laden, field tested piece of code.

Assembling or can I say boiler-plating, an unbound form together takes no
longer than many programmers would take to create the standard set of bound
forms.

Most of the work is up front, getting the client requirements on paper,
creating the layout, setting up the server, the SQL database with it's
security, roles, Stored Procedures, Views etc. Creating mockup forms (the
client may what everything in purple and the client is always right :-).),
the flow-charts, reporting requirements and finally getting the signed
contract is by far most of the work. I have had a client who took three days
just to decide on the icon at the top of each of the screens.

The internal coding requires a lot of cutting, pasting, modifying the
'types', collections and list etc. There is very little original coding
done. At this point the designing is very routine and structured.

At the completion, the client, IMHO, ends up with a superior product.

Jim

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of jwcolby
Sent: Sunday, June 27, 2004 5:08 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


> 1. Working with unlimited licenses and bound forms are not always an
option. Try sixty plus users and a SQL server with a dozen connection
license. Not every client can afford $10,000+, but $1,200.00+ is an easy
swallow.

How much did they pay to develop unbound forms and get it all working.  All
that "bound stuff" that just happens has to be recreated by someone!

John W. Colby
www.ColbyConsulting.com

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Jim
Lawrence (AccessD)
Sent: Sunday, June 27, 2004 1:28 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


Hi Arthur:

Can not let you get in the last word. Please find my comments inline.

Jim

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of Arthur
Fuller
Sent: Thursday, June 24, 2004 1:18 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


We have serious differences of opinion here, Jim.

1. I have experimented with bound and unbound forms against SQL Server and I
firmly dispute MS's recommendation that bound forms should not be used. I
have several "major" apps running using bound forms and we're experiencing
no problems at all.

<comment>
...and I have found no problems with unbound forms. In a stable environment
both techniques should be very 'problem free'. </comment>

2. In a SQL environment, the concept "bound" is not quite the same as in
Access. For example, I could have a form bound to a multi-table view (which
is therefore not updateable), but that simply means that I write some code
to perform the multi-table updates. It's still a bound form.

<comment>
...with unbound forms this is never an issues as you are handling all the
access data anyways. </comment>

3. I have complete control over every piece of data displayed in a bound
form. All I need to to is create the underlying view/sproc/UDF which for
example retrieves all the relevant fields from all the related tables, then
present them. This is a no-brainer once you understand how Access will deal
with it. You can create a very complex view and then AutoForm it, and then
add the update/insert code you need. Not as simple as a one-table bound form
talking to an Access table, but almost as simple.

<comment>
...I agree, that is a no-brainer.

But there are also other ways of retrieving and handling data, especially
within a 'unbound' format, that can not be fully taken advantage of within a
'bound' environment. Given one example, you can optimize data retrieval by
simply assembling a dynamic recordset list of various fields, that would be
used to link or find a specific form record. Once a form record is selected
from this list, the entire form can then be populated. This methodology can
be highly tuned to the given data set and to client's requirements.
</comment>

4. Before concluding that the methods above were better than the
MS-recommended strategy, I did some benchmarks. I used a class-based
approach (i.e. a class with Get and Put methods). The performance difference
was significant. Once I saw this difference, I decided to put my head
against the grinder and deal with the issues of bound forms. They're not
perfect. Nothing is. But IMO they are WAY better than unbound forms. It all
depends on what you bind them to.

<comment>
...My experience with connecting to SQL server with unbound forms did not
result in the same experience you had. On the other hand, I have not used
the 'Get' and 'Put' methods in any design. (Have you tried using the 'Getex'
and 'Putex' methods which always retrieve values in an array?) I have just
used the 'Insert' and 'Update' methods or passed the variable through
parameters and just allowed a SP to take care of multiple tables. Are you
using ODBC? I once used an ODBC connection to a SQL server and found it was
a dog. Direct ADO-OLE is more appropriate. I have found when attaching new
users performance remain consistent and flat.

Some of the areas and reasons for using unbound forms, you have not
mentioned. I assume you have only been in offices where there is unlimited
connection licenses and with a very stable and simple LAN environments.

1. Working with unlimited licenses and bound forms are not always an option.
Try sixty plus users and a SQL server with a dozen connection license. Not
every client can afford $10,000+, but $1,200.00+ is an easy swallow.

2. Mixed environments that are using Web and Desktop forms or multiple
databases or multiple database types say like SQL and Oracle, are relatively
easy to setup. I could not imagine the same (relative) ease of design in
bound forms.

In conclusion, I agree that you can use bound forms, it is probably more
simple to implement and it can be very functional but when it comes to
flexibility regarding licenses, data handling, data sources and data
delivery, unbound forms are unparalleled. Do not get me wrong. I do not
believe that bound forms do not have their place. Their implementation is
quicker for small contracts but within large complex environments unbound
forms, IMHO, are faster in creation and performance. </comment>

Arthur

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Jim
Lawrence (AccessD)
Sent: Friday, June 11, 2004 2:08 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


Joe:

You should know better than ask that question. It sort of stirs up things.
The following are my personnel guide-lines but they can be changed but there
has to be a very good reason.

1. Bound forms can be used on small Access projects but never on anything
major.

There are a host of pluses and minus on both side.

Facts as I see them:

Bound forms are much easier to implement. The existing operating system
handles access to records, locking, updates while multiple people are
working on a single record, populating the forms, sub-forms etc. When there
are a small number of people accessing a simple MDB database, for example,
performance can be superior.

Unbound forms are harder to implement...properly. All the above benefits,
you as the programmer, must provide. It takes longer to implement and test.
There are a whole range of programming issues that have to be addressed. It
is not for the faint-of-heart or first time developers.

On the plus side of unbound forms, is that you now have complete control
over every piece of data that is displayed on the form or stored in the
database.

1. You can provide an extensive set of business rules, on just a single
field, if required. 2. Now that you control the data-access layer, multiple
data sources can be accessed and easily integrated. For example; you can be
using a SQL, Oracle and MDB data sources simultaneously. 3. Data access can
be merged deep within your code, so as to provide a layer of security. (That
is one of the reasons I do not like ODBC connection because they can be
easily used by any skilled client, to gain direct access to protected data
sources and because they are exposed and not imbedded in your code.) 4. Much
of the issues around record-locking, multi-user and the potential data
over-writing are managed through the bigger data engines like SQL and
Oracle. It is your responsibility to use proper transaction controls,
monitor return codes and take appropriate actions. 5. With you now managing
the data connections, remote sites with unstable or slow access, can be
carefully handled, with virtual no data loss or database corruption. 6.
Because you now precisely handle data access, only the specific data sets
required, to populate the current form and sub-forms, are extracted. Static
data for controls can be pulled once at the beginning of a session and not
as each record is accessed. When it comes to the major sequel databases, the
raw data can be extracted, at the server end through, Stored Procedure and
functions calls. To provide better performance the raw data can then, at the
client side, be grouped and sorted which in some cases will provide up to a
seventy percent performance boost. (Distributive computing). 7. Complete
access control of the data can leverage a small SQL system. For example;
given a SQL DB, only licensed with a dozen connections, sixty plus people
can have, as far as they are concerned, full access. More bang for the buck.

In summary, the downside is that it requires a lot more work to implement an
unbound database, internal documentation and structured code lay-out has to
be very carefully done. I can not stress tidiness and organization enough.
Consider someone who has to go back in to update the code, that someone
might be you.

The upside, is that you, as a programmer, have absolute control, garner
superior performance (on larger systems), better stability and much better
security.

This is my quarter's worth, thank you
Jim


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of Joe Rojas
Sent: Friday, June 11, 2004 5:38 AM
To: 'dba-sqlserver at databaseadvisors.com'
Subject: RE: [dba-SQLServer] Difference between views and queries


Hi Jim,

What is the argument for not using bound forms?

JR

-----Original Message-----
From: Jim Lawrence (AccessD) [mailto:accessd at shaw.ca]
Sent: Thursday, June 10, 2004 6:46 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries

Hi All:

As to all these issues I would like to dump some of my own comments. At the
risk of saying 'I told you so', I firmly believe that users should:

1. Always (or should I say only), use windows authentication and judiciously
distribute security access, to your SQLxx, to only those who need it.
Appropriate passwords and time limits. 1. Never allow access to the data
except through your program. That means NO to ODBC drivers only ADO-OLE. 2.
In 99% of cases, control is handled through SPs. 3. And the biggy never,
never use bound forms to access SQLxx data. I have been whining about that
for years, a position that M$ has also fully supported. 4. You, as the
programmer, should design your program to carefully validate all requests
and data before they are posted.

I may be already talking to the converted so you can ignore this; if
not..Get on the program.

Seeing we at in the midst of an election campaign, a good stump, political
speech is the expected. Jim


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of Francisco H
Tapia
Sent: Thursday, June 10, 2004 1:55 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Difference between views and queries


Andy,
  SQL Server is not Access on steriods, it's a diffrent engine, and thus
requires a new level of thinking towards your database engine.  It's NOT
that you couldn't, you can do anything, heck if you wanted to you can set up
your SQL Server with a blank SA password or SA as the password. For all that
matters, and avoiding all SQL Server authentication, just use NT
authentication and enable guest users :).

There have been quite a few white papers circulating on why you "wouldn't"
use dynamic sql w/ your sql server (check out www.sqlservercentral.com, a
fine resource) but the 2 very critical factors include performance and also
quite possible damage to your data.

It is entirely possible for your sql statement to read in this manner,
lets's say that you are Selecting Data from a table and you have a combobox
to help choose data, so your SQL Statment looks like this:

"Select CompanyName, CompanyAttribute1, pKey FROM tblCompany WHERE
CompanyAttribute1 = '" & me.cboMyBOX & "'", If I was a malicious user on
your system and I have direct access to tables, and if you're doing
statements like the above it is entirely plausible that you also have
"INSERT" statements thus you are giving more than just simple SELECT access
to these tables., thus with some malformed selection I can add this in the
select

'; DELETE FROM tblCompany; SELECT '

your final statement would look like this

Select CompanyName, CompanyAttribute1, pKey FROM tblCompany WHERE
CompanyAttribute1 = ''; DELETE FROM tblCompany; SELECT ''

Now your entire COMPANY table has been wiped out, while it is completely
possible to restore your db up to the minute, you've still lost some
downtime given that you had ONE bad apple in the bunch.

Besides the sql injection threats, you also suffer from a NON-pre-compiled
statement, thus your data could conceptually be returned a lot faster if you
let it, simply by creating a view or stored procedure.  By the way just
because you are using a stored procedure does not make you completly excempt
of sql injections, if you are using dynamic sql within that procedure you
are still open to these kind of attacks and your stored procedure is always
re-comiled and thus suffers from the same performance deficits.


Andy Lacey wrote On 6/10/2004 1:27 PM:

>But, Francisco, if I was porting to SQL Server my Access app which
>builds SELECT statements dynamically all of the time for many and
>various situations are you saying I couldn't, or shouldn't or
>something?
>
>-- Andy Lacey
>http://www.minstersystems.co.uk
>
>
>
>>-----Original Message-----
>>From: dba-sqlserver-bounces at databaseadvisors.com
>>[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of
>>Francisco H Tapia
>>Sent: 10 June 2004 20:58
>>To: dba-sqlserver at databaseadvisors.com
>>Subject: Re: [dba-SQLServer] Difference between views and queries
>>
>>
>>jwcolby wrote On 6/10/2004 9:33 AM:
>>
>>
>>
>>>Can anyone explain the difference between a view and a query?  Views
>>>use a query, plus the view keyword.  I have a couple of books that I
>>>have read the chapter on Views, but I so far haven't managed
>>>
>>>
>>to "get"
>>
>>
>>>why you wouldn't just use the query itself instead of
>>>
>>>
>>turning it into a
>>
>>
>>>view.
>>>
>>>
>>>
>>>
>>A query is a request for an Access Database, however for Sql Server
>>you would either use a View or Stored Procedure to return the data you
>>wanted... you are also able to use dynamic SQL to retrieve the
>>information you need.  ANY request given to the SQL Server engine is
>>managed by the engine, unless you are running Remote servers (iirc).
>>
>>In Sql Server, it is TABOO, nay, GENERALLY bad practice to use dynamic
>>sql because of the implication of SQL INJECTION attacks, this poses a
>>"real" security threat to your database. and your server.
>>
>>another reason to use a VIEW over dynamic sql is that it is
>>pre-optimized by the SQL Server Engine and thus runs faster and more
>>efficient.  Additionally if you use Dynamic SQL then your individual
>>users who access the server will need EXPLICIT "SELECT" permissions by
>>you, which is another 'bad' practice.  In SQL Server you make data
>>available to your users via VIEWs and Stored Procedures or some other
>>secure way in order to protect your tables and it's data.
>>
>>ya get wot I mean?
>>
>>--
>>-Francisco
>>
>>
>>_______________________________________________
>>dba-SQLServer mailing list
>>dba-SQLServer at databaseadvisors.com
>>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>>http://www.databaseadvisors.com
>>
>>
>>
>>
>>
>
>_______________________________________________
>dba-SQLServer mailing list
>dba-SQLServer at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>http://www.databaseadvisors.com
>
>
>
>


--
-Francisco


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

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



This electronic transmission is strictly confidential to TNCO, Inc. and
intended solely for the addressee. It may contain information which is
covered by legal, professional, or other privileges. If you are not the
intended addressee, or someone authorized by the intended addressee to
receive transmissions on behalf of the addressee, you must not retain,
disclose in any form, copy, or take any action in reliance on this
transmission. If you have received this transmission in error, please notify
the sender as soon as possible and destroy this message. While TNCO, Inc.
uses virus protection, the recipient should check this email and any
attachments for the presence of viruses. TNCO, Inc. accepts no liability for
any damage caused by any virus transmitted by this email.
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com

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

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

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




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



From my.lists at verizon.net  Mon Jun 28 11:41:59 2004
From: my.lists at verizon.net (Francisco H Tapia)
Date: Mon, 28 Jun 2004 09:41:59 -0700
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <446DDE75CFC7E1438061462F85557B0F0BFF21@remail2.westat.com>
References: <446DDE75CFC7E1438061462F85557B0F0BFF21@remail2.westat.com>
Message-ID: <40E04A57.8050402@verizon.net>

Francis,
   I respectfully agree w/ Arthur on this.  Dynamic SQL as a rule, is 
bad design.  Many times over you will find that there are comparable 
solutions that often meet the demand much better, and "scale" much 
better than that of dynamic sql.  There is no "ONE" right way of doing 
things, that is the nature of this business.  However justifying dynamic 
sql because of some time spent on design is imnsho incorrect.  You will 
often find more times that enabling users/roles via Views/Sprocs and 
Functions to be far superior solutions than to open wide dynamic sql.

re: security.
Of course if you deny permissions on any object the take precedence over 
allows, this is the nature of security.  That is why you must be 
explicitly "SURE" when making DENY requests on any object.  NOT giving 
rights to an object does not equeal REJECT.

If I do not give a user rights to a view, under Role1, but then give him 
rights to that object via Role2.  There will be 0 issues w/ 
accessability.  However If by poor planning I had a "REJECT" rights in 
Role1, then I'd have the issues you are stating.




Francis Harvey wrote On 6/25/2004 2:24 PM:

>Arthur,
>
>Do some research on the basic solutions for SQL that has to adjust for
>varying databases, conditions (dynamic search), or servers (different
>SQL dialects). Some designs also call for encapsulating business logic
>outside of the data tier. In these situations, dynamic SQL is often
>the only logical choice. I have only had to deal with dynamic search
>myself, but this is enough to convince me of its usefulness.
>
>Describing permissions solely as additive in nature is incorrect. This
>is the point I was making.
>
>Francis R Harvey III
>WB 303, (301)294-3952
>harveyf1 at westat.com
>
>
>  
>
>>-----Original Message-----
>>From: dba-sqlserver-bounces at databaseadvisors.com 
>>[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf 
>>Of Arthur Fuller
>>Sent: Friday, June 25, 2004 4:23 PM
>>To: dba-sqlserver at databaseadvisors.com
>>Subject: RE: [dba-SQLServer] Difference between views and queries
>>
>>
>>1. I haven't yet seen a case where dynamic SQL is necessary. All it
>>takes to avoid it is one or more well-constructed sprocs, IMO.
>>
>>2. This is a good thing. But the point I was making is that 
>>you set up a
>>hierarchy of permissions by role, and then add roles to roles. This
>>works very well.
>>
>>-----Original Message-----
>>From: dba-sqlserver-bounces at databaseadvisors.com
>>[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf 
>>Of Francis
>>Harvey
>>Sent: Thursday, June 24, 2004 4:28 PM
>>To: 'dba-sqlserver at databaseadvisors.com'
>>Subject: RE: [dba-SQLServer] Difference between views and queries
>>
>>
>>Arthur,
>>
>>Two points:
>>
>>1) Never say no exceptions. Currently, I need dynamic SQL,
>>and there is no comparable work around without it.
>>
>>2) Permissions are not additive in that denied permissions always take
>>precedence. You cannot gain rights to an object by adding adding
>>additional roles if you have been denied rights at some level.
>>
>>Francis R Harvey III
>>WB 303, (301)294-3952
>>harveyf1 at westat.com
>>
>>
>>    
>>
>>>-----Original Message-----
>>>From: dba-sqlserver-bounces at databaseadvisors.com
>>>[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf 
>>>Of Arthur Fuller
>>>Sent: Thursday, June 24, 2004 4:05 PM
>>>To: dba-sqlserver at databaseadvisors.com
>>>Subject: RE: [dba-SQLServer] Difference between views and queries
>>>
>>>      
>>>
>><snip>
>>    
>>
>>>NO users except sa (and possibly developers) should have 
>>>      
>>>
>>access to any
>>
>>    
>>
>>>SQL table. Everything should be done with views or sprocs 
>>>      
>>>
>>or UDFs. No 
>>    
>>
>>>exceptions.
>>>
>>>Access to said objects should be governed by roles, and users
>>>should be
>>>assigned to roles; this can be done additively. I.e. suppose 
>>>you have 3
>>>levels of access, a, b and c. Everyone in level B can do 
>>>everything that
>>>everyone in level A can. So just role B as a user in level 
>>>      
>>>
>>A; then you
>>    
>>
>>>"inherit" everything permitted for level A. Similarly, add 
>>>      
>>>
>>role C as a
>>    
>>
>>>user in level B, and inherit both B and A. This is a 
>>>simplistic example;
>>>it may arise in the real world that level C should be able to do
>>>anything A can but nothing that B can. In that case it's a 
>>>      
>>>
>>little more
>>    
>>
>>>difficult, but the underlying principle is the same. IMO, as 
>>>always, and
>>>I could be wrong, and it wouldn't be the first time.
>>>
>>>Arthur
>>>      
>>>
>><snip>
>>    
>>
><snip>
>_______________________________________________
>dba-SQLServer mailing list
>dba-SQLServer at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>http://www.databaseadvisors.com
>
>
>  
>


-- 
-Francisco




From artful at rogers.com  Mon Jun 28 13:19:36 2004
From: artful at rogers.com (Arthur Fuller)
Date: Mon, 28 Jun 2004 14:19:36 -0400
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <FJEJLIPOMCGJALMGLLLIMEAICEAA.accessd@shaw.ca>
Message-ID: <01fb01c45d3c$78433d70$6601a8c0@rock>

You're quite right, Jim, IMO. When I did the class-based unbound-form
stuff I mentioned earlier, first thing I did was code one by hand;
second thing was generalize the code and write a code-generator that
could spit out the gets and sets just by looking at a form. I used it on
each of by bound forms and in a couple of seconds each I could turn them
into unbound class-based equivalents.

Obviously, custom code would be required here and there, but the
class-approach and gets/sets was so simple to generate that  the gap
between bound and unbound forms pretty much disappeared.

On your other point about using a listbox or whatever mechanism, and
postponing the population of the form until something is selected, I
absolutely agree, and have used that technique even in small apps. But
it works just as well with sprocs (i.e. a sproc that populates a
listbox, and a form bound to a second sproc that accepts a parameter; as
soon as something is selected, the form is made visible and its sproc
executes).

I don't think we're arguing. I'm in complete agreement with the points
you made. When scalability is an issue, it's a different problem than a
Mom'n'Pop business app. No sense taking a stealth bomber to a
knife-fight, and vice-versa.

Arthur

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Jim
Lawrence (AccessD)
Sent: Sunday, June 27, 2004 11:31 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


Hi John:

Good question. The actual difference, in cost and this is a WAG, was
about $6,000. Taken in perspective, that particular project extended
over three months and then there was a couple of years of support fees,
the additional costs were not a big percentage.

Consider the thing similar to your 'frame-work'. If you had to write the
whole thing from scratch, for ever contract, no one would be able to
afford it. Every subsequent client benefits from the frame-work by
having a feature laden, field tested piece of code.

Assembling or can I say boiler-plating, an unbound form together takes
no longer than many programmers would take to create the standard set of
bound forms.

Most of the work is up front, getting the client requirements on paper,
creating the layout, setting up the server, the SQL database with it's
security, roles, Stored Procedures, Views etc. Creating mockup forms
(the client may what everything in purple and the client is always right
:-).), the flow-charts, reporting requirements and finally getting the
signed contract is by far most of the work. I have had a client who took
three days just to decide on the icon at the top of each of the screens.

The internal coding requires a lot of cutting, pasting, modifying the
'types', collections and list etc. There is very little original coding
done. At this point the designing is very routine and structured.

At the completion, the client, IMHO, ends up with a superior product.

Jim

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of jwcolby
Sent: Sunday, June 27, 2004 5:08 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


> 1. Working with unlimited licenses and bound forms are not always an
option. Try sixty plus users and a SQL server with a dozen connection
license. Not every client can afford $10,000+, but $1,200.00+ is an easy
swallow.

How much did they pay to develop unbound forms and get it all working.
All that "bound stuff" that just happens has to be recreated by someone!

John W. Colby
www.ColbyConsulting.com

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Jim
Lawrence (AccessD)
Sent: Sunday, June 27, 2004 1:28 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


Hi Arthur:

Can not let you get in the last word. Please find my comments inline.

Jim

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of Arthur
Fuller
Sent: Thursday, June 24, 2004 1:18 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


We have serious differences of opinion here, Jim.

1. I have experimented with bound and unbound forms against SQL Server
and I firmly dispute MS's recommendation that bound forms should not be
used. I have several "major" apps running using bound forms and we're
experiencing no problems at all.

<comment>
...and I have found no problems with unbound forms. In a stable
environment both techniques should be very 'problem free'. </comment>

2. In a SQL environment, the concept "bound" is not quite the same as in
Access. For example, I could have a form bound to a multi-table view
(which is therefore not updateable), but that simply means that I write
some code to perform the multi-table updates. It's still a bound form.

<comment>
...with unbound forms this is never an issues as you are handling all
the access data anyways. </comment>

3. I have complete control over every piece of data displayed in a bound
form. All I need to to is create the underlying view/sproc/UDF which for
example retrieves all the relevant fields from all the related tables,
then present them. This is a no-brainer once you understand how Access
will deal with it. You can create a very complex view and then AutoForm
it, and then add the update/insert code you need. Not as simple as a
one-table bound form talking to an Access table, but almost as simple.

<comment>
...I agree, that is a no-brainer.

But there are also other ways of retrieving and handling data,
especially within a 'unbound' format, that can not be fully taken
advantage of within a 'bound' environment. Given one example, you can
optimize data retrieval by simply assembling a dynamic recordset list of
various fields, that would be used to link or find a specific form
record. Once a form record is selected from this list, the entire form
can then be populated. This methodology can be highly tuned to the given
data set and to client's requirements. </comment>

4. Before concluding that the methods above were better than the
MS-recommended strategy, I did some benchmarks. I used a class-based
approach (i.e. a class with Get and Put methods). The performance
difference was significant. Once I saw this difference, I decided to put
my head against the grinder and deal with the issues of bound forms.
They're not perfect. Nothing is. But IMO they are WAY better than
unbound forms. It all depends on what you bind them to.

<comment>
...My experience with connecting to SQL server with unbound forms did
not result in the same experience you had. On the other hand, I have not
used the 'Get' and 'Put' methods in any design. (Have you tried using
the 'Getex' and 'Putex' methods which always retrieve values in an
array?) I have just used the 'Insert' and 'Update' methods or passed the
variable through parameters and just allowed a SP to take care of
multiple tables. Are you using ODBC? I once used an ODBC connection to a
SQL server and found it was a dog. Direct ADO-OLE is more appropriate. I
have found when attaching new users performance remain consistent and
flat.

Some of the areas and reasons for using unbound forms, you have not
mentioned. I assume you have only been in offices where there is
unlimited connection licenses and with a very stable and simple LAN
environments.

1. Working with unlimited licenses and bound forms are not always an
option. Try sixty plus users and a SQL server with a dozen connection
license. Not every client can afford $10,000+, but $1,200.00+ is an easy
swallow.

2. Mixed environments that are using Web and Desktop forms or multiple
databases or multiple database types say like SQL and Oracle, are
relatively easy to setup. I could not imagine the same (relative) ease
of design in bound forms.

In conclusion, I agree that you can use bound forms, it is probably more
simple to implement and it can be very functional but when it comes to
flexibility regarding licenses, data handling, data sources and data
delivery, unbound forms are unparalleled. Do not get me wrong. I do not
believe that bound forms do not have their place. Their implementation
is quicker for small contracts but within large complex environments
unbound forms, IMHO, are faster in creation and performance. </comment>

Arthur

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Jim
Lawrence (AccessD)
Sent: Friday, June 11, 2004 2:08 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


Joe:

You should know better than ask that question. It sort of stirs up
things. The following are my personnel guide-lines but they can be
changed but there has to be a very good reason.

1. Bound forms can be used on small Access projects but never on
anything major.

There are a host of pluses and minus on both side.

Facts as I see them:

Bound forms are much easier to implement. The existing operating system
handles access to records, locking, updates while multiple people are
working on a single record, populating the forms, sub-forms etc. When
there are a small number of people accessing a simple MDB database, for
example, performance can be superior.

Unbound forms are harder to implement...properly. All the above
benefits, you as the programmer, must provide. It takes longer to
implement and test. There are a whole range of programming issues that
have to be addressed. It is not for the faint-of-heart or first time
developers.

On the plus side of unbound forms, is that you now have complete control
over every piece of data that is displayed on the form or stored in the
database.

1. You can provide an extensive set of business rules, on just a single
field, if required. 2. Now that you control the data-access layer,
multiple data sources can be accessed and easily integrated. For
example; you can be using a SQL, Oracle and MDB data sources
simultaneously. 3. Data access can be merged deep within your code, so
as to provide a layer of security. (That is one of the reasons I do not
like ODBC connection because they can be easily used by any skilled
client, to gain direct access to protected data sources and because they
are exposed and not imbedded in your code.) 4. Much of the issues around
record-locking, multi-user and the potential data over-writing are
managed through the bigger data engines like SQL and Oracle. It is your
responsibility to use proper transaction controls, monitor return codes
and take appropriate actions. 5. With you now managing the data
connections, remote sites with unstable or slow access, can be carefully
handled, with virtual no data loss or database corruption. 6. Because
you now precisely handle data access, only the specific data sets
required, to populate the current form and sub-forms, are extracted.
Static data for controls can be pulled once at the beginning of a
session and not as each record is accessed. When it comes to the major
sequel databases, the raw data can be extracted, at the server end
through, Stored Procedure and functions calls. To provide better
performance the raw data can then, at the client side, be grouped and
sorted which in some cases will provide up to a seventy percent
performance boost. (Distributive computing). 7. Complete access control
of the data can leverage a small SQL system. For example; given a SQL
DB, only licensed with a dozen connections, sixty plus people can have,
as far as they are concerned, full access. More bang for the buck.

In summary, the downside is that it requires a lot more work to
implement an unbound database, internal documentation and structured
code lay-out has to be very carefully done. I can not stress tidiness
and organization enough. Consider someone who has to go back in to
update the code, that someone might be you.

The upside, is that you, as a programmer, have absolute control, garner
superior performance (on larger systems), better stability and much
better security.

This is my quarter's worth, thank you
Jim


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of Joe
Rojas
Sent: Friday, June 11, 2004 5:38 AM
To: 'dba-sqlserver at databaseadvisors.com'
Subject: RE: [dba-SQLServer] Difference between views and queries


Hi Jim,

What is the argument for not using bound forms?

JR

-----Original Message-----
From: Jim Lawrence (AccessD) [mailto:accessd at shaw.ca]
Sent: Thursday, June 10, 2004 6:46 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries

Hi All:

As to all these issues I would like to dump some of my own comments. At
the risk of saying 'I told you so', I firmly believe that users should:

1. Always (or should I say only), use windows authentication and
judiciously distribute security access, to your SQLxx, to only those who
need it. Appropriate passwords and time limits. 1. Never allow access to
the data except through your program. That means NO to ODBC drivers only
ADO-OLE. 2. In 99% of cases, control is handled through SPs. 3. And the
biggy never, never use bound forms to access SQLxx data. I have been
whining about that for years, a position that M$ has also fully
supported. 4. You, as the programmer, should design your program to
carefully validate all requests and data before they are posted.

I may be already talking to the converted so you can ignore this; if
not..Get on the program.

Seeing we at in the midst of an election campaign, a good stump,
political speech is the expected. Jim


-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of
Francisco H Tapia
Sent: Thursday, June 10, 2004 1:55 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Difference between views and queries


Andy,
  SQL Server is not Access on steriods, it's a diffrent engine, and thus
requires a new level of thinking towards your database engine.  It's NOT
that you couldn't, you can do anything, heck if you wanted to you can
set up your SQL Server with a blank SA password or SA as the password.
For all that matters, and avoiding all SQL Server authentication, just
use NT authentication and enable guest users :).

There have been quite a few white papers circulating on why you
"wouldn't" use dynamic sql w/ your sql server (check out
www.sqlservercentral.com, a fine resource) but the 2 very critical
factors include performance and also quite possible damage to your data.

It is entirely possible for your sql statement to read in this manner,
lets's say that you are Selecting Data from a table and you have a
combobox to help choose data, so your SQL Statment looks like this:

"Select CompanyName, CompanyAttribute1, pKey FROM tblCompany WHERE
CompanyAttribute1 = '" & me.cboMyBOX & "'", If I was a malicious user on
your system and I have direct access to tables, and if you're doing
statements like the above it is entirely plausible that you also have
"INSERT" statements thus you are giving more than just simple SELECT
access to these tables., thus with some malformed selection I can add
this in the select

'; DELETE FROM tblCompany; SELECT '

your final statement would look like this

Select CompanyName, CompanyAttribute1, pKey FROM tblCompany WHERE
CompanyAttribute1 = ''; DELETE FROM tblCompany; SELECT ''

Now your entire COMPANY table has been wiped out, while it is completely
possible to restore your db up to the minute, you've still lost some
downtime given that you had ONE bad apple in the bunch.

Besides the sql injection threats, you also suffer from a
NON-pre-compiled statement, thus your data could conceptually be
returned a lot faster if you let it, simply by creating a view or stored
procedure.  By the way just because you are using a stored procedure
does not make you completly excempt of sql injections, if you are using
dynamic sql within that procedure you are still open to these kind of
attacks and your stored procedure is always re-comiled and thus suffers
from the same performance deficits.


Andy Lacey wrote On 6/10/2004 1:27 PM:

>But, Francisco, if I was porting to SQL Server my Access app which 
>builds SELECT statements dynamically all of the time for many and 
>various situations are you saying I couldn't, or shouldn't or 
>something?
>
>-- Andy Lacey
>http://www.minstersystems.co.uk
>
>
>
>>-----Original Message-----
>>From: dba-sqlserver-bounces at databaseadvisors.com
>>[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of 
>>Francisco H Tapia
>>Sent: 10 June 2004 20:58
>>To: dba-sqlserver at databaseadvisors.com
>>Subject: Re: [dba-SQLServer] Difference between views and queries
>>
>>
>>jwcolby wrote On 6/10/2004 9:33 AM:
>>
>>
>>
>>>Can anyone explain the difference between a view and a query?  Views 
>>>use a query, plus the view keyword.  I have a couple of books that I 
>>>have read the chapter on Views, but I so far haven't managed
>>>
>>>
>>to "get"
>>
>>
>>>why you wouldn't just use the query itself instead of
>>>
>>>
>>turning it into a
>>
>>
>>>view.
>>>
>>>
>>>
>>>
>>A query is a request for an Access Database, however for Sql Server 
>>you would either use a View or Stored Procedure to return the data you

>>wanted... you are also able to use dynamic SQL to retrieve the 
>>information you need.  ANY request given to the SQL Server engine is 
>>managed by the engine, unless you are running Remote servers (iirc).
>>
>>In Sql Server, it is TABOO, nay, GENERALLY bad practice to use dynamic

>>sql because of the implication of SQL INJECTION attacks, this poses a 
>>"real" security threat to your database. and your server.
>>
>>another reason to use a VIEW over dynamic sql is that it is 
>>pre-optimized by the SQL Server Engine and thus runs faster and more 
>>efficient.  Additionally if you use Dynamic SQL then your individual 
>>users who access the server will need EXPLICIT "SELECT" permissions by

>>you, which is another 'bad' practice.  In SQL Server you make data 
>>available to your users via VIEWs and Stored Procedures or some other 
>>secure way in order to protect your tables and it's data.
>>
>>ya get wot I mean?
>>
>>--
>>-Francisco
>>
>>
>>_______________________________________________
>>dba-SQLServer mailing list
>>dba-SQLServer at databaseadvisors.com
>>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>>http://www.databaseadvisors.com
>>



From artful at rogers.com  Mon Jun 28 16:04:29 2004
From: artful at rogers.com (Arthur Fuller)
Date: Mon, 28 Jun 2004 17:04:29 -0400
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <40E04A57.8050402@verizon.net>
Message-ID: <023501c45d53$80831700$6601a8c0@rock>

Call me stupid, ignorant, inexperienced, whatever, but so far I have
used "DENY" even once. Maybe that means my clients are victims of bad
design, but so far I have done virtually everything additively, i.e.

Levels:
1. access to a very few sprocs, a few of which do inserts, most of which
permit lookups (for cities, states, products, etc.)
2. ability to update records in some tables
3. ability to create and update records in some tables (only certain
users can add products or change their prices, etc.)
4. ability to run the sprocs underlying various management reports
(grained by department, i.e. warehouse folks don't need to see most of
the reports in the system, just the ones relevant to loading boxcars,
etc.)
5. senior managers, who can view any report.
6. President of the company, who thinks he can do anything but actually
can't :-)
7. Me: I can do ANYthing. Trust me :-)

In some (typically large) firms, Me might not be able to do ANYthing.
For example, as a developer, I might not be able to create a new sproc,
or edit an existing one. I might instead have to request a new sproc
that returns X or edit an existing sproc to also include column Y. In a
situation like this, we have to add (at the least) 

8. DBA: can create, destroy, edit anything

And revise 7 to read:

7. Me: I have access (as developer) to any sproc in the system, but
cannot create, edit or delete any sproc. I must request changes from
DBA.

Maybe it's more efficient to create a new role and then grant certain
accesses while denying others. That approach was simply too hard to get
my mind around. I opted for the strictly additive approach. I could be
wrong, and am prepared to be corrected. The approach I took was to
create as many roles as I needed in order to assemble a strictly
additive structure.

For example, on first pass I let any data-entry person add cities. This
quickly proved foolish. So I created a role that could add data to
lookup tables (simplifying). Anyone in this role can add to/edit lookup
tables such as Cities, States, Countries, etc. Different from this is
the ability to add to/edit tables such as Customers (which most of the
time is a lookup, but fundamentally different than Cities). From there,
it's easy to create a role that can do both.

Ok, I am simple-minded. But it's too complex for me to think of a role
minus certain abilities, because then I have to go in both directions. I
prefer to think of roles strictly in terms of what they can do rather
than what they cannot do. Then I can create a new role and say, "include
data-entry, lookup-table edits, customer-creation and nothing else."
After that, for a new hire I simply assign her to the requisite role.

Maybe that means that I create way too many roles. But so far it seems
like the simplest path to me. I admit that until now I haven't really
given this a lot of thought, but now it occurs to me that there is an
algorithm to solve this.

Let's suppose 100 tables and 10 roles. Each higher role gets access to
all lower roles, i.e. role 1 can access 10 tables, role 2 those same 10
plus 10 new ones, role 3 10 additional tables, etc.

That's a simple case. Complicating it a bit more, suppose role 3a can
access the first 20 tables but only view the next 10. I suppose you
could create 3a by cloning 3 and subtracting the insert/update
privileges for tables 21-30. That would work; it just never occurs to me
to do it that way. Instead I would add the first 20 tables and then add
the next 10, specifying view-only.

Upon consideration, I can't really defend the way I do it, except to say
that conceptually it works for me. The other approach may have
advantages that I'm not seeing, such as performance increase,
architectural simplicity, etc. But so far I don't see them.

I've been wrong before, and this could be yet another occasion of same.

Back to the original subject.... Would someone kindly supply an occasion
in which no sproc can handle the requirement, and dynamic SQL is
necessary? 

I am NOT saying that any single sproc can handle all the requirements; I
am including the possibility that I write one sproc for each situation,
passing various parameters, and that the front end examines the parms
and decides which sproc to invoke.

For example, imagine a form that offers 3 combo-boxes or somesuch, and
tracks in which order I make my selections... One is State/Province, and
one is a DateRange and the third is a CompanyName thing that can handle
wildcards. You fill in the CompanyName thing with "W*", the State thing
with "M*" or "N*" (which I think results in 5 states each", and any
given date range.

I can write one or more sprocs that can handle this input, and it won't
take long. Even granted that the sequence in which you fill in the
controls matters (i.e. sort order), a small number of sprocs can do
this. And if you really want to stretch the point, a single sproc could
receive the sort order and deal with it using CASE statements (though
emphatically that is NOT my chosen approach).

So what I would like someone to offer is a situation in which one or
more sprocs cannot handle the input parameters. Ideally, work it against
Northwind so I can easily check my assertion, and try to come up with a
sproc that can handle your various inputs (the one sproc might invoke
another, depending on conditions; you have to grant me that).

I don't mean to issue this as an in-your-face challenge, but rather to
invite you to teach me this non-obvious lesson.

Arthur




From HARVEYF1 at WESTAT.com  Tue Jun 29 09:47:03 2004
From: HARVEYF1 at WESTAT.com (Francis Harvey)
Date: Tue, 29 Jun 2004 10:47:03 -0400
Subject: [dba-SQLServer] Difference between views and queries
Message-ID: <446DDE75CFC7E1438061462F85557B0F0BFF27@remail2.westat.com>

Francisco,

I would like to consider the opinion of someone who shares my namesake
as seriously as possible, but in this case, I believe you suffer from
Arthur's problem of a lack of experience with the very specific
problems I cited. It is fine to talk about not using dynamic SQL
in general when using SQL Server, but just as with normalization,
there are exceptions and no one should be stating it as an absolute
rule or bad practice until they have reviewed the problems I
mentioned. Again, I will state, for those particular problems,
dynamic SQL is often the superior solution.

Also, the "scaling" issue is teetering awfully close to using FUD.
You can always use any programming method incorrectly, but
correctly written dynamic SQL does not suffer from the horrible
efficiency loss that not having a cached query plan would seem to
imply. Similarly, the "time spent" argument is bad logic. I don't
spend less time on my dynamic SQL solutions, I spend more time
because the problems are difficult. Adding more time for a static SQL
solution will not result in a better design or even a working design
in some cases.

I don't think you, Arthur or I are in disagreement over security, I
just didn't like the oversimplified way security was described, so I
chose to emphasize a particular point. I think this is an important
part that should be highlighted.

Francis R Harvey III
WB 303, (301)294-3952
harveyf1 at westat.com


> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com 
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf 
> Of Francisco H Tapia
> Sent: Monday, June 28, 2004 12:42 PM
> To: dba-sqlserver at databaseadvisors.com
> Subject: Re: [dba-SQLServer] Difference between views and queries
> 
> 
> Francis,
>    I respectfully agree w/ Arthur on this.  Dynamic SQL as a rule, is 
> bad design.  Many times over you will find that there are comparable 
> solutions that often meet the demand much better, and "scale" much 
> better than that of dynamic sql.  There is no "ONE" right way 
> of doing 
> things, that is the nature of this business.  However 
> justifying dynamic 
> sql because of some time spent on design is imnsho incorrect. 
>  You will 
> often find more times that enabling users/roles via Views/Sprocs and 
> Functions to be far superior solutions than to open wide dynamic sql.
> 
> re: security.
> Of course if you deny permissions on any object the take 
> precedence over 
> allows, this is the nature of security.  That is why you must be 
> explicitly "SURE" when making DENY requests on any object.  
> NOT giving 
> rights to an object does not equeal REJECT.
> 
> If I do not give a user rights to a view, under Role1, but 
> then give him 
> rights to that object via Role2.  There will be 0 issues w/ 
> accessability.  However If by poor planning I had a "REJECT" 
> rights in 
> Role1, then I'd have the issues you are stating.
> 
> 
> 
> 
> Francis Harvey wrote On 6/25/2004 2:24 PM:
> 
> >Arthur,
> >
> >Do some research on the basic solutions for SQL that has to 
> adjust for
> >varying databases, conditions (dynamic search), or servers (different
> >SQL dialects). Some designs also call for encapsulating 
> business logic
> >outside of the data tier. In these situations, dynamic SQL is often
> >the only logical choice. I have only had to deal with dynamic search
> >myself, but this is enough to convince me of its usefulness.
> >
> >Describing permissions solely as additive in nature is 
> incorrect. This
> >is the point I was making.
> >
> >Francis R Harvey III
> >WB 303, (301)294-3952
> >harveyf1 at westat.com
<snip>


From HARVEYF1 at WESTAT.com  Tue Jun 29 10:09:45 2004
From: HARVEYF1 at WESTAT.com (Francis Harvey)
Date: Tue, 29 Jun 2004 11:09:45 -0400
Subject: [dba-SQLServer] Difference between views and queries
Message-ID: <446DDE75CFC7E1438061462F85557B0F0BFF28@remail2.westat.com>

Arthur,

I don't think anyone cares if you use the capability, however, I don't
see how you can describe security while leaving such a key point out.
I don't use GUID's in my Access designs, but I would hardly try to
describe all of the autonumber capabilities and avoid mentioning them.
I am not clear whether you are arguing against them, which I would
have a problem with, or whether you are just stating why you don't use
them, so I will just assume you don't care if I use DENY permissions
as long as I don't care if you don't. However, please try not to
unfairly ignore the poor misbegotten creatures in future security
summaries, :-). Especially, don't describe all permissions as
additive, brr, just sends shivers up my spine.

As to your challenge to produce a task requiring dynamic SQL, the
answer from me is no. I have already given you suitable searchable 
phrases for the main justified uses of dynamic SQL that I am aware of,
and I lack John Colby's seemingly infinite patience for prolonging a
discussion by holding up both sides of the argument (trust me, this is
a compliment, I only wish I could be that intense).

Francis R Harvey III
WB 303, (301)294-3952
harveyf1 at westat.com


From my.lists at verizon.net  Tue Jun 29 10:49:03 2004
From: my.lists at verizon.net (Francisco H Tapia)
Date: Tue, 29 Jun 2004 08:49:03 -0700
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <446DDE75CFC7E1438061462F85557B0F0BFF27@remail2.westat.com>
References: <446DDE75CFC7E1438061462F85557B0F0BFF27@remail2.westat.com>
Message-ID: <40E18F6F.8050604@verizon.net>

Francis,
   In my current project, there is "ONE" sproc that is still dynamic 
sql.  This sproc was developed in the early stages of the desgin almost 
2 years ago, and it was never upgraded to a full static sql because of 
lack of time.  In fact when revisiting it, it is actually fairly 
straight forward to fix the problematic dynamic SQL and once again 
remove "SELECT" access from the 3 tables it points to.  In fact it was 
written as dynamic sql because of lack of time.  While I did take extra 
steps to help validate and protect against sql injections, this 
particular sproc is 'wrong', had we had more time and experiance at the 
time, it would have been done as static sql the first time.  In fact all 
new sprocs are evaluated repeatedly if Dynamic Sql appears to be the 
"only" choice.  Unlike normalization, if your database stresses to be 
secure, then you will never acheive this buy allowing dynamic SQL to be 
passed through in such fashions.  The scaling issues are not insane.  
You will have a better query plan by having stored static sql and will 
be able to provide the data that much faster w/ less cost to the 
server.  additionally the time spent logic is not bad logic, because if 
you can do it either way, why "WOULDNT" you do it as static sql?

Lastly, Security.  Security when working in a Network environment is 
always done as additive.  You join the Service Group, the HR Group, the 
Accounting Group. so on and so forth.  IF by chance the sysadmin locks 
out a particular access at any level in those groups, well anyone in 
that DENY group will never "GAIN" access to the respective data store.  
This is the fashion in which SQL Server security works.  SURE you can do 
it any way you want.  But addtive is the streamline way to go.  IF I do 
not grant you access, you can not select/insert/update/delete.  If I 
GRANT you access to SELECT, then you will be able to do so.  HOWEVER, 
Denying you access to read from the table will never GIVE you access 
again via that login, which is why ONE should be extremly careful of how 
you give and reject access.



Francis Harvey wrote On 6/29/2004 7:47 AM:

>Francisco,
>
>I would like to consider the opinion of someone who shares my namesake
>as seriously as possible, but in this case, I believe you suffer from
>Arthur's problem of a lack of experience with the very specific
>problems I cited. It is fine to talk about not using dynamic SQL
>in general when using SQL Server, but just as with normalization,
>there are exceptions and no one should be stating it as an absolute
>rule or bad practice until they have reviewed the problems I
>mentioned. Again, I will state, for those particular problems,
>dynamic SQL is often the superior solution.
>
>Also, the "scaling" issue is teetering awfully close to using FUD.
>You can always use any programming method incorrectly, but
>correctly written dynamic SQL does not suffer from the horrible
>efficiency loss that not having a cached query plan would seem to
>imply. Similarly, the "time spent" argument is bad logic. I don't
>spend less time on my dynamic SQL solutions, I spend more time
>because the problems are difficult. Adding more time for a static SQL
>solution will not result in a better design or even a working design
>in some cases.
>
>I don't think you, Arthur or I are in disagreement over security, I
>just didn't like the oversimplified way security was described, so I
>chose to emphasize a particular point. I think this is an important
>part that should be highlighted.
>
>Francis R Harvey III
>WB 303, (301)294-3952
>harveyf1 at westat.com
>
>
>  
>
>>-----Original Message-----
>>From: dba-sqlserver-bounces at databaseadvisors.com 
>>[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf 
>>Of Francisco H Tapia
>>Sent: Monday, June 28, 2004 12:42 PM
>>To: dba-sqlserver at databaseadvisors.com
>>Subject: Re: [dba-SQLServer] Difference between views and queries
>>
>>
>>Francis,
>>   I respectfully agree w/ Arthur on this.  Dynamic SQL as a rule, is 
>>bad design.  Many times over you will find that there are comparable 
>>solutions that often meet the demand much better, and "scale" much 
>>better than that of dynamic sql.  There is no "ONE" right way 
>>of doing 
>>things, that is the nature of this business.  However 
>>justifying dynamic 
>>sql because of some time spent on design is imnsho incorrect. 
>> You will 
>>often find more times that enabling users/roles via Views/Sprocs and 
>>Functions to be far superior solutions than to open wide dynamic sql.
>>
>>re: security.
>>Of course if you deny permissions on any object the take 
>>precedence over 
>>allows, this is the nature of security.  That is why you must be 
>>explicitly "SURE" when making DENY requests on any object.  
>>NOT giving 
>>rights to an object does not equeal REJECT.
>>
>>If I do not give a user rights to a view, under Role1, but 
>>then give him 
>>rights to that object via Role2.  There will be 0 issues w/ 
>>accessability.  However If by poor planning I had a "REJECT" 
>>rights in 
>>Role1, then I'd have the issues you are stating.
>>
>>
>>
>>
>>Francis Harvey wrote On 6/25/2004 2:24 PM:
>>
>>    
>>
>>>Arthur,
>>>
>>>Do some research on the basic solutions for SQL that has to 
>>>      
>>>
>>adjust for
>>    
>>
>>>varying databases, conditions (dynamic search), or servers (different
>>>SQL dialects). Some designs also call for encapsulating 
>>>      
>>>
>>business logic
>>    
>>
>>>outside of the data tier. In these situations, dynamic SQL is often
>>>the only logical choice. I have only had to deal with dynamic search
>>>myself, but this is enough to convince me of its usefulness.
>>>
>>>Describing permissions solely as additive in nature is 
>>>      
>>>
>>incorrect. This
>>    
>>
>>>is the point I was making.
>>>
>>>Francis R Harvey III
>>>WB 303, (301)294-3952
>>>harveyf1 at westat.com
>>>      
>>>
><snip>
>
>
>  
>


-- 
-Francisco




From my.lists at verizon.net  Tue Jun 29 10:51:27 2004
From: my.lists at verizon.net (Francisco H Tapia)
Date: Tue, 29 Jun 2004 08:51:27 -0700
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <446DDE75CFC7E1438061462F85557B0F0BFF28@remail2.westat.com>
References: <446DDE75CFC7E1438061462F85557B0F0BFF28@remail2.westat.com>
Message-ID: <40E18FFF.6030206@verizon.net>

Francis Harvey wrote On 6/29/2004 8:09 AM:

>As to your challenge to produce a task requiring dynamic SQL, the
>answer from me is no. I have already given you suitable searchable 
>phrases for the main justified uses of dynamic SQL that I am aware of,
>and I lack John Colby's seemingly infinite patience for prolonging a
>discussion by holding up both sides of the argument (trust me, this is
>a compliment, I only wish I could be that intense).
>  
>
I must have missed that post where you provided such searchable 
keywords; could you repost again?

Thanks,

-- 
-Francisco




From HARVEYF1 at WESTAT.com  Tue Jun 29 12:10:53 2004
From: HARVEYF1 at WESTAT.com (Francis Harvey)
Date: Tue, 29 Jun 2004 13:10:53 -0400
Subject: [dba-SQLServer] Difference between views and queries
Message-ID: <446DDE75CFC7E1438061462F85557B0F0BFF29@remail2.westat.com>

Francisco,

I am not going to debate a straw man example that is specifically
chosen to highlight the supposed "evils" of dynamic SQL. It was done
because there wasn't sufficient time, lack of experience, can be
done better with static SQL, etc; are all easy points to win against
using dynamic SQL if you were somehow naive enough to believe this
actually represented a realistic example of when it should be used.
It doesn't, so I won't.

Security is a different issue, and I am willing to discuss it, but
first a question, do you honestly believe that security considerations
should outweigh any other consideration? I don't get that impression 
since you have allowed the sproc to continue in its present form, so I
wonder at your statement that you cannot achieve security using
dynamic SQL. Basically, there is a certain level of security I am
comfortable with and dynamic SQL does not violate it. I can go into
more detail, but I don't get the impression that you would protest
this balancing anyway.

I didn't say scaling issues were insane. I implied that most people
haven't actually done tests to see how much performance gain you lose
by not having a cached query plan, which is not even always the case
for dynamic SQL in any event. IOW, you will not always get a better
query plan (in fact, for complex dynamic searches, you are virtually
guaranteed that a generic static solution would have a very bad
query plan) and it will not always have less cost.

Again, aren't we all basically in agreement except you both have this
addiction to using the word additive to describe what clearly has a
non-additive element, DENY permissions? You keep restating what all
three of us already know, and then you and Arthur seem to make the
leap from not liking to use DENY permissions to implying that only
the additive model should be used. Guess what, just like with dynamic
SQL, my needs are apparently more complex then yours, and you cannot
propose to give a meaningful summary of SQL Server security while
ignoring one of its key features. It wasn't added as a lark; it was
added to provide additional security options. If you don't want to
use it then don't, stop trying to convince me of its benefits. I
use what is appropriate, and DENY permissions are appropriate for
my needs. Unless you are saying there is some reason you wouldn't
use DENY permissions if needed, I can't do any better than the BOL
examples on why they are needed. Find a fault with their examples
and this might become an interesting discussion. Otherwise, I will
repeat that to have a true security summary you must also mention
DENY permissions which are not additive in nature.

Francis R Harvey III
WB 303, (301)294-3952
harveyf1 at westat.com


> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com 
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf 
> Of Francisco H Tapia
> Sent: Tuesday, June 29, 2004 11:49 AM
> To: dba-sqlserver at databaseadvisors.com
> Subject: Re: [dba-SQLServer] Difference between views and queries
> 
> 
> Francis,
>    In my current project, there is "ONE" sproc that is still dynamic 
> sql.  This sproc was developed in the early stages of the 
> desgin almost 
> 2 years ago, and it was never upgraded to a full static sql 
> because of 
> lack of time.  In fact when revisiting it, it is actually fairly 
> straight forward to fix the problematic dynamic SQL and once again 
> remove "SELECT" access from the 3 tables it points to.  In 
> fact it was 
> written as dynamic sql because of lack of time.  While I did 
> take extra 
> steps to help validate and protect against sql injections, this 
> particular sproc is 'wrong', had we had more time and 
> experiance at the 
> time, it would have been done as static sql the first time.  
> In fact all 
> new sprocs are evaluated repeatedly if Dynamic Sql appears to be the 
> "only" choice.  Unlike normalization, if your database stresses to be 
> secure, then you will never acheive this buy allowing dynamic 
> SQL to be 
> passed through in such fashions.  The scaling issues are not insane.  
> You will have a better query plan by having stored static sql 
> and will 
> be able to provide the data that much faster w/ less cost to the 
> server.  additionally the time spent logic is not bad logic, 
> because if 
> you can do it either way, why "WOULDNT" you do it as static sql?
> 
> Lastly, Security.  Security when working in a Network environment is 
> always done as additive.  You join the Service Group, the HR 
> Group, the 
> Accounting Group. so on and so forth.  IF by chance the 
> sysadmin locks 
> out a particular access at any level in those groups, well anyone in 
> that DENY group will never "GAIN" access to the respective 
> data store.  
> This is the fashion in which SQL Server security works.  SURE 
> you can do 
> it any way you want.  But addtive is the streamline way to 
> go.  IF I do 
> not grant you access, you can not select/insert/update/delete.  If I 
> GRANT you access to SELECT, then you will be able to do so.  HOWEVER, 
> Denying you access to read from the table will never GIVE you access 
> again via that login, which is why ONE should be extremly 
> careful of how 
> you give and reject access.
<snip>


From HARVEYF1 at WESTAT.com  Tue Jun 29 12:21:30 2004
From: HARVEYF1 at WESTAT.com (Francis Harvey)
Date: Tue, 29 Jun 2004 13:21:30 -0400
Subject: [dba-SQLServer] Difference between views and queries
Message-ID: <446DDE75CFC7E1438061462F85557B0F0BFF2A@remail2.westat.com>

Francisco,

Francis Harvey wrote On 6/25/2004 2:24 PM:

>Do some research on the basic solutions for SQL that has to adjust for
>varying databases, conditions (dynamic search), or servers (different
>SQL dialects). Some designs also call for encapsulating business logic
>outside of the data tier. In these situations, dynamic SQL is often
>the only logical choice. I have only had to deal with dynamic search
>myself, but this is enough to convince me of its usefulness.

Basically, some of them aren't really up for debate. If you need your
business logic outside of your data tier for business or performance
reasons, then it isn't a programming choice anymore. Similarly, I
would think with needing to speak more than one SQL language in terms
of maintenance or design considerations.

Francis R Harvey III
WB 303, (301)294-3952
harveyf1 at westat.com


From my.lists at verizon.net  Tue Jun 29 16:16:10 2004
From: my.lists at verizon.net (Francisco H Tapia)
Date: Tue, 29 Jun 2004 14:16:10 -0700
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <446DDE75CFC7E1438061462F85557B0F0BFF29@remail2.westat.com>
References: <446DDE75CFC7E1438061462F85557B0F0BFF29@remail2.westat.com>
Message-ID: <40E1DC1A.3000008@verizon.net>

Francis Harvey wrote On 6/29/2004 10:10 AM:

>Francisco,
>
>I am not going to debate a straw man example that is specifically
>chosen to highlight the supposed "evils" of dynamic SQL. It was done
>because there wasn't sufficient time, lack of experience, can be
>done better with static SQL, etc; are all easy points to win against
>using dynamic SQL if you were somehow naive enough to believe this
>actually represented a realistic example of when it should be used.
>It doesn't, so I won't.
>
>  
>
every problem that people encounter where Dynamic SQL appears to be the 
only or best solution is often looked at in this light. If you don't see 
it, well then I guess there is nothing more to discuss.

>Security is a different issue, and I am willing to discuss it, but
>first a question, do you honestly believe that security considerations
>should outweigh any other consideration? I don't get that impression 
>since you have allowed the sproc to continue in its present form, so I
>wonder at your statement that you cannot achieve security using
>dynamic SQL. Basically, there is a certain level of security I am
>comfortable with and dynamic SQL does not violate it. I can go into
>more detail, but I don't get the impression that you would protest
>this balancing anyway.
>
>  
>
Security is always a balance of how much data is allowed through w/o 
comprimising the rest of the system.  Our particular problem w/ our 
sproc was one because of "TIME" and because our user base currently 
lacks the knowledge to exploit this has been the determining factor to 
NOT get this sproc up and running in the correct fashion, It is 
currently on our list "todo" and will be assimilated (so to speak).

>I didn't say scaling issues were insane. I implied that most people
>haven't actually done tests to see how much performance gain you lose
>by not having a cached query plan, which is not even always the case
>for dynamic SQL in any event. IOW, you will not always get a better
>query plan (in fact, for complex dynamic searches, you are virtually
>guaranteed that a generic static solution would have a very bad
>query plan) and it will not always have less cost.
>
>Again, aren't we all basically in agreement except you both have this
>addiction to using the word additive to describe what clearly has a
>non-additive element, DENY permissions? You keep restating what all
>three of us already know, and then you and Arthur seem to make the
>leap from not liking to use DENY permissions to implying that only
>the additive model should be used. Guess what, just like with dynamic
>SQL, my needs are apparently more complex then yours, and you cannot
>propose to give a meaningful summary of SQL Server security while
>ignoring one of its key features. It wasn't added as a lark; it was
>added to provide additional security options. If you don't want to
>use it then don't, stop trying to convince me of its benefits. I
>use what is appropriate, and DENY permissions are appropriate for
>my needs. Unless you are saying there is some reason you wouldn't
>use DENY permissions if needed, I can't do any better than the BOL
>examples on why they are needed. Find a fault with their examples
>and this might become an interesting discussion. Otherwise, I will
>repeat that to have a true security summary you must also mention
>DENY permissions which are not additive in nature.
>
>  
>
Security is Additive.  BOL states to be explicitly careful when issuing 
DENY seucurity as it will take precedence over any GRANTs and therefor 
you will only be able to grant premissions if the user is removed from 
any ROLES that have DENY rights.  It works this way in NT security as 
well.   There is nothing diffrent or even remotely obscure in this 
topology.  You just have to make sure you realize you've issued DENYs.  
And of course there are situtations where DENYs are necessary.  But I've 
yet to find a solution where Dynamic SQL was the only out. (or the better).

-- 
-Francisco




From HARVEYF1 at WESTAT.com  Tue Jun 29 17:21:44 2004
From: HARVEYF1 at WESTAT.com (Francis Harvey)
Date: Tue, 29 Jun 2004 18:21:44 -0400
Subject: [dba-SQLServer] Difference between views and queries
Message-ID: <446DDE75CFC7E1438061462F85557B0F0481E92C@remail2.westat.com>

Francisco,

Give me a break. If you haven't done the research to find an actual
example somebody would agree to as valid usage of dynamic SQL and then
just start coming up with reasons why your sproc wouldn't be better as
dynamic SQL, you aren't interested in actually debating its merits.
You apparently prefer to debate your own version of dynamic SQL which
is easily bested, thus suitably earning its title of straw man. I
never claimed your sproc was suitable for dynamic SQL, and I
certainly won't argue its merits on that inappropriate example.

To my knowledge, you have posted nothing suggesting you have the
experience to classify "every problem that people encounter where
Dynamic SQL appears to be the only or best solution". Have you done
the minimal research I suggested? If you won't do it, then I have
already stated I am not a John Colby, willing to do the research for
you. I hold up my side of the debate; you are responsible for yours.

So, we can agree security is a balance? Thus, saying dynamic SQL means
you must have an unsecured system is not strictly true depending on
where you put the balance. For us, this database is accessed via only
one application which codes the dynamic SQL according to specific user
choices. For us, this is an acceptable security balance for the
performance we get from dynamic SQL, and we consider this to be a
secured system.

Again with the additive. I am starting to wonder whether you are
reading my comments as you simply restate material that everybody
involved: Arthur, you, myself; already knows. Fine, I'll agree not to
object to the additive adjective if in future summaries everyone will
agree to mention DENY as well if only in passing. Please, at the very
least, don't feel required to requote BOL information again. Argh.

Your experience means nothing to me as mine should mean nothing to you.
I don't care if you've never had a use for a linked server, UDF, or
anything else in SQL server. I have given you the terms to search for
exactly because you seem to have had no experience with SQL that
needs to be dynamic. For you to then complain that you haven't seen
any examples is a bit disingenuous. Go look. Or don't. Whatever. Until
then, enjoy beating up your straw man.

Francis R Harvey III
WB 303, (301)294-3952
harveyf1 at westat.com

> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com 
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf 
> Of Francisco H Tapia
> Sent: Tuesday, June 29, 2004 5:16 PM
> To: dba-sqlserver at databaseadvisors.com
> Subject: Re: [dba-SQLServer] Difference between views and queries
> 
> 
> Francis Harvey wrote On 6/29/2004 10:10 AM:
> 
> >Francisco,
> >
> >I am not going to debate a straw man example that is specifically
> >chosen to highlight the supposed "evils" of dynamic SQL. It was done
> >because there wasn't sufficient time, lack of experience, can be
> >done better with static SQL, etc; are all easy points to win against
> >using dynamic SQL if you were somehow naive enough to believe this
> >actually represented a realistic example of when it should be used.
> >It doesn't, so I won't.
> >
> >  
> >
> every problem that people encounter where Dynamic SQL appears 
> to be the 
> only or best solution is often looked at in this light. If 
> you don't see 
> it, well then I guess there is nothing more to discuss.
> 
> >Security is a different issue, and I am willing to discuss it, but
> >first a question, do you honestly believe that security 
> considerations
> >should outweigh any other consideration? I don't get that impression 
> >since you have allowed the sproc to continue in its present 
> form, so I
> >wonder at your statement that you cannot achieve security using
> >dynamic SQL. Basically, there is a certain level of security I am
> >comfortable with and dynamic SQL does not violate it. I can go into
> >more detail, but I don't get the impression that you would protest
> >this balancing anyway.
> >
> >  
> >
> Security is always a balance of how much data is allowed through w/o 
> comprimising the rest of the system.  Our particular problem w/ our 
> sproc was one because of "TIME" and because our user base currently 
> lacks the knowledge to exploit this has been the determining 
> factor to 
> NOT get this sproc up and running in the correct fashion, It is 
> currently on our list "todo" and will be assimilated (so to speak).
> 
> >I didn't say scaling issues were insane. I implied that most people
> >haven't actually done tests to see how much performance gain you lose
> >by not having a cached query plan, which is not even always the case
> >for dynamic SQL in any event. IOW, you will not always get a better
> >query plan (in fact, for complex dynamic searches, you are virtually
> >guaranteed that a generic static solution would have a very bad
> >query plan) and it will not always have less cost.
> >
> >Again, aren't we all basically in agreement except you both have this
> >addiction to using the word additive to describe what clearly has a
> >non-additive element, DENY permissions? You keep restating what all
> >three of us already know, and then you and Arthur seem to make the
> >leap from not liking to use DENY permissions to implying that only
> >the additive model should be used. Guess what, just like with dynamic
> >SQL, my needs are apparently more complex then yours, and you cannot
> >propose to give a meaningful summary of SQL Server security while
> >ignoring one of its key features. It wasn't added as a lark; it was
> >added to provide additional security options. If you don't want to
> >use it then don't, stop trying to convince me of its benefits. I
> >use what is appropriate, and DENY permissions are appropriate for
> >my needs. Unless you are saying there is some reason you wouldn't
> >use DENY permissions if needed, I can't do any better than the BOL
> >examples on why they are needed. Find a fault with their examples
> >and this might become an interesting discussion. Otherwise, I will
> >repeat that to have a true security summary you must also mention
> >DENY permissions which are not additive in nature.
> >
> >  
> >
> Security is Additive.  BOL states to be explicitly careful 
> when issuing 
> DENY seucurity as it will take precedence over any GRANTs and 
> therefor 
> you will only be able to grant premissions if the user is 
> removed from 
> any ROLES that have DENY rights.  It works this way in NT security as 
> well.   There is nothing diffrent or even remotely obscure in this 
> topology.  You just have to make sure you realize you've 
> issued DENYs.  
> And of course there are situtations where DENYs are 
> necessary.  But I've 
> yet to find a solution where Dynamic SQL was the only out. 
> (or the better).
> 
> -- 
> -Francisco
<snip>


From artful at rogers.com  Tue Jun 29 19:08:54 2004
From: artful at rogers.com (Arthur Fuller)
Date: Tue, 29 Jun 2004 20:08:54 -0400
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <446DDE75CFC7E1438061462F85557B0F0BFF27@remail2.westat.com>
Message-ID: <03f701c45e36$6e8632b0$6601a8c0@rock>

All I want is an example that cannot be coded by one or more sprocs.

Arthur

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Francis
Harvey
Sent: Tuesday, June 29, 2004 10:47 AM
To: 'dba-sqlserver at databaseadvisors.com'
Subject: RE: [dba-SQLServer] Difference between views and queries


Francisco,

I would like to consider the opinion of someone who shares my namesake
as seriously as possible, but in this case, I believe you suffer from
Arthur's problem of a lack of experience with the very specific problems
I cited. It is fine to talk about not using dynamic SQL in general when
using SQL Server, but just as with normalization, there are exceptions
and no one should be stating it as an absolute rule or bad practice
until they have reviewed the problems I mentioned. Again, I will state,
for those particular problems, dynamic SQL is often the superior
solution.

Also, the "scaling" issue is teetering awfully close to using FUD. You
can always use any programming method incorrectly, but correctly written
dynamic SQL does not suffer from the horrible efficiency loss that not
having a cached query plan would seem to imply. Similarly, the "time
spent" argument is bad logic. I don't spend less time on my dynamic SQL
solutions, I spend more time because the problems are difficult. Adding
more time for a static SQL solution will not result in a better design
or even a working design in some cases.

I don't think you, Arthur or I are in disagreement over security, I just
didn't like the oversimplified way security was described, so I chose to
emphasize a particular point. I think this is an important part that
should be highlighted.

Francis R Harvey III
WB 303, (301)294-3952
harveyf1 at westat.com


> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf 
> Of Francisco H Tapia
> Sent: Monday, June 28, 2004 12:42 PM
> To: dba-sqlserver at databaseadvisors.com
> Subject: Re: [dba-SQLServer] Difference between views and queries
> 
> 
> Francis,
>    I respectfully agree w/ Arthur on this.  Dynamic SQL as a rule, is
> bad design.  Many times over you will find that there are comparable 
> solutions that often meet the demand much better, and "scale" much 
> better than that of dynamic sql.  There is no "ONE" right way 
> of doing 
> things, that is the nature of this business.  However 
> justifying dynamic 
> sql because of some time spent on design is imnsho incorrect. 
>  You will 
> often find more times that enabling users/roles via Views/Sprocs and 
> Functions to be far superior solutions than to open wide dynamic sql.
> 
> re: security.
> Of course if you deny permissions on any object the take
> precedence over 
> allows, this is the nature of security.  That is why you must be 
> explicitly "SURE" when making DENY requests on any object.  
> NOT giving 
> rights to an object does not equeal REJECT.
> 
> If I do not give a user rights to a view, under Role1, but
> then give him 
> rights to that object via Role2.  There will be 0 issues w/ 
> accessability.  However If by poor planning I had a "REJECT" 
> rights in 
> Role1, then I'd have the issues you are stating.
> 
> 
> 
> 
> Francis Harvey wrote On 6/25/2004 2:24 PM:
> 
> >Arthur,
> >
> >Do some research on the basic solutions for SQL that has to
> adjust for
> >varying databases, conditions (dynamic search), or servers (different

> >SQL dialects). Some designs also call for encapsulating
> business logic
> >outside of the data tier. In these situations, dynamic SQL is often 
> >the only logical choice. I have only had to deal with dynamic search 
> >myself, but this is enough to convince me of its usefulness.
> >
> >Describing permissions solely as additive in nature is
> incorrect. This
> >is the point I was making.
> >
> >Francis R Harvey III
> >WB 303, (301)294-3952
> >harveyf1 at westat.com
<snip>
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com



From my.lists at verizon.net  Tue Jun 29 19:16:01 2004
From: my.lists at verizon.net (Francisco H Tapia)
Date: Tue, 29 Jun 2004 17:16:01 -0700
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <03f701c45e36$6e8632b0$6601a8c0@rock>
References: <03f701c45e36$6e8632b0$6601a8c0@rock>
Message-ID: <40E20641.5010000@verizon.net>

me too, but all he wants is for you and me to go out and look for our 
own examples that we cannot re-code as a sproc.


Arthur Fuller wrote On 6/29/2004 5:08 PM:

>All I want is an example that cannot be coded by one or more sprocs.
>
>Arthur
>
>-----Original Message-----
>From: dba-sqlserver-bounces at databaseadvisors.com
>[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Francis
>Harvey
>Sent: Tuesday, June 29, 2004 10:47 AM
>To: 'dba-sqlserver at databaseadvisors.com'
>Subject: RE: [dba-SQLServer] Difference between views and queries
>
>
>Francisco,
>
>I would like to consider the opinion of someone who shares my namesake
>as seriously as possible, but in this case, I believe you suffer from
>Arthur's problem of a lack of experience with the very specific problems
>I cited. It is fine to talk about not using dynamic SQL in general when
>using SQL Server, but just as with normalization, there are exceptions
>and no one should be stating it as an absolute rule or bad practice
>until they have reviewed the problems I mentioned. Again, I will state,
>for those particular problems, dynamic SQL is often the superior
>solution.
>
>Also, the "scaling" issue is teetering awfully close to using FUD. You
>can always use any programming method incorrectly, but correctly written
>dynamic SQL does not suffer from the horrible efficiency loss that not
>having a cached query plan would seem to imply. Similarly, the "time
>spent" argument is bad logic. I don't spend less time on my dynamic SQL
>solutions, I spend more time because the problems are difficult. Adding
>more time for a static SQL solution will not result in a better design
>or even a working design in some cases.
>
>I don't think you, Arthur or I are in disagreement over security, I just
>didn't like the oversimplified way security was described, so I chose to
>emphasize a particular point. I think this is an important part that
>should be highlighted.
>
>Francis R Harvey III
>WB 303, (301)294-3952
>harveyf1 at westat.com
>
>
>  
>
>>-----Original Message-----
>>From: dba-sqlserver-bounces at databaseadvisors.com
>>[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf 
>>Of Francisco H Tapia
>>Sent: Monday, June 28, 2004 12:42 PM
>>To: dba-sqlserver at databaseadvisors.com
>>Subject: Re: [dba-SQLServer] Difference between views and queries
>>
>>
>>Francis,
>>   I respectfully agree w/ Arthur on this.  Dynamic SQL as a rule, is
>>bad design.  Many times over you will find that there are comparable 
>>solutions that often meet the demand much better, and "scale" much 
>>better than that of dynamic sql.  There is no "ONE" right way 
>>of doing 
>>things, that is the nature of this business.  However 
>>justifying dynamic 
>>sql because of some time spent on design is imnsho incorrect. 
>> You will 
>>often find more times that enabling users/roles via Views/Sprocs and 
>>Functions to be far superior solutions than to open wide dynamic sql.
>>
>>re: security.
>>Of course if you deny permissions on any object the take
>>precedence over 
>>allows, this is the nature of security.  That is why you must be 
>>explicitly "SURE" when making DENY requests on any object.  
>>NOT giving 
>>rights to an object does not equeal REJECT.
>>
>>If I do not give a user rights to a view, under Role1, but
>>then give him 
>>rights to that object via Role2.  There will be 0 issues w/ 
>>accessability.  However If by poor planning I had a "REJECT" 
>>rights in 
>>Role1, then I'd have the issues you are stating.
>>
>>
>>
>>
>>Francis Harvey wrote On 6/25/2004 2:24 PM:
>>
>>    
>>
>>>Arthur,
>>>
>>>Do some research on the basic solutions for SQL that has to
>>>      
>>>
>>adjust for
>>    
>>
>>>varying databases, conditions (dynamic search), or servers (different
>>>      
>>>
>
>  
>
>>>SQL dialects). Some designs also call for encapsulating
>>>      
>>>
>>business logic
>>    
>>
>>>outside of the data tier. In these situations, dynamic SQL is often 
>>>the only logical choice. I have only had to deal with dynamic search 
>>>myself, but this is enough to convince me of its usefulness.
>>>
>>>Describing permissions solely as additive in nature is
>>>      
>>>
>>incorrect. This
>>    
>>
>>>is the point I was making.
>>>
>>>Francis R Harvey III
>>>WB 303, (301)294-3952
>>>harveyf1 at westat.com
>>>      
>>>
><snip>
>_______________________________________________
>dba-SQLServer mailing list
>dba-SQLServer at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>http://www.databaseadvisors.com
>
>_______________________________________________
>dba-SQLServer mailing list
>dba-SQLServer at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>http://www.databaseadvisors.com
>
>
>  
>


-- 
-Francisco




From my.lists at verizon.net  Tue Jun 29 19:16:07 2004
From: my.lists at verizon.net (Francisco H Tapia)
Date: Tue, 29 Jun 2004 17:16:07 -0700
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <446DDE75CFC7E1438061462F85557B0F0481E92C@remail2.westat.com>
References: <446DDE75CFC7E1438061462F85557B0F0481E92C@remail2.westat.com>
Message-ID: <40E20647.5010804@verizon.net>

Francis Harvey wrote On 6/29/2004 3:21 PM:

>Francisco,
>
>Give me a break. If you haven't done the research to find an actual
>example somebody would agree to as valid usage of dynamic SQL and then
>just start coming up with reasons why your sproc wouldn't be better as
>dynamic SQL, you aren't interested in actually debating its merits.
>You apparently prefer to debate your own version of dynamic SQL which
>is easily bested, thus suitably earning its title of straw man. I
>never claimed your sproc was suitable for dynamic SQL, and I
>certainly won't argue its merits on that inappropriate example.
>
>To my knowledge, you have posted nothing suggesting you have the
>experience to classify "every problem that people encounter where
>Dynamic SQL appears to be the only or best solution". Have you done
>the minimal research I suggested? If you won't do it, then I have
>already stated I am not a John Colby, willing to do the research for
>you. I hold up my side of the debate; you are responsible for yours.
>  
>
Francis,
    Of course you are,

>So, we can agree security is a balance? Thus, saying dynamic SQL means
>you must have an unsecured system is not strictly true depending on
>where you put the balance. For us, this database is accessed via only
>one application which codes the dynamic SQL according to specific user
>choices. For us, this is an acceptable security balance for the
>performance we get from dynamic SQL, and we consider this to be a
>secured system.
>
>  
>
There are varying defenitions of security, so you can use whatever 
guidelines.

>Again with the additive. I am starting to wonder whether you are
>reading my comments as you simply restate material that everybody
>involved: Arthur, you, myself; already knows. Fine, I'll agree not to
>object to the additive adjective if in future summaries everyone will
>agree to mention DENY as well if only in passing. Please, at the very
>least, don't feel required to requote BOL information again. Argh.
>  
>

>Your experience means nothing to me as mine should mean nothing to you.
>I don't care if you've never had a use for a linked server, UDF, or
>anything else in SQL server. I have given you the terms to search for
>exactly because you seem to have had no experience with SQL that
>needs to be dynamic. For you to then complain that you haven't seen
>any examples is a bit disingenuous. Go look. Or don't. Whatever. Until
>then, enjoy beating up your straw man.
>  
>
Only if you beat up yours first.

-- 
-Francisco




From artful at rogers.com  Tue Jun 29 19:18:52 2004
From: artful at rogers.com (Arthur Fuller)
Date: Tue, 29 Jun 2004 20:18:52 -0400
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <446DDE75CFC7E1438061462F85557B0F0BFF29@remail2.westat.com>
Message-ID: <03f801c45e37$d314bb60$6601a8c0@rock>

OK, we'll let you off the hook due to insufficient time. Fine. Point
remains unproven, however.

I still pose the challenge:

Give me a situation in which a dynamic query cannot be ported to 1+
stored procs.

I don't think you can do it. And in addition, I don't think it would
take me a vast amount of time to come up with a case statement and the
requisite sprocs.

I think dynamic SQL is for the lazy. So there, I said it. Prove me wrong
with an example that cannot be coded in 1+ sprocs.

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Francis
Harvey
Sent: Tuesday, June 29, 2004 1:11 PM
To: 'dba-sqlserver at databaseadvisors.com'
Subject: RE: [dba-SQLServer] Difference between views and queries


Francisco,

I am not going to debate a straw man example that is specifically chosen
to highlight the supposed "evils" of dynamic SQL. It was done because
there wasn't sufficient time, lack of experience, can be done better
with static SQL, etc; are all easy points to win against using dynamic
SQL if you were somehow naive enough to believe this actually
represented a realistic example of when it should be used. It doesn't,
so I won't.

Security is a different issue, and I am willing to discuss it, but first
a question, do you honestly believe that security considerations should
outweigh any other consideration? I don't get that impression 
since you have allowed the sproc to continue in its present form, so I
wonder at your statement that you cannot achieve security using dynamic
SQL. Basically, there is a certain level of security I am comfortable
with and dynamic SQL does not violate it. I can go into more detail, but
I don't get the impression that you would protest this balancing anyway.

I didn't say scaling issues were insane. I implied that most people
haven't actually done tests to see how much performance gain you lose by
not having a cached query plan, which is not even always the case for
dynamic SQL in any event. IOW, you will not always get a better query
plan (in fact, for complex dynamic searches, you are virtually
guaranteed that a generic static solution would have a very bad query
plan) and it will not always have less cost.

Again, aren't we all basically in agreement except you both have this
addiction to using the word additive to describe what clearly has a
non-additive element, DENY permissions? You keep restating what all
three of us already know, and then you and Arthur seem to make the leap
from not liking to use DENY permissions to implying that only the
additive model should be used. Guess what, just like with dynamic SQL,
my needs are apparently more complex then yours, and you cannot propose
to give a meaningful summary of SQL Server security while ignoring one
of its key features. It wasn't added as a lark; it was added to provide
additional security options. If you don't want to use it then don't,
stop trying to convince me of its benefits. I use what is appropriate,
and DENY permissions are appropriate for my needs. Unless you are saying
there is some reason you wouldn't use DENY permissions if needed, I
can't do any better than the BOL examples on why they are needed. Find a
fault with their examples and this might become an interesting
discussion. Otherwise, I will repeat that to have a true security
summary you must also mention DENY permissions which are not additive in
nature.

Francis R Harvey III
WB 303, (301)294-3952
harveyf1 at westat.com


> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf 
> Of Francisco H Tapia
> Sent: Tuesday, June 29, 2004 11:49 AM
> To: dba-sqlserver at databaseadvisors.com
> Subject: Re: [dba-SQLServer] Difference between views and queries
> 
> 
> Francis,
>    In my current project, there is "ONE" sproc that is still dynamic
> sql.  This sproc was developed in the early stages of the 
> desgin almost 
> 2 years ago, and it was never upgraded to a full static sql 
> because of 
> lack of time.  In fact when revisiting it, it is actually fairly 
> straight forward to fix the problematic dynamic SQL and once again 
> remove "SELECT" access from the 3 tables it points to.  In 
> fact it was 
> written as dynamic sql because of lack of time.  While I did 
> take extra 
> steps to help validate and protect against sql injections, this 
> particular sproc is 'wrong', had we had more time and 
> experiance at the 
> time, it would have been done as static sql the first time.  
> In fact all 
> new sprocs are evaluated repeatedly if Dynamic Sql appears to be the 
> "only" choice.  Unlike normalization, if your database stresses to be 
> secure, then you will never acheive this buy allowing dynamic 
> SQL to be 
> passed through in such fashions.  The scaling issues are not insane.  
> You will have a better query plan by having stored static sql 
> and will 
> be able to provide the data that much faster w/ less cost to the 
> server.  additionally the time spent logic is not bad logic, 
> because if 
> you can do it either way, why "WOULDNT" you do it as static sql?
> 
> Lastly, Security.  Security when working in a Network environment is
> always done as additive.  You join the Service Group, the HR 
> Group, the 
> Accounting Group. so on and so forth.  IF by chance the 
> sysadmin locks 
> out a particular access at any level in those groups, well anyone in 
> that DENY group will never "GAIN" access to the respective 
> data store.  
> This is the fashion in which SQL Server security works.  SURE 
> you can do 
> it any way you want.  But addtive is the streamline way to 
> go.  IF I do 
> not grant you access, you can not select/insert/update/delete.  If I 
> GRANT you access to SELECT, then you will be able to do so.  HOWEVER, 
> Denying you access to read from the table will never GIVE you access 
> again via that login, which is why ONE should be extremly 
> careful of how 
> you give and reject access.
<snip>
_______________________________________________
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 29 19:18:44 2004
From: jwcolby at colbyconsulting.com (jwcolby)
Date: Tue, 29 Jun 2004 20:18:44 -0400
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <446DDE75CFC7E1438061462F85557B0F0481E92C@remail2.westat.com>
Message-ID: <009e01c45e37$ce288230$0501a8c0@colbyws>

Is my name being taken in vain?

8-(

John W. Colby 
www.ColbyConsulting.com

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Francis
Harvey
Sent: Tuesday, June 29, 2004 6:22 PM
To: 'dba-sqlserver at databaseadvisors.com'
Subject: RE: [dba-SQLServer] Difference between views and queries


Francisco,

Give me a break. If you haven't done the research to find an actual example
somebody would agree to as valid usage of dynamic SQL and then just start
coming up with reasons why your sproc wouldn't be better as dynamic SQL, you
aren't interested in actually debating its merits. You apparently prefer to
debate your own version of dynamic SQL which is easily bested, thus suitably
earning its title of straw man. I never claimed your sproc was suitable for
dynamic SQL, and I certainly won't argue its merits on that inappropriate
example.

To my knowledge, you have posted nothing suggesting you have the experience
to classify "every problem that people encounter where Dynamic SQL appears
to be the only or best solution". Have you done the minimal research I
suggested? If you won't do it, then I have already stated I am not a John
Colby, willing to do the research for you. I hold up my side of the debate;
you are responsible for yours.

So, we can agree security is a balance? Thus, saying dynamic SQL means you
must have an unsecured system is not strictly true depending on where you
put the balance. For us, this database is accessed via only one application
which codes the dynamic SQL according to specific user choices. For us, this
is an acceptable security balance for the performance we get from dynamic
SQL, and we consider this to be a secured system.

Again with the additive. I am starting to wonder whether you are reading my
comments as you simply restate material that everybody
involved: Arthur, you, myself; already knows. Fine, I'll agree not to object
to the additive adjective if in future summaries everyone will agree to
mention DENY as well if only in passing. Please, at the very least, don't
feel required to requote BOL information again. Argh.

Your experience means nothing to me as mine should mean nothing to you. I
don't care if you've never had a use for a linked server, UDF, or anything
else in SQL server. I have given you the terms to search for exactly because
you seem to have had no experience with SQL that needs to be dynamic. For
you to then complain that you haven't seen any examples is a bit
disingenuous. Go look. Or don't. Whatever. Until then, enjoy beating up your
straw man.

Francis R Harvey III
WB 303, (301)294-3952
harveyf1 at westat.com

> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf 
> Of Francisco H Tapia
> Sent: Tuesday, June 29, 2004 5:16 PM
> To: dba-sqlserver at databaseadvisors.com
> Subject: Re: [dba-SQLServer] Difference between views and queries
> 
> 
> Francis Harvey wrote On 6/29/2004 10:10 AM:
> 
> >Francisco,
> >
> >I am not going to debate a straw man example that is specifically 
> >chosen to highlight the supposed "evils" of dynamic SQL. It was done 
> >because there wasn't sufficient time, lack of experience, can be done 
> >better with static SQL, etc; are all easy points to win against using 
> >dynamic SQL if you were somehow naive enough to believe this actually 
> >represented a realistic example of when it should be used. It 
> >doesn't, so I won't.
> >
> >  
> >
> every problem that people encounter where Dynamic SQL appears
> to be the 
> only or best solution is often looked at in this light. If 
> you don't see 
> it, well then I guess there is nothing more to discuss.
> 
> >Security is a different issue, and I am willing to discuss it, but 
> >first a question, do you honestly believe that security
> considerations
> >should outweigh any other consideration? I don't get that impression
> >since you have allowed the sproc to continue in its present 
> form, so I
> >wonder at your statement that you cannot achieve security using 
> >dynamic SQL. Basically, there is a certain level of security I am 
> >comfortable with and dynamic SQL does not violate it. I can go into 
> >more detail, but I don't get the impression that you would protest 
> >this balancing anyway.
> >
> >  
> >
> Security is always a balance of how much data is allowed through w/o
> comprimising the rest of the system.  Our particular problem w/ our 
> sproc was one because of "TIME" and because our user base currently 
> lacks the knowledge to exploit this has been the determining 
> factor to 
> NOT get this sproc up and running in the correct fashion, It is 
> currently on our list "todo" and will be assimilated (so to speak).
> 
> >I didn't say scaling issues were insane. I implied that most people 
> >haven't actually done tests to see how much performance gain you lose 
> >by not having a cached query plan, which is not even always the case 
> >for dynamic SQL in any event. IOW, you will not always get a better 
> >query plan (in fact, for complex dynamic searches, you are virtually 
> >guaranteed that a generic static solution would have a very bad query 
> >plan) and it will not always have less cost.
> >
> >Again, aren't we all basically in agreement except you both have this 
> >addiction to using the word additive to describe what clearly has a 
> >non-additive element, DENY permissions? You keep restating what all 
> >three of us already know, and then you and Arthur seem to make the 
> >leap from not liking to use DENY permissions to implying that only 
> >the additive model should be used. Guess what, just like with dynamic 
> >SQL, my needs are apparently more complex then yours, and you cannot 
> >propose to give a meaningful summary of SQL Server security while 
> >ignoring one of its key features. It wasn't added as a lark; it was 
> >added to provide additional security options. If you don't want to 
> >use it then don't, stop trying to convince me of its benefits. I use 
> >what is appropriate, and DENY permissions are appropriate for my 
> >needs. Unless you are saying there is some reason you wouldn't use 
> >DENY permissions if needed, I can't do any better than the BOL 
> >examples on why they are needed. Find a fault with their examples and 
> >this might become an interesting discussion. Otherwise, I will repeat 
> >that to have a true security summary you must also mention DENY 
> >permissions which are not additive in nature.
> >
> >  
> >
> Security is Additive.  BOL states to be explicitly careful
> when issuing 
> DENY seucurity as it will take precedence over any GRANTs and 
> therefor 
> you will only be able to grant premissions if the user is 
> removed from 
> any ROLES that have DENY rights.  It works this way in NT security as 
> well.   There is nothing diffrent or even remotely obscure in this 
> topology.  You just have to make sure you realize you've 
> issued DENYs.  
> And of course there are situtations where DENYs are 
> necessary.  But I've 
> yet to find a solution where Dynamic SQL was the only out. 
> (or the better).
> 
> --
> -Francisco
<snip>
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com






From artful at rogers.com  Tue Jun 29 19:22:05 2004
From: artful at rogers.com (Arthur Fuller)
Date: Tue, 29 Jun 2004 20:22:05 -0400
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <446DDE75CFC7E1438061462F85557B0F0481E92C@remail2.westat.com>
Message-ID: <03fb01c45e38$45db5c80$6601a8c0@rock>

I must have missed the post including your links to said examples.
Please re-post them.

Arthur

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Francis
Harvey
Sent: Tuesday, June 29, 2004 6:22 PM
To: 'dba-sqlserver at databaseadvisors.com'
Subject: RE: [dba-SQLServer] Difference between views and queries


Francisco,

Give me a break. If you haven't done the research to find an actual
example somebody would agree to as valid usage of dynamic SQL and then
just start coming up with reasons why your sproc wouldn't be better as
dynamic SQL, you aren't interested in actually debating its merits. You
apparently prefer to debate your own version of dynamic SQL which is
easily bested, thus suitably earning its title of straw man. I never
claimed your sproc was suitable for dynamic SQL, and I certainly won't
argue its merits on that inappropriate example.

To my knowledge, you have posted nothing suggesting you have the
experience to classify "every problem that people encounter where
Dynamic SQL appears to be the only or best solution". Have you done the
minimal research I suggested? If you won't do it, then I have already
stated I am not a John Colby, willing to do the research for you. I hold
up my side of the debate; you are responsible for yours.

So, we can agree security is a balance? Thus, saying dynamic SQL means
you must have an unsecured system is not strictly true depending on
where you put the balance. For us, this database is accessed via only
one application which codes the dynamic SQL according to specific user
choices. For us, this is an acceptable security balance for the
performance we get from dynamic SQL, and we consider this to be a
secured system.

Again with the additive. I am starting to wonder whether you are reading
my comments as you simply restate material that everybody
involved: Arthur, you, myself; already knows. Fine, I'll agree not to
object to the additive adjective if in future summaries everyone will
agree to mention DENY as well if only in passing. Please, at the very
least, don't feel required to requote BOL information again. Argh.

Your experience means nothing to me as mine should mean nothing to you.
I don't care if you've never had a use for a linked server, UDF, or
anything else in SQL server. I have given you the terms to search for
exactly because you seem to have had no experience with SQL that needs
to be dynamic. For you to then complain that you haven't seen any
examples is a bit disingenuous. Go look. Or don't. Whatever. Until then,
enjoy beating up your straw man.

Francis R Harvey III
WB 303, (301)294-3952
harveyf1 at westat.com

> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf 
> Of Francisco H Tapia
> Sent: Tuesday, June 29, 2004 5:16 PM
> To: dba-sqlserver at databaseadvisors.com
> Subject: Re: [dba-SQLServer] Difference between views and queries
> 
> 
> Francis Harvey wrote On 6/29/2004 10:10 AM:
> 
> >Francisco,
> >
> >I am not going to debate a straw man example that is specifically 
> >chosen to highlight the supposed "evils" of dynamic SQL. It was done 
> >because there wasn't sufficient time, lack of experience, can be done

> >better with static SQL, etc; are all easy points to win against using

> >dynamic SQL if you were somehow naive enough to believe this actually

> >represented a realistic example of when it should be used. It 
> >doesn't, so I won't.
> >
> >  
> >
> every problem that people encounter where Dynamic SQL appears
> to be the 
> only or best solution is often looked at in this light. If 
> you don't see 
> it, well then I guess there is nothing more to discuss.
> 
> >Security is a different issue, and I am willing to discuss it, but 
> >first a question, do you honestly believe that security
> considerations
> >should outweigh any other consideration? I don't get that impression
> >since you have allowed the sproc to continue in its present 
> form, so I
> >wonder at your statement that you cannot achieve security using 
> >dynamic SQL. Basically, there is a certain level of security I am 
> >comfortable with and dynamic SQL does not violate it. I can go into 
> >more detail, but I don't get the impression that you would protest 
> >this balancing anyway.
> >
> >  
> >
> Security is always a balance of how much data is allowed through w/o
> comprimising the rest of the system.  Our particular problem w/ our 
> sproc was one because of "TIME" and because our user base currently 
> lacks the knowledge to exploit this has been the determining 
> factor to 
> NOT get this sproc up and running in the correct fashion, It is 
> currently on our list "todo" and will be assimilated (so to speak).
> 
> >I didn't say scaling issues were insane. I implied that most people 
> >haven't actually done tests to see how much performance gain you lose

> >by not having a cached query plan, which is not even always the case 
> >for dynamic SQL in any event. IOW, you will not always get a better 
> >query plan (in fact, for complex dynamic searches, you are virtually 
> >guaranteed that a generic static solution would have a very bad query

> >plan) and it will not always have less cost.
> >
> >Again, aren't we all basically in agreement except you both have this

> >addiction to using the word additive to describe what clearly has a 
> >non-additive element, DENY permissions? You keep restating what all 
> >three of us already know, and then you and Arthur seem to make the 
> >leap from not liking to use DENY permissions to implying that only 
> >the additive model should be used. Guess what, just like with dynamic

> >SQL, my needs are apparently more complex then yours, and you cannot 
> >propose to give a meaningful summary of SQL Server security while 
> >ignoring one of its key features. It wasn't added as a lark; it was 
> >added to provide additional security options. If you don't want to 
> >use it then don't, stop trying to convince me of its benefits. I use 
> >what is appropriate, and DENY permissions are appropriate for my 
> >needs. Unless you are saying there is some reason you wouldn't use 
> >DENY permissions if needed, I can't do any better than the BOL 
> >examples on why they are needed. Find a fault with their examples and

> >this might become an interesting discussion. Otherwise, I will repeat

> >that to have a true security summary you must also mention DENY 
> >permissions which are not additive in nature.
> >
> >  
> >
> Security is Additive.  BOL states to be explicitly careful
> when issuing 
> DENY seucurity as it will take precedence over any GRANTs and 
> therefor 
> you will only be able to grant premissions if the user is 
> removed from 
> any ROLES that have DENY rights.  It works this way in NT security as 
> well.   There is nothing diffrent or even remotely obscure in this 
> topology.  You just have to make sure you realize you've 
> issued DENYs.  
> And of course there are situtations where DENYs are 
> necessary.  But I've 
> yet to find a solution where Dynamic SQL was the only out. 
> (or the better).
> 
> --
> -Francisco
<snip>
_______________________________________________
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 29 21:59:52 2004
From: accessd at shaw.ca (Jim Lawrence (AccessD))
Date: Tue, 29 Jun 2004 19:59:52 -0700
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <446DDE75CFC7E1438061462F85557B0F0BFF29@remail2.westat.com>
Message-ID: <FJEJLIPOMCGJALMGLLLIGEBICEAA.accessd@shaw.ca>

Hi All:

For those that are interested, here is a series of modules, from M$, on SQL
security. They might not always be right, but you  can be reliable assured
they understand the security issues as related to their SQL product and best
methods to handle same:
http://www.microsoft.com/resources/documentation/sql/2000/all/reskit/en-us/p
art3/c1061.mspx

(watch for wrap)
HTH
Jim

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of Francis
Harvey
Sent: Tuesday, June 29, 2004 10:11 AM
To: 'dba-sqlserver at databaseadvisors.com'
Subject: RE: [dba-SQLServer] Difference between views and queries


Francisco,

I am not going to debate a straw man example that is specifically
chosen to highlight the supposed "evils" of dynamic SQL. It was done
because there wasn't sufficient time, lack of experience, can be
done better with static SQL, etc; are all easy points to win against
using dynamic SQL if you were somehow naive enough to believe this
actually represented a realistic example of when it should be used.
It doesn't, so I won't.

Security is a different issue, and I am willing to discuss it, but
first a question, do you honestly believe that security considerations
should outweigh any other consideration? I don't get that impression
since you have allowed the sproc to continue in its present form, so I
wonder at your statement that you cannot achieve security using
dynamic SQL. Basically, there is a certain level of security I am
comfortable with and dynamic SQL does not violate it. I can go into
more detail, but I don't get the impression that you would protest
this balancing anyway.

I didn't say scaling issues were insane. I implied that most people
haven't actually done tests to see how much performance gain you lose
by not having a cached query plan, which is not even always the case
for dynamic SQL in any event. IOW, you will not always get a better
query plan (in fact, for complex dynamic searches, you are virtually
guaranteed that a generic static solution would have a very bad
query plan) and it will not always have less cost.

Again, aren't we all basically in agreement except you both have this
addiction to using the word additive to describe what clearly has a
non-additive element, DENY permissions? You keep restating what all
three of us already know, and then you and Arthur seem to make the
leap from not liking to use DENY permissions to implying that only
the additive model should be used. Guess what, just like with dynamic
SQL, my needs are apparently more complex then yours, and you cannot
propose to give a meaningful summary of SQL Server security while
ignoring one of its key features. It wasn't added as a lark; it was
added to provide additional security options. If you don't want to
use it then don't, stop trying to convince me of its benefits. I
use what is appropriate, and DENY permissions are appropriate for
my needs. Unless you are saying there is some reason you wouldn't
use DENY permissions if needed, I can't do any better than the BOL
examples on why they are needed. Find a fault with their examples
and this might become an interesting discussion. Otherwise, I will
repeat that to have a true security summary you must also mention
DENY permissions which are not additive in nature.

Francis R Harvey III
WB 303, (301)294-3952
harveyf1 at westat.com


> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf
> Of Francisco H Tapia
> Sent: Tuesday, June 29, 2004 11:49 AM
> To: dba-sqlserver at databaseadvisors.com
> Subject: Re: [dba-SQLServer] Difference between views and queries
>
>
> Francis,
>    In my current project, there is "ONE" sproc that is still dynamic
> sql.  This sproc was developed in the early stages of the
> desgin almost
> 2 years ago, and it was never upgraded to a full static sql
> because of
> lack of time.  In fact when revisiting it, it is actually fairly
> straight forward to fix the problematic dynamic SQL and once again
> remove "SELECT" access from the 3 tables it points to.  In
> fact it was
> written as dynamic sql because of lack of time.  While I did
> take extra
> steps to help validate and protect against sql injections, this
> particular sproc is 'wrong', had we had more time and
> experiance at the
> time, it would have been done as static sql the first time.
> In fact all
> new sprocs are evaluated repeatedly if Dynamic Sql appears to be the
> "only" choice.  Unlike normalization, if your database stresses to be
> secure, then you will never acheive this buy allowing dynamic
> SQL to be
> passed through in such fashions.  The scaling issues are not insane.
> You will have a better query plan by having stored static sql
> and will
> be able to provide the data that much faster w/ less cost to the
> server.  additionally the time spent logic is not bad logic,
> because if
> you can do it either way, why "WOULDNT" you do it as static sql?
>
> Lastly, Security.  Security when working in a Network environment is
> always done as additive.  You join the Service Group, the HR
> Group, the
> Accounting Group. so on and so forth.  IF by chance the
> sysadmin locks
> out a particular access at any level in those groups, well anyone in
> that DENY group will never "GAIN" access to the respective
> data store.
> This is the fashion in which SQL Server security works.  SURE
> you can do
> it any way you want.  But addtive is the streamline way to
> go.  IF I do
> not grant you access, you can not select/insert/update/delete.  If I
> GRANT you access to SELECT, then you will be able to do so.  HOWEVER,
> Denying you access to read from the table will never GIVE you access
> again via that login, which is why ONE should be extremly
> careful of how
> you give and reject access.
<snip>
_______________________________________________
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 29 22:37:57 2004
From: accessd at shaw.ca (Jim Lawrence (AccessD))
Date: Tue, 29 Jun 2004 20:37:57 -0700
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <03f701c45e36$6e8632b0$6601a8c0@rock>
Message-ID: <FJEJLIPOMCGJALMGLLLIGEBJCEAA.accessd@shaw.ca>

Hi Arthur:

I think, given a limited set of options, assuming you are in control of
writing the program, from top to bottom, there is no reason why, all the SQL
interface could not be managed with static SPs. ...but if the option range
becomes extremely complex then a more dynamic set will be required. I do not
think it is a matter of right or wrong but keeping the complexity of the
program down to a point where you, as the programmer, can still manage it.

I have a friend who had worked, with a team, on huge system, for some giant
oil conglomerate, out of Calgary and they had managed to badly bend SQL2000,
almost to it's knees, using a complex sets of dynamic function calls and
re-naming techniques, right within the SP. As I understand, the security was
a nightmare, but much of the internal SPs handled that by checking the roles
against the procedure caller. Mind you, the system ran better than it
predecessor, a full-blown Oracle DB, which they tossed after a year. On the
other hand, I think, for most practical purposes, the sky is the limit, if
you what to design all your processing within SQL SPs.

My two cents worth.
Jim

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com]On Behalf Of Arthur
Fuller
Sent: Tuesday, June 29, 2004 5:09 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


All I want is an example that cannot be coded by one or more sprocs.

Arthur

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Francis
Harvey
Sent: Tuesday, June 29, 2004 10:47 AM
To: 'dba-sqlserver at databaseadvisors.com'
Subject: RE: [dba-SQLServer] Difference between views and queries


Francisco,

I would like to consider the opinion of someone who shares my namesake
as seriously as possible, but in this case, I believe you suffer from
Arthur's problem of a lack of experience with the very specific problems
I cited. It is fine to talk about not using dynamic SQL in general when
using SQL Server, but just as with normalization, there are exceptions
and no one should be stating it as an absolute rule or bad practice
until they have reviewed the problems I mentioned. Again, I will state,
for those particular problems, dynamic SQL is often the superior
solution.

Also, the "scaling" issue is teetering awfully close to using FUD. You
can always use any programming method incorrectly, but correctly written
dynamic SQL does not suffer from the horrible efficiency loss that not
having a cached query plan would seem to imply. Similarly, the "time
spent" argument is bad logic. I don't spend less time on my dynamic SQL
solutions, I spend more time because the problems are difficult. Adding
more time for a static SQL solution will not result in a better design
or even a working design in some cases.

I don't think you, Arthur or I are in disagreement over security, I just
didn't like the oversimplified way security was described, so I chose to
emphasize a particular point. I think this is an important part that
should be highlighted.

Francis R Harvey III
WB 303, (301)294-3952
harveyf1 at westat.com


> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf
> Of Francisco H Tapia
> Sent: Monday, June 28, 2004 12:42 PM
> To: dba-sqlserver at databaseadvisors.com
> Subject: Re: [dba-SQLServer] Difference between views and queries
>
>
> Francis,
>    I respectfully agree w/ Arthur on this.  Dynamic SQL as a rule, is
> bad design.  Many times over you will find that there are comparable
> solutions that often meet the demand much better, and "scale" much
> better than that of dynamic sql.  There is no "ONE" right way
> of doing
> things, that is the nature of this business.  However
> justifying dynamic
> sql because of some time spent on design is imnsho incorrect.
>  You will
> often find more times that enabling users/roles via Views/Sprocs and
> Functions to be far superior solutions than to open wide dynamic sql.
>
> re: security.
> Of course if you deny permissions on any object the take
> precedence over
> allows, this is the nature of security.  That is why you must be
> explicitly "SURE" when making DENY requests on any object.
> NOT giving
> rights to an object does not equeal REJECT.
>
> If I do not give a user rights to a view, under Role1, but
> then give him
> rights to that object via Role2.  There will be 0 issues w/
> accessability.  However If by poor planning I had a "REJECT"
> rights in
> Role1, then I'd have the issues you are stating.
>
>
>
>
> Francis Harvey wrote On 6/25/2004 2:24 PM:
>
> >Arthur,
> >
> >Do some research on the basic solutions for SQL that has to
> adjust for
> >varying databases, conditions (dynamic search), or servers (different

> >SQL dialects). Some designs also call for encapsulating
> business logic
> >outside of the data tier. In these situations, dynamic SQL is often
> >the only logical choice. I have only had to deal with dynamic search
> >myself, but this is enough to convince me of its usefulness.
> >
> >Describing permissions solely as additive in nature is
> incorrect. This
> >is the point I was making.
> >
> >Francis R Harvey III
> >WB 303, (301)294-3952
> >harveyf1 at westat.com
<snip>
_______________________________________________
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 tuxedo_man at hotmail.com  Tue Jun 29 23:56:50 2004
From: tuxedo_man at hotmail.com (Billy Pang)
Date: Wed, 30 Jun 2004 04:56:50 +0000
Subject: [dba-SQLServer] Difference between views and queries
Message-ID: <BAY1-F16dBdsnvUFcxT00000972@hotmail.com>

oh boy, can't wait to get into this discussion :)...there is one example I 
can think of..  the example would be based on the physical storage of the 
sproc in a single db.  it is not possible for a sproc to query table in 
another db that the sproc does not reside in.

To illustrate, let's say that there are three copies of the northwind db on 
db server: northwind0, northwind1 and northwind2; all three have exact db 
schema;

Your goal is to develop a report that counts number of records in the 
products table in each of the northwind databases.  sometimes you may only 
want to count records in northwind0 and northwind1 but not northwind2; 
sometimes you may only want northwind2 and northwind1 but not northwind0; 
and sometimes you want all three northwind dbs in your count.  It is 
possible to create a sp for each of the permutation but if a fourth 
northwind db is introduced to the system, then the code base is doubled.

The alternate solution would be to build dynamic sql to piece together 
select statement referencing tables using the [db].[owner].[table] format; 
which tables are pieced together is based on what the user selects as 
criteria for report.  Not elegant solution but it is a lot less code to 
maintain.

With that being said, dynamic sql is not as safe for reporting compared to 
sproc.

I think what Francis is trying to get at is that it is not possible for a 
developer to claim that a particular "coding method" is never needed.  
Rather, it is more correct to state that it is not likely that a particular 
"coding method" is ever needed.  Difference between the words "impossible" 
and "improbable".  Similiar to how a judge cannot hand out a verdict to 
court case before the case is presented no matter obvious it may seem.

Another point of reference on this topic would be look up "Validating User 
Input" in BOL for best practices on this issue.

Billy


>From: "Arthur Fuller" <artful at rogers.com>
>Reply-To: dba-sqlserver at databaseadvisors.com
>To: <dba-sqlserver at databaseadvisors.com>
>Subject: RE: [dba-SQLServer] Difference between views and queries
>Date: Tue, 29 Jun 2004 20:08:54 -0400
>
>All I want is an example that cannot be coded by one or more sprocs.
>
>Arthur
>
>-----Original Message-----
>From: dba-sqlserver-bounces at databaseadvisors.com
>[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Francis
>Harvey
>Sent: Tuesday, June 29, 2004 10:47 AM
>To: 'dba-sqlserver at databaseadvisors.com'
>Subject: RE: [dba-SQLServer] Difference between views and queries
>
>
>Francisco,
>
>I would like to consider the opinion of someone who shares my namesake
>as seriously as possible, but in this case, I believe you suffer from
>Arthur's problem of a lack of experience with the very specific problems
>I cited. It is fine to talk about not using dynamic SQL in general when
>using SQL Server, but just as with normalization, there are exceptions
>and no one should be stating it as an absolute rule or bad practice
>until they have reviewed the problems I mentioned. Again, I will state,
>for those particular problems, dynamic SQL is often the superior
>solution.
>
>Also, the "scaling" issue is teetering awfully close to using FUD. You
>can always use any programming method incorrectly, but correctly written
>dynamic SQL does not suffer from the horrible efficiency loss that not
>having a cached query plan would seem to imply. Similarly, the "time
>spent" argument is bad logic. I don't spend less time on my dynamic SQL
>solutions, I spend more time because the problems are difficult. Adding
>more time for a static SQL solution will not result in a better design
>or even a working design in some cases.
>
>I don't think you, Arthur or I are in disagreement over security, I just
>didn't like the oversimplified way security was described, so I chose to
>emphasize a particular point. I think this is an important part that
>should be highlighted.
>
>Francis R Harvey III
>WB 303, (301)294-3952
>harveyf1 at westat.com
>
>
> > -----Original Message-----
> > From: dba-sqlserver-bounces at databaseadvisors.com
> > [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf
> > Of Francisco H Tapia
> > Sent: Monday, June 28, 2004 12:42 PM
> > To: dba-sqlserver at databaseadvisors.com
> > Subject: Re: [dba-SQLServer] Difference between views and queries
> >
> >
> > Francis,
> >    I respectfully agree w/ Arthur on this.  Dynamic SQL as a rule, is
> > bad design.  Many times over you will find that there are comparable
> > solutions that often meet the demand much better, and "scale" much
> > better than that of dynamic sql.  There is no "ONE" right way
> > of doing
> > things, that is the nature of this business.  However
> > justifying dynamic
> > sql because of some time spent on design is imnsho incorrect.
> >  You will
> > often find more times that enabling users/roles via Views/Sprocs and
> > Functions to be far superior solutions than to open wide dynamic sql.
> >
> > re: security.
> > Of course if you deny permissions on any object the take
> > precedence over
> > allows, this is the nature of security.  That is why you must be
> > explicitly "SURE" when making DENY requests on any object.
> > NOT giving
> > rights to an object does not equeal REJECT.
> >
> > If I do not give a user rights to a view, under Role1, but
> > then give him
> > rights to that object via Role2.  There will be 0 issues w/
> > accessability.  However If by poor planning I had a "REJECT"
> > rights in
> > Role1, then I'd have the issues you are stating.
> >
> >
> >
> >
> > Francis Harvey wrote On 6/25/2004 2:24 PM:
> >
> > >Arthur,
> > >
> > >Do some research on the basic solutions for SQL that has to
> > adjust for
> > >varying databases, conditions (dynamic search), or servers (different
>
> > >SQL dialects). Some designs also call for encapsulating
> > business logic
> > >outside of the data tier. In these situations, dynamic SQL is often
> > >the only logical choice. I have only had to deal with dynamic search
> > >myself, but this is enough to convince me of its usefulness.
> > >
> > >Describing permissions solely as additive in nature is
> > incorrect. This
> > >is the point I was making.
> > >
> > >Francis R Harvey III
> > >WB 303, (301)294-3952
> > >harveyf1 at westat.com
><snip>
>_______________________________________________
>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
>

_________________________________________________________________
MSN Premium with Virus Guard and Firewall* from McAfee? Security : 2 months 
FREE*   
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines



From tuxedo_man at hotmail.com  Wed Jun 30 00:01:28 2004
From: tuxedo_man at hotmail.com (Billy Pang)
Date: Wed, 30 Jun 2004 05:01:28 +0000
Subject: [dba-SQLServer] Difference between views and queries
Message-ID: <BAY1-F12waliycIw6C400011c1b@hotmail.com>

sorry... just reread what I wrote... instead of:

"it is not possible for a sproc to query table in another db that the sproc 
does not reside in."

rather, it should have read....

"it is difficult for a sproc to query other tables in other databases after 
the sproc has been created."

Billy


>From: "Billy Pang" <tuxedo_man at hotmail.com>
>Reply-To: dba-sqlserver at databaseadvisors.com
>To: dba-sqlserver at databaseadvisors.com
>Subject: RE: [dba-SQLServer] Difference between views and queries
>Date: Wed, 30 Jun 2004 04:56:50 +0000
>
>oh boy, can't wait to get into this discussion :)...there is one example I 
>can think of..  the example would be based on the physical storage of the 
>sproc in a single db.  it is not possible for a sproc to query table in 
>another db that the sproc does not reside in.
>
>To illustrate, let's say that there are three copies of the northwind db on 
>db server: northwind0, northwind1 and northwind2; all three have exact db 
>schema;
>
>Your goal is to develop a report that counts number of records in the 
>products table in each of the northwind databases.  sometimes you may only 
>want to count records in northwind0 and northwind1 but not northwind2; 
>sometimes you may only want northwind2 and northwind1 but not northwind0; 
>and sometimes you want all three northwind dbs in your count.  It is 
>possible to create a sp for each of the permutation but if a fourth 
>northwind db is introduced to the system, then the code base is doubled.
>
>The alternate solution would be to build dynamic sql to piece together 
>select statement referencing tables using the [db].[owner].[table] format; 
>which tables are pieced together is based on what the user selects as 
>criteria for report.  Not elegant solution but it is a lot less code to 
>maintain.
>
>With that being said, dynamic sql is not as safe for reporting compared to 
>sproc.
>
>I think what Francis is trying to get at is that it is not possible for a 
>developer to claim that a particular "coding method" is never needed.  
>Rather, it is more correct to state that it is not likely that a particular 
>"coding method" is ever needed.  Difference between the words "impossible" 
>and "improbable".  Similiar to how a judge cannot hand out a verdict to 
>court case before the case is presented no matter obvious it may seem.
>
>Another point of reference on this topic would be look up "Validating User 
>Input" in BOL for best practices on this issue.
>
>Billy
>
>
>>From: "Arthur Fuller" <artful at rogers.com>
>>Reply-To: dba-sqlserver at databaseadvisors.com
>>To: <dba-sqlserver at databaseadvisors.com>
>>Subject: RE: [dba-SQLServer] Difference between views and queries
>>Date: Tue, 29 Jun 2004 20:08:54 -0400
>>
>>All I want is an example that cannot be coded by one or more sprocs.
>>
>>Arthur
>>
>>-----Original Message-----
>>From: dba-sqlserver-bounces at databaseadvisors.com
>>[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Francis
>>Harvey
>>Sent: Tuesday, June 29, 2004 10:47 AM
>>To: 'dba-sqlserver at databaseadvisors.com'
>>Subject: RE: [dba-SQLServer] Difference between views and queries
>>
>>
>>Francisco,
>>
>>I would like to consider the opinion of someone who shares my namesake
>>as seriously as possible, but in this case, I believe you suffer from
>>Arthur's problem of a lack of experience with the very specific problems
>>I cited. It is fine to talk about not using dynamic SQL in general when
>>using SQL Server, but just as with normalization, there are exceptions
>>and no one should be stating it as an absolute rule or bad practice
>>until they have reviewed the problems I mentioned. Again, I will state,
>>for those particular problems, dynamic SQL is often the superior
>>solution.
>>
>>Also, the "scaling" issue is teetering awfully close to using FUD. You
>>can always use any programming method incorrectly, but correctly written
>>dynamic SQL does not suffer from the horrible efficiency loss that not
>>having a cached query plan would seem to imply. Similarly, the "time
>>spent" argument is bad logic. I don't spend less time on my dynamic SQL
>>solutions, I spend more time because the problems are difficult. Adding
>>more time for a static SQL solution will not result in a better design
>>or even a working design in some cases.
>>
>>I don't think you, Arthur or I are in disagreement over security, I just
>>didn't like the oversimplified way security was described, so I chose to
>>emphasize a particular point. I think this is an important part that
>>should be highlighted.
>>
>>Francis R Harvey III
>>WB 303, (301)294-3952
>>harveyf1 at westat.com
>>
>>
>> > -----Original Message-----
>> > From: dba-sqlserver-bounces at databaseadvisors.com
>> > [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf
>> > Of Francisco H Tapia
>> > Sent: Monday, June 28, 2004 12:42 PM
>> > To: dba-sqlserver at databaseadvisors.com
>> > Subject: Re: [dba-SQLServer] Difference between views and queries
>> >
>> >
>> > Francis,
>> >    I respectfully agree w/ Arthur on this.  Dynamic SQL as a rule, is
>> > bad design.  Many times over you will find that there are comparable
>> > solutions that often meet the demand much better, and "scale" much
>> > better than that of dynamic sql.  There is no "ONE" right way
>> > of doing
>> > things, that is the nature of this business.  However
>> > justifying dynamic
>> > sql because of some time spent on design is imnsho incorrect.
>> >  You will
>> > often find more times that enabling users/roles via Views/Sprocs and
>> > Functions to be far superior solutions than to open wide dynamic sql.
>> >
>> > re: security.
>> > Of course if you deny permissions on any object the take
>> > precedence over
>> > allows, this is the nature of security.  That is why you must be
>> > explicitly "SURE" when making DENY requests on any object.
>> > NOT giving
>> > rights to an object does not equeal REJECT.
>> >
>> > If I do not give a user rights to a view, under Role1, but
>> > then give him
>> > rights to that object via Role2.  There will be 0 issues w/
>> > accessability.  However If by poor planning I had a "REJECT"
>> > rights in
>> > Role1, then I'd have the issues you are stating.
>> >
>> >
>> >
>> >
>> > Francis Harvey wrote On 6/25/2004 2:24 PM:
>> >
>> > >Arthur,
>> > >
>> > >Do some research on the basic solutions for SQL that has to
>> > adjust for
>> > >varying databases, conditions (dynamic search), or servers (different
>>
>> > >SQL dialects). Some designs also call for encapsulating
>> > business logic
>> > >outside of the data tier. In these situations, dynamic SQL is often
>> > >the only logical choice. I have only had to deal with dynamic search
>> > >myself, but this is enough to convince me of its usefulness.
>> > >
>> > >Describing permissions solely as additive in nature is
>> > incorrect. This
>> > >is the point I was making.
>> > >
>> > >Francis R Harvey III
>> > >WB 303, (301)294-3952
>> > >harveyf1 at westat.com
>><snip>
>>_______________________________________________
>>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
>>
>
>_________________________________________________________________
>MSN Premium with Virus Guard and Firewall* from McAfee? Security : 2 months 
>FREE*   
>http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines
>
>_______________________________________________
>dba-SQLServer mailing list
>dba-SQLServer at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>http://www.databaseadvisors.com
>

_________________________________________________________________
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines



From HARVEYF1 at WESTAT.com  Wed Jun 30 08:45:33 2004
From: HARVEYF1 at WESTAT.com (Francis Harvey)
Date: Wed, 30 Jun 2004 09:45:33 -0400
Subject: [dba-SQLServer] Difference between views and queries
Message-ID: <446DDE75CFC7E1438061462F85557B0F0481E92D@remail2.westat.com>

Francisco,

I haven't proposed any examples, so your comment doesn't make any
sense. Might I suggest another search on exactly what a straw man
argument is.

I have made vague claims without evidence, but I have no intention of
backing them up until somebody responds who can show they at least
made an attempt to research the issues responds. Until then, this is a
waste of my time as I will not provide a tutorial for you.

Francis R Harvey III
WB 303, (301)294-3952
harveyf1 at westat.com


From HARVEYF1 at WESTAT.com  Wed Jun 30 08:51:35 2004
From: HARVEYF1 at WESTAT.com (Francis Harvey)
Date: Wed, 30 Jun 2004 09:51:35 -0400
Subject: [dba-SQLServer] Difference between views and queries
Message-ID: <446DDE75CFC7E1438061462F85557B0F0481E92E@remail2.westat.com>

Francisco,

Don't give an example then. Give me some sign you know something about
one of the classes of problems. If you won't bother to make the effort,
I'm not interested in debating. It's of no interest to me to have to
run both sides of the argument because you don't know anything about
the topic. I already know what I think, and how would you know if I
am giving you a fair picture if you won't try to find some information
for yourself? Is there a problem with the search terms? Honestly,
give me some reason for your reluctance here.

Francis R Harvey III
WB 303, (301)294-3952
harveyf1 at westat.com


> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com 
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf 
> Of Francisco H Tapia
> Sent: Tuesday, June 29, 2004 8:16 PM
> To: dba-sqlserver at databaseadvisors.com
> Subject: Re: [dba-SQLServer] Difference between views and queries
> 
> 
> me too, but all he wants is for you and me to go out and look for our 
> own examples that we cannot re-code as a sproc.
<snip>


From HARVEYF1 at WESTAT.com  Wed Jun 30 08:55:13 2004
From: HARVEYF1 at WESTAT.com (Francis Harvey)
Date: Wed, 30 Jun 2004 09:55:13 -0400
Subject: [dba-SQLServer] Difference between views and queries
Message-ID: <446DDE75CFC7E1438061462F85557B0F0481E92F@remail2.westat.com>

Arthur,

No time problem. I just won't argue with someone who doesn't have the
underlying background. You will either take the time to become
properly informed (not agreeing, just informed) or not. I am not
going to walk you from an example through every nuance of the problem.
I don't have that kind of patience. Show me in some way that you have
at least made an attempt to research one of the problems, and I'll
spend as much time as is needed.

Seeing you are willing to characterize dynamic SQL without doing the
basic research I suggested, I will characterize you as too lazy to be
offering anyone a valid opinion about the subject. Seems about as
fair.

Francis R Harvey III
WB 303, (301)294-3952
harveyf1 at westat.com


> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com 
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf 
> Of Arthur Fuller
> Sent: Tuesday, June 29, 2004 8:19 PM
> To: dba-sqlserver at databaseadvisors.com
> Subject: RE: [dba-SQLServer] Difference between views and queries
> 
> 
> OK, we'll let you off the hook due to insufficient time. Fine. Point
> remains unproven, however.
> 
> I still pose the challenge:
> 
> Give me a situation in which a dynamic query cannot be ported to 1+
> stored procs.
> 
> I don't think you can do it. And in addition, I don't think it would
> take me a vast amount of time to come up with a case statement and the
> requisite sprocs.
> 
> I think dynamic SQL is for the lazy. So there, I said it. 
> Prove me wrong
> with an example that cannot be coded in 1+ sprocs.
<snip>


From my.lists at verizon.net  Wed Jun 30 09:42:54 2004
From: my.lists at verizon.net (Francisco H Tapia)
Date: Wed, 30 Jun 2004 07:42:54 -0700
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <446DDE75CFC7E1438061462F85557B0F0481E92E@remail2.westat.com>
References: <446DDE75CFC7E1438061462F85557B0F0481E92E@remail2.westat.com>
Message-ID: <40E2D16E.1050508@verizon.net>

Francis,
    Let's not stray from the thread which was debating on Security 
(additively, even though I know you disagree w/ the term [this includes 
non-additive properties such as DENY rights]) and Dynamic vs Static 
SQL.  The proposed "search terms" as you put are a figment of your 
imagination.  I've asked you to re-post your keywords you wish for me 
search on, but you've simply negated, stating that you do not have the 
energy/time to do so. Fine, I'm not pushing you on that, however you 
keep insisting that no one wants to do any research, and yet you do 
nothing as well.  Hmm.. talk about a straw man argument there :). 

It is obvious you like to have in the last word edgewise, and so I 
expect you to reply, however I ask you NOT to stray from the topic 
thread, this list is about SQL Server topics, not who has not done any 
research, ie, it's the dba-SqlServer list not the dba-ResearchTopics 
list.  Please DO NOT post another request for people to do the said 
research and then call them lazy, when you refuse to do the same.  I'd 
say that's the pot calling the tea-kettle black.



Francis Harvey wrote On 6/30/2004 6:51 AM:

>Francisco,
>
>Don't give an example then. Give me some sign you know something about
>one of the classes of problems. If you won't bother to make the effort,
>I'm not interested in debating. It's of no interest to me to have to
>run both sides of the argument because you don't know anything about
>the topic. I already know what I think, and how would you know if I
>am giving you a fair picture if you won't try to find some information
>for yourself? Is there a problem with the search terms? Honestly,
>give me some reason for your reluctance here.
>
>Francis R Harvey III
>WB 303, (301)294-3952
>harveyf1 at westat.com
>
>
>  
>
>>-----Original Message-----
>>From: dba-sqlserver-bounces at databaseadvisors.com 
>>[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf 
>>Of Francisco H Tapia
>>Sent: Tuesday, June 29, 2004 8:16 PM
>>To: dba-sqlserver at databaseadvisors.com
>>Subject: Re: [dba-SQLServer] Difference between views and queries
>>
>>
>>me too, but all he wants is for you and me to go out and look for our 
>>own examples that we cannot re-code as a sproc.
>>    
>>
><snip>
>_______________________________________________
>dba-SQLServer mailing list
>dba-SQLServer at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>http://www.databaseadvisors.com
>
>
>  
>


-- 
-Francisco




From artful at rogers.com  Wed Jun 30 09:57:06 2004
From: artful at rogers.com (Arthur Fuller)
Date: Wed, 30 Jun 2004 10:57:06 -0400
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <BAY1-F16dBdsnvUFcxT00000972@hotmail.com>
Message-ID: <04d901c45eb2$82afb780$6601a8c0@rock>

Good example, and good reasoning, and I agree that dynamic SQL is never
out of the question. What I intended to write is that more often than
not, dynamic SQL is the lazy way out of thinking carefully about sprocs.
Most of the time it is unnecessary and costly in terms of performance
and front-end code; some of the time, there is no other way.

Arthur

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Billy
Pang
Sent: Wednesday, June 30, 2004 12:57 AM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Difference between views and queries


oh boy, can't wait to get into this discussion :)...there is one example
I 
can think of..  the example would be based on the physical storage of
the 
sproc in a single db.  it is not possible for a sproc to query table in 
another db that the sproc does not reside in.

To illustrate, let's say that there are three copies of the northwind db
on 
db server: northwind0, northwind1 and northwind2; all three have exact
db 
schema;

Your goal is to develop a report that counts number of records in the 
products table in each of the northwind databases.  sometimes you may
only 
want to count records in northwind0 and northwind1 but not northwind2; 
sometimes you may only want northwind2 and northwind1 but not
northwind0; 
and sometimes you want all three northwind dbs in your count.  It is 
possible to create a sp for each of the permutation but if a fourth 
northwind db is introduced to the system, then the code base is doubled.

The alternate solution would be to build dynamic sql to piece together 
select statement referencing tables using the [db].[owner].[table]
format; 
which tables are pieced together is based on what the user selects as 
criteria for report.  Not elegant solution but it is a lot less code to 
maintain.

With that being said, dynamic sql is not as safe for reporting compared
to 
sproc.

I think what Francis is trying to get at is that it is not possible for
a 
developer to claim that a particular "coding method" is never needed.  
Rather, it is more correct to state that it is not likely that a
particular 
"coding method" is ever needed.  Difference between the words
"impossible" 
and "improbable".  Similiar to how a judge cannot hand out a verdict to 
court case before the case is presented no matter obvious it may seem.

Another point of reference on this topic would be look up "Validating
User 
Input" in BOL for best practices on this issue.

Billy


>From: "Arthur Fuller" <artful at rogers.com>
>Reply-To: dba-sqlserver at databaseadvisors.com
>To: <dba-sqlserver at databaseadvisors.com>
>Subject: RE: [dba-SQLServer] Difference between views and queries
>Date: Tue, 29 Jun 2004 20:08:54 -0400
>
>All I want is an example that cannot be coded by one or more sprocs.
>
>Arthur
>
>-----Original Message-----
>From: dba-sqlserver-bounces at databaseadvisors.com
>[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of 
>Francis Harvey
>Sent: Tuesday, June 29, 2004 10:47 AM
>To: 'dba-sqlserver at databaseadvisors.com'
>Subject: RE: [dba-SQLServer] Difference between views and queries
>
>
>Francisco,
>
>I would like to consider the opinion of someone who shares my namesake 
>as seriously as possible, but in this case, I believe you suffer from 
>Arthur's problem of a lack of experience with the very specific 
>problems I cited. It is fine to talk about not using dynamic SQL in 
>general when using SQL Server, but just as with normalization, there 
>are exceptions and no one should be stating it as an absolute rule or 
>bad practice until they have reviewed the problems I mentioned. Again, 
>I will state, for those particular problems, dynamic SQL is often the 
>superior solution.
>
>Also, the "scaling" issue is teetering awfully close to using FUD. You 
>can always use any programming method incorrectly, but correctly 
>written dynamic SQL does not suffer from the horrible efficiency loss 
>that not having a cached query plan would seem to imply. Similarly, the

>"time spent" argument is bad logic. I don't spend less time on my 
>dynamic SQL solutions, I spend more time because the problems are 
>difficult. Adding more time for a static SQL solution will not result 
>in a better design or even a working design in some cases.
>
>I don't think you, Arthur or I are in disagreement over security, I 
>just didn't like the oversimplified way security was described, so I 
>chose to emphasize a particular point. I think this is an important 
>part that should be highlighted.
>
>Francis R Harvey III
>WB 303, (301)294-3952
>harveyf1 at westat.com
>
>
> > -----Original Message-----
> > From: dba-sqlserver-bounces at databaseadvisors.com
> > [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of 
> > Francisco H Tapia
> > Sent: Monday, June 28, 2004 12:42 PM
> > To: dba-sqlserver at databaseadvisors.com
> > Subject: Re: [dba-SQLServer] Difference between views and queries
> >
> >
> > Francis,
> >    I respectfully agree w/ Arthur on this.  Dynamic SQL as a rule, 
> > is bad design.  Many times over you will find that there are 
> > comparable solutions that often meet the demand much better, and 
> > "scale" much better than that of dynamic sql.  There is no "ONE" 
> > right way of doing things, that is the nature of this business.  
> > However justifying dynamic
> > sql because of some time spent on design is imnsho incorrect.
> >  You will
> > often find more times that enabling users/roles via Views/Sprocs and
> > Functions to be far superior solutions than to open wide dynamic
sql.
> >
> > re: security.
> > Of course if you deny permissions on any object the take precedence 
> > over allows, this is the nature of security.  That is why you must 
> > be explicitly "SURE" when making DENY requests on any object.
> > NOT giving
> > rights to an object does not equeal REJECT.
> >
> > If I do not give a user rights to a view, under Role1, but then give

> > him rights to that object via Role2.  There will be 0 issues w/
> > accessability.  However If by poor planning I had a "REJECT"
> > rights in
> > Role1, then I'd have the issues you are stating.
> >
> >
> >
> >
> > Francis Harvey wrote On 6/25/2004 2:24 PM:
> >
> > >Arthur,
> > >
> > >Do some research on the basic solutions for SQL that has to
> > adjust for
> > >varying databases, conditions (dynamic search), or servers 
> > >(different
>
> > >SQL dialects). Some designs also call for encapsulating
> > business logic
> > >outside of the data tier. In these situations, dynamic SQL is often

> > >the only logical choice. I have only had to deal with dynamic 
> > >search myself, but this is enough to convince me of its usefulness.
> > >
> > >Describing permissions solely as additive in nature is
> > incorrect. This
> > >is the point I was making.
> > >
> > >Francis R Harvey III
> > >WB 303, (301)294-3952
> > >harveyf1 at westat.com
><snip>
>_______________________________________________
>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
>

_________________________________________________________________
MSN Premium with Virus Guard and Firewall* from McAfeeR Security : 2
months 
FREE*   
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU
=http://hotmail.com/enca&HL=Market_MSNIS_Taglines

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



From artful at rogers.com  Wed Jun 30 10:09:13 2004
From: artful at rogers.com (Arthur Fuller)
Date: Wed, 30 Jun 2004 11:09:13 -0400
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <446DDE75CFC7E1438061462F85557B0F0481E92F@remail2.westat.com>
Message-ID: <04e501c45eb4$346c1800$6601a8c0@rock>

You have a backhanded way of calling me ignorant. In many ways and in
many areas I am ignorant, but just because I hold an opinion that
differs from yours, that's no reason for you to assume that I am unaware
of the issues you raise. I worked on a project for ABB which relied on a
database comprising over 400 tables and ran in both Oracle and SQL
Server. Both versions used sprocs of the same name. Where there were
differences in syntax, they were encapsulated in the sprocs. From the
viewpoint of the various Front End modules, it didn't matter which
database you were talking to. The FE had virtually no knowledge of the
back end flavour, other than the connection. Now, granted, should ABB
decide suddenly to support MySQL, and given MySQL's limited support of
sprocs, well then there is a problem. Any fool can recognize that -- but
substitute Access for MySQL and you have the same problem. This is
beneath discussion.

Regarding dynamic search, I have done at least one form that presents 25
controls and invokes one sproc that in turn invokes others, depending on
which parameters are null. No problem there. Add a control later in
development, I change a sproc and maybe add another few. No problem
there either.

Does this constitute research into the issues involved?

Arthur

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Francis
Harvey
Sent: Wednesday, June 30, 2004 9:55 AM
To: 'dba-sqlserver at databaseadvisors.com'
Subject: RE: [dba-SQLServer] Difference between views and queries


Arthur,

No time problem. I just won't argue with someone who doesn't have the
underlying background. You will either take the time to become properly
informed (not agreeing, just informed) or not. I am not going to walk
you from an example through every nuance of the problem. I don't have
that kind of patience. Show me in some way that you have at least made
an attempt to research one of the problems, and I'll spend as much time
as is needed.

Seeing you are willing to characterize dynamic SQL without doing the
basic research I suggested, I will characterize you as too lazy to be
offering anyone a valid opinion about the subject. Seems about as fair.

Francis R Harvey III
WB 303, (301)294-3952
harveyf1 at westat.com


> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf 
> Of Arthur Fuller
> Sent: Tuesday, June 29, 2004 8:19 PM
> To: dba-sqlserver at databaseadvisors.com
> Subject: RE: [dba-SQLServer] Difference between views and queries
> 
> 
> OK, we'll let you off the hook due to insufficient time. Fine. Point 
> remains unproven, however.
> 
> I still pose the challenge:
> 
> Give me a situation in which a dynamic query cannot be ported to 1+ 
> stored procs.
> 
> I don't think you can do it. And in addition, I don't think it would 
> take me a vast amount of time to come up with a case statement and the

> requisite sprocs.
> 
> I think dynamic SQL is for the lazy. So there, I said it.
> Prove me wrong
> with an example that cannot be coded in 1+ sprocs.
<snip>
_______________________________________________
dba-SQLServer mailing list
dba-SQLServer at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
http://www.databaseadvisors.com



From HARVEYF1 at WESTAT.com  Wed Jun 30 10:10:11 2004
From: HARVEYF1 at WESTAT.com (Francis Harvey)
Date: Wed, 30 Jun 2004 11:10:11 -0400
Subject: [dba-SQLServer] Difference between views and queries
Message-ID: <446DDE75CFC7E1438061462F85557B0F0481E930@remail2.westat.com>

Francisco,

I think you might have invented a whole new debating technique.
Probably not, but it is novel too me. Labeling someone's post a
figment because you apparently don't want to remember it. Oh, never
mind. I guess I'll treat this as a fair request anyway. Here is the
second repeat on my part.

* -----Original Message-----
* From: dba-sqlserver-bounces at databaseadvisors.com 
* [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf 
* Of Francis Harvey
* Sent: Tuesday, June 29, 2004 1:22 PM
* To: 'dba-sqlserver at databaseadvisors.com'
* Subject: RE: [dba-SQLServer] Difference between views and queries
* 
* 
* Francisco,
* 
* Francis Harvey wrote On 6/25/2004 2:24 PM:
* 
* >Do some research on the basic solutions for SQL that has to 
* adjust for
* >varying databases, conditions (dynamic search), or servers (different
* >SQL dialects). Some designs also call for encapsulating 
* business logic
* >outside of the data tier. In these situations, dynamic SQL is often
* >the only logical choice. I have only had to deal with dynamic search
* >myself, but this is enough to convince me of its usefulness.
* 
* Basically, some of them aren't really up for debate. If you need your
* business logic outside of your data tier for business or performance
* reasons, then it isn't a programming choice anymore. Similarly, I
* would think with needing to speak more than one SQL language in terms
* of maintenance or design considerations.

Let's call the last repeat a figment of email. I hope this is enough
effort for you.

Okay, this has to stop, just for my sanity. Look up straw man
argument. Show me where I provided an example for debate. I didn't.
That is the whole point of your irritation. Mine is that I won't do
it because I think I will have to cover ground that is better
researched on your own. It will give you a fairer and more complete
picture if you don't rely on me to provide the information, and it
would certainly save time if you would just do it.

I have now provided my search terms three times with many additional
repeats provided as you and Arthur requote my posts. I don't know why
keep complaining. I want you to have them. I want you to come back
with stinging rebukes for any of the problems listed. I just don't
want to do a tutorial.

Francis R Harvey III
WB 303, (301)294-3952
harveyf1 at westat.com


> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com 
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf 
> Of Francisco H Tapia
> Sent: Wednesday, June 30, 2004 10:43 AM
> To: dba-sqlserver at databaseadvisors.com
> Subject: Re: [dba-SQLServer] Difference between views and queries
> 
> 
> Francis,
>     Let's not stray from the thread which was debating on Security 
> (additively, even though I know you disagree w/ the term 
> [this includes 
> non-additive properties such as DENY rights]) and Dynamic vs Static 
> SQL.  The proposed "search terms" as you put are a figment of your 
> imagination.  I've asked you to re-post your keywords you wish for me 
> search on, but you've simply negated, stating that you do not 
> have the 
> energy/time to do so. Fine, I'm not pushing you on that, however you 
> keep insisting that no one wants to do any research, and yet you do 
> nothing as well.  Hmm.. talk about a straw man argument there :). 
> 
> It is obvious you like to have in the last word edgewise, and so I 
> expect you to reply, however I ask you NOT to stray from the topic 
> thread, this list is about SQL Server topics, not who has not 
> done any 
> research, ie, it's the dba-SqlServer list not the dba-ResearchTopics 
> list.  Please DO NOT post another request for people to do the said 
> research and then call them lazy, when you refuse to do the 
> same.  I'd 
> say that's the pot calling the tea-kettle black.
<snip>


From HARVEYF1 at WESTAT.com  Wed Jun 30 10:21:12 2004
From: HARVEYF1 at WESTAT.com (Francis Harvey)
Date: Wed, 30 Jun 2004 11:21:12 -0400
Subject: [dba-SQLServer] Difference between views and queries
Message-ID: <446DDE75CFC7E1438061462F85557B0F0481E931@remail2.westat.com>

Arthur,

More often than not? 

> From: dba-sqlserver-bounces at databaseadvisors.com 
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf 
> Of Arthur Fuller
> Sent: Friday, June 25, 2004 4:23 PM
> To: dba-sqlserver at databaseadvisors.com
> Subject: RE: [dba-SQLServer] Difference between views and queries
> 
> 
> 1. I haven't yet seen a case where dynamic SQL is necessary. All it
> takes to avoid it is one or more well-constructed sprocs, IMO.

> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com 
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf 
> Of Arthur Fuller
> Sent: Tuesday, June 29, 2004 8:19 PM
> To: dba-sqlserver at databaseadvisors.com
> Subject: RE: [dba-SQLServer] Difference between views and queries
> 
<snip>

> I think dynamic SQL is for the lazy. So there, I said it. 

You really would characterize your responses as that balanced? I find
your current restatement far more agreeable. Of course, I could add
similar comments about people who's databases aren't fully normalized.
Most of the time it is due to laziness and causes inefficiency and
requires greater coding. Yet, sometimes it is necessary. Would you
then make those same statements from above about everyone whose database
isn't fully normalized? I would think you would at least be curious as
to why it was done before making such blanket statements.

Francis R Harvey III
WB 303, (301)294-3952
harveyf1 at westat.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 30, 2004 10:57 AM
> To: dba-sqlserver at databaseadvisors.com
> Subject: RE: [dba-SQLServer] Difference between views and queries
> 
> 
> Good example, and good reasoning, and I agree that dynamic 
> SQL is never
> out of the question. What I intended to write is that more often than
> not, dynamic SQL is the lazy way out of thinking carefully 
> about sprocs.
> Most of the time it is unnecessary and costly in terms of performance
> and front-end code; some of the time, there is no other way.
> 
> Arthur
<snip>


From DavidL at sierranevada.com  Wed Jun 30 10:26:06 2004
From: DavidL at sierranevada.com (David Lewis)
Date: Wed, 30 Jun 2004 08:26:06 -0700
Subject: [dba-SQLServer] RE: Difference between views and queries (Billy
	Pang)
Message-ID: <9923336B7F4D1A459B983065D95397B92CC8B4@pale.sierranevada.corp>

Hi All:

Regarding Billy Pang's comment:

> .  it is not possible for a sproc to 
> query table in 
> another db that the sproc does not reside in.

you note later in your comment that the syntax [db].[objectowner].[objectname] will make the above possible.
So, to avoid dynamic sql for the problem you've posed one could do the following:

1) if the number/names of the databases is not static, the user interface (let's assume it is web based) could query the server or servers and build a list of all available databases.

2) if the tables to be examined are another variable, the next step would be to present a list of [db]..[tablename] from each database selected.

3)a comma delimited string of [database].[objectowner].[tablename] could be delivered to a sproc, which would then parse it (a udf can accomplish this, or it could be done directly in the sproc), after which  the appropriate system tables could be queried.

This is not to say that dynamic sql is never necessary, but I think the above approach would allow one to avoid it (if that was the goal) for the problem you've posed.

P.S. I think Billy's question has made the dynamic sql vs. stored procedures topic practical.  It was beginning to get a touch dogmatic, and, dare I say it, personal ...  :)


Kind regards to all.  D. Lewis

> Message: 3
> Date: Wed, 30 Jun 2004 04:56:50 +0000
> From: "Billy Pang" <tuxedo_man at hotmail.com>
> Subject: RE: [dba-SQLServer] Difference between views and queries
> To: dba-sqlserver at databaseadvisors.com
> Message-ID: <BAY1-F16dBdsnvUFcxT00000972 at hotmail.com>
> Content-Type: text/plain; format=flowed
> 
> oh boy, can't wait to get into this discussion :)...there is 
> one example I 
> can think of..  the example would be based on the physical 
> storage of the 
> sproc in a single db.  it is not possible for a sproc to 
> query table in 
> another db that the sproc does not reside in.
> 
> To illustrate, let's say that there are three copies of the 
> northwind db on 
> db server: northwind0, northwind1 and northwind2; all three 
> have exact db 
> schema;
> 
> Your goal is to develop a report that counts number of records in the 
> products table in each of the northwind databases.  sometimes 
> you may only 
> want to count records in northwind0 and northwind1 but not 
> northwind2; 
> sometimes you may only want northwind2 and northwind1 but not 
> northwind0; 
> and sometimes you want all three northwind dbs in your count.  It is 
> possible to create a sp for each of the permutation but if a fourth 
> northwind db is introduced to the system, then the code base 
> is doubled.
> 
> The alternate solution would be to build dynamic sql to piece 
> together 
> select statement referencing tables using the 
> [db].[owner].[table] format; 
> which tables are pieced together is based on what the user selects as 
> criteria for report.  Not elegant solution but it is a lot 
> less code to 
> maintain.
> 
> With that being said, dynamic sql is not as safe for 
> reporting compared to 
> sproc.
> 
> I think what Francis is trying to get at is that it is not 
> possible for a 
> developer to claim that a particular "coding method" is never 
> needed.  
> Rather, it is more correct to state that it is not likely 
> that a particular 
> "coding method" is ever needed.  Difference between the words 
> "impossible" 
> and "improbable".  Similiar to how a judge cannot hand out a 
> verdict to 
> court case before the case is presented no matter obvious it may seem.
> 
> Another point of reference on this topic would be look up 
> "Validating User 
> Input" in BOL for best practices on this issue.
> 
> Billy
> 


From my.lists at verizon.net  Wed Jun 30 10:44:40 2004
From: my.lists at verizon.net (Francisco H Tapia)
Date: Wed, 30 Jun 2004 08:44:40 -0700
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <BAY1-F16dBdsnvUFcxT00000972@hotmail.com>
References: <BAY1-F16dBdsnvUFcxT00000972@hotmail.com>
Message-ID: <40E2DFE8.50001@verizon.net>

Billy,
  Typically in a sproc, end users are capable of 
selects/inserts/updates(even deletes) based on the sproc owners rights 
and the sproc's logic.  I relalize that there is a limitation of the 
sproc to run cross joins over databases if said users are not members in 
said db either.

So you'd have to add roles into the respective databases 
(Northwind0/1/2/3 etc..) You'll have to do this anyways for Dynamic Sql 
as you will for Static SQL., but because you are also in pursuit of 
security you'd lock down access to tables and provide access via 
sprocs/views or functions that can be accessed via these roles.  
Something that can be done via dynamic sql however if a developer is 
already using dynamic sql at this point it is unlikely that they will 
consider to lock access to the tables anyways.



Billy Pang wrote On 6/29/2004 9:56 PM:

> oh boy, can't wait to get into this discussion :)...there is one 
> example I can think of..  the example would be based on the physical 
> storage of the sproc in a single db.  it is not possible for a sproc 
> to query table in another db that the sproc does not reside in.
>
> To illustrate, let's say that there are three copies of the northwind 
> db on db server: northwind0, northwind1 and northwind2; all three have 
> exact db schema;
>
> Your goal is to develop a report that counts number of records in the 
> products table in each of the northwind databases.  sometimes you may 
> only want to count records in northwind0 and northwind1 but not 
> northwind2; sometimes you may only want northwind2 and northwind1 but 
> not northwind0; and sometimes you want all three northwind dbs in your 
> count.  It is possible to create a sp for each of the permutation but 
> if a fourth northwind db is introduced to the system, then the code 
> base is doubled.
>
> The alternate solution would be to build dynamic sql to piece together 
> select statement referencing tables using the [db].[owner].[table] 
> format; which tables are pieced together is based on what the user 
> selects as criteria for report.  Not elegant solution but it is a lot 
> less code to maintain.
>
> With that being said, dynamic sql is not as safe for reporting 
> compared to sproc.
>
> I think what Francis is trying to get at is that it is not possible 
> for a developer to claim that a particular "coding method" is never 
> needed.  Rather, it is more correct to state that it is not likely 
> that a particular "coding method" is ever needed.  Difference between 
> the words "impossible" and "improbable".  Similiar to how a judge 
> cannot hand out a verdict to court case before the case is presented 
> no matter obvious it may seem.
>
> Another point of reference on this topic would be look up "Validating 
> User Input" in BOL for best practices on this issue.
>


-- 
-Francisco




From my.lists at verizon.net  Wed Jun 30 10:55:33 2004
From: my.lists at verizon.net (Francisco H Tapia)
Date: Wed, 30 Jun 2004 08:55:33 -0700
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <446DDE75CFC7E1438061462F85557B0F0481E930@remail2.westat.com>
References: <446DDE75CFC7E1438061462F85557B0F0481E930@remail2.westat.com>
Message-ID: <40E2E275.8060509@verizon.net>

Yet you keep arguing that it is possible for a need for Dynamic SQL. :), 
w/o any backing and then expecting everyone else to look it up, 
including terms that have nothing to do w/ SQL Server, perhaps you need 
a link for strawman.  It's sad really, but here's the link if you need one.

Straw Man
http://www.nizkor.org/features/fallacies/straw-man.html
Dynamic vs Static
http://www.sqlservercentral.com/columnists/rmarda/whendynamicsqlisuseful_printversion.asp

in this basic argument (you may need a free registration w/ Sql Server 
Central to read the article).
it is a far stretch just to justify the use of dynamic sql.


Francis Harvey wrote On 6/30/2004 8:10 AM:

>Okay, this has to stop, just for my sanity. Look up straw man
>argument. Show me where I provided an example for debate. I didn't.
>  
>
-- 
-Francisco




From rl_stewart at highstream.net  Wed Jun 30 12:17:41 2004
From: rl_stewart at highstream.net (Robert L. Stewart)
Date: Wed, 30 Jun 2004 12:17:41 -0500
Subject: [dba-SQLServer] Re: Difference between views and queries
In-Reply-To: <200406301701.i5UH1AQ25770@databaseadvisors.com>
Message-ID: <5.1.0.14.2.20040630121441.01698078@pop3.highstream.net>

Francis,

Actually the reason most databases are not fully normalized is not 
laziness, but ignorance.  Most DBA's know nothing about normalization and 
many developers even less.  And, yes I would make such a blanket statement.

Robert

At 12:01 PM 30/06/2004 -0500, you wrote:
>Date: Wed, 30 Jun 2004 11:21:12 -0400
>From: Francis Harvey <HARVEYF1 at WESTAT.com>
>Subject: RE: [dba-SQLServer] Difference between views and queries
>To: "'dba-sqlserver at databaseadvisors.com'"
>         <dba-sqlserver at databaseadvisors.com>
>Message-ID:
>         <446DDE75CFC7E1438061462F85557B0F0481E931 at remail2.westat.com>
>Content-Type: text/plain
>
>Arthur,
>
>More often than not?
>
> > From: dba-sqlserver-bounces at databaseadvisors.com
> > [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf
> > Of Arthur Fuller
> > Sent: Friday, June 25, 2004 4:23 PM
> > To: dba-sqlserver at databaseadvisors.com
> > Subject: RE: [dba-SQLServer] Difference between views and queries
> >
> >
> > 1. I haven't yet seen a case where dynamic SQL is necessary. All it
> > takes to avoid it is one or more well-constructed sprocs, IMO.
>
> > -----Original Message-----
> > From: dba-sqlserver-bounces at databaseadvisors.com
> > [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf
> > Of Arthur Fuller
> > Sent: Tuesday, June 29, 2004 8:19 PM
> > To: dba-sqlserver at databaseadvisors.com
> > Subject: RE: [dba-SQLServer] Difference between views and queries
> >
><snip>
>
> > I think dynamic SQL is for the lazy. So there, I said it.
>
>You really would characterize your responses as that balanced? I find
>your current restatement far more agreeable. Of course, I could add
>similar comments about people who's databases aren't fully normalized.
>Most of the time it is due to laziness and causes inefficiency and
>requires greater coding. Yet, sometimes it is necessary. Would you
>then make those same statements from above about everyone whose database
>isn't fully normalized? I would think you would at least be curious as
>to why it was done before making such blanket statements.




From tuxedo_man at hotmail.com  Wed Jun 30 15:37:49 2004
From: tuxedo_man at hotmail.com (Billy Pang)
Date: Wed, 30 Jun 2004 20:37:49 +0000
Subject: [dba-SQLServer] Re: Difference between views and queries
Message-ID: <BAY1-F33SDPAJESuTei00017ebb@hotmail.com>

A database could be not normalized for reporting reasons, isn't that true?
difference between OLTP and OLAP?

Billy


>From: "Robert L. Stewart" <rl_stewart at highstream.net>
>Reply-To: dba-sqlserver at databaseadvisors.com
>To: dba-sqlserver at databaseadvisors.com
>Subject: [dba-SQLServer] Re: Difference between views and queries
>Date: Wed, 30 Jun 2004 12:17:41 -0500
>
>Francis,
>
>Actually the reason most databases are not fully normalized is not 
>laziness, but ignorance.  Most DBA's know nothing about normalization and 
>many developers even less.  And, yes I would make such a blanket statement.
>
>Robert
>
>At 12:01 PM 30/06/2004 -0500, you wrote:
>>Date: Wed, 30 Jun 2004 11:21:12 -0400
>>From: Francis Harvey <HARVEYF1 at WESTAT.com>
>>Subject: RE: [dba-SQLServer] Difference between views and queries
>>To: "'dba-sqlserver at databaseadvisors.com'"
>>         <dba-sqlserver at databaseadvisors.com>
>>Message-ID:
>>         <446DDE75CFC7E1438061462F85557B0F0481E931 at remail2.westat.com>
>>Content-Type: text/plain
>>
>>Arthur,
>>
>>More often than not?
>>
>> > From: dba-sqlserver-bounces at databaseadvisors.com
>> > [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf
>> > Of Arthur Fuller
>> > Sent: Friday, June 25, 2004 4:23 PM
>> > To: dba-sqlserver at databaseadvisors.com
>> > Subject: RE: [dba-SQLServer] Difference between views and queries
>> >
>> >
>> > 1. I haven't yet seen a case where dynamic SQL is necessary. All it
>> > takes to avoid it is one or more well-constructed sprocs, IMO.
>>
>> > -----Original Message-----
>> > From: dba-sqlserver-bounces at databaseadvisors.com
>> > [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf
>> > Of Arthur Fuller
>> > Sent: Tuesday, June 29, 2004 8:19 PM
>> > To: dba-sqlserver at databaseadvisors.com
>> > Subject: RE: [dba-SQLServer] Difference between views and queries
>> >
>><snip>
>>
>> > I think dynamic SQL is for the lazy. So there, I said it.
>>
>>You really would characterize your responses as that balanced? I find
>>your current restatement far more agreeable. Of course, I could add
>>similar comments about people who's databases aren't fully normalized.
>>Most of the time it is due to laziness and causes inefficiency and
>>requires greater coding. Yet, sometimes it is necessary. Would you
>>then make those same statements from above about everyone whose database
>>isn't fully normalized? I would think you would at least be curious as
>>to why it was done before making such blanket statements.
>
>
>_______________________________________________
>dba-SQLServer mailing list
>dba-SQLServer at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>http://www.databaseadvisors.com
>

_________________________________________________________________
Free yourself from those irritating pop-up ads with MSn Premium. Get 2months 
FREE*  
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=http://hotmail.com/enca&HL=Market_MSNIS_Taglines



From shamil at users.mns.ru  Wed Jun 30 17:56:01 2004
From: shamil at users.mns.ru (Shamil Salakhetdinov)
Date: Thu, 1 Jul 2004 02:56:01 +0400
Subject: [dba-SQLServer] Difference between views and queries
References: <04d901c45eb2$82afb780$6601a8c0@rock>
Message-ID: <005401c45ef5$7716d500$0201a8c0@PARIS>

Arthur,

Just a philosopical opinion/point of view:

Database-centered programming for nowaday businesses are becoming more
and more dynamic and constantly changing....
The SPs are like a "chiseled in stone" stuff.
And dynamic SQL is an amorphic matter, flexibly and smoothly adapting to
constantly changing businesses and their business rules.
Please take into consideration this fact: "chiseled in stone" DLL-Hell
producing COM interfaces are being substituted with .NET Framework
flexible architecture...
IMHO the similar tendence is starting to appear itself more and more
apparently in data(base) layer programming.
Here is why Application Roles (see BOL) were introduced.
Here is why Youkon will support smooth integration with C#/VB.NET/...
extended SPs which in turn will (I guess) work heavily with dynamic
SQL...

And as far as I see metadata-based data access and data
integrity/business rules verification/support are also becoming more and
more popular - and this is what is needed for the modern small and
middle size businesses: they urge for the broad automation of their
businesses because of economical and other reasons but they don't have
enough resources to finance design and development and then constant
redesign and code rewriting/refactoring...

And of course I'm not talking about "SPs must die" - as usual solution
is somewhere in between and is a balance of many interests but for sure
dynamic SQL's role isn't that  narrow as described in
http://www.sqlservercentral.com/columnists/rmarda/whendynamicsqlisuseful_printversion.asp -
the fact is that most of these samples look obsolete because they can be
rewritten IMO using UDFs, XML (OpenXML) - i.e.using SPs but without EXEC
I think! :)

Just my pair of roubles,
Sorry in advance if I did miss the subject of this thread,
Shamil

--
e-mail: shamil at smsconsulting.spb.ru
Web:   http://smsconsulting.spb.ru/shamil_s

----- Original Message ----- 
From: "Arthur Fuller" <artful at rogers.com>
To: <dba-sqlserver at databaseadvisors.com>
Sent: Wednesday, June 30, 2004 6:57 PM
Subject: RE: [dba-SQLServer] Difference between views and queries


> Good example, and good reasoning, and I agree that dynamic SQL is
never
> out of the question. What I intended to write is that more often than
> not, dynamic SQL is the lazy way out of thinking carefully about
sprocs.
> Most of the time it is unnecessary and costly in terms of performance
> and front-end code; some of the time, there is no other way.
>
> Arthur
>
> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Billy
> Pang
> Sent: Wednesday, June 30, 2004 12:57 AM
> To: dba-sqlserver at databaseadvisors.com
> Subject: RE: [dba-SQLServer] Difference between views and queries
>
>
> oh boy, can't wait to get into this discussion :)...there is one
example
> I
> can think of..  the example would be based on the physical storage of
> the
> sproc in a single db.  it is not possible for a sproc to query table
in
> another db that the sproc does not reside in.
>
> To illustrate, let's say that there are three copies of the northwind
db
> on
> db server: northwind0, northwind1 and northwind2; all three have exact
> db
> schema;
>
> Your goal is to develop a report that counts number of records in the
> products table in each of the northwind databases.  sometimes you may
> only
> want to count records in northwind0 and northwind1 but not northwind2;
> sometimes you may only want northwind2 and northwind1 but not
> northwind0;
> and sometimes you want all three northwind dbs in your count.  It is
> possible to create a sp for each of the permutation but if a fourth
> northwind db is introduced to the system, then the code base is
doubled.
>
> The alternate solution would be to build dynamic sql to piece together
> select statement referencing tables using the [db].[owner].[table]
> format;
> which tables are pieced together is based on what the user selects as
> criteria for report.  Not elegant solution but it is a lot less code
to
> maintain.
>
> With that being said, dynamic sql is not as safe for reporting
compared
> to
> sproc.
>
> I think what Francis is trying to get at is that it is not possible
for
> a
> developer to claim that a particular "coding method" is never needed.
> Rather, it is more correct to state that it is not likely that a
> particular
> "coding method" is ever needed.  Difference between the words
> "impossible"
> and "improbable".  Similiar to how a judge cannot hand out a verdict
to
> court case before the case is presented no matter obvious it may seem.
>
> Another point of reference on this topic would be look up "Validating
> User
> Input" in BOL for best practices on this issue.
>
> Billy
>
>
> >From: "Arthur Fuller" <artful at rogers.com>
> >Reply-To: dba-sqlserver at databaseadvisors.com
> >To: <dba-sqlserver at databaseadvisors.com>
> >Subject: RE: [dba-SQLServer] Difference between views and queries
> >Date: Tue, 29 Jun 2004 20:08:54 -0400
> >
> >All I want is an example that cannot be coded by one or more sprocs.
> >
> >Arthur
> >
> >-----Original Message-----
> >From: dba-sqlserver-bounces at databaseadvisors.com
> >[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of
> >Francis Harvey
> >Sent: Tuesday, June 29, 2004 10:47 AM
> >To: 'dba-sqlserver at databaseadvisors.com'
> >Subject: RE: [dba-SQLServer] Difference between views and queries
> >
> >
> >Francisco,
> >
> >I would like to consider the opinion of someone who shares my
namesake
> >as seriously as possible, but in this case, I believe you suffer from
> >Arthur's problem of a lack of experience with the very specific
> >problems I cited. It is fine to talk about not using dynamic SQL in
> >general when using SQL Server, but just as with normalization, there
> >are exceptions and no one should be stating it as an absolute rule or
> >bad practice until they have reviewed the problems I mentioned.
Again,
> >I will state, for those particular problems, dynamic SQL is often the
> >superior solution.
> >
> >Also, the "scaling" issue is teetering awfully close to using FUD.
You
> >can always use any programming method incorrectly, but correctly
> >written dynamic SQL does not suffer from the horrible efficiency loss
> >that not having a cached query plan would seem to imply. Similarly,
the
>
> >"time spent" argument is bad logic. I don't spend less time on my
> >dynamic SQL solutions, I spend more time because the problems are
> >difficult. Adding more time for a static SQL solution will not result
> >in a better design or even a working design in some cases.
> >
> >I don't think you, Arthur or I are in disagreement over security, I
> >just didn't like the oversimplified way security was described, so I
> >chose to emphasize a particular point. I think this is an important
> >part that should be highlighted.
> >
> >Francis R Harvey III
> >WB 303, (301)294-3952
> >harveyf1 at westat.com
> >
> >
> > > -----Original Message-----
> > > From: dba-sqlserver-bounces at databaseadvisors.com
> > > [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of
> > > Francisco H Tapia
> > > Sent: Monday, June 28, 2004 12:42 PM
> > > To: dba-sqlserver at databaseadvisors.com
> > > Subject: Re: [dba-SQLServer] Difference between views and queries
> > >
> > >
> > > Francis,
> > >    I respectfully agree w/ Arthur on this.  Dynamic SQL as a rule,
> > > is bad design.  Many times over you will find that there are
> > > comparable solutions that often meet the demand much better, and
> > > "scale" much better than that of dynamic sql.  There is no "ONE"
> > > right way of doing things, that is the nature of this business.
> > > However justifying dynamic
> > > sql because of some time spent on design is imnsho incorrect.
> > >  You will
> > > often find more times that enabling users/roles via Views/Sprocs
and
> > > Functions to be far superior solutions than to open wide dynamic
> sql.
> > >
> > > re: security.
> > > Of course if you deny permissions on any object the take
precedence
> > > over allows, this is the nature of security.  That is why you must
> > > be explicitly "SURE" when making DENY requests on any object.
> > > NOT giving
> > > rights to an object does not equeal REJECT.
> > >
> > > If I do not give a user rights to a view, under Role1, but then
give
>
> > > him rights to that object via Role2.  There will be 0 issues w/
> > > accessability.  However If by poor planning I had a "REJECT"
> > > rights in
> > > Role1, then I'd have the issues you are stating.
> > >
> > >
> > >
> > >
> > > Francis Harvey wrote On 6/25/2004 2:24 PM:
> > >
> > > >Arthur,
> > > >
> > > >Do some research on the basic solutions for SQL that has to
> > > adjust for
> > > >varying databases, conditions (dynamic search), or servers
> > > >(different
> >
> > > >SQL dialects). Some designs also call for encapsulating
> > > business logic
> > > >outside of the data tier. In these situations, dynamic SQL is
often
>
> > > >the only logical choice. I have only had to deal with dynamic
> > > >search myself, but this is enough to convince me of its
usefulness.
> > > >
> > > >Describing permissions solely as additive in nature is
> > > incorrect. This
> > > >is the point I was making.
> > > >
> > > >Francis R Harvey III
> > > >WB 303, (301)294-3952
> > > >harveyf1 at westat.com
> ><snip>
> >_______________________________________________
> >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
> >
>
> _________________________________________________________________
> MSN Premium with Virus Guard and Firewall* from McAfeeR Security : 2
> months
> FREE*
>
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU
> =http://hotmail.com/enca&HL=Market_MSNIS_Taglines
>
> _______________________________________________
> 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 my.lists at verizon.net  Wed Jun 30 18:42:32 2004
From: my.lists at verizon.net (Francisco H Tapia)
Date: Wed, 30 Jun 2004 16:42:32 -0700
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <005401c45ef5$7716d500$0201a8c0@PARIS>
References: <04d901c45eb2$82afb780$6601a8c0@rock>
	<005401c45ef5$7716d500$0201a8c0@PARIS>
Message-ID: <40E34FE8.2020803@verizon.net>

I hear what you're saying Shamil, but coding is coding at any layer.  So 
even with less resources, ie, .net or c# programmers, code must still be 
altered even if not at the sql server, but at the gui or webservice 
layer.  These statements don't make as much sense to me as just 
modifying the logic at the source. 

coding w/ .net components in your sproc doesn't make them dynamic sql, 
it's like coding .COM objects in your sproc you can do it via sp_OAxxx 
but these are limited to sysadmin roles because of the major security 
risk involved.

no offense either to you or to the article you posted, it's a good 
article, I just don't agree that column names justify dynamic sql.  
There are otherways of working output at the gui level if that is ultra 
imporant.

Shamil Salakhetdinov wrote On 6/30/2004 3:56 PM:

>Arthur,
>
>Just a philosopical opinion/point of view:
>
>Database-centered programming for nowaday businesses are becoming more
>and more dynamic and constantly changing....
>The SPs are like a "chiseled in stone" stuff.
>And dynamic SQL is an amorphic matter, flexibly and smoothly adapting to
>constantly changing businesses and their business rules.
>Please take into consideration this fact: "chiseled in stone" DLL-Hell
>producing COM interfaces are being substituted with .NET Framework
>flexible architecture...
>IMHO the similar tendence is starting to appear itself more and more
>apparently in data(base) layer programming.
>Here is why Application Roles (see BOL) were introduced.
>Here is why Youkon will support smooth integration with C#/VB.NET/...
>extended SPs which in turn will (I guess) work heavily with dynamic
>SQL...
>
>And as far as I see metadata-based data access and data
>integrity/business rules verification/support are also becoming more and
>more popular - and this is what is needed for the modern small and
>middle size businesses: they urge for the broad automation of their
>businesses because of economical and other reasons but they don't have
>enough resources to finance design and development and then constant
>redesign and code rewriting/refactoring...
>
>And of course I'm not talking about "SPs must die" - as usual solution
>is somewhere in between and is a balance of many interests but for sure
>dynamic SQL's role isn't that  narrow as described in
>http://www.sqlservercentral.com/columnists/rmarda/whendynamicsqlisuseful_printversion.asp -
>the fact is that most of these samples look obsolete because they can be
>rewritten IMO using UDFs, XML (OpenXML) - i.e.using SPs but without EXEC
>I think! :)
>
>Just my pair of roubles,
>Sorry in advance if I did miss the subject of this thread,
>Shamil
>
>--
>e-mail: shamil at smsconsulting.spb.ru
>Web:   http://smsconsulting.spb.ru/shamil_s
>
>----- Original Message ----- 
>From: "Arthur Fuller" <artful at rogers.com>
>To: <dba-sqlserver at databaseadvisors.com>
>Sent: Wednesday, June 30, 2004 6:57 PM
>Subject: RE: [dba-SQLServer] Difference between views and queries
>
>
>  
>
>>Good example, and good reasoning, and I agree that dynamic SQL is
>>    
>>
>never
>  
>
>>out of the question. What I intended to write is that more often than
>>not, dynamic SQL is the lazy way out of thinking carefully about
>>    
>>
>sprocs.
>  
>
>>Most of the time it is unnecessary and costly in terms of performance
>>and front-end code; some of the time, there is no other way.
>>
>>Arthur
>>


-- 
-Francisco




From artful at rogers.com  Wed Jun 30 19:08:30 2004
From: artful at rogers.com (Arthur Fuller)
Date: Wed, 30 Jun 2004 20:08:30 -0400
Subject: [dba-SQLServer] Re: Difference between views and queries
In-Reply-To: <BAY1-F33SDPAJESuTei00017ebb@hotmail.com>
Message-ID: <058301c45eff$8ab4e980$6601a8c0@rock>

Yes, Billy! Big difference between OLTP and OLAP systems. In short,
don't consume CPU cycles etc. on the OLTP system; write a separate OLAP
system that contains nothing but serious reports, so as not to slow the
OLTP system down when some manager wants some report. In this case
(OLAP) it is most often correct to denormalize.

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Billy
Pang
Sent: Wednesday, June 30, 2004 4:38 PM
To: dba-sqlserver at databaseadvisors.com
Subject: RE: [dba-SQLServer] Re: Difference between views and queries


A database could be not normalized for reporting reasons, isn't that
true? difference between OLTP and OLAP?

Billy


>From: "Robert L. Stewart" <rl_stewart at highstream.net>
>Reply-To: dba-sqlserver at databaseadvisors.com
>To: dba-sqlserver at databaseadvisors.com
>Subject: [dba-SQLServer] Re: Difference between views and queries
>Date: Wed, 30 Jun 2004 12:17:41 -0500
>
>Francis,
>
>Actually the reason most databases are not fully normalized is not
>laziness, but ignorance.  Most DBA's know nothing about normalization
and 
>many developers even less.  And, yes I would make such a blanket
statement.
>
>Robert
>
>At 12:01 PM 30/06/2004 -0500, you wrote:
>>Date: Wed, 30 Jun 2004 11:21:12 -0400
>>From: Francis Harvey <HARVEYF1 at WESTAT.com>
>>Subject: RE: [dba-SQLServer] Difference between views and queries
>>To: "'dba-sqlserver at databaseadvisors.com'"
>>         <dba-sqlserver at databaseadvisors.com>
>>Message-ID:
>>         <446DDE75CFC7E1438061462F85557B0F0481E931 at remail2.westat.com>
>>Content-Type: text/plain
>>
>>Arthur,
>>
>>More often than not?
>>
>> > From: dba-sqlserver-bounces at databaseadvisors.com
>> > [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of 
>> > Arthur Fuller
>> > Sent: Friday, June 25, 2004 4:23 PM
>> > To: dba-sqlserver at databaseadvisors.com
>> > Subject: RE: [dba-SQLServer] Difference between views and queries
>> >
>> >
>> > 1. I haven't yet seen a case where dynamic SQL is necessary. All it

>> > takes to avoid it is one or more well-constructed sprocs, IMO.
>>
>> > -----Original Message-----
>> > From: dba-sqlserver-bounces at databaseadvisors.com
>> > [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of 
>> > Arthur Fuller
>> > Sent: Tuesday, June 29, 2004 8:19 PM
>> > To: dba-sqlserver at databaseadvisors.com
>> > Subject: RE: [dba-SQLServer] Difference between views and queries
>> >
>><snip>
>>
>> > I think dynamic SQL is for the lazy. So there, I said it.
>>
>>You really would characterize your responses as that balanced? I find 
>>your current restatement far more agreeable. Of course, I could add 
>>similar comments about people who's databases aren't fully normalized.

>>Most of the time it is due to laziness and causes inefficiency and 
>>requires greater coding. Yet, sometimes it is necessary. Would you 
>>then make those same statements from above about everyone whose 
>>database isn't fully normalized? I would think you would at least be 
>>curious as to why it was done before making such blanket statements.
>
>
>_______________________________________________
>dba-SQLServer mailing list
>dba-SQLServer at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/dba-sqlserver
>http://www.databaseadvisors.com
>

_________________________________________________________________
Free yourself from those irritating pop-up ads with MSn Premium. Get
2months 
FREE*  
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU
=http://hotmail.com/enca&HL=Market_MSNIS_Taglines

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



From artful at rogers.com  Wed Jun 30 19:46:12 2004
From: artful at rogers.com (Arthur Fuller)
Date: Wed, 30 Jun 2004 20:46:12 -0400
Subject: [dba-SQLServer] Difference between views and queries
In-Reply-To: <005401c45ef5$7716d500$0201a8c0@PARIS>
Message-ID: <058801c45f04$ceaa6d40$6601a8c0@rock>

As usual, Shamil, you make excellenmt points. We are not arguing so much
as complementing each other's position.

IMO, (and that's all it is), everything the database can do the database
should do. In my ideal SQL app, there would be almost no code in the FE
except the code that decides which sproc to fire and what to pass as
arguments. The more code that exists in the FE, the weaker I think the
app is. Why? Because I don't want some "power user" to load Excel and
f**k with the data!

So when I build a SQL database, NO ONE (except me and my peers) can
touch a table. Everyone else using the system hits a sproc or view or
UDF. End of story. I, as godlike being, can touch tables. Mere mortals
cannot. Period. No exceptions.

In practice, this means that I examine the human roles, i.e. job specs,
to see what the various humans in the organization are allowed to do. I
build roles corresponding to job specs. I generate simple sprocs for
each op (DISU = delete/insert/select/update) on each table. Could be
that a single form hits a number of tables, but the hits always result
in some combination of DISU -- there are no other ops. Having built the
single-table DISU ops, it becomes trivial to write a sproc that hits say
5 tables, inserting into 2, updating 1, and deleting from 2. Nothing to
it, brain-dead simple once you have the atomic pieces in place.

Ideally, I don't want any code that touches the database in the FE. Why?
Because if we dump FE#1 (let's call it Access) and replace it with FE#2
(let's call it vb.net), I don't want to rewrite any database-hitting
code. I want to fire sprocs and/or call UDFS and be done with it. So if
some "power user" fires up Excel and creates an ODBC hook to the
database, he can't do anything but select (at most). Can't add, can't
edit, can't insert, can't delete. Substitute POwerBuilder or Delphi or
anything you want... If the only available access is via
sprocs/views/udfs, then I'm confident that you can't trudge in and stomp
all over my data.

Every new UI inherits the smarts in the sprocs, and nothing needs to be
duplicated except the calls to the sprocs/views/udfs. IMO, this way no
code needs to be copied from one UI to another; you simply fire the
sprocs, passing what they require. If there's a bug in the sproc you fix
the sproc and all apps inherit the fix -- because the logic resides in
precisely one place -- the db, where it belongs!

Ok, I stated this a little bit fundamentalist. There are exceptions, and
I accept them. 

-----Original Message-----
From: dba-sqlserver-bounces at databaseadvisors.com
[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Shamil
Salakhetdinov
Sent: Wednesday, June 30, 2004 6:56 PM
To: dba-sqlserver at databaseadvisors.com
Subject: Re: [dba-SQLServer] Difference between views and queries


Arthur,

Just a philosopical opinion/point of view:

Database-centered programming for nowaday businesses are becoming more
and more dynamic and constantly changing.... The SPs are like a
"chiseled in stone" stuff. And dynamic SQL is an amorphic matter,
flexibly and smoothly adapting to constantly changing businesses and
their business rules. Please take into consideration this fact:
"chiseled in stone" DLL-Hell producing COM interfaces are being
substituted with .NET Framework flexible architecture... IMHO the
similar tendence is starting to appear itself more and more apparently
in data(base) layer programming. Here is why Application Roles (see BOL)
were introduced. Here is why Youkon will support smooth integration with
C#/VB.NET/... extended SPs which in turn will (I guess) work heavily
with dynamic SQL...

And as far as I see metadata-based data access and data
integrity/business rules verification/support are also becoming more and
more popular - and this is what is needed for the modern small and
middle size businesses: they urge for the broad automation of their
businesses because of economical and other reasons but they don't have
enough resources to finance design and development and then constant
redesign and code rewriting/refactoring...

And of course I'm not talking about "SPs must die" - as usual solution
is somewhere in between and is a balance of many interests but for sure
dynamic SQL's role isn't that  narrow as described in
http://www.sqlservercentral.com/columnists/rmarda/whendynamicsqlisuseful
_printversion.asp - the fact is that most of these samples look obsolete
because they can be rewritten IMO using UDFs, XML (OpenXML) - i.e.using
SPs but without EXEC I think! :)

Just my pair of roubles,
Sorry in advance if I did miss the subject of this thread, Shamil

--
e-mail: shamil at smsconsulting.spb.ru
Web:   http://smsconsulting.spb.ru/shamil_s

----- Original Message ----- 
From: "Arthur Fuller" <artful at rogers.com>
To: <dba-sqlserver at databaseadvisors.com>
Sent: Wednesday, June 30, 2004 6:57 PM
Subject: RE: [dba-SQLServer] Difference between views and queries


> Good example, and good reasoning, and I agree that dynamic SQL is
never
> out of the question. What I intended to write is that more often than 
> not, dynamic SQL is the lazy way out of thinking carefully about
sprocs.
> Most of the time it is unnecessary and costly in terms of performance 
> and front-end code; some of the time, there is no other way.
>
> Arthur
>
> -----Original Message-----
> From: dba-sqlserver-bounces at databaseadvisors.com
> [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of Billy

> Pang
> Sent: Wednesday, June 30, 2004 12:57 AM
> To: dba-sqlserver at databaseadvisors.com
> Subject: RE: [dba-SQLServer] Difference between views and queries
>
>
> oh boy, can't wait to get into this discussion :)...there is one
example
> I
> can think of..  the example would be based on the physical storage of 
> the sproc in a single db.  it is not possible for a sproc to query 
> table
in
> another db that the sproc does not reside in.
>
> To illustrate, let's say that there are three copies of the northwind
db
> on
> db server: northwind0, northwind1 and northwind2; all three have exact

> db schema;
>
> Your goal is to develop a report that counts number of records in the 
> products table in each of the northwind databases.  sometimes you may 
> only want to count records in northwind0 and northwind1 but not 
> northwind2; sometimes you may only want northwind2 and northwind1 but 
> not northwind0;
> and sometimes you want all three northwind dbs in your count.  It is
> possible to create a sp for each of the permutation but if a fourth
> northwind db is introduced to the system, then the code base is
doubled.
>
> The alternate solution would be to build dynamic sql to piece together

> select statement referencing tables using the [db].[owner].[table] 
> format; which tables are pieced together is based on what the user 
> selects as criteria for report.  Not elegant solution but it is a lot 
> less code
to
> maintain.
>
> With that being said, dynamic sql is not as safe for reporting
compared
> to
> sproc.
>
> I think what Francis is trying to get at is that it is not possible
for
> a
> developer to claim that a particular "coding method" is never needed. 
> Rather, it is more correct to state that it is not likely that a 
> particular "coding method" is ever needed.  Difference between the 
> words "impossible"
> and "improbable".  Similiar to how a judge cannot hand out a verdict
to
> court case before the case is presented no matter obvious it may seem.
>
> Another point of reference on this topic would be look up "Validating 
> User Input" in BOL for best practices on this issue.
>
> Billy
>
>
> >From: "Arthur Fuller" <artful at rogers.com>
> >Reply-To: dba-sqlserver at databaseadvisors.com
> >To: <dba-sqlserver at databaseadvisors.com>
> >Subject: RE: [dba-SQLServer] Difference between views and queries
> >Date: Tue, 29 Jun 2004 20:08:54 -0400
> >
> >All I want is an example that cannot be coded by one or more sprocs.
> >
> >Arthur
> >
> >-----Original Message-----
> >From: dba-sqlserver-bounces at databaseadvisors.com
> >[mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of 
> >Francis Harvey
> >Sent: Tuesday, June 29, 2004 10:47 AM
> >To: 'dba-sqlserver at databaseadvisors.com'
> >Subject: RE: [dba-SQLServer] Difference between views and queries
> >
> >
> >Francisco,
> >
> >I would like to consider the opinion of someone who shares my
namesake
> >as seriously as possible, but in this case, I believe you suffer from

> >Arthur's problem of a lack of experience with the very specific 
> >problems I cited. It is fine to talk about not using dynamic SQL in 
> >general when using SQL Server, but just as with normalization, there 
> >are exceptions and no one should be stating it as an absolute rule or

> >bad practice until they have reviewed the problems I mentioned.
Again,
> >I will state, for those particular problems, dynamic SQL is often the

> >superior solution.
> >
> >Also, the "scaling" issue is teetering awfully close to using FUD.
You
> >can always use any programming method incorrectly, but correctly 
> >written dynamic SQL does not suffer from the horrible efficiency loss

> >that not having a cached query plan would seem to imply. Similarly,
the
>
> >"time spent" argument is bad logic. I don't spend less time on my 
> >dynamic SQL solutions, I spend more time because the problems are 
> >difficult. Adding more time for a static SQL solution will not result

> >in a better design or even a working design in some cases.
> >
> >I don't think you, Arthur or I are in disagreement over security, I 
> >just didn't like the oversimplified way security was described, so I 
> >chose to emphasize a particular point. I think this is an important 
> >part that should be highlighted.
> >
> >Francis R Harvey III
> >WB 303, (301)294-3952
> >harveyf1 at westat.com
> >
> >
> > > -----Original Message-----
> > > From: dba-sqlserver-bounces at databaseadvisors.com
> > > [mailto:dba-sqlserver-bounces at databaseadvisors.com] On Behalf Of 
> > > Francisco H Tapia
> > > Sent: Monday, June 28, 2004 12:42 PM
> > > To: dba-sqlserver at databaseadvisors.com
> > > Subject: Re: [dba-SQLServer] Difference between views and queries
> > >
> > >
> > > Francis,
> > >    I respectfully agree w/ Arthur on this.  Dynamic SQL as a rule,

> > > is bad design.  Many times over you will find that there are 
> > > comparable solutions that often meet the demand much better, and 
> > > "scale" much better than that of dynamic sql.  There is no "ONE" 
> > > right way of doing things, that is the nature of this business. 
> > > However justifying dynamic sql because of some time spent on 
> > > design is imnsho incorrect.  You will
> > > often find more times that enabling users/roles via Views/Sprocs
and
> > > Functions to be far superior solutions than to open wide dynamic
> sql.
> > >
> > > re: security.
> > > Of course if you deny permissions on any object the take
precedence
> > > over allows, this is the nature of security.  That is why you must

> > > be explicitly "SURE" when making DENY requests on any object. NOT 
> > > giving rights to an object does not equeal REJECT.
> > >
> > > If I do not give a user rights to a view, under Role1, but then
give
>
> > > him rights to that object via Role2.  There will be 0 issues w/ 
> > > accessability.  However If by poor planning I had a "REJECT" 
> > > rights in Role1, then I'd have the issues you are stating.
> > >
> > >
> > >
> > >
> > > Francis Harvey wrote On 6/25/2004 2:24 PM:
> > >
> > > >Arthur,
> > > >
> > > >Do some research on the basic solutions for SQL that has to
> > > adjust for
> > > >varying databases, conditions (dynamic search), or servers 
> > > >(different
> >
> > > >SQL dialects). Some designs also call for encapsulating
> > > business logic
> > > >outside of the data tier. In these situations, dynamic SQL is
often
>
> > > >the only logical choice. I have only had to deal with dynamic 
> > > >search myself, but this is enough to convince me of its
usefulness.
> > > >
> > > >Describing permissions solely as additive in nature is
> > > incorrect. This
> > > >is the point I was making.
> > > >
> > > >Francis R Harvey III
> > > >WB 303, (301)294-3952
> > > >harveyf1 at westat.com
> ><snip>
> >_______________________________________________
> >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
> >
>
> _________________________________________________________________
> MSN Premium with Virus Guard and Firewall* from McAfeeR Security : 2 
> months
> FREE*
>
http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU
> =http://hotmail.com/enca&HL=Market_MSNIS_Taglines
>
> _______________________________________________
> 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 DMcAfee at haascnc.com  Wed Jun 30 20:05:17 2004
From: DMcAfee at haascnc.com (David McAfee)
Date: Wed, 30 Jun 2004 18:05:17 -0700
Subject: [dba-SQLServer] Difference between views and queries
Message-ID: <657FB70438B7D311AF320090279C180106144245@exchmail.haascnc.com>

Amen, brother! I couldn't have said that better myself.

:)

David


Arthur Fuller wrote:


	As usual, Shamil, you make excellenmt points. We are not arguing so much
	as complementing each other's position.
	
	IMO, (and that's all it is), everything the database can do the database
	should do. In my ideal SQL app, there would be almost no code in the FE
	except the code that decides which sproc to fire and what to pass as
	arguments. The more code that exists in the FE, the weaker I think the
	app is. Why? Because I don't want some "power user" to load Excel and
	f**k with the data!
	
	So when I build a SQL database, NO ONE (except me and my peers) can
	touch a table. Everyone else using the system hits a sproc or view or
	UDF. End of story. I, as godlike being, can touch tables. Mere mortals
	cannot. Period. No exceptions.
	
	In practice, this means that I examine the human roles, i.e. job specs,
	to see what the various humans in the organization are allowed to do. I
	build roles corresponding to job specs. I generate simple sprocs for
	each op (DISU = delete/insert/select/update) on each table. Could be
	that a single form hits a number of tables, but the hits always result
	in some combination of DISU -- there are no other ops. Having built the
	single-table DISU ops, it becomes trivial to write a sproc that hits say
	5 tables, inserting into 2, updating 1, and deleting from 2. Nothing to
	it, brain-dead simple once you have the atomic pieces in place.
	
	Ideally, I don't want any code that touches the database in the FE. Why?
	Because if we dump FE#1 (let's call it Access) and replace it with FE#2
	(let's call it vb.net), I don't want to rewrite any database-hitting
	code. I want to fire sprocs and/or call UDFS and be done with it. So if
	some "power user" fires up Excel and creates an ODBC hook to the
	database, he can't do anything but select (at most). Can't add, can't
	edit, can't insert, can't delete. Substitute POwerBuilder or Delphi or
	anything you want... If the only available access is via
	sprocs/views/udfs, then I'm confident that you can't trudge in and stomp
	all over my data.
	
	Every new UI inherits the smarts in the sprocs, and nothing needs to be
	duplicated except the calls to the sprocs/views/udfs. IMO, this way no
	code needs to be copied from one UI to another; you simply fire the
	sprocs, passing what they require. If there's a bug in the sproc you fix
	the sproc and all apps inherit the fix -- because the logic resides in
	precisely one place -- the db, where it belongs!
	
	Ok, I stated this a little bit fundamentalist. There are exceptions, and
	I accept them.