Do I need two login ID's?

In installed SQL Server under my Win2003 Server userID, specifying NT
authentication. Then I down loaded MS JDBC, which requires Mixed mode
authentication, so I modifyed SQL Server to that. Now in Query analyzer, I
can log in to the db using windows authentication, but my user ID and
password don't work under SQL Server authentication. I need a login ID that
works under SQL Server authentication so I can login via JDBC. Do I need to
establish another ID for this? Can it be the same as the windows ID?
Thanks
JimJim Shaw wrote:
> In installed SQL Server under my Win2003 Server userID, specifying NT
> authentication. Then I down loaded MS JDBC, which requires Mixed
mode
> authentication, so I modifyed SQL Server to that. Now in Query
analyzer, I
> can log in to the db using windows authentication, but my user ID and
> password don't work under SQL Server authentication. I need a login
ID that
> works under SQL Server authentication so I can login via JDBC. Do I
need to
> establish another ID for this? Can it be the same as the windows ID?
The administrator user name is 'sa' and the default password is blank.
You can use that for SQL authentication. Or you can log in using
Windows authentication with jTDS or one of the commercial drivers.
Alin,
The jTDS Project.|||You can (should) create a new SQL login to be used for JDBC.
Make sure that the sa login has a strong password
(alphanumeric, special characters, no known words) and then
hide that one away somewhere. Then create a new SQL login
that you can use for your SQL login connections. You don't
want to use the sa login for applications or daily use due
to security risks. Give the new SQL login just the
permissions it needs for the application.
-Sue
On Tue, 8 Feb 2005 23:55:35 -0500, "Jim Shaw"
<jeshaw2@.comcast.net> wrote:

>In installed SQL Server under my Win2003 Server userID, specifying NT
>authentication. Then I down loaded MS JDBC, which requires Mixed mode
>authentication, so I modifyed SQL Server to that. Now in Query analyzer, I
>can log in to the db using windows authentication, but my user ID and
>password don't work under SQL Server authentication. I need a login ID tha
t
>works under SQL Server authentication so I can login via JDBC. Do I need t
o
>establish another ID for this? Can it be the same as the windows ID?
>Thanks
>Jim
>|||Thanks Sue;
A good answer to my question. It will work for applications having only one
common role for all users.
Now I'm wondering what the best practice is for multiple roles at the
application level of abstraction, e.g., A Compensation System having roles
of HR Clerk, Employee supervisor, Paymaster, Employee, etc.
1. I can do an application level login and manage the roles at the
application level; or,
2. Pass the authentication data in the application's connect to SQL Server
and manage the roles in the database; or,
3. Have multiple sub-applications, each with its own authentication, one for
each application defined role.
Any thoughts on this? I think I like #3 best. Makes development easier I
think. Maybe a combination of #2 & #3 ?
Thanks
Jim
"Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
news:21il019u4kgjrmj5khi7tcm37uqqg8t1hu@.
4ax.com...
> You can (should) create a new SQL login to be used for JDBC.
> Make sure that the sa login has a strong password
> (alphanumeric, special characters, no known words) and then
> hide that one away somewhere. Then create a new SQL login
> that you can use for your SQL login connections. You don't
> want to use the sa login for applications or daily use due
> to security risks. Give the new SQL login just the
> permissions it needs for the application.
> -Sue
> On Tue, 8 Feb 2005 23:55:35 -0500, "Jim Shaw"
> <jeshaw2@.comcast.net> wrote:
>
I[vbcol=seagreen]
that[vbcol=seagreen]
to[vbcol=seagreen]
>|||Not really. I just don't know enough specifics about your
application or security needs to say. At a high level, I'd
tend to go with first whatever provides the best security.
Next I'd go with ease of maintenance. I'd probably consider
ease of programming last. Years ago, programming everything
using the sa login and a blank password was the easiest for
development and used quite often. That certainly didn't work
out well. With business needs changing and issues such as
sarbanes oxley, I'd go more with whatever serves those areas
best.
-Sue
On Thu, 10 Feb 2005 11:32:04 -0500, "Jim Shaw"
<jeshaw2@.comcast.net> wrote:

>Thanks Sue;
>A good answer to my question. It will work for applications having only on
e
>common role for all users.
>Now I'm wondering what the best practice is for multiple roles at the
>application level of abstraction, e.g., A Compensation System having roles
>of HR Clerk, Employee supervisor, Paymaster, Employee, etc.
>1. I can do an application level login and manage the roles at the
>application level; or,
>2. Pass the authentication data in the application's connect to SQL Server
>and manage the roles in the database; or,
>3. Have multiple sub-applications, each with its own authentication, one fo
r
>each application defined role.
>Any thoughts on this? I think I like #3 best. Makes development easier I
>think. Maybe a combination of #2 & #3 ?
>Thanks
>Jim
>"Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
> news:21il019u4kgjrmj5khi7tcm37uqqg8t1hu@.
4ax.com...
>I
>that
>to
>

