Path of SystemDB during SQL Server 2005 Installation

Hello,
During SQL Server 2005 Installation I would like to change the path for .mdf
on D:\MSSQL\Data\ and .ldf on E:\MSSQL\LOG\ for all the system databases.
Can anybody guide me how we can do it?
Thanks in advance,
MBsee the following link
http://support.microsoft.com/kb/224071
VT
"MB" <mital.bhadaniya@.itcinfotech.com> wrote in message
news:OAsMHNcJHHA.2456@.TK2MSFTNGP06.phx.gbl...
> Hello,
> During SQL Server 2005 Installation I would like to change the path for
> .mdf
> on D:\MSSQL\Data\ and .ldf on E:\MSSQL\LOG\ for all the system databases.
> Can anybody guide me how we can do it?
> Thanks in advance,
> MB
>|||Hello,
During the SETUP process; in the Feature selection, option select database
services; click browse and change the drive and directory
and continue the installation.
Thanks
Hari
"MB" <mital.bhadaniya@.itcinfotech.com> wrote in message
news:OAsMHNcJHHA.2456@.TK2MSFTNGP06.phx.gbl...
> Hello,
> During SQL Server 2005 Installation I would like to change the path for
> .mdf
> on D:\MSSQL\Data\ and .ldf on E:\MSSQL\LOG\ for all the system databases.
> Can anybody guide me how we can do it?
> Thanks in advance,
> MB
>|||Thank you Vinu & Hari,
Actually I am looking for the specific location only. When we change
location while doing installation it's installing other folders also and the
.mdf & .ldf location won't be exact as we desired an on the same drive.
Hence, the only solution is attached and detached db.
But I am looking for any optins how we can do it on SQL Server 2000. i.e.
specifying exact location for .mdf & .ldf
Best Regards,
Mital Bhadaniya
"MB" <mital.bhadaniya@.itcinfotech.com> wrote in message
news:OAsMHNcJHHA.2456@.TK2MSFTNGP06.phx.gbl...
> Hello,
> During SQL Server 2005 Installation I would like to change the path for
> .mdf
> on D:\MSSQL\Data\ and .ldf on E:\MSSQL\LOG\ for all the system databases.
> Can anybody guide me how we can do it?
> Thanks in advance,
> MB
>

patch application procedure

Hi,
I am having an mssql server with sp3. It is in sql cluster
(NT) as well as it participates in replication (merge). My
comany is very paranoid about doing things and all the
more there is no testing environment. Could any one please
explain how to apply SP4 for this server? We need to
consider the problematic conditions and disaster recovery
as well. My recovery mode is set to full.
james bond...-- james bond wrote: --
> Hi,
>> I am having an mssql server with sp3. It is in sql cluster
> (NT) as well as it participates in replication (merge). My
> company is very paranoid about doing things and all the
> more there is no testing environment. Could any one please
> explain how to apply SP4 for this server? We need to
> consider the problematic conditions and disaster recovery
> as well. My recovery mode is set to full.
--
Hi James Bond,
The best source of information for a service pack install is the README.htm of the service pack itself.
Hope this helps,
-Eric Cárdenas
SQL Server support

Password question

Morning,
Yesterday I got a call from a developer, telling me that the MSSQL Login
(for a application) that I set up for him on ServerA was not letting him
login. This exact same MSSQL Login was also set up on ServerB and it works
fine. After, a bit of time, of looking into it I stumbled on the problem and
fix. The fix was the password length for the SQL Server login account.
According to BOL, the password can be from 1 to 128 & alpha-numeric. The
password was a 19 alpha-numeric character password. This worked with no
problems on ServerB but failed on ServerA.
ServerB is a Windows 2000 server while ServerA is NT4 SP6.
So, I'm thinking that even though this was a MSSQL login and not a OS login,
the OS layer is playing a role in the authentication process. Does anyone
know if this is so and what are the limitations of NT4 password length?
Thanks for you time,I forgot to add, both are SQL2000 SP3.
"JoeyDBA" <JoeyDBA@.yahoo.com> wrote in message
news:uQErEJmbEHA.716@.TK2MSFTNGP11.phx.gbl...
> Morning,
> Yesterday I got a call from a developer, telling me that the MSSQL Login
> (for a application) that I set up for him on ServerA was not letting him
> login. This exact same MSSQL Login was also set up on ServerB and it works
> fine. After, a bit of time, of looking into it I stumbled on the problem
and
> fix. The fix was the password length for the SQL Server login account.
> According to BOL, the password can be from 1 to 128 & alpha-numeric. The
> password was a 19 alpha-numeric character password. This worked with no
> problems on ServerB but failed on ServerA.
> ServerB is a Windows 2000 server while ServerA is NT4 SP6.
> So, I'm thinking that even though this was a MSSQL login and not a OS
login,
> the OS layer is playing a role in the authentication process. Does anyone
> know if this is so and what are the limitations of NT4 password length?
> Thanks for you time,
>|||If it's a SQL login account we don't interact with the OS.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.|||As Kevin already pointed out, a SQL Login doesn't interact
with the OS.
One possibility, If the server uses a case-sensitive
collation, then your passwords are case sensitive as well.
-Sue
On Tue, 20 Jul 2004 09:02:59 -0500, "JoeyDBA"
<JoeyDBA@.yahoo.com> wrote:

>Morning,
>Yesterday I got a call from a developer, telling me that the MSSQL Login
>(for a application) that I set up for him on ServerA was not letting him
>login. This exact same MSSQL Login was also set up on ServerB and it works
>fine. After, a bit of time, of looking into it I stumbled on the problem an
d
>fix. The fix was the password length for the SQL Server login account.
>According to BOL, the password can be from 1 to 128 & alpha-numeric. The
>password was a 19 alpha-numeric character password. This worked with no
>problems on ServerB but failed on ServerA.
>ServerB is a Windows 2000 server while ServerA is NT4 SP6.
>So, I'm thinking that even though this was a MSSQL login and not a OS login
,
>the OS layer is playing a role in the authentication process. Does anyone
>know if this is so and what are the limitations of NT4 password length?
>Thanks for you time,
>|||ok - thanks for the feed back. I'll go back and play with it again.
"Kevin McDonnell [MSFT]" <kevmc@.online.microsoft.com> wrote in message
news:8SC7MkobEHA.2924@.cpmsftngxa06.phx.gbl...
> If it's a SQL login account we don't interact with the OS.
> Thanks,
> Kevin McDonnell
> Microsoft Corporation
> This posting is provided AS IS with no warranties, and confers no rights.
>
>

Passing table to MSSQL stored procedure

Hi all,
Any suggestions on the best way to pass a set of values to a stored
procedure that will use them in a query? Specifically, I want to call a
stored procedure from .NET that takes a set of phone numbers and returns a
resultset of records containing these numbers from a table. Is it possible
to pass a dataset/XML or something that would be interpreted as a table? Or
do I need to pass a string and convert it to a temporary table in the stored
procedure? Or...?
TIA,
JohnArrays and Lists in SQL Server
http://www.sommarskog.se/arrays-in-sql.html
AMB
"John Spiegel" wrote:

> Hi all,
> Any suggestions on the best way to pass a set of values to a stored
> procedure that will use them in a query? Specifically, I want to call a
> stored procedure from .NET that takes a set of phone numbers and returns a
> resultset of records containing these numbers from a table. Is it possibl
e
> to pass a dataset/XML or something that would be interpreted as a table?
Or
> do I need to pass a string and convert it to a temporary table in the stor
ed
> procedure? Or...?
> TIA,
> John
>
>|||Thanks, Alejandro. Exactly the kind of stuff I was wondering.
- John
"Alejandro Mesa" <AlejandroMesa@.discussions.microsoft.com> wrote in message
news:EFAFA1B0-C1A5-49F7-8764-6FAEF26CF493@.microsoft.com...
> Arrays and Lists in SQL Server
> http://www.sommarskog.se/arrays-in-sql.html
>
> AMB
>
> "John Spiegel" wrote:
>

Passing SMALLDATETIME into a Stored Proc

Hello people,

I am haivng an issue passing a smalldatetime into a stored proc.

The issue is on MSSQL to be valid, you have to enter it as

'2003-10-03 00:00:00'

This makes it into a stored proc with no issues,

but to be valid

I need something like this

select * from FIWORKING where DEALDATE > '@.WINDOW'

I can't seem to get the ' to stick in the stored proc,
is there a way to protect it ??

ChrisGot it to work by passing the datetime into the stored proc using the
below syntax

{ d '2003-31-11' }

Anyone know of another way to pass datetime into a Stored Proc ?