Best Practices for Design of Views

Hi, I have been using Views for a while now instead of constructing SQL
statements in the application but one the problems is that as the
applications grow the views need more and more columns, alisaes, and
both Lookup values and Foreign key ID for a range of uses.
At least when constructing SQL SELECT in the application each form or
function has a specific need for columns so you dont aim for any
re-usability.
How it is best to manage this when designing views? Showuld there be
one view only per logical entity that has a lot of columns making it
applicable for a whole range of uses, or individual views, one per use
with its own specific columns. If the latter is used I have a problem
naming and remembering names of all the different views.
An example may help illustrate this:
vwInvoices - This currently contains only the columns needed to diplay
a list of Invoices after doing a search, + any columns used in the
search. But when drilling into a single Invoice from the list it will
need many more columns. While the search tool only needs the foreign
key ID of the user who created it (The search tool users a dropdownn
list of users with IDs behind names) , the full detail screen needs to
show the actual user name from the users table.
Shold this view even be used for for selecting one record? Should a
stored procedure be used instead?
Are there any design principles or best practices anyone ccan share for
these issues.
Thanks.hals_left wrote:
> Hi, I have been using Views for a while now instead of constructing SQL
> statements in the application but one the problems is that as the
> applications grow the views need more and more columns, alisaes, and
> both Lookup values and Foreign key ID for a range of uses.
> At least when constructing SQL SELECT in the application each form or
> function has a specific need for columns so you dont aim for any
> re-usability.
> How it is best to manage this when designing views? Showuld there be
> one view only per logical entity that has a lot of columns making it
> applicable for a whole range of uses, or individual views, one per use
> with its own specific columns. If the latter is used I have a problem
> naming and remembering names of all the different views.
> An example may help illustrate this:
> vwInvoices - This currently contains only the columns needed to diplay
> a list of Invoices after doing a search, + any columns used in the
> search. But when drilling into a single Invoice from the list it will
> need many more columns. While the search tool only needs the foreign
> key ID of the user who created it (The search tool users a dropdownn
> list of users with IDs behind names) , the full detail screen needs to
> show the actual user name from the users table.
> Shold this view even be used for for selecting one record? Should a
> stored procedure be used instead?
> Are there any design principles or best practices anyone ccan share for
> these issues.
> Thanks.
Best practice in most environments is that the application should
access the database only through stored procedures, not views. Procs
are the best method to encapsulate logic, facilitate code reuse,
optimise performance and implement security. Views are useful if you
need to share the same query logic in several procs. For most business
process applications it isn't good practice to access views or tables
directly. See:
http://msdn.microsoft.com/library/d...y/en-us/opti...
http://www.sql-server-performance.c..._procedures.asp
http://www.sommarskog.se/dynamic_sql.html
http://weblogs.asp.net/rhoward/arch...1/17/38095.aspx
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
--|||Oops. One of the links got scrambled:
http://msdn.microsoft.com/library/d.../>
1a_6x45.asp
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
--|||Thanks David.
If I understand correctly, the best practice to display lines for a
single invoice would therefore be to have a stored procedure that
queries a view , rather than have the application construct a WHERE
clause and query the view directly ?
The procedure would be something like this ?
-- Retrieves the Invoice Lines for 1 invoice
CREATE PROCEDURE [dbo].[getSingleInvoiceLines]
@.InvoiceID Int
AS
SELECT [Description],Quantity,UnitCost, Department,Nominal
FROM dbo.vwInvoiceLines
WHERE Invoice=@.InvoiceID
GO
And used something like this in an application ?
set oRS = objConn.Execute ( "dbo.getSingleInvoiceLines " & intInvoice )
// Or with ADODB.Command / Explicit Parameters etc..
If Not oRS.EOF THen
while not oRS.EOF%>
...|||hals_left wrote:
> Thanks David.
> If I understand correctly, the best practice to display lines for a
> single invoice would therefore be to have a stored procedure that
> queries a view , rather than have the application construct a WHERE
> clause and query the view directly ?
> The procedure would be something like this ?
> -- Retrieves the Invoice Lines for 1 invoice
> CREATE PROCEDURE [dbo].[getSingleInvoiceLines]
> @.InvoiceID Int
> AS
> SELECT [Description],Quantity,UnitCost, Department,Nominal
> FROM dbo.vwInvoiceLines
> WHERE Invoice=@.InvoiceID
> GO
> And used something like this in an application ?
> set oRS = objConn.Execute ( "dbo.getSingleInvoiceLines " & intInvoice )
> // Or with ADODB.Command / Explicit Parameters etc..
> If Not oRS.EOF THen
> while not oRS.EOF%>
> ...
Use the ADO parameters collection rather than construct strings
dynamically. Usually you'll also want to put some error handling in
your procs - in fact that's one of the advantages of procs.
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
--

