Showing posts with label files. Show all posts
Showing posts with label files. Show all posts

Friday, March 23, 2012

new sql server

hi,
i was wondering is it a good idea to use sata drive as a system\mssql
drive and scsi for data ant log files?
am i right that data and log files must be on raid 10'
one more q... if i want to have 300gb data on db how much Filegroups
should i use ?
how much disk drives should i use for best performance (7 or 8 as best
performance is achieve only if even no. of drives is used)?
thanx"benamis" <nera@.meilo.lt> wrote in message
news:OZtP$ixpFHA.3936@.TK2MSFTNGP10.phx.gbl...
> hi,
> i was wondering is it a good idea to use sata drive as a system\mssql
> drive and scsi for data ant log files?
> am i right that data and log files must be on raid 10'
> one more q... if i want to have 300gb data on db how much Filegroups
> should i use ?
> how much disk drives should i use for best performance (7 or 8 as best
> performance is achieve only if even no. of drives is used)?
> thanx
>
All of that depends!
SATA drives are find for the O/S and software. I'm not sure why you would
need those in addition to your SCSI drives. SCSI is generally going to have
double the throughput of comparable SATA drives.
As far as filegroups are concerned. Filegroups are used in two situations.
Situation 1 is to ease administration and allow for partial backups and
restores. Situation 2 is to create a poor mans RAID. If you already have
a RAID solution, then there is no reason to use filegroups to force
table-writes across multiple specific hard drives.
Now for best performance on drives. It depends? Is your application
primarily read only? If so, then a big RAID-5 would do the trick. Is your
application write intensive. Then some combination of data on RAID 0+1 and
logs on separate RAID 0+1. Do you have a single channel RAID controller or
dual channel?
All of this may be a moot point if you don't have enough RAM in your system.
Read up on performance and www.sql-server-performance.com
This should give you enough information to make better choices about your
given situation.
Rick Sawtell
MCT, MCSD, MCDBA|||thanx lots of info
Rick Sawtell wrote:
> "benamis" <nera@.meilo.lt> wrote in message
> news:OZtP$ixpFHA.3936@.TK2MSFTNGP10.phx.gbl...
>
>
> All of that depends!
> SATA drives are find for the O/S and software. I'm not sure why you would
> need those in addition to your SCSI drives. SCSI is generally going to ha
ve
> double the throughput of comparable SATA drives.
> As far as filegroups are concerned. Filegroups are used in two situations
.
> Situation 1 is to ease administration and allow for partial backups and
> restores. Situation 2 is to create a poor mans RAID. If you already hav
e
> a RAID solution, then there is no reason to use filegroups to force
> table-writes across multiple specific hard drives.
> Now for best performance on drives. It depends? Is your application
> primarily read only? If so, then a big RAID-5 would do the trick. Is you
r
> application write intensive. Then some combination of data on RAID 0+1 an
d
> logs on separate RAID 0+1. Do you have a single channel RAID controller
or
> dual channel?
> All of this may be a moot point if you don't have enough RAM in your syste
m.
>
> Read up on performance and www.sql-server-performance.com
>
> This should give you enough information to make better choices about your
> given situation.
> Rick Sawtell
> MCT, MCSD, MCDBA
>
>

new sql server

hi,
i was wondering is it a good idea to use sata drive as a system\mssql
drive and scsi for data ant log files?
am i right that data and log files must be on raid 10?
one more q... if i want to have 300gb data on db how much Filegroups
should i use ?
how much disk drives should i use for best performance (7 or 8 as best
performance is achieve only if even no. of drives is used)?
thanx
"benamis" <nera@.meilo.lt> wrote in message
news:OZtP$ixpFHA.3936@.TK2MSFTNGP10.phx.gbl...
> hi,
> i was wondering is it a good idea to use sata drive as a system\mssql
> drive and scsi for data ant log files?
> am i right that data and log files must be on raid 10?
> one more q... if i want to have 300gb data on db how much Filegroups
> should i use ?
> how much disk drives should i use for best performance (7 or 8 as best
> performance is achieve only if even no. of drives is used)?
> thanx
>
All of that depends!
SATA drives are find for the O/S and software. I'm not sure why you would
need those in addition to your SCSI drives. SCSI is generally going to have
double the throughput of comparable SATA drives.
As far as filegroups are concerned. Filegroups are used in two situations.
Situation 1 is to ease administration and allow for partial backups and
restores. Situation 2 is to create a poor mans RAID. If you already have
a RAID solution, then there is no reason to use filegroups to force
table-writes across multiple specific hard drives.
Now for best performance on drives. It depends? Is your application
primarily read only? If so, then a big RAID-5 would do the trick. Is your
application write intensive. Then some combination of data on RAID 0+1 and
logs on separate RAID 0+1. Do you have a single channel RAID controller or
dual channel?
All of this may be a moot point if you don't have enough RAM in your system.
Read up on performance and www.sql-server-performance.com
This should give you enough information to make better choices about your
given situation.
Rick Sawtell
MCT, MCSD, MCDBA
|||thanx lots of info
Rick Sawtell wrote:
> "benamis" <nera@.meilo.lt> wrote in message
> news:OZtP$ixpFHA.3936@.TK2MSFTNGP10.phx.gbl...
>
> All of that depends!
> SATA drives are find for the O/S and software. I'm not sure why you would
> need those in addition to your SCSI drives. SCSI is generally going to have
> double the throughput of comparable SATA drives.
> As far as filegroups are concerned. Filegroups are used in two situations.
> Situation 1 is to ease administration and allow for partial backups and
> restores. Situation 2 is to create a poor mans RAID. If you already have
> a RAID solution, then there is no reason to use filegroups to force
> table-writes across multiple specific hard drives.
> Now for best performance on drives. It depends? Is your application
> primarily read only? If so, then a big RAID-5 would do the trick. Is your
> application write intensive. Then some combination of data on RAID 0+1 and
> logs on separate RAID 0+1. Do you have a single channel RAID controller or
> dual channel?
> All of this may be a moot point if you don't have enough RAM in your system.
>
> Read up on performance and www.sql-server-performance.com
>
> This should give you enough information to make better choices about your
> given situation.
> Rick Sawtell
> MCT, MCSD, MCDBA
>
>

