Adding a second processor

Hello,
We use a client/server application from our vendor running on SQL 2000,
which runs on a Windows 2003 Server in an ADS domain. The server is
currently only running a single Xeon processor and it has the capability for
having 2 processors. Our vendor claims that their application is not "coded
"
to run on a dual-processor machine (a bunch of bull?), but their application
only runs on the client end, not on the server.
The way I see it, it is Windows and SQL that have to be able to handle the
processor, which we all know they can certainly do. Does anyone think that
by adding a second processor, we would be doing any damage to our data and o
r
the application?
The application is Time Matters Enterprise 5.0 (sr2), by LexisNexis and it
is a case management system for a law firm. This is our mission-critical
application.
Thanks, JeffOutside of the fact that your vendor doesn't support it, I really see no
reason why you would want to limit yourself to just one processor. In most
cases, SQL Server would run faster with more CPU's. This is because your
workload is distributed across all of the CPU's. Thus, if you have 100
concurrent queries, 50 would run on one and 50 would run on the other -
ignoring parallelism. However, in most cases parallelism would improve an
individual query's performance, since both CPU's would be used to service
the query. In some cases, parallelism makes specific queries run slower,
but you can turn parallelism off on a per-query basis (or even at the server
level, if you prefer).
Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Toronto, ON Canada
.
"Jeff" <Jeff@.discussions.microsoft.com> wrote in message
news:56410EBD-043F-4AC4-870B-652141840545@.microsoft.com...
Hello,
We use a client/server application from our vendor running on SQL 2000,
which runs on a Windows 2003 Server in an ADS domain. The server is
currently only running a single Xeon processor and it has the capability for
having 2 processors. Our vendor claims that their application is not
"coded"
to run on a dual-processor machine (a bunch of bull?), but their application
only runs on the client end, not on the server.
The way I see it, it is Windows and SQL that have to be able to handle the
processor, which we all know they can certainly do. Does anyone think that
by adding a second processor, we would be doing any damage to our data and
or
the application?
The application is Time Matters Enterprise 5.0 (sr2), by LexisNexis and it
is a case management system for a law firm. This is our mission-critical
application.
Thanks, Jeff|||I do realize the benefits of a second processor in SQL and that's just it, w
e
don't want to limit ourselves to a single processor. We purchased a new
server recently and only purchased one processor because of what our vendor
told us. It didn't make any sense to me then and it doesn't now. The mobo
on that server is setup for dual-processors. Since the application runs on
the client, I didn't understand why they would tell us that.
More importantly, we no longer have a service contract with that vendor so
they are not going to support us either way unless we get another contract.
My thought is that the worst that can happen is that we have to restore the
database off of a backup and pull the second processor out.
--
Thanks, Jeff
"Tom Moreau" wrote:

> Outside of the fact that your vendor doesn't support it, I really see no
> reason why you would want to limit yourself to just one processor. In mos
t
> cases, SQL Server would run faster with more CPU's. This is because your
> workload is distributed across all of the CPU's. Thus, if you have 100
> concurrent queries, 50 would run on one and 50 would run on the other -
> ignoring parallelism. However, in most cases parallelism would improve an
> individual query's performance, since both CPU's would be used to service
> the query. In some cases, parallelism makes specific queries run slower,
> but you can turn parallelism off on a per-query basis (or even at the serv
er
> level, if you prefer).
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Toronto, ON Canada
> ..
> "Jeff" <Jeff@.discussions.microsoft.com> wrote in message
> news:56410EBD-043F-4AC4-870B-652141840545@.microsoft.com...
> Hello,
> We use a client/server application from our vendor running on SQL 2000,
> which runs on a Windows 2003 Server in an ADS domain. The server is
> currently only running a single Xeon processor and it has the capability f
or
> having 2 processors. Our vendor claims that their application is not
> "coded"
> to run on a dual-processor machine (a bunch of bull?), but their applicati
on
> only runs on the client end, not on the server.
> The way I see it, it is Windows and SQL that have to be able to handle the
> processor, which we all know they can certainly do. Does anyone think tha
t
> by adding a second processor, we would be doing any damage to our data and
> or
> the application?
> The application is Time Matters Enterprise 5.0 (sr2), by LexisNexis and it
> is a case management system for a law firm. This is our mission-critical
> application.
> --
> Thanks, Jeff
>|||The only real issue I see is that of licensing. If you go with a per-CPU
license, you will have to spend some change to do the upgrade. Other than
that, you're fine.
Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Toronto, ON Canada
"Jeff" <Jeff@.discussions.microsoft.com> wrote in message
news:7CA5419B-884D-4D51-8B1C-3DEE16B291F1@.microsoft.com...
I do realize the benefits of a second processor in SQL and that's just it,
we
don't want to limit ourselves to a single processor. We purchased a new
server recently and only purchased one processor because of what our vendor
told us. It didn't make any sense to me then and it doesn't now. The mobo
on that server is setup for dual-processors. Since the application runs on
the client, I didn't understand why they would tell us that.
More importantly, we no longer have a service contract with that vendor so
they are not going to support us either way unless we get another contract.
My thought is that the worst that can happen is that we have to restore the
database off of a backup and pull the second processor out.
--
Thanks, Jeff
"Tom Moreau" wrote:

> Outside of the fact that your vendor doesn't support it, I really see no
> reason why you would want to limit yourself to just one processor. In
> most
> cases, SQL Server would run faster with more CPU's. This is because your
> workload is distributed across all of the CPU's. Thus, if you have 100
> concurrent queries, 50 would run on one and 50 would run on the other -
> ignoring parallelism. However, in most cases parallelism would improve an
> individual query's performance, since both CPU's would be used to service
> the query. In some cases, parallelism makes specific queries run slower,
> but you can turn parallelism off on a per-query basis (or even at the
> server
> level, if you prefer).
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Toronto, ON Canada
> ..
> "Jeff" <Jeff@.discussions.microsoft.com> wrote in message
> news:56410EBD-043F-4AC4-870B-652141840545@.microsoft.com...
> Hello,
> We use a client/server application from our vendor running on SQL 2000,
> which runs on a Windows 2003 Server in an ADS domain. The server is
> currently only running a single Xeon processor and it has the capability
> for
> having 2 processors. Our vendor claims that their application is not
> "coded"
> to run on a dual-processor machine (a bunch of bull?), but their
> application
> only runs on the client end, not on the server.
> The way I see it, it is Windows and SQL that have to be able to handle the
> processor, which we all know they can certainly do. Does anyone think
> that
> by adding a second processor, we would be doing any damage to our data and
> or
> the application?
> The application is Time Matters Enterprise 5.0 (sr2), by LexisNexis and it
> is a case management system for a law firm. This is our mission-critical
> application.
> --
> Thanks, Jeff
>|||"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:uzy8rPbeGHA.5016@.TK2MSFTNGP04.phx.gbl...
> The only real issue I see is that of licensing. If you go with a per-CPU
> license, you will have to spend some change to do the upgrade. Other than
> that, you're fine.
I'll second this.
And second the opinion that the original vendor is full of it. :-)

> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Toronto, ON Canada
> "Jeff" <Jeff@.discussions.microsoft.com> wrote in message
> news:7CA5419B-884D-4D51-8B1C-3DEE16B291F1@.microsoft.com...
> I do realize the benefits of a second processor in SQL and that's just it,
> we
> don't want to limit ourselves to a single processor. We purchased a new
> server recently and only purchased one processor because of what our
vendor
> told us. It didn't make any sense to me then and it doesn't now. The
mobo
> on that server is setup for dual-processors. Since the application runs
on
> the client, I didn't understand why they would tell us that.
> More importantly, we no longer have a service contract with that vendor so
> they are not going to support us either way unless we get another
contract.
> My thought is that the worst that can happen is that we have to restore
the
> database off of a backup and pull the second processor out.
> --
> Thanks, Jeff
>
> "Tom Moreau" wrote:
>
your[vbcol=seagreen]
an[vbcol=seagreen]
service[vbcol=seagreen]
slower,[vbcol=seagreen]
the[vbcol=seagreen]
and[vbcol=seagreen]
it[vbcol=seagreen]
mission-critical[vbcol=seagreen]
>sql

Adding a second processor