Best Practice for Windows Authentication?

Hi,
We are changing our classic ASP web application to use Windows
Authentication instead of SQL Server Authentication.
I would like to know the best practice for:
1. IIS and SQL Server are on the same machine and
2.When they are on different machines in the same domain.
I *think* the solution to 1. is to add the IUSR_MACHINENAME user to SQL
Server (this works but is it the best practice?)
For 2. I have read different opinions. Some say create a IUSR_IISMACHINENAME
account on the SQL Server and make sure they have the same password. Other
say create a user on the domain and use that in IIS as the anonymous user
(and give that user the relevant rights on SQL Server)
I would like to know what is considered the best practice for this sort of
authentication.
Thanks in advancewhat version of IIS you running ?, using ASP.NET ?
http://msdn2.microsoft.com/en-us/library/bsz5788z
"Hugh Mungo" <hugh_mungo@.hotmail.com> wrote in message
news:%23igmiopuFHA.3500@.TK2MSFTNGP09.phx.gbl...
> Hi,
> We are changing our classic ASP web application to use Windows
> Authentication instead of SQL Server Authentication.
> I would like to know the best practice for:
> 1. IIS and SQL Server are on the same machine and
> 2.When they are on different machines in the same domain.
> I *think* the solution to 1. is to add the IUSR_MACHINENAME user to SQL
> Server (this works but is it the best practice?)
> For 2. I have read different opinions. Some say create a
> IUSR_IISMACHINENAME
> account on the SQL Server and make sure they have the same password. Other
> say create a user on the domain and use that in IIS as the anonymous user
> (and give that user the relevant rights on SQL Server)
> I would like to know what is considered the best practice for this sort of
> authentication.
> Thanks in advance
>|||The solution should work with IIS5 and above.
We are not using ASP.NET this is a classic ASP application.
"David J. Cartwright" <davidcartwright@.hotmail.com> wrote in message
news:OcQFYgruFHA.2076@.TK2MSFTNGP14.phx.gbl...
> what version of IIS you running ?, using ASP.NET ?
> http://msdn2.microsoft.com/en-us/library/bsz5788z
> "Hugh Mungo" <hugh_mungo@.hotmail.com> wrote in message
> news:%23igmiopuFHA.3500@.TK2MSFTNGP09.phx.gbl...
Other[vbcol=seagreen]
user[vbcol=seagreen]
of[vbcol=seagreen]
>|||What a coincidence. Same here. I would definitely be interested to know
how to do this best practice also as this is the exact same thing that I'm
currently working on. One slightly different thing here is that we require
individual accounts (so we can track user activity with our sql profiler)
and would believe we would create a windows account on our domain controller
which resides on a different machine than our web (.asp files) and sql
server (also on separate machine) and was wondering if this would be
possible and how to go about doing this. Would it be as straight forward in
changing the connection string in our .asp files specifying windows
authentication? I am not too familiar in how to do this but was thinking of
maybe removing the anonymous account in IIS so that it would force the user
to login with the windows authentication pop up (in the possible situation
if users share a public machine and/or if the machine's operating system is
not windows with a valid corresponding domain windows account on our domain
controller?...which makes me wonder how this would be incorporated into our
connection string in our .asp files? Thanks in advance
"Hugh Mungo" <hugh_mungo@.hotmail.com> wrote in message
news:eJLVIyruFHA.2312@.TK2MSFTNGP14.phx.gbl...
> The solution should work with IIS5 and above.
> We are not using ASP.NET this is a classic ASP application.
> "David J. Cartwright" <davidcartwright@.hotmail.com> wrote in message
> news:OcQFYgruFHA.2076@.TK2MSFTNGP14.phx.gbl...
> Other
> user
> of
>|||_-=?/today_-=?/354
"Hugh Mungo" wrote:

> Hi,
> We are changing our classic ASP web application to use Windows
> Authentication instead of SQL Server Authentication.
> I would like to know the best practice for:
> 1. IIS and SQL Server are on the same machine and
> 2.When they are on different machines in the same domain.
> I *think* the solution to 1. is to add the IUSR_MACHINENAME user to SQL
> Server (this works but is it the best practice?)
> For 2. I have read different opinions. Some say create a IUSR_IISMACHINENA
ME
> account on the SQL Server and make sure they have the same password. Other
> say create a user on the domain and use that in IIS as the anonymous user
> (and give that user the relevant rights on SQL Server)
> I would like to know what is considered the best practice for this sort of
> authentication.
> Thanks in advance
>
>

Best practice BIT or SET('no','yes') ?

Hi,
I know it's quite common to use BIT fields for boolean values.
CREATE TABLE tblTest (
door BIT DEFAULT 0,
accept BIT DEFAULT 0
)
instead of:
CREATE TABLE tblTest (
door SET('close','open') DEFAULT 'close',
accept SET('no','yes') DEFAULT 'no'
)
(By the way, I use MSSQL and MySQL, not sure if I'm using the right
datatypes for MSSQL)
I reckon the first uses less storage space, but the meaning of the values in
the latter is more unanimous.
So what's best practice? I'm tempted to use the latter, but I almost always
see the first used everywhere.
I'm definitely interested in what CELKO has to say about this.
LisaMy opinion, FWIW
-Comarison operators with bit datatypes will be faster
-You don't have to worry about differences in collations when comparing
-More efficient storage on disk
-You could always add the unanimous-ness (which I'm positive is not a word!)
in a select that extracts the data out of these fields like
select case when door = 0 then 'closed' else 'open' end from tblTest
Proper T-SQL syntax for the character-based table would be
CREATE TABLE tblTest (
door varchar(5) CHECK (door IN ('close','open')) DEFAULT 'close',
accept varchar(5) CHECK (accept IN ('no','yes')) DEFAULT 'no'
)
--
"Lisa Pearlson" wrote:

> Hi,
> I know it's quite common to use BIT fields for boolean values.
> CREATE TABLE tblTest (
> door BIT DEFAULT 0,
> accept BIT DEFAULT 0
> )
> instead of:
> CREATE TABLE tblTest (
> door SET('close','open') DEFAULT 'close',
> accept SET('no','yes') DEFAULT 'no'
> )
> (By the way, I use MSSQL and MySQL, not sure if I'm using the right
> datatypes for MSSQL)
> I reckon the first uses less storage space, but the meaning of the values
in
> the latter is more unanimous.
> So what's best practice? I'm tempted to use the latter, but I almost alway
s
> see the first used everywhere.
> I'm definitely interested in what CELKO has to say about this.
> Lisa
>
>|||Here we use the latter one cuz too many different programmers working off
the same database and each programmer has their own programs that they are
responsible for.
I prefer to use the first one to save size.
"Lisa Pearlson" <no@.spam.plz> wrote in message
news:O1u6wZDKGHA.3984@.TK2MSFTNGP14.phx.gbl...
> Hi,
> I know it's quite common to use BIT fields for boolean values.
> CREATE TABLE tblTest (
> door BIT DEFAULT 0,
> accept BIT DEFAULT 0
> )
> instead of:
> CREATE TABLE tblTest (
> door SET('close','open') DEFAULT 'close',
> accept SET('no','yes') DEFAULT 'no'
> )
> (By the way, I use MSSQL and MySQL, not sure if I'm using the right
> datatypes for MSSQL)
> I reckon the first uses less storage space, but the meaning of the values
> in the latter is more unanimous.
> So what's best practice? I'm tempted to use the latter, but I almost
> always see the first used everywhere.
> I'm definitely interested in what CELKO has to say about this.
> Lisa
>|||Lisa Pearlson wrote:

> Hi,
> I know it's quite common to use BIT fields for boolean values.
> CREATE TABLE tblTest (
> door BIT DEFAULT 0,
> accept BIT DEFAULT 0
> )
> instead of:
> CREATE TABLE tblTest (
> door SET('close','open') DEFAULT 'close',
> accept SET('no','yes') DEFAULT 'no'
> )
> (By the way, I use MSSQL and MySQL, not sure if I'm using the right
> datatypes for MSSQL)
> I reckon the first uses less storage space, but the meaning of the values
in
> the latter is more unanimous.
> So what's best practice? I'm tempted to use the latter, but I almost alway
s
> see the first used everywhere.
> I'm definitely interested in what CELKO has to say about this.
> Lisa
My main objection to BIT is that its behaviour is too strange and
counter-intuitive. For example, can you predict or explain the results
of the following INSERT statement and the SELECT statement?
CREATE TABLE T (x BIT NOT NULL);
INSERT INTO T VALUES (2);
SELECT MAX(x) FROM T;
In most cases BIT's saving on storage is probably modest. I prefer
concise, readable status codes (CHAR(1) for example) and when I need to
add a third status I don't need to change the datatype I just change a
CHECK constraint.
David Portas, SQL Server MVP
Whenever possible please post enough code to reproduce your problem.
Including CREATE TABLE and INSERT statements usually helps.
State what version of SQL Server you are using and specify the content
of any error messages.
SQL Server Books Online:
http://msdn2.microsoft.com/library/ms130214(en-US,SQL.90).aspx
--|||Like David, I usually use a 1 character flag. In my experience, when I
initially think I have a binary status, it is really a multi-varied
flag. In other words, as soon as I code to tell if the door is open or
closed, someone else wants to know if it's locked.
Payson
Lisa Pearlson wrote:
> Hi,
> I know it's quite common to use BIT fields for boolean values.
> CREATE TABLE tblTest (
> door BIT DEFAULT 0,
> accept BIT DEFAULT 0
> )
> instead of:
> CREATE TABLE tblTest (
> door SET('close','open') DEFAULT 'close',
> accept SET('no','yes') DEFAULT 'no'
> )
> (By the way, I use MSSQL and MySQL, not sure if I'm using the right
> datatypes for MSSQL)
> I reckon the first uses less storage space, but the meaning of the values
in
> the latter is more unanimous.
> So what's best practice? I'm tempted to use the latter, but I almost alway
s
> see the first used everywhere.
> I'm definitely interested in what CELKO has to say about this.
> Lisa|||> In other words, as soon as I code to tell if the door is open or
> closed, someone else wants to know if it's locked.
I love the analogy. :-)
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Payson" <payson_b@.hotmail.com> wrote in message
news:1138914380.158598.148590@.f14g2000cwb.googlegroups.com...
> Like David, I usually use a 1 character flag. In my experience, when I
> initially think I have a binary status, it is really a multi-varied
> flag. In other words, as soon as I code to tell if the door is open or
> closed, someone else wants to know if it's locked.
> Payson
> Lisa Pearlson wrote:
>|||Lisa--
Great question. One way of clearing this up is by naming your columns in a
way where it won't be ambiguous. If you know that a Door only has two
states, Open and Closed, the meaning will be clear with a BIT datatype if yo
u
use a convention like "IsDoorOpen". That way, it's obvious what "1" and "0"
mean. If it's possible that a door will have more than 2 states in the
future, use a single character {[O]pen, [C]losed, [A]jar} to represent the
state of the door. In that case, you might call your column DoorStatus, or
DoorState... Likewise, you can name your "Accept" column "IsAccepted" and
clarify the meaning there. At my company, we use "Is" to prefix just about
all of the boolean values that we put in our code for just this reason.
HTH
-Dave Markle
"Lisa Pearlson" wrote:

> Hi,
> I know it's quite common to use BIT fields for boolean values.
> CREATE TABLE tblTest (
> door BIT DEFAULT 0,
> accept BIT DEFAULT 0
> )
> instead of:
> CREATE TABLE tblTest (
> door SET('close','open') DEFAULT 'close',
> accept SET('no','yes') DEFAULT 'no'
> )
> (By the way, I use MSSQL and MySQL, not sure if I'm using the right
> datatypes for MSSQL)
> I reckon the first uses less storage space, but the meaning of the values
in
> the latter is more unanimous.
> So what's best practice? I'm tempted to use the latter, but I almost alway
s
> see the first used everywhere.
> I'm definitely interested in what CELKO has to say about this.
> Lisa
>
>|||>> In other words, as soon as I code to tell if the door is open or closed,
someone else wants to know if it's locked.
I love the analogy. :-) <
Me, too!! I think I will steal it in the next edition of one of my
books! Hey, Imitation is the sincerest form of flattery; Plagiarism is
the sincerest form of imitation!|||Stop writing code as if you were an assembly language programmer in
1957.
Machine level things like a BIT or BYTE datatype have no place in a
high level language like SQL. SQL is a high level language; it is
abstract and defined without regard to PHYSICAL implementation. This
basic principle of data modeling is called data abstraction.
Bits and Bytes are the <i>lowest<i> units of hardware-specific,
physical implementation you can get. Are you on a high-end or low-end
machine? Does the machine have 8, 16, 32, 64, or 128 bit words? Twos
complement or ones complement math? Hey, the standards allow decimal
machines, so bits do not exist at all!! What about NULLs? To be an
SQL datatype, you have to have NULLs, so what is a NULL bit? By
definition a bit, is on or off and has no NULL.
What does the implementation of the host languages do with bits? Did
you know that +1, +0, -0 and -1 are all used for BOOLEANs, but not
consistently (look at C# and VB from the same vendor)? That means
<i>all<i> the host languages -- present, future and not-yet-defined.
Surely, no good programmer would ever write non-portable code by
getting to such a low level as bit fiddling!!
There are two situations in practice. Either the bits are individual
attributes or they are used as a vector to represent a single
attribute. In the case of a single attribute, the encoding is limited
to two values, which do not port to host languages or other SQLs,
cannot be easily understood by an end user, and which cannot be
expanded. Use CHAR(1) which will move.
In the second case what some Newbies, who are still thinking in terms
of second and third generation programming languages or even punch
cards, do is build a vector for a series of "yes/no" status codes,
failing to see the status vector as a single attribute. Did you ever
play the children's game "20 Questions" when you were young? Bingo!!
Imagine you have six components for a loan approval, so you allocate
bits in your second generation model of the world. You have 64 possible
vectors, but only 5 of them are valid (i.e. you cannot be rejected for
bankruptcy and still have good credit). For your data integrity, you
can:
1) Ignore the problem. This is actually what <i>most<i> newbies do.
2) Write elaborate CHECK() constraints with user defined functions or
proprietary bit level library functions that cannot port and that run
like cold glue.
Now we add a 7-th condition to the vector -- which end does it go on?
Why? How did you get it in the right place on all the possible
hardware that it will ever use? Did all the code that references a bit
in a word by its position do it right after the change?
You need to sit down and think about how to design an encoding of the
data that is high level, general enough to expand, abstract and
portable. For example, is that loan approval a hierarchical code?
concatenation code? vector code? etc? Did you provide codes for
unknown, missing and N/A values? It is not easy to design such things!
Get a copy of SQL PROGRAMMING STYLE and look at the chapters on design
encoding schemes.|||An excellent post Celko. I wish more of your posts were like this.
i.e. You focused more on the solution and the reasons behind it than
insulting folks who are doing it wrong.
When you make posts like this one we can all learn a little bit, without
being offended in the process.
"--CELKO--" <jcelko212@.earthlink.net> wrote in message
news:1139090746.005907.99750@.g14g2000cwa.googlegroups.com...
> Stop writing code as if you were an assembly language programmer in
> 1957.
> Machine level things like a BIT or BYTE datatype have no place in a
> high level language like SQL. SQL is a high level language; it is
> abstract and defined without regard to PHYSICAL implementation. This
> basic principle of data modeling is called data abstraction.
> Bits and Bytes are the <i>lowest<i> units of hardware-specific,
> physical implementation you can get. Are you on a high-end or low-end
> machine? Does the machine have 8, 16, 32, 64, or 128 bit words? Twos
> complement or ones complement math? Hey, the standards allow decimal
> machines, so bits do not exist at all!! What about NULLs? To be an
> SQL datatype, you have to have NULLs, so what is a NULL bit? By
> definition a bit, is on or off and has no NULL.
> What does the implementation of the host languages do with bits? Did
> you know that +1, +0, -0 and -1 are all used for BOOLEANs, but not
> consistently (look at C# and VB from the same vendor)? That means
> <i>all<i> the host languages -- present, future and not-yet-defined.
> Surely, no good programmer would ever write non-portable code by
> getting to such a low level as bit fiddling!!
> There are two situations in practice. Either the bits are individual
> attributes or they are used as a vector to represent a single
> attribute. In the case of a single attribute, the encoding is limited
> to two values, which do not port to host languages or other SQLs,
> cannot be easily understood by an end user, and which cannot be
> expanded. Use CHAR(1) which will move.
> In the second case what some Newbies, who are still thinking in terms
> of second and third generation programming languages or even punch
> cards, do is build a vector for a series of "yes/no" status codes,
> failing to see the status vector as a single attribute. Did you ever
> play the children's game "20 Questions" when you were young? Bingo!!
> Imagine you have six components for a loan approval, so you allocate
> bits in your second generation model of the world. You have 64 possible
> vectors, but only 5 of them are valid (i.e. you cannot be rejected for
> bankruptcy and still have good credit). For your data integrity, you
> can:
> 1) Ignore the problem. This is actually what <i>most<i> newbies do.
> 2) Write elaborate CHECK() constraints with user defined functions or
> proprietary bit level library functions that cannot port and that run
> like cold glue.
> Now we add a 7-th condition to the vector -- which end does it go on?
> Why? How did you get it in the right place on all the possible
> hardware that it will ever use? Did all the code that references a bit
> in a word by its position do it right after the change?
> You need to sit down and think about how to design an encoding of the
> data that is high level, general enough to expand, abstract and
> portable. For example, is that loan approval a hierarchical code?
> concatenation code? vector code? etc? Did you provide codes for
> unknown, missing and N/A values? It is not easy to design such things!
> Get a copy of SQL PROGRAMMING STYLE and look at the chapters on design
> encoding schemes.
>