Wednesday, March 21, 2012

new sql server

hi,
i was wondering is it a good idea to use sata drive as a system\mssql
drive and scsi for data ant log files?
am i right that data and log files must be on raid 10'
one more q... if i want to have 300gb data on db how much Filegroups
should i use ?
how much disk drives should i use for best performance (7 or 8 as best
performance is achieve only if even no. of drives is used)?
thanx"benamis" <nera@.meilo.lt> wrote in message
news:OZtP$ixpFHA.3936@.TK2MSFTNGP10.phx.gbl...
> hi,
> i was wondering is it a good idea to use sata drive as a system\mssql
> drive and scsi for data ant log files?
> am i right that data and log files must be on raid 10'
> one more q... if i want to have 300gb data on db how much Filegroups
> should i use ?
> how much disk drives should i use for best performance (7 or 8 as best
> performance is achieve only if even no. of drives is used)?
> thanx
>
All of that depends!
SATA drives are find for the O/S and software. I'm not sure why you would
need those in addition to your SCSI drives. SCSI is generally going to have
double the throughput of comparable SATA drives.
As far as filegroups are concerned. Filegroups are used in two situations.
Situation 1 is to ease administration and allow for partial backups and
restores. Situation 2 is to create a poor mans RAID. If you already have
a RAID solution, then there is no reason to use filegroups to force
table-writes across multiple specific hard drives.
Now for best performance on drives. It depends? Is your application
primarily read only? If so, then a big RAID-5 would do the trick. Is your
application write intensive. Then some combination of data on RAID 0+1 and
logs on separate RAID 0+1. Do you have a single channel RAID controller or
dual channel?
All of this may be a moot point if you don't have enough RAM in your system.
Read up on performance and www.sql-server-performance.com
This should give you enough information to make better choices about your
given situation.
Rick Sawtell
MCT, MCSD, MCDBA|||thanx lots of info :)
Rick Sawtell wrote:
> "benamis" <nera@.meilo.lt> wrote in message
> news:OZtP$ixpFHA.3936@.TK2MSFTNGP10.phx.gbl...
>>hi,
>>i was wondering is it a good idea to use sata drive as a system\mssql
>>drive and scsi for data ant log files?
>>am i right that data and log files must be on raid 10'
>>one more q... if i want to have 300gb data on db how much Filegroups
>>should i use ?
>>how much disk drives should i use for best performance (7 or 8 as best
>>performance is achieve only if even no. of drives is used)?
>>thanx
>
> All of that depends!
> SATA drives are find for the O/S and software. I'm not sure why you would
> need those in addition to your SCSI drives. SCSI is generally going to have
> double the throughput of comparable SATA drives.
> As far as filegroups are concerned. Filegroups are used in two situations.
> Situation 1 is to ease administration and allow for partial backups and
> restores. Situation 2 is to create a poor mans RAID. If you already have
> a RAID solution, then there is no reason to use filegroups to force
> table-writes across multiple specific hard drives.
> Now for best performance on drives. It depends? Is your application
> primarily read only? If so, then a big RAID-5 would do the trick. Is your
> application write intensive. Then some combination of data on RAID 0+1 and
> logs on separate RAID 0+1. Do you have a single channel RAID controller or
> dual channel?
> All of this may be a moot point if you don't have enough RAM in your system.
>
> Read up on performance and www.sql-server-performance.com
>
> This should give you enough information to make better choices about your
> given situation.
> Rick Sawtell
> MCT, MCSD, MCDBA
>
>

Wednesday, March 7, 2012

New Install, But I Need to Move Data Files

I could really use some help on this one. I know virtually nothing about SQL Server. We installed this because our database for the application we're running (Lexis Nexis Time Matters) had gotten too large for the Express 2005 version. We've also installed a new version of the software, and on a new server.

The new server has the drive partitioned into two partitions. When installing the application, I selected drive D (545 gb) as the data drive, but when I installed SQL server, it was installed on drive C (12 gb). I did not realize that the the application data was simply configuration information, and the data for the program is actually being installed on the C drive (\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data).

Is there a simple procedure to move this data, including the SQL instance (TIMEMATTERS) to the D drive? Or should I uninstall and start over?

If possible it would be better to uninstall SQL Server and reinstall it.

When installing SQL Server when you get to the page which asks you what services you want to install (the screen has 5 or 6 check boxes on it) you have to click on the Advanced Button to change the drive that SQL Server installs to.

If you can't uninstall the SQL Server you can detach the database (right click on the database and select "Tasks", then "Detach").

Then go move the physical MDF and LDF files for the database to the D drive (I recommend to a folder name D:\MSSQL\MSSQL.1\MSSQL\Data\).

Then in the SQL Management Studio right click on Databases, and select "Attach". Browse to the folder that you moved the MDF and LDF to and select the MDF file. Validate that the LDF is shown with the correct path (you may need to change it) then click OK (or what ever the correct name for the button is).

This will reattach the database so that users can access it and your application will begin working again.