Hello,
We use a client/server application from our vendor running on SQL 2000,
which runs on a Windows 2003 Server in an ADS domain. The server is
currently only running a single Xeon processor and it has the capability for
having 2 processors. Our vendor claims that their application is not "coded"
to run on a dual-processor machine (a bunch of bull?), but their application
only runs on the client end, not on the server.
The way I see it, it is Windows and SQL that have to be able to handle the
processor, which we all know they can certainly do. Does anyone think that
by adding a second processor, we would be doing any damage to our data and or
the application?
The application is Time Matters Enterprise 5.0 (sr2), by LexisNexis and it
is a case management system for a law firm. This is our mission-critical
application.
--
Thanks, JeffOutside of the fact that your vendor doesn't support it, I really see no
reason why you would want to limit yourself to just one processor. In most
cases, SQL Server would run faster with more CPU's. This is because your
workload is distributed across all of the CPU's. Thus, if you have 100
concurrent queries, 50 would run on one and 50 would run on the other -
ignoring parallelism. However, in most cases parallelism would improve an
individual query's performance, since both CPU's would be used to service
the query. In some cases, parallelism makes specific queries run slower,
but you can turn parallelism off on a per-query basis (or even at the server
level, if you prefer).
--
Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Toronto, ON Canada
.
"Jeff" <Jeff@.discussions.microsoft.com> wrote in message
news:56410EBD-043F-4AC4-870B-652141840545@.microsoft.com...
Hello,
We use a client/server application from our vendor running on SQL 2000,
which runs on a Windows 2003 Server in an ADS domain. The server is
currently only running a single Xeon processor and it has the capability for
having 2 processors. Our vendor claims that their application is not
"coded"
to run on a dual-processor machine (a bunch of bull?), but their application
only runs on the client end, not on the server.
The way I see it, it is Windows and SQL that have to be able to handle the
processor, which we all know they can certainly do. Does anyone think that
by adding a second processor, we would be doing any damage to our data and
or
the application?
The application is Time Matters Enterprise 5.0 (sr2), by LexisNexis and it
is a case management system for a law firm. This is our mission-critical
application.
--
Thanks, Jeff|||I do realize the benefits of a second processor in SQL and that's just it, we
don't want to limit ourselves to a single processor. We purchased a new
server recently and only purchased one processor because of what our vendor
told us. It didn't make any sense to me then and it doesn't now. The mobo
on that server is setup for dual-processors. Since the application runs on
the client, I didn't understand why they would tell us that.
More importantly, we no longer have a service contract with that vendor so
they are not going to support us either way unless we get another contract.
My thought is that the worst that can happen is that we have to restore the
database off of a backup and pull the second processor out.
--
Thanks, Jeff
"Tom Moreau" wrote:
> Outside of the fact that your vendor doesn't support it, I really see no
> reason why you would want to limit yourself to just one processor. In most
> cases, SQL Server would run faster with more CPU's. This is because your
> workload is distributed across all of the CPU's. Thus, if you have 100
> concurrent queries, 50 would run on one and 50 would run on the other -
> ignoring parallelism. However, in most cases parallelism would improve an
> individual query's performance, since both CPU's would be used to service
> the query. In some cases, parallelism makes specific queries run slower,
> but you can turn parallelism off on a per-query basis (or even at the server
> level, if you prefer).
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Toronto, ON Canada
> ..
> "Jeff" <Jeff@.discussions.microsoft.com> wrote in message
> news:56410EBD-043F-4AC4-870B-652141840545@.microsoft.com...
> Hello,
> We use a client/server application from our vendor running on SQL 2000,
> which runs on a Windows 2003 Server in an ADS domain. The server is
> currently only running a single Xeon processor and it has the capability for
> having 2 processors. Our vendor claims that their application is not
> "coded"
> to run on a dual-processor machine (a bunch of bull?), but their application
> only runs on the client end, not on the server.
> The way I see it, it is Windows and SQL that have to be able to handle the
> processor, which we all know they can certainly do. Does anyone think that
> by adding a second processor, we would be doing any damage to our data and
> or
> the application?
> The application is Time Matters Enterprise 5.0 (sr2), by LexisNexis and it
> is a case management system for a law firm. This is our mission-critical
> application.
> --
> Thanks, Jeff
>|||The only real issue I see is that of licensing. If you go with a per-CPU
license, you will have to spend some change to do the upgrade. Other than
that, you're fine.
--
Tom
----
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Toronto, ON Canada
"Jeff" <Jeff@.discussions.microsoft.com> wrote in message
news:7CA5419B-884D-4D51-8B1C-3DEE16B291F1@.microsoft.com...
I do realize the benefits of a second processor in SQL and that's just it,
we
don't want to limit ourselves to a single processor. We purchased a new
server recently and only purchased one processor because of what our vendor
told us. It didn't make any sense to me then and it doesn't now. The mobo
on that server is setup for dual-processors. Since the application runs on
the client, I didn't understand why they would tell us that.
More importantly, we no longer have a service contract with that vendor so
they are not going to support us either way unless we get another contract.
My thought is that the worst that can happen is that we have to restore the
database off of a backup and pull the second processor out.
--
Thanks, Jeff
"Tom Moreau" wrote:
> Outside of the fact that your vendor doesn't support it, I really see no
> reason why you would want to limit yourself to just one processor. In
> most
> cases, SQL Server would run faster with more CPU's. This is because your
> workload is distributed across all of the CPU's. Thus, if you have 100
> concurrent queries, 50 would run on one and 50 would run on the other -
> ignoring parallelism. However, in most cases parallelism would improve an
> individual query's performance, since both CPU's would be used to service
> the query. In some cases, parallelism makes specific queries run slower,
> but you can turn parallelism off on a per-query basis (or even at the
> server
> level, if you prefer).
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Toronto, ON Canada
> ..
> "Jeff" <Jeff@.discussions.microsoft.com> wrote in message
> news:56410EBD-043F-4AC4-870B-652141840545@.microsoft.com...
> Hello,
> We use a client/server application from our vendor running on SQL 2000,
> which runs on a Windows 2003 Server in an ADS domain. The server is
> currently only running a single Xeon processor and it has the capability
> for
> having 2 processors. Our vendor claims that their application is not
> "coded"
> to run on a dual-processor machine (a bunch of bull?), but their
> application
> only runs on the client end, not on the server.
> The way I see it, it is Windows and SQL that have to be able to handle the
> processor, which we all know they can certainly do. Does anyone think
> that
> by adding a second processor, we would be doing any damage to our data and
> or
> the application?
> The application is Time Matters Enterprise 5.0 (sr2), by LexisNexis and it
> is a case management system for a law firm. This is our mission-critical
> application.
> --
> Thanks, Jeff
>|||"Tom Moreau" <tom@.dont.spam.me.cips.ca> wrote in message
news:uzy8rPbeGHA.5016@.TK2MSFTNGP04.phx.gbl...
> The only real issue I see is that of licensing. If you go with a per-CPU
> license, you will have to spend some change to do the upgrade. Other than
> that, you're fine.
I'll second this.
And second the opinion that the original vendor is full of it. :-)
> --
> Tom
> ----
> Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> SQL Server MVP
> Toronto, ON Canada
> "Jeff" <Jeff@.discussions.microsoft.com> wrote in message
> news:7CA5419B-884D-4D51-8B1C-3DEE16B291F1@.microsoft.com...
> I do realize the benefits of a second processor in SQL and that's just it,
> we
> don't want to limit ourselves to a single processor. We purchased a new
> server recently and only purchased one processor because of what our
vendor
> told us. It didn't make any sense to me then and it doesn't now. The
mobo
> on that server is setup for dual-processors. Since the application runs
on
> the client, I didn't understand why they would tell us that.
> More importantly, we no longer have a service contract with that vendor so
> they are not going to support us either way unless we get another
contract.
> My thought is that the worst that can happen is that we have to restore
the
> database off of a backup and pull the second processor out.
> --
> Thanks, Jeff
>
> "Tom Moreau" wrote:
> > Outside of the fact that your vendor doesn't support it, I really see no
> > reason why you would want to limit yourself to just one processor. In
> > most
> > cases, SQL Server would run faster with more CPU's. This is because
your
> > workload is distributed across all of the CPU's. Thus, if you have 100
> > concurrent queries, 50 would run on one and 50 would run on the other -
> > ignoring parallelism. However, in most cases parallelism would improve
an
> > individual query's performance, since both CPU's would be used to
service
> > the query. In some cases, parallelism makes specific queries run
slower,
> > but you can turn parallelism off on a per-query basis (or even at the
> > server
> > level, if you prefer).
> >
> > --
> > Tom
> >
> > ----
> > Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
> > SQL Server MVP
> > Toronto, ON Canada
> > ..
> > "Jeff" <Jeff@.discussions.microsoft.com> wrote in message
> > news:56410EBD-043F-4AC4-870B-652141840545@.microsoft.com...
> > Hello,
> >
> > We use a client/server application from our vendor running on SQL 2000,
> > which runs on a Windows 2003 Server in an ADS domain. The server is
> > currently only running a single Xeon processor and it has the capability
> > for
> > having 2 processors. Our vendor claims that their application is not
> > "coded"
> > to run on a dual-processor machine (a bunch of bull?), but their
> > application
> > only runs on the client end, not on the server.
> >
> > The way I see it, it is Windows and SQL that have to be able to handle
the
> > processor, which we all know they can certainly do. Does anyone think
> > that
> > by adding a second processor, we would be doing any damage to our data
and
> > or
> > the application?
> >
> > The application is Time Matters Enterprise 5.0 (sr2), by LexisNexis and
it
> > is a case management system for a law firm. This is our
mission-critical
> > application.
> >
> > --
> > Thanks, Jeff
> >
> >
>