Do I need two login ID's?

In installed SQL Server under my Win2003 Server userID, specifying NT
authentication. Then I down loaded MS JDBC, which requires Mixed mode
authentication, so I modifyed SQL Server to that. Now in Query analyzer, I
can log in to the db using windows authentication, but my user ID and
password don't work under SQL Server authentication. I need a login ID that
works under SQL Server authentication so I can login via JDBC. Do I need to
establish another ID for this? Can it be the same as the windows ID?
Thanks
Jim
Jim Shaw wrote:
> In installed SQL Server under my Win2003 Server userID, specifying NT
> authentication. Then I down loaded MS JDBC, which requires Mixed
mode
> authentication, so I modifyed SQL Server to that. Now in Query
analyzer, I
> can log in to the db using windows authentication, but my user ID and
> password don't work under SQL Server authentication. I need a login
ID that
> works under SQL Server authentication so I can login via JDBC. Do I
need to
> establish another ID for this? Can it be the same as the windows ID?
The administrator user name is 'sa' and the default password is blank.
You can use that for SQL authentication. Or you can log in using
Windows authentication with jTDS or one of the commercial drivers.
Alin,
The jTDS Project.
|||You can (should) create a new SQL login to be used for JDBC.
Make sure that the sa login has a strong password
(alphanumeric, special characters, no known words) and then
hide that one away somewhere. Then create a new SQL login
that you can use for your SQL login connections. You don't
want to use the sa login for applications or daily use due
to security risks. Give the new SQL login just the
permissions it needs for the application.
-Sue
On Tue, 8 Feb 2005 23:55:35 -0500, "Jim Shaw"
<jeshaw2@.comcast.net> wrote:

>In installed SQL Server under my Win2003 Server userID, specifying NT
>authentication. Then I down loaded MS JDBC, which requires Mixed mode
>authentication, so I modifyed SQL Server to that. Now in Query analyzer, I
>can log in to the db using windows authentication, but my user ID and
>password don't work under SQL Server authentication. I need a login ID that
>works under SQL Server authentication so I can login via JDBC. Do I need to
>establish another ID for this? Can it be the same as the windows ID?
>Thanks
>Jim
>
|||Thanks Sue;
A good answer to my question. It will work for applications having only one
common role for all users.
Now I'm wondering what the best practice is for multiple roles at the
application level of abstraction, e.g., A Compensation System having roles
of HR Clerk, Employee supervisor, Paymaster, Employee, etc.
1. I can do an application level login and manage the roles at the
application level; or,
2. Pass the authentication data in the application's connect to SQL Server
and manage the roles in the database; or,
3. Have multiple sub-applications, each with its own authentication, one for
each application defined role.
Any thoughts on this? I think I like #3 best. Makes development easier I
think. Maybe a combination of #2 & #3 ?
Thanks
Jim
"Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
news:21il019u4kgjrmj5khi7tcm37uqqg8t1hu@.4ax.com... [vbcol=seagreen]
> You can (should) create a new SQL login to be used for JDBC.
> Make sure that the sa login has a strong password
> (alphanumeric, special characters, no known words) and then
> hide that one away somewhere. Then create a new SQL login
> that you can use for your SQL login connections. You don't
> want to use the sa login for applications or daily use due
> to security risks. Give the new SQL login just the
> permissions it needs for the application.
> -Sue
> On Tue, 8 Feb 2005 23:55:35 -0500, "Jim Shaw"
> <jeshaw2@.comcast.net> wrote:
I[vbcol=seagreen]
that[vbcol=seagreen]
to
>
|||Not really. I just don't know enough specifics about your
application or security needs to say. At a high level, I'd
tend to go with first whatever provides the best security.
Next I'd go with ease of maintenance. I'd probably consider
ease of programming last. Years ago, programming everything
using the sa login and a blank password was the easiest for
development and used quite often. That certainly didn't work
out well. With business needs changing and issues such as
sarbanes oxley, I'd go more with whatever serves those areas
best.
-Sue
On Thu, 10 Feb 2005 11:32:04 -0500, "Jim Shaw"
<jeshaw2@.comcast.net> wrote:

>Thanks Sue;
>A good answer to my question. It will work for applications having only one
>common role for all users.
>Now I'm wondering what the best practice is for multiple roles at the
>application level of abstraction, e.g., A Compensation System having roles
>of HR Clerk, Employee supervisor, Paymaster, Employee, etc.
>1. I can do an application level login and manage the roles at the
>application level; or,
>2. Pass the authentication data in the application's connect to SQL Server
>and manage the roles in the database; or,
>3. Have multiple sub-applications, each with its own authentication, one for
>each application defined role.
>Any thoughts on this? I think I like #3 best. Makes development easier I
>think. Maybe a combination of #2 & #3 ?
>Thanks
>Jim
>"Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
>news:21il019u4kgjrmj5khi7tcm37uqqg8t1hu@.4ax.com.. .
>I
>that
>to
>