Please keep in mind that your users will NOT be able to access the application while you are doing this, so it should be done after hours to minimize the impact.

Monday, February 20, 2012

New database on other local network drive

Hello,

I need help with the setup of my sql server express 2005 and more specifically, with the location of the database files. Normally, database files are located on the c: drive. In my situation, being in a high school environnement, I need to have the database files on the network drive ... lets call it g:\drive. The reason why it cannot be on c:\drive is because this drive is protected using DeepFreeze. Now, I was able to change the location of the new drive as I went into the properties window of the sql server instance but when I try to create this new database, sql gives me grief ;-|

I am from the group of people that thinks that to anything, there is a solution and am hoping that to this problem, there is hope of a solution.

Can anyone help?

Thank you

Yep there is Trace flag 1807 when you add that to your CREATE DATABASE statement it will be accepted, I found Microsoft documentation of the requirement and a link showing how easy it is to run DBCC TRACEON before executing your CREATE DATABASE statement. Hope this helps.

http://support.microsoft.com/default.aspx?scid=304261

http://www.yafla.com/dennisforbes/SAN-NAS-and-iSCSI-SQL-Server-/SAN-NAS-and-iSCSI-SQL-Server-.html

New database file locations

Hi. Could anyone suggest why, whenever a third-party application that creates
and uses its own SQL Server database, it creates the physical files in a
location that is not the default? This doesn't seem to be an app-specific
issue as different apps have done the same thing.
As per the general advise data and log files on my system are held on
separate volumes and when I create a new database myself the physical files
are created in their default locations. However this is not the case with
third-party apps. They seem to be creating the files in the same volume. How
do I change this behavior. I had thought that the settings of the model
database would determine where those files would go?
YaHozna.Hello,
I feel that your third party application creates the database specifying the
path. In this case the database will be created based on the path specified
in CREATE DATABASE command. Incase if the path is not configurab,e in
application installlation, you could detach the database, copy the files
to required drive and folder and attach the database. See SP_DETACH_DB and
SP_ATTACH_DB in books online..
Thanks
Hari
"YaHozna" <YaHozna@.discussions.microsoft.com> wrote in message
news:A74E91B5-7CDC-4143-ADFE-EF814499DE0B@.microsoft.com...
> Hi. Could anyone suggest why, whenever a third-party application that
> creates
> and uses its own SQL Server database, it creates the physical files in a
> location that is not the default? This doesn't seem to be an app-specific
> issue as different apps have done the same thing.
> As per the general advise data and log files on my system are held on
> separate volumes and when I create a new database myself the physical
> files
> are created in their default locations. However this is not the case with
> third-party apps. They seem to be creating the files in the same volume.
> How
> do I change this behavior. I had thought that the settings of the model
> database would determine where those files would go?
> YaHozna.|||There is a server setting that determines the default location for the data
and log files, not hte master db. Check the properties of the server in
Enterprise Manager and you will find them.
--
Andrew J. Kelly SQL MVP
"YaHozna" <YaHozna@.discussions.microsoft.com> wrote in message
news:A74E91B5-7CDC-4143-ADFE-EF814499DE0B@.microsoft.com...
> Hi. Could anyone suggest why, whenever a third-party application that
> creates
> and uses its own SQL Server database, it creates the physical files in a
> location that is not the default? This doesn't seem to be an app-specific
> issue as different apps have done the same thing.
> As per the general advise data and log files on my system are held on
> separate volumes and when I create a new database myself the physical
> files
> are created in their default locations. However this is not the case with
> third-party apps. They seem to be creating the files in the same volume.
> How
> do I change this behavior. I had thought that the settings of the model
> database would determine where those files would go?
> YaHozna.|||Many 3rd party applications do this, unfortunately.
When CREATE DATABASE is used without options, the defaults are
taken from the model database, but it is perfectly possible to
override the defaults by using the NAME and FILENAME options with
the CREATE DATABASE statement.
You can change the location of the files after the installation.
From http://sql.veranoest.net/sql_faq.htm
Q. How can I move my database files to another disk in my SQL
Server?
A. An easy way to move user database files to a different location
is by detaching, moving and attaching the user database.
This can be done in SQL Server Management Studio so you don't have
to type any code.
Here are the steps:
1. Start SQL Server Management Studio
2. Expand the server instance, expand Databases
3. right-click the database you want to move, and choose
"Properties"
4. In the Properties window, choose "Files" and write down the
current file paths. Click "Cancel"
5. right-click the database again, and choose "Tasks - Detach..."
6. click "OK" in the next window
7. Use Windows Explorer to move the data and log files (.mdf and
.ldf) to the new location
8. right-click Databases, and choose "Attach..."
9. In the "Attach databases" window, click "Add"
10.In the "Locate database files" window, browse to the new
location and select the .mdf file. Click "OK"
11.In the details pane, verify that the new location is listed for
both the .mdf and the .ldf file. Click "OK"
12.In SQL Server Management Studio, choose "View - Refresh" and
verify that your database is listed again under Databases
Alternatively you can backup the database and restore it,
specifying a different location for the files on the options table
or use the MOVE clause in the RESTORE command in Transact-SQL.
Details are here:
221465 - INF: Using the WITH MOVE Option with the RESTORE Statement
http://support.microsoft.com/?kbid=221465
If you want to move the system databases, be sure to read these
articles:
Moving the SQL 2005 System Databases
http://www.sqlservercentral.com/columnists/vIacoboni/2605.asp
224071 - How to move SQL Server databases to a new location by
using Detach and Attach functions in SQL Server
http://support.microsoft.com/?kbid=224071
_________________________________________________________
Vera Noest
MCSE, CCEA, Microsoft MVP - Terminal Server
SQL troubleshooting: http://sql.veranoest.net
___ please respond in newsgroup, NOT by private email ___
=?Utf-8?B?WWFIb3puYQ==?= <YaHozna@.discussions.microsoft.com> wrote
on 11 feb 2007 in microsoft.public.sqlserver.server:
> Hi. Could anyone suggest why, whenever a third-party application
> that creates and uses its own SQL Server database, it creates
> the physical files in a location that is not the default? This
> doesn't seem to be an app-specific issue as different apps have
> done the same thing.
> As per the general advise data and log files on my system are
> held on separate volumes and when I create a new database myself
> the physical files are created in their default locations.
> However this is not the case with third-party apps. They seem to
> be creating the files in the same volume. How do I change this
> behavior. I had thought that the settings of the model database
> would determine where those files would go?
> YaHozna.|||> When CREATE DATABASE is used without options, the defaults are
> taken from the model database, but it is perfectly possible to
> override the defaults by using the NAME and FILENAME options with
> the CREATE DATABASE statement.
Although the model database is used as a template for new databases, the
default file locations are not determined by the model database. As Andrew
mentioned, default file locations can be specified separately via server
properties.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"Vera Noest" <vera.noest@.remove-this.hem.utfors.se> wrote in message
news:Xns98D4A3986E7CDveranoesthemutforsse@.207.46.248.16...
> Many 3rd party applications do this, unfortunately.
> When CREATE DATABASE is used without options, the defaults are
> taken from the model database, but it is perfectly possible to
> override the defaults by using the NAME and FILENAME options with
> the CREATE DATABASE statement.
> You can change the location of the files after the installation.
> From http://sql.veranoest.net/sql_faq.htm
> Q. How can I move my database files to another disk in my SQL
> Server?
> A. An easy way to move user database files to a different location
> is by detaching, moving and attaching the user database.
> This can be done in SQL Server Management Studio so you don't have
> to type any code.
> Here are the steps:
> 1. Start SQL Server Management Studio
> 2. Expand the server instance, expand Databases
> 3. right-click the database you want to move, and choose
> "Properties"
> 4. In the Properties window, choose "Files" and write down the
> current file paths. Click "Cancel"
> 5. right-click the database again, and choose "Tasks - Detach..."
> 6. click "OK" in the next window
> 7. Use Windows Explorer to move the data and log files (.mdf and
> .ldf) to the new location
> 8. right-click Databases, and choose "Attach..."
> 9. In the "Attach databases" window, click "Add"
> 10.In the "Locate database files" window, browse to the new
> location and select the .mdf file. Click "OK"
> 11.In the details pane, verify that the new location is listed for
> both the .mdf and the .ldf file. Click "OK"
> 12.In SQL Server Management Studio, choose "View - Refresh" and
> verify that your database is listed again under Databases
> Alternatively you can backup the database and restore it,
> specifying a different location for the files on the options table
> or use the MOVE clause in the RESTORE command in Transact-SQL.
> Details are here:
> 221465 - INF: Using the WITH MOVE Option with the RESTORE Statement
> http://support.microsoft.com/?kbid=221465
> If you want to move the system databases, be sure to read these
> articles:
> Moving the SQL 2005 System Databases
> http://www.sqlservercentral.com/columnists/vIacoboni/2605.asp
> 224071 - How to move SQL Server databases to a new location by
> using Detach and Attach functions in SQL Server
> http://support.microsoft.com/?kbid=224071
> _________________________________________________________
> Vera Noest
> MCSE, CCEA, Microsoft MVP - Terminal Server
> SQL troubleshooting: http://sql.veranoest.net
> ___ please respond in newsgroup, NOT by private email ___
> =?Utf-8?B?WWFIb3puYQ==?= <YaHozna@.discussions.microsoft.com> wrote
> on 11 feb 2007 in microsoft.public.sqlserver.server:
>> Hi. Could anyone suggest why, whenever a third-party application
>> that creates and uses its own SQL Server database, it creates
>> the physical files in a location that is not the default? This
>> doesn't seem to be an app-specific issue as different apps have
>> done the same thing.
>> As per the general advise data and log files on my system are
>> held on separate volumes and when I create a new database myself
>> the physical files are created in their default locations.
>> However this is not the case with third-party apps. They seem to
>> be creating the files in the same volume. How do I change this
>> behavior. I had thought that the settings of the model database
>> would determine where those files would go?
>> YaHozna.|||Applications should never care where the database files are placed. That's a
DBA's job. Ideally, applications shouldn't be creating databases (I know they
do). They should use databases created for them. In cases they do create
databases in wrong locations, you should plan to move the files to the
correct locations.
But then I've seen apps that create databases on the fly as part of the
normal production process. Ouch!
Linchi
"YaHozna" wrote:
> Hi. Could anyone suggest why, whenever a third-party application that creates
> and uses its own SQL Server database, it creates the physical files in a
> location that is not the default? This doesn't seem to be an app-specific
> issue as different apps have done the same thing.
> As per the general advise data and log files on my system are held on
> separate volumes and when I create a new database myself the physical files
> are created in their default locations. However this is not the case with
> third-party apps. They seem to be creating the files in the same volume. How
> do I change this behavior. I had thought that the settings of the model
> database would determine where those files would go?
> YaHozna.|||Thanks Andrew and to the others who contributed. I did double-check the
Server settings and these are as they should be: data files are created on
volume E of a RAID array and Log files on volume D. Tempdb is also on volume
E and it was in that location - the folder in which the tempdb files exist -
that all files for new databases created by third-party apps seemed to be
being created for some reason.
No problem moving the files. Just wondered why this was happening.
Regards,
YaHozna
"Andrew J. Kelly" wrote:
> There is a server setting that determines the default location for the data
> and log files, not hte master db. Check the properties of the server in
> Enterprise Manager and you will find them.
> --
> Andrew J. Kelly SQL MVP
> "YaHozna" <YaHozna@.discussions.microsoft.com> wrote in message
> news:A74E91B5-7CDC-4143-ADFE-EF814499DE0B@.microsoft.com...
> > Hi. Could anyone suggest why, whenever a third-party application that
> > creates
> > and uses its own SQL Server database, it creates the physical files in a
> > location that is not the default? This doesn't seem to be an app-specific
> > issue as different apps have done the same thing.
> >
> > As per the general advise data and log files on my system are held on
> > separate volumes and when I create a new database myself the physical
> > files
> > are created in their default locations. However this is not the case with
> > third-party apps. They seem to be creating the files in the same volume.
> > How
> > do I change this behavior. I had thought that the settings of the model
> > database would determine where those files would go?
> >
> > YaHozna.
>
>