Adding 2nd Processor

I'm preparing to add a second cpu to our server that runs
SQL Server 7 database software. Are there any changes I
need to make to SQL 7 platform to get database to
recognize the second processor?
The OS is Windows NT Server 4.0 SP6a
Thanks,
GregThe hard bit is getting NT4 to pick it up :-)
As Keith says , once that's done then SQL will pick it up automatically
--
HTH
Jasper Smith (SQL Server MVP)
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"Gregory Dover" <gdovernospam@.bolingbrook.com> wrote in message
news:056401c35b8f$5b65b930$a101280a@.phx.gbl...
I'm preparing to add a second cpu to our server that runs
SQL Server 7 database software. Are there any changes I
need to make to SQL 7 platform to get database to
recognize the second processor?
The OS is Windows NT Server 4.0 SP6a
Thanks,
Greg|||Would this also be true for an OS of Windows 2000
Professional?
>--Original Message--
>SQL Server should see it after you get NT to recognize
the second processor.
>--
>Keith, SQL Server MVP
>"Gregory Dover" <gdovernospam@.bolingbrook.com> wrote in
message news:056401c35b8f$5b65b930$a101280a@.phx.gbl...
>> I'm preparing to add a second cpu to our server that
runs
>> SQL Server 7 database software. Are there any changes
I
>> need to make to SQL 7 platform to get database to
>> recognize the second processor?
>> The OS is Windows NT Server 4.0 SP6a
>> Thanks,
>>
>> Greg
>.
>sql