Benefits of SQL authentication?

SQL2K
SP4
I can find lots of info regarding the justification to use WINNT instead of
SQL authentication. Are there any good reasons to use SQL authentication
instead?
TIA, ChrisRWeb applications, Mac or Linux users, or any situation where the users are
not members of the domain.
Arnie Rowland, Ph.D.
Westwood Consulting, Inc
Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous
"ChrisR" <ChrisR@.discussions.microsoft.com> wrote in message
news:AFC675ED-FE57-41DD-8CF9-F494E112E95A@.microsoft.com...
> SQL2K
> SP4
> I can find lots of info regarding the justification to use WINNT instead
> of
> SQL authentication. Are there any good reasons to use SQL authentication
> instead?
> TIA, ChrisR|||Thanks, I should have been more specific. I know there are times when users
MUST use SQL auth. However, if it could go either way, what would the
benefits be to SQL auth?
"Arnie Rowland" wrote:

> Web applications, Mac or Linux users, or any situation where the users are
> not members of the domain.
> --
> Arnie Rowland, Ph.D.
> Westwood Consulting, Inc
> Most good judgment comes from experience.
> Most experience comes from bad judgment.
> - Anonymous
>
> "ChrisR" <ChrisR@.discussions.microsoft.com> wrote in message
> news:AFC675ED-FE57-41DD-8CF9-F494E112E95A@.microsoft.com...
>
>|||If you have a choice, the pros are for Windows authentication, and the cons
are for SQL Authentication.
I, honestly, can't recall situations where SQL Authentication is the best
choice over Windows Authentication -unless SQL Authentication is required
for some specific need.
Arnie Rowland, Ph.D.
Westwood Consulting, Inc
Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous
"ChrisR" <ChrisR@.discussions.microsoft.com> wrote in message
news:F115C81F-55BA-46B1-A7AE-F156BD815A95@.microsoft.com...[vbcol=seagreen]
> Thanks, I should have been more specific. I know there are times when
> users
> MUST use SQL auth. However, if it could go either way, what would the
> benefits be to SQL auth?
>
> "Arnie Rowland" wrote:
>|||There aren't any benefits aside from needing to use it. You wouldn't
'choose' SQL Auth over Windows auth if you had both as a viable option -
ever. SQL Auth is a subset of Windows Auth - not vice versa.
"ChrisR" <ChrisR@.discussions.microsoft.com> wrote in message
news:F115C81F-55BA-46B1-A7AE-F156BD815A95@.microsoft.com...[vbcol=seagreen]
> Thanks, I should have been more specific. I know there are times when
> users
> MUST use SQL auth. However, if it could go either way, what would the
> benefits be to SQL auth?
>
> "Arnie Rowland" wrote:
>