New database file locations

Hi. Could anyone suggest why, whenever a third-party application that creates
and uses its own SQL Server database, it creates the physical files in a
location that is not the default? This doesn't seem to be an app-specific
issue as different apps have done the same thing.
As per the general advise data and log files on my system are held on
separate volumes and when I create a new database myself the physical files
are created in their default locations. However this is not the case with
third-party apps. They seem to be creating the files in the same volume. How
do I change this behavior. I had thought that the settings of the model
database would determine where those files would go?
YaHozna.
Hello,
I feel that your third party application creates the database specifying the
path. In this case the database will be created based on the path specified
in CREATE DATABASE command. Incase if the path is not configurab,e in
application installlation, you could detach the database, copy the files
to required drive and folder and attach the database. See SP_DETACH_DB and
SP_ATTACH_DB in books online..
Thanks
Hari
"YaHozna" <YaHozna@.discussions.microsoft.com> wrote in message
news:A74E91B5-7CDC-4143-ADFE-EF814499DE0B@.microsoft.com...
> Hi. Could anyone suggest why, whenever a third-party application that
> creates
> and uses its own SQL Server database, it creates the physical files in a
> location that is not the default? This doesn't seem to be an app-specific
> issue as different apps have done the same thing.
> As per the general advise data and log files on my system are held on
> separate volumes and when I create a new database myself the physical
> files
> are created in their default locations. However this is not the case with
> third-party apps. They seem to be creating the files in the same volume.
> How
> do I change this behavior. I had thought that the settings of the model
> database would determine where those files would go?
> YaHozna.
|||There is a server setting that determines the default location for the data
and log files, not hte master db. Check the properties of the server in
Enterprise Manager and you will find them.
Andrew J. Kelly SQL MVP
"YaHozna" <YaHozna@.discussions.microsoft.com> wrote in message
news:A74E91B5-7CDC-4143-ADFE-EF814499DE0B@.microsoft.com...
> Hi. Could anyone suggest why, whenever a third-party application that
> creates
> and uses its own SQL Server database, it creates the physical files in a
> location that is not the default? This doesn't seem to be an app-specific
> issue as different apps have done the same thing.
> As per the general advise data and log files on my system are held on
> separate volumes and when I create a new database myself the physical
> files
> are created in their default locations. However this is not the case with
> third-party apps. They seem to be creating the files in the same volume.
> How
> do I change this behavior. I had thought that the settings of the model
> database would determine where those files would go?
> YaHozna.
|||Many 3rd party applications do this, unfortunately.
When CREATE DATABASE is used without options, the defaults are
taken from the model database, but it is perfectly possible to
override the defaults by using the NAME and FILENAME options with
the CREATE DATABASE statement.
You can change the location of the files after the installation.
From http://sql.veranoest.net/sql_faq.htm
Q. How can I move my database files to another disk in my SQL
Server?
A. An easy way to move user database files to a different location
is by detaching, moving and attaching the user database.
This can be done in SQL Server Management Studio so you don't have
to type any code.
Here are the steps:
1. Start SQL Server Management Studio
2. Expand the server instance, expand Databases
3. right-click the database you want to move, and choose
"Properties"
4. In the Properties window, choose "Files" and write down the
current file paths. Click "Cancel"
5. right-click the database again, and choose "Tasks - Detach..."
6. click "OK" in the next window
7. Use Windows Explorer to move the data and log files (.mdf and
.ldf) to the new location
8. right-click Databases, and choose "Attach..."
9. In the "Attach databases" window, click "Add"
10.In the "Locate database files" window, browse to the new
location and select the .mdf file. Click "OK"
11.In the details pane, verify that the new location is listed for
both the .mdf and the .ldf file. Click "OK"
12.In SQL Server Management Studio, choose "View - Refresh" and
verify that your database is listed again under Databases
Alternatively you can backup the database and restore it,
specifying a different location for the files on the options table
or use the MOVE clause in the RESTORE command in Transact-SQL.
Details are here:
221465 - INF: Using the WITH MOVE Option with the RESTORE Statement
http://support.microsoft.com/?kbid=221465
If you want to move the system databases, be sure to read these
articles:
Moving the SQL 2005 System Databases
http://www.sqlservercentral.com/columnists/vIacoboni/2605.asp
224071 - How to move SQL Server databases to a new location by
using Detach and Attach functions in SQL Server
http://support.microsoft.com/?kbid=224071
__________________________________________________ _______
Vera Noest
MCSE, CCEA, Microsoft MVP - Terminal Server
SQL troubleshooting: http://sql.veranoest.net
___ please respond in newsgroup, NOT by private email ___
=?Utf-8?B?WWFIb3puYQ==?= <YaHozna@.discussions.microsoft.com> wrote
on 11 feb 2007 in microsoft.public.sqlserver.server:

> Hi. Could anyone suggest why, whenever a third-party application
> that creates and uses its own SQL Server database, it creates
> the physical files in a location that is not the default? This
> doesn't seem to be an app-specific issue as different apps have
> done the same thing.
> As per the general advise data and log files on my system are
> held on separate volumes and when I create a new database myself
> the physical files are created in their default locations.
> However this is not the case with third-party apps. They seem to
> be creating the files in the same volume. How do I change this
> behavior. I had thought that the settings of the model database
> would determine where those files would go?
> YaHozna.
|||> When CREATE DATABASE is used without options, the defaults are
> taken from the model database, but it is perfectly possible to
> override the defaults by using the NAME and FILENAME options with
> the CREATE DATABASE statement.
Although the model database is used as a template for new databases, the
default file locations are not determined by the model database. As Andrew
mentioned, default file locations can be specified separately via server
properties.
Hope this helps.
Dan Guzman
SQL Server MVP
"Vera Noest" <vera.noest@.remove-this.hem.utfors.se> wrote in message
news:Xns98D4A3986E7CDveranoesthemutforsse@.207.46.2 48.16...[vbcol=seagreen]
> Many 3rd party applications do this, unfortunately.
> When CREATE DATABASE is used without options, the defaults are
> taken from the model database, but it is perfectly possible to
> override the defaults by using the NAME and FILENAME options with
> the CREATE DATABASE statement.
> You can change the location of the files after the installation.
> From http://sql.veranoest.net/sql_faq.htm
> Q. How can I move my database files to another disk in my SQL
> Server?
> A. An easy way to move user database files to a different location
> is by detaching, moving and attaching the user database.
> This can be done in SQL Server Management Studio so you don't have
> to type any code.
> Here are the steps:
> 1. Start SQL Server Management Studio
> 2. Expand the server instance, expand Databases
> 3. right-click the database you want to move, and choose
> "Properties"
> 4. In the Properties window, choose "Files" and write down the
> current file paths. Click "Cancel"
> 5. right-click the database again, and choose "Tasks - Detach..."
> 6. click "OK" in the next window
> 7. Use Windows Explorer to move the data and log files (.mdf and
> .ldf) to the new location
> 8. right-click Databases, and choose "Attach..."
> 9. In the "Attach databases" window, click "Add"
> 10.In the "Locate database files" window, browse to the new
> location and select the .mdf file. Click "OK"
> 11.In the details pane, verify that the new location is listed for
> both the .mdf and the .ldf file. Click "OK"
> 12.In SQL Server Management Studio, choose "View - Refresh" and
> verify that your database is listed again under Databases
> Alternatively you can backup the database and restore it,
> specifying a different location for the files on the options table
> or use the MOVE clause in the RESTORE command in Transact-SQL.
> Details are here:
> 221465 - INF: Using the WITH MOVE Option with the RESTORE Statement
> http://support.microsoft.com/?kbid=221465
> If you want to move the system databases, be sure to read these
> articles:
> Moving the SQL 2005 System Databases
> http://www.sqlservercentral.com/columnists/vIacoboni/2605.asp
> 224071 - How to move SQL Server databases to a new location by
> using Detach and Attach functions in SQL Server
> http://support.microsoft.com/?kbid=224071
> __________________________________________________ _______
> Vera Noest
> MCSE, CCEA, Microsoft MVP - Terminal Server
> SQL troubleshooting: http://sql.veranoest.net
> ___ please respond in newsgroup, NOT by private email ___
> =?Utf-8?B?WWFIb3puYQ==?= <YaHozna@.discussions.microsoft.com> wrote
> on 11 feb 2007 in microsoft.public.sqlserver.server:
|||Applications should never care where the database files are placed. That's a
DBA's job. Ideally, applications shouldn't be creating databases (I know they
do). They should use databases created for them. In cases they do create
databases in wrong locations, you should plan to move the files to the
correct locations.
But then I've seen apps that create databases on the fly as part of the
normal production process. Ouch!
Linchi
"YaHozna" wrote:

> Hi. Could anyone suggest why, whenever a third-party application that creates
> and uses its own SQL Server database, it creates the physical files in a
> location that is not the default? This doesn't seem to be an app-specific
> issue as different apps have done the same thing.
> As per the general advise data and log files on my system are held on
> separate volumes and when I create a new database myself the physical files
> are created in their default locations. However this is not the case with
> third-party apps. They seem to be creating the files in the same volume. How
> do I change this behavior. I had thought that the settings of the model
> database would determine where those files would go?
> YaHozna.
|||Thanks Andrew and to the others who contributed. I did double-check the
Server settings and these are as they should be: data files are created on
volume E of a RAID array and Log files on volume D. Tempdb is also on volume
E and it was in that location - the folder in which the tempdb files exist -
that all files for new databases created by third-party apps seemed to be
being created for some reason.
No problem moving the files. Just wondered why this was happening.
Regards,
YaHozna
"Andrew J. Kelly" wrote:

> There is a server setting that determines the default location for the data
> and log files, not hte master db. Check the properties of the server in
> Enterprise Manager and you will find them.
> --
> Andrew J. Kelly SQL MVP
> "YaHozna" <YaHozna@.discussions.microsoft.com> wrote in message
> news:A74E91B5-7CDC-4143-ADFE-EF814499DE0B@.microsoft.com...
>
>