Add sdf file to my project when my sources are on remote server

I have an application that runs on a PDA and manage a database (.sdf) file I use C# with visual studio 5.0.

What I want to do is to add the database file (.sdf) to my project files and open a connection to it.

The problem is that all my source file are stored on remote machine and not locally on my machine and the .sdf file is also stored with the project source files.

When I try to add the file to the project I get the following error fro the data source configuration wizard :

"An error occured while retrieving the information from the database"

DRIVE_REMOTE

Parameter Name : N:\

I get the same error also when I try to open a new connection to the file from the server explorer. When i copy the file to drive "C" I can open a connection to it with no errors.

---

Software engineer

Hello,

Remotely opening an sdf file (SSC database) is not supported. From desktop to device (DB on a device) access is possible, but, I don't think the other way is.

Thanks

Udaya.

Add New Row Problems

This code runs with no errors.
The problem is nothing actually gets updated.

Private Sub btnAdd_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnAdd.Click
Dim mEmp As New YessClass1
Dim EmpID As Long
Dim Conn As New SqlConnection(ConfigurationSettings.AppSettings("ConnectionString"))

'Dim mRdg As YessClass1 = New YessClass1
Dim lngID As Long
'This is to save a record to tblFeedback
Dim strSelect As String = "SELECT * FROM tblFeedback"
'now create the data adapter object and connect it to
'sql string and the connection
Dim dscmd As New SqlDataAdapter(strSelect, Conn)
' Load a data set.
ds = New DataSet
'data Adapter fill with dataset, name of dataset
dscmd.Fill(ds, "Feedback")
SqlConnection1.Close()
'get the EmployeeID and the Rounding RecordID
Try
mEmp = CType(Session("objEmp"), YessClass1)
EmpID = mEmp.Employee
Try
Dim dt As DataTable = ds.Tables.Item("FeedBack")
Dim rowFeedback As DataRow = dt.NewRow