Benefits of SQL authentication?

SQL2K
SP4
I can find lots of info regarding the justification to use WINNT instead of
SQL authentication. Are there any good reasons to use SQL authentication
instead?
TIA, ChrisRWeb applications, Mac or Linux users, or any situation where the users are
not members of the domain.
--
Arnie Rowland, Ph.D.
Westwood Consulting, Inc
Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous
"ChrisR" <ChrisR@.discussions.microsoft.com> wrote in message
news:AFC675ED-FE57-41DD-8CF9-F494E112E95A@.microsoft.com...
> SQL2K
> SP4
> I can find lots of info regarding the justification to use WINNT instead
> of
> SQL authentication. Are there any good reasons to use SQL authentication
> instead?
> TIA, ChrisR|||Thanks, I should have been more specific. I know there are times when users
MUST use SQL auth. However, if it could go either way, what would the
benefits be to SQL auth?
"Arnie Rowland" wrote:
> Web applications, Mac or Linux users, or any situation where the users are
> not members of the domain.
> --
> Arnie Rowland, Ph.D.
> Westwood Consulting, Inc
> Most good judgment comes from experience.
> Most experience comes from bad judgment.
> - Anonymous
>
> "ChrisR" <ChrisR@.discussions.microsoft.com> wrote in message
> news:AFC675ED-FE57-41DD-8CF9-F494E112E95A@.microsoft.com...
> > SQL2K
> > SP4
> >
> > I can find lots of info regarding the justification to use WINNT instead
> > of
> > SQL authentication. Are there any good reasons to use SQL authentication
> > instead?
> >
> > TIA, ChrisR
>
>|||If you have a choice, the pros are for Windows authentication, and the cons
are for SQL Authentication.
I, honestly, can't recall situations where SQL Authentication is the best
choice over Windows Authentication -unless SQL Authentication is required
for some specific need.
--
Arnie Rowland, Ph.D.
Westwood Consulting, Inc
Most good judgment comes from experience.
Most experience comes from bad judgment.
- Anonymous
"ChrisR" <ChrisR@.discussions.microsoft.com> wrote in message
news:F115C81F-55BA-46B1-A7AE-F156BD815A95@.microsoft.com...
> Thanks, I should have been more specific. I know there are times when
> users
> MUST use SQL auth. However, if it could go either way, what would the
> benefits be to SQL auth?
>
> "Arnie Rowland" wrote:
>> Web applications, Mac or Linux users, or any situation where the users
>> are
>> not members of the domain.
>> --
>> Arnie Rowland, Ph.D.
>> Westwood Consulting, Inc
>> Most good judgment comes from experience.
>> Most experience comes from bad judgment.
>> - Anonymous
>>
>> "ChrisR" <ChrisR@.discussions.microsoft.com> wrote in message
>> news:AFC675ED-FE57-41DD-8CF9-F494E112E95A@.microsoft.com...
>> > SQL2K
>> > SP4
>> >
>> > I can find lots of info regarding the justification to use WINNT
>> > instead
>> > of
>> > SQL authentication. Are there any good reasons to use SQL
>> > authentication
>> > instead?
>> >
>> > TIA, ChrisR
>>|||There aren't any benefits aside from needing to use it. You wouldn't
'choose' SQL Auth over Windows auth if you had both as a viable option -
ever. SQL Auth is a subset of Windows Auth - not vice versa.
"ChrisR" <ChrisR@.discussions.microsoft.com> wrote in message
news:F115C81F-55BA-46B1-A7AE-F156BD815A95@.microsoft.com...
> Thanks, I should have been more specific. I know there are times when
> users
> MUST use SQL auth. However, if it could go either way, what would the
> benefits be to SQL auth?
>
> "Arnie Rowland" wrote:
>> Web applications, Mac or Linux users, or any situation where the users
>> are
>> not members of the domain.
>> --
>> Arnie Rowland, Ph.D.
>> Westwood Consulting, Inc
>> Most good judgment comes from experience.
>> Most experience comes from bad judgment.
>> - Anonymous
>>
>> "ChrisR" <ChrisR@.discussions.microsoft.com> wrote in message
>> news:AFC675ED-FE57-41DD-8CF9-F494E112E95A@.microsoft.com...
>> > SQL2K
>> > SP4
>> >
>> > I can find lots of info regarding the justification to use WINNT
>> > instead
>> > of
>> > SQL authentication. Are there any good reasons to use SQL
>> > authentication
>> > instead?
>> >
>> > TIA, ChrisR
>>