Do i need primary key?

Here is the scenario
I have a table (let's call it tblTest) with 3 fields, UserID, Note,
NoteEnterDate (simple one to many relationship. user can have many notes)
Query would be to join it with user table and get the first and last name of
the user (based on UserID) and show the Note and NoteEnterDate (at this
point, I cannot think of any other query that uses this tblTest other than
this).
As far as index is concerned, I think I just need to create clustered index
on UserID.
I know it is good to declare a primary key for every table. Is there a need
for primary key for tblTest perhaps by adding another field called NoteID?
Thanks"Justin" <jus820@.hotmail.com> wrote in message
news:e4OGN5TbGHA.3812@.TK2MSFTNGP04.phx.gbl...
> Here is the scenario
> I have a table (let's call it tblTest) with 3 fields, UserID, Note,
> NoteEnterDate (simple one to many relationship. user can have many notes)
> Query would be to join it with user table and get the first and last name
> of the user (based on UserID) and show the Note and NoteEnterDate (at this
> point, I cannot think of any other query that uses this tblTest other than
> this).
> As far as index is concerned, I think I just need to create clustered
> index on UserID.
> I know it is good to declare a primary key for every table. Is there a
> need for primary key for tblTest perhaps by adding another field called
> NoteID?
>
Would you allow the same (UserID,Note,NoteEnterDate) to be entered twice?
If so, add a synthetic NoteID to tell them apart. If not, create the PK on
(UserID, NoteEnterDate,Note).
David|||you don 't need to waste the space on another column, if the noteid is not
having significance. and if you are going to use an identity for it then its
of no use at all.
u can use user ID and NoteEnterDate as the primary key.
Hope this helps.
--
"Justin" wrote:

> Here is the scenario
> I have a table (let's call it tblTest) with 3 fields, UserID, Note,
> NoteEnterDate (simple one to many relationship. user can have many notes)
> Query would be to join it with user table and get the first and last name
of
> the user (based on UserID) and show the Note and NoteEnterDate (at this
> point, I cannot think of any other query that uses this tblTest other than
> this).
> As far as index is concerned, I think I just need to create clustered inde
x
> on UserID.
> I know it is good to declare a primary key for every table. Is there a ne
ed
> for primary key for tblTest perhaps by adding another field called NoteID?
> Thanks
>
>|||NoteEnterDate is smalldatetime datatype (since we don't basically care about
the seconds). User can type more than one note in a minute. If I create
primary key on UserID and NoteEnterDate, this is not allowed.
Even even if this was not allowed (creating more than one notes in a
minute), what would be the point of creating primary key on UserID,
NoteEnterDate?
Thanks
"Omnibuzz" <Omnibuzz@.discussions.microsoft.com> wrote in message
news:0F05A821-5FFD-4A20-97E2-301565FFA187@.microsoft.com...
> you don 't need to waste the space on another column, if the noteid is not
> having significance. and if you are going to use an identity for it then
> its
> of no use at all.
> u can use user ID and NoteEnterDate as the primary key.
> Hope this helps.
> --
>
>
> "Justin" wrote:
>|||> Even even if this was not allowed (creating more than one notes in a
> minute), what would be the point of creating primary key on UserID,
> NoteEnterDate?
Maybe to prevent someone hitting refresh on your web page, 80 times in a
minute, and populating your table with redundant data.
A|||> you don 't need to waste the space on another column, if the noteid is not
> having significance. and if you are going to use an identity for it then
> its
> of no use at all.
I don't think I particularly agree. What harm does an IDENTITY column do?
I don't think it's as horrible as you make it out to be. The OP doesn't
know all future requirements now, so we can't really gauge its significance,
but let's say you wanted to track notes for some reason (e.g. show who has
viewed them and when). You might create another table called:
CREATE TABLE dbo.NoteTracking
(
? FOREIGN KEY REFERENCES dbo.tblTest(?),
ViewDate SMALLDATETIME
)
Surely you don't suggest it would be better to make up this primary key
UserID,NoteEnterDate and use that as your reference in the secondary table?
Like the OP, I'm not clear on what business sense a primary key on
UserID,NoteEnterDate would make, other than to fulfill the mantra "every
table must have a primary key." If it really is possible (and even
desirable) for a single user to enter two notes in one minute, then we're
back at square one.
A|||All tables must have at least one set of columns that can invariably
identify every row in the table. And there are obvious practical reasons to
explicitly declare one of those sets of columns as the primary key.
Anithsql