With rowFeedback
.Item("RoundingID") = RdgID
.Item("QuestionID") = Me.lstQuestion.SelectedItem.Value
.Item("ResponseActionID") = Me.lstAction.SelectedItem.Value
.Item("EmployeeID") = Me.lstDirector.SelectedItem.Value
.Item("ActivityID") = Me.lstActivity.SelectedItem.Value
.Item("Feedback") = Me.txtFeedback.Text
If Me.ckReq.Checked = True Then
.Item("Acknowledgement") = 1
.Item("AckDate") = Now
End If
End With

dt.Rows.Add(rowFeedback)

Catch ex As Exception

Response.Write("Error occured" & ex.Message)
End Try
Catch ex As Exception
Response.Write("ERROR: " & ex.Message)
End Try
End SubWhere are you actually updating the database? Adding the row to the DataTable does not do it. You need to call .Update somewhere on the DataSet.

add disk to a cluster running sql2005

hi,
I have a windows 2003 sp1 cluster running sql2005.
the DB is installed on S: and i have a R: & U: drive letter that is both
differend disk and runs fine in the cluster.
But i can not see those disks in sql 2005 why ?
the disks are in the same resource group (SQL)
where can I choose the R drive ?
if I choose attach DB I see only the S drive where the DB is installed.
any help is welcome
greetings,
Robert
Hi,
Just fixed it
I added the disk resources to the SQL2005 server resource and now it is
running.
greetings,
"Robert Smit ( 450331)" <RSM.news@.thebackbone.nl> wrote in message
news:OeiQZhQFGHA.524@.TK2MSFTNGP09.phx.gbl...
> hi,
> I have a windows 2003 sp1 cluster running sql2005.
> the DB is installed on S: and i have a R: & U: drive letter that is both
> differend disk and runs fine in the cluster.
> But i can not see those disks in sql 2005 why ?
> the disks are in the same resource group (SQL)
> where can I choose the R drive ?
> if I choose attach DB I see only the S drive where the DB is installed.
> any help is welcome
> greetings,
> Robert
>
|||Just adding them to the SQL Server group is not enough. They have to be
added as a dependency of the SQL Server resource.
Mike
Mentor
Solid Quality Learning
http://www.solidqualitylearning.com
"Robert Smit ( 450331)" <RSM.news@.thebackbone.nl> wrote in message
news:OeiQZhQFGHA.524@.TK2MSFTNGP09.phx.gbl...
> hi,
> I have a windows 2003 sp1 cluster running sql2005.
> the DB is installed on S: and i have a R: & U: drive letter that is both
> differend disk and runs fine in the cluster.
> But i can not see those disks in sql 2005 why ?
> the disks are in the same resource group (SQL)
> where can I choose the R drive ?
> if I choose attach DB I see only the S drive where the DB is installed.
> any help is welcome
> greetings,
> Robert
>

AD password & SQL database syncronisation

Hi Fred
"Fred" wrote:

> Hi, my company currently runs a native domain, and within the domain, a
> corporate SQL database.
> At the moment i need to add new users to the AD infrastructure, and then to
> the SQL database.
> is there anyway i can link the SQL table containing u/names & passwords to
> AD, so i do not need to keep updating both?
> TIA
>
You would be better adding the users to a AD group and then giving that
group access to SQL Server, then all the admin of adding users is done in the
AD.
John
Fred wrote:
> Many thanks for the reply,
> i may have not myself clear, but the users credentials are currently
> stored within the SQL database and also obviously in AD.
> I'm looking to get AD to populate whats in the SQL database automaticaly.
>
Hi Fred,
I think you need to read up on Security in SQL Server. In SQL Server you
can use Windows authentication and/or SQL Server authentication.
SQL Server authentication means that the loginname/userid (and password)
ONLY exists in SQL server and has nothing to do with your AD.
Windows authentication means that you give an Active Directoy userid
access to you SQL server databases. This can be done either via group
memberships as suggested by John or you can give single users various
rights in SQL Server. If you give access based on AD groups, you can
don't have to go to the SQL server to assign rights, but you can do it
directly from the AD gui. This will of course require that you can
define some general rights for a group of users.
Regards
Steen Schlüter Persson
Database Administrator / System Administrator
|||Hi
"Fred" wrote:

> Many thanks for the reply,
> i may have not myself clear, but the users credentials are currently stored
> within the SQL database and also obviously in AD.
> I'm looking to get AD to populate whats in the SQL database automaticaly.
>
As Steen points out this should not be necessary for logins, but if a list
is needed for some other reason you can query AD through an ADSI linked
server see
http://msdn2.microsoft.com/en-us/library/aa772170.aspx
http://msdn2.microsoft.com/en-us/library/aa746379.aspx
or through a scripting such as http://support.microsoft.com/kb/319716
John

AD password & SQL database syncronisation

Hi, my company currently runs a native domain, and within the domain, a
corporate SQL database.
At the moment i need to add new users to the AD infrastructure, and then to
the SQL database.
is there anyway i can link the SQL table containing u/names & passwords to
AD, so i do not need to keep updating both?
TIAHi Fred
"Fred" wrote:

> Hi, my company currently runs a native domain, and within the domain, a
> corporate SQL database.
> At the moment i need to add new users to the AD infrastructure, and then t
o
> the SQL database.
> is there anyway i can link the SQL table containing u/names & passwords to
> AD, so i do not need to keep updating both?
> TIA
>
You would be better adding the users to a AD group and then giving that
group access to SQL Server, then all the admin of adding users is done in th
e
AD.
John|||Many thanks for the reply,
i may have not myself clear, but the users credentials are currently stored
within the SQL database and also obviously in AD.
I'm looking to get AD to populate whats in the SQL database automaticaly.
"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:056B6E3C-3AF7-46E3-9BD5-4E0B2318EC7A@.microsoft.com...
> Hi Fred
> "Fred" wrote:
>
> You would be better adding the users to a AD group and then giving that
> group access to SQL Server, then all the admin of adding users is done in
> the
> AD.
> John|||Fred wrote:
> Many thanks for the reply,
> i may have not myself clear, but the users credentials are currently
> stored within the SQL database and also obviously in AD.
> I'm looking to get AD to populate whats in the SQL database automaticaly.
>
Hi Fred,
I think you need to read up on Security in SQL Server. In SQL Server you
can use Windows authentication and/or SQL Server authentication.
SQL Server authentication means that the loginname/userid (and password)
ONLY exists in SQL server and has nothing to do with your AD.
Windows authentication means that you give an Active Directoy userid
access to you SQL server databases. This can be done either via group
memberships as suggested by John or you can give single users various
rights in SQL Server. If you give access based on AD groups, you can
don't have to go to the SQL server to assign rights, but you can do it
directly from the AD gui. This will of course require that you can
define some general rights for a group of users.
Regards
Steen Schlüter Persson
Database Administrator / System Administrator|||Hi
"Fred" wrote:

> Many thanks for the reply,
> i may have not myself clear, but the users credentials are currently stor
ed
> within the SQL database and also obviously in AD.
> I'm looking to get AD to populate whats in the SQL database automaticaly.
>
As Steen points out this should not be necessary for logins, but if a list
is needed for some other reason you can query AD through an ADSI linked
server see
http://msdn2.microsoft.com/en-us/library/aa772170.aspx
http://msdn2.microsoft.com/en-us/library/aa746379.aspx
or through a scripting such as http://support.microsoft.com/kb/319716
John|||Many thanks for your input guys,
i'll start reading up on this through your links etc.
Cheers
"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:29C53C3C-41EF-4C6C-A9F8-F4783BE4E9F1@.microsoft.com...
> Hi
> "Fred" wrote:
>
> As Steen points out this should not be necessary for logins, but if a list
> is needed for some other reason you can query AD through an ADSI linked
> server see
> http://msdn2.microsoft.com/en-us/library/aa772170.aspx
> http://msdn2.microsoft.com/en-us/library/aa746379.aspx
> or through a scripting such as http://support.microsoft.com/kb/319716
> John