New database file locations

Hi. Could anyone suggest why, whenever a third-party application that create
s
and uses its own SQL Server database, it creates the physical files in a
location that is not the default? This doesn't seem to be an app-specific
issue as different apps have done the same thing.
As per the general advise data and log files on my system are held on
separate volumes and when I create a new database myself the physical files
are created in their default locations. However this is not the case with
third-party apps. They seem to be creating the files in the same volume. How
do I change this behavior. I had thought that the settings of the model
database would determine where those files would go?
YaHozna.Hello,
I feel that your third party application creates the database specifying the
path. In this case the database will be created based on the path specified
in CREATE DATABASE command. Incase if the path is not configurab,e in
application installlation, you could detach the database, copy the files
to required drive and folder and attach the database. See SP_DETACH_DB and
SP_ATTACH_DB in books online..
Thanks
Hari
"YaHozna" <YaHozna@.discussions.microsoft.com> wrote in message
news:A74E91B5-7CDC-4143-ADFE-EF814499DE0B@.microsoft.com...
> Hi. Could anyone suggest why, whenever a third-party application that
> creates
> and uses its own SQL Server database, it creates the physical files in a
> location that is not the default? This doesn't seem to be an app-specific
> issue as different apps have done the same thing.
> As per the general advise data and log files on my system are held on
> separate volumes and when I create a new database myself the physical
> files
> are created in their default locations. However this is not the case with
> third-party apps. They seem to be creating the files in the same volume.
> How
> do I change this behavior. I had thought that the settings of the model
> database would determine where those files would go?
> YaHozna.|||There is a server setting that determines the default location for the data
and log files, not hte master db. Check the properties of the server in
Enterprise Manager and you will find them.
Andrew J. Kelly SQL MVP
"YaHozna" <YaHozna@.discussions.microsoft.com> wrote in message
news:A74E91B5-7CDC-4143-ADFE-EF814499DE0B@.microsoft.com...
> Hi. Could anyone suggest why, whenever a third-party application that
> creates
> and uses its own SQL Server database, it creates the physical files in a
> location that is not the default? This doesn't seem to be an app-specific
> issue as different apps have done the same thing.
> As per the general advise data and log files on my system are held on
> separate volumes and when I create a new database myself the physical
> files
> are created in their default locations. However this is not the case with
> third-party apps. They seem to be creating the files in the same volume.
> How
> do I change this behavior. I had thought that the settings of the model
> database would determine where those files would go?
> YaHozna.|||Many 3rd party applications do this, unfortunately.
When CREATE DATABASE is used without options, the defaults are
taken from the model database, but it is perfectly possible to
override the defaults by using the NAME and FILENAME options with
the CREATE DATABASE statement.
You can change the location of the files after the installation.
From http://sql.veranoest.net/sql_faq.htm
Q. How can I move my database files to another disk in my SQL
Server?
A. An easy way to move user database files to a different location
is by detaching, moving and attaching the user database.
This can be done in SQL Server Management Studio so you don't have
to type any code.
Here are the steps:
1. Start SQL Server Management Studio
2. Expand the server instance, expand Databases
3. right-click the database you want to move, and choose
"Properties"
4. In the Properties window, choose "Files" and write down the
current file paths. Click "Cancel"
5. right-click the database again, and choose "Tasks - Detach..."
6. click "OK" in the next window
7. Use Windows Explorer to move the data and log files (.mdf and
.ldf) to the new location
8. right-click Databases, and choose "Attach..."
9. In the "Attach databases" window, click "Add"
10.In the "Locate database files" window, browse to the new
location and select the .mdf file. Click "OK"
11.In the details pane, verify that the new location is listed for
both the .mdf and the .ldf file. Click "OK"
12.In SQL Server Management Studio, choose "View - Refresh" and
verify that your database is listed again under Databases
Alternatively you can backup the database and restore it,
specifying a different location for the files on the options table
or use the MOVE clause in the RESTORE command in Transact-SQL.
Details are here:
221465 - INF: Using the WITH MOVE Option with the RESTORE Statement
http://support.microsoft.com/?kbid=221465
If you want to move the system databases, be sure to read these
articles:
Moving the SQL 2005 System Databases
http://www.sqlservercentral.com/col...coboni/2605.asp
224071 - How to move SQL Server databases to a new location by
using Detach and Attach functions in SQL Server
http://support.microsoft.com/?kbid=224071
________________________________________
_________________
Vera Noest
MCSE, CCEA, Microsoft MVP - Terminal Server
SQL troubleshooting: http://sql.veranoest.net
___ please respond in newsgroup, NOT by private email ___
examnotes <YaHozna@.discussions.microsoft.com> wrote
on 11 feb 2007 in microsoft.public.sqlserver.server:

> Hi. Could anyone suggest why, whenever a third-party application
> that creates and uses its own SQL Server database, it creates
> the physical files in a location that is not the default? This
> doesn't seem to be an app-specific issue as different apps have
> done the same thing.
> As per the general advise data and log files on my system are
> held on separate volumes and when I create a new database myself
> the physical files are created in their default locations.
> However this is not the case with third-party apps. They seem to
> be creating the files in the same volume. How do I change this
> behavior. I had thought that the settings of the model database
> would determine where those files would go?
> YaHozna.|||> When CREATE DATABASE is used without options, the defaults are
> taken from the model database, but it is perfectly possible to
> override the defaults by using the NAME and FILENAME options with
> the CREATE DATABASE statement.
Although the model database is used as a template for new databases, the
default file locations are not determined by the model database. As Andrew
mentioned, default file locations can be specified separately via server
properties.
Hope this helps.
Dan Guzman
SQL Server MVP
"Vera Noest" <vera.noest@.remove-this.hem.utfors.se> wrote in message
news:Xns98D4A3986E7CDveranoesthemutforss
e@.207.46.248.16...[vbcol=seagreen]
> Many 3rd party applications do this, unfortunately.
> When CREATE DATABASE is used without options, the defaults are
> taken from the model database, but it is perfectly possible to
> override the defaults by using the NAME and FILENAME options with
> the CREATE DATABASE statement.
> You can change the location of the files after the installation.
> From http://sql.veranoest.net/sql_faq.htm
> Q. How can I move my database files to another disk in my SQL
> Server?
> A. An easy way to move user database files to a different location
> is by detaching, moving and attaching the user database.
> This can be done in SQL Server Management Studio so you don't have
> to type any code.
> Here are the steps:
> 1. Start SQL Server Management Studio
> 2. Expand the server instance, expand Databases
> 3. right-click the database you want to move, and choose
> "Properties"
> 4. In the Properties window, choose "Files" and write down the
> current file paths. Click "Cancel"
> 5. right-click the database again, and choose "Tasks - Detach..."
> 6. click "OK" in the next window
> 7. Use Windows Explorer to move the data and log files (.mdf and
> .ldf) to the new location
> 8. right-click Databases, and choose "Attach..."
> 9. In the "Attach databases" window, click "Add"
> 10.In the "Locate database files" window, browse to the new
> location and select the .mdf file. Click "OK"
> 11.In the details pane, verify that the new location is listed for
> both the .mdf and the .ldf file. Click "OK"
> 12.In SQL Server Management Studio, choose "View - Refresh" and
> verify that your database is listed again under Databases
> Alternatively you can backup the database and restore it,
> specifying a different location for the files on the options table
> or use the MOVE clause in the RESTORE command in Transact-SQL.
> Details are here:
> 221465 - INF: Using the WITH MOVE Option with the RESTORE Statement
> http://support.microsoft.com/?kbid=221465
> If you want to move the system databases, be sure to read these
> articles:
> Moving the SQL 2005 System Databases
> http://www.sqlservercentral.com/col...coboni/2605.asp
> 224071 - How to move SQL Server databases to a new location by
> using Detach and Attach functions in SQL Server
> http://support.microsoft.com/?kbid=224071
> ________________________________________
_________________
> Vera Noest
> MCSE, CCEA, Microsoft MVP - Terminal Server
> SQL troubleshooting: http://sql.veranoest.net
> ___ please respond in newsgroup, NOT by private email ___
> examnotes <YaHozna@.discussions.microsoft.com> wrote
> on 11 feb 2007 in microsoft.public.sqlserver.server:
>|||Applications should never care where the database files are placed. That's a
DBA's job. Ideally, applications shouldn't be creating databases (I know the
y
do). They should use databases created for them. In cases they do create
databases in wrong locations, you should plan to move the files to the
correct locations.
But then I've seen apps that create databases on the fly as part of the
normal production process. Ouch!
Linchi
"YaHozna" wrote:

> Hi. Could anyone suggest why, whenever a third-party application that crea
tes
> and uses its own SQL Server database, it creates the physical files in a
> location that is not the default? This doesn't seem to be an app-specific
> issue as different apps have done the same thing.
> As per the general advise data and log files on my system are held on
> separate volumes and when I create a new database myself the physical file
s
> are created in their default locations. However this is not the case with
> third-party apps. They seem to be creating the files in the same volume. H
ow
> do I change this behavior. I had thought that the settings of the model
> database would determine where those files would go?
> YaHozna.|||Thanks Andrew and to the others who contributed. I did double-check the
Server settings and these are as they should be: data files are created on
volume E of a RAID array and Log files on volume D. Tempdb is also on volume
E and it was in that location - the folder in which the tempdb files exist -
that all files for new databases created by third-party apps seemed to be
being created for some reason.
No problem moving the files. Just wondered why this was happening.
Regards,
YaHozna
"Andrew J. Kelly" wrote:

> There is a server setting that determines the default location for the dat
a
> and log files, not hte master db. Check the properties of the server in
> Enterprise Manager and you will find them.
> --
> Andrew J. Kelly SQL MVP
> "YaHozna" <YaHozna@.discussions.microsoft.com> wrote in message
> news:A74E91B5-7CDC-4143-ADFE-EF814499DE0B@.microsoft.com...
>
>

New Database

I've configured my data and log files for SQL Server Databases on separate drives.

D:\MSSQL\Data\User_db_data\
E:\MSSQL\Log\User_db_logs\

however, everytime i create a new database it defaults to the old location. How can i create a database using enterprise manager to default to the new locations ?Enterprise Manager
..Right-click on server
...Click on Properties
...Database Settings tab
....Set Default data directory and Default log directory

new custom flat file connection manager component

The standard flat file connection component does not handle flat files with different column counts on different rows. Since that's the type of file I have to read, I like to create a modified version of the flat file connection manager that can do this. I have found some info in how to create a connection manager. But I can't find anything that tels me how to build one that would be recognized by the flat file source dataflow component.

So how do you build an connection manager that can used by the standard flat file source component? Anyone ever did this or knows were to get the docs?

I know my problem is also solvable by reading the row into a single column and then using a script component to split them but that is not the solution I want.

The new connection manager is not going to solve this problem. The parsing logic is not part of the connection manager, it is part of the Flat File source adapter. You would need to build a new source, not connection manager.

Thanks,

Bob