AD password & SQL database syncronisation

Hi, my company currently runs a native domain, and within the domain, a
corporate SQL database.
At the moment i need to add new users to the AD infrastructure, and then to
the SQL database.
is there anyway i can link the SQL table containing u/names & passwords to
AD, so i do not need to keep updating both?
TIAHi Fred
"Fred" wrote:
> Hi, my company currently runs a native domain, and within the domain, a
> corporate SQL database.
> At the moment i need to add new users to the AD infrastructure, and then to
> the SQL database.
> is there anyway i can link the SQL table containing u/names & passwords to
> AD, so i do not need to keep updating both?
> TIA
>
You would be better adding the users to a AD group and then giving that
group access to SQL Server, then all the admin of adding users is done in the
AD.
John|||Many thanks for the reply,
i may have not myself clear, but the users credentials are currently stored
within the SQL database and also obviously in AD.
I'm looking to get AD to populate whats in the SQL database automaticaly.
"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:056B6E3C-3AF7-46E3-9BD5-4E0B2318EC7A@.microsoft.com...
> Hi Fred
> "Fred" wrote:
>> Hi, my company currently runs a native domain, and within the domain, a
>> corporate SQL database.
>> At the moment i need to add new users to the AD infrastructure, and then
>> to
>> the SQL database.
>> is there anyway i can link the SQL table containing u/names & passwords
>> to
>> AD, so i do not need to keep updating both?
>> TIA
> You would be better adding the users to a AD group and then giving that
> group access to SQL Server, then all the admin of adding users is done in
> the
> AD.
> John|||Fred wrote:
> Many thanks for the reply,
> i may have not myself clear, but the users credentials are currently
> stored within the SQL database and also obviously in AD.
> I'm looking to get AD to populate whats in the SQL database automaticaly.
>
Hi Fred,
I think you need to read up on Security in SQL Server. In SQL Server you
can use Windows authentication and/or SQL Server authentication.
SQL Server authentication means that the loginname/userid (and password)
ONLY exists in SQL server and has nothing to do with your AD.
Windows authentication means that you give an Active Directoy userid
access to you SQL server databases. This can be done either via group
memberships as suggested by John or you can give single users various
rights in SQL Server. If you give access based on AD groups, you can
don't have to go to the SQL server to assign rights, but you can do it
directly from the AD gui. This will of course require that you can
define some general rights for a group of users.
--
Regards
Steen Schlüter Persson
Database Administrator / System Administrator|||Hi
"Fred" wrote:
> Many thanks for the reply,
> i may have not myself clear, but the users credentials are currently stored
> within the SQL database and also obviously in AD.
> I'm looking to get AD to populate whats in the SQL database automaticaly.
>
As Steen points out this should not be necessary for logins, but if a list
is needed for some other reason you can query AD through an ADSI linked
server see
http://msdn2.microsoft.com/en-us/library/aa772170.aspx
http://msdn2.microsoft.com/en-us/library/aa746379.aspx
or through a scripting such as http://support.microsoft.com/kb/319716
John|||Many thanks for your input guys,
i'll start reading up on this through your links etc.
Cheers
"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:29C53C3C-41EF-4C6C-A9F8-F4783BE4E9F1@.microsoft.com...
> Hi
> "Fred" wrote:
>> Many thanks for the reply,
>> i may have not myself clear, but the users credentials are currently
>> stored
>> within the SQL database and also obviously in AD.
>> I'm looking to get AD to populate whats in the SQL database automaticaly.
> As Steen points out this should not be necessary for logins, but if a list
> is needed for some other reason you can query AD through an ADSI linked
> server see
> http://msdn2.microsoft.com/en-us/library/aa772170.aspx
> http://msdn2.microsoft.com/en-us/library/aa746379.aspx
> or through a scripting such as http://support.microsoft.com/kb/319716
> John