Best way to install data files?

Warning beginner here.
I posted this in the setup news group but haven't received and replies, so
perphaps someone here can help me.
I am developing a small ASP.NET web application that will use an SQL Server
2000 database. The database will start with 1,000 records in a main table
and about 100,000 records in a related table. How much this database will
grow is unknown.
I have one desktop machine that I am using for testing. It has one hard
drive, and nothing special about it.
Another test machine will pretend to be a production server. It is a real
server. It has the operating (Win Server 2003) system on a RAID 1 (2 drives)
setup. It also has 6 other drives set up as a RAID 5.
Should SQL Server be installed on the RAID 1, and then install the data
files only to the RAID 5? OR Should SQL Server and the data files be
installed on the RAID 5 drive?
The reason I ask is... From prior experience with Access I learned that
although attached data files can be worked with, they often required much
more code.
So... What is the best way to do this? And... why?
TIA.
With the disk setup that server has, install the SQL Server executables on
the RAID 1, and the user database on the RAID 5. You can create the master,
model and msdb system databases on the RAID 1 as well, and the tempdb on
RAID 1 as well, if there is enough space.
Jacco Schalkwijk
SQL Server MVP
"kvr901" <kvr901@.discussions.microsoft.com> wrote in message
news:E45F9F10-8B51-4644-A239-9A4F674BBFFD@.microsoft.com...
> Warning beginner here.
> I posted this in the setup news group but haven't received and replies, so
> perphaps someone here can help me.
> I am developing a small ASP.NET web application that will use an SQL
> Server
> 2000 database. The database will start with 1,000 records in a main table
> and about 100,000 records in a related table. How much this database will
> grow is unknown.
> I have one desktop machine that I am using for testing. It has one hard
> drive, and nothing special about it.
> Another test machine will pretend to be a production server. It is a real
> server. It has the operating (Win Server 2003) system on a RAID 1 (2
> drives)
> setup. It also has 6 other drives set up as a RAID 5.
> Should SQL Server be installed on the RAID 1, and then install the data
> files only to the RAID 5? OR Should SQL Server and the data files be
> installed on the RAID 5 drive?
> The reason I ask is... From prior experience with Access I learned that
> although attached data files can be worked with, they often required much
> more code.
> So... What is the best way to do this? And... why?
> TIA.
>
|||Thank you for your reply.
Another question:
**IF** some time in the future I decide to distribute the application
including the distributable version of SQL Server (I believe it is called the
"MSDE") would the installation procedure be the same?
In earlier versions of Access there was a considerable learning curve
(coding) to use attached Access secured "backend" databases, and I am
wondering if I should expect similar hurdles with the distributable version
of SQL Server.
Thank you.
"Jacco Schalkwijk" wrote:

> With the disk setup that server has, install the SQL Server executables on
> the RAID 1, and the user database on the RAID 5. You can create the master,
> model and msdb system databases on the RAID 1 as well, and the tempdb on
> RAID 1 as well, if there is enough space.
> --
> Jacco Schalkwijk
> SQL Server MVP
>
> "kvr901" <kvr901@.discussions.microsoft.com> wrote in message
> news:E45F9F10-8B51-4644-A239-9A4F674BBFFD@.microsoft.com...
>
>
|||kvr901 wrote:[vbcol=seagreen]
> Thank you for your reply.
> Another question:
> **IF** some time in the future I decide to distribute the application
> including the distributable version of SQL Server (I believe it is called the
> "MSDE") would the installation procedure be the same?
> In earlier versions of Access there was a considerable learning curve
> (coding) to use attached Access secured "backend" databases, and I am
> wondering if I should expect similar hurdles with the distributable version
> of SQL Server.
> Thank you.
>
> "Jacco Schalkwijk" wrote:
>
I am not sure I understand your concern about attached files. Once a
database is mounted by the server accessing is no different than any
other database on the server, regardless of the location of the actual
physical data file.
As to installing your database on a customers site. The issues around
RAID are more data integrity and performance related. Whatever their
configuration is will be dependent on the number of users and their
pocket books. But the system will work on any platform that supports SQL
Server.

Best way to implement external Log file

Hi,

I am developing application for our clinet.
some of requirements are system failure scenarios.
SQL Server is generating numbers for items inserted in some tables ( something like "oridinal number / year". logic for this is specified by my client and is somewhat complicated ) . most important requirement is to have external( usb stick on the server for example ) log file with latest numbers generated so that in the case of system failure it can be red and work can be countinued on the paper( with countinuing numbers) until system recovery.
Ideally, write it should be done inside of number generating and record inserting transaction.
There is avarage of 1 number generated per minute, but there is also a batch insert option for inserting thousands of records which must have numbers generated.

What is the best way to implement this:
-new data file on usb stic (external hard disk?) and single table in that data file? What about speed of usb stick. i suppose that usb stick with caching on can be fast enough (we are talkong about few rows only).
-maybe to configure SQL Server log to be written on that usb stick?
-some of the offices may have Internet access and some may not, so sending numbers via e-mail is not an option

-maybe some new MS SQL Server 2005 feature?.
What is the best practice in this case?

PS.
I know this sounds like an MCP exam, so, come on, MCSD's nad MCDBAs ;)

Hi,

if this is business critical I would suggest you to harden the availbility o your SQL Server instead :-). The idea about the USB stick sounds fancy but wouldn′t be professional at all. So use a job which reads periodically the numbers from that table and persit that in a log (I assume that you numbers dont have to be machine-readable, so the option with the logfile of the job is sufficient for you). otherwise if it shoudl be machine-readable, you could use a job which uses SQLCMD / or OSQL (depending on your version) does a export of some data.

HTH, Jens Suessmeyer.

http://www.sqlserver2005.de

|||

I understans what are you saying, but i need to conform to specs i recieved. They have some old-school requsts that they think are robust. I thik it is becouse they were thinking it will be done in older and less reliable system than SQL Server.

Job is not suitable becouse there will be lost data if SQL Express goes down. It needs to be done within insert transaction.

|||

ok, then you would need to implement something which purges out a log within OSQL.

Using a trigger / or within your stored procedure, depends on how you insert the data in the table) which will use sort of the following code:

OSQL -Q"SELECT Yournumber from youtable" -SServername -O"C:\yourlogfile"

Keep in mind that triggers react asynchronously, so the transaction will nlock the rest of the system unless the process comes back with either an error message or the successfull execution of the command.

HTH, Jens Suessmeyer.

http://www.sqlserver2005.de

Best way to handle License issues

Here is the scenario:

We are developing an ETL type data load application and we're thinking building a SSIS package to assist with this.

The application and data files to be loaded would be on the client Windows XP Workstation. The SQL Server 2005 instance would be on a networked server elsewhere.

The XP Workstation would NOT have sql server 2005.

What is the best way to handle this? Can this be achieved fairly easily?

Kevin

You’ll have to be a bit more specific on how you want to do your licensing... on a per seat basis? Per server?

No matter the model, I would highly recommend taking a read of this article on the mechanisms provided by the .NET Framework to help you implement a licensing mechanism.

|||I'm sorry I wasn't clear. I do not want to CREATE licensing for my application. I want to find out what the best, cost effective solution for me would be.

Example:
Buy 1 SQL Server 2005 and call SSIS packages from the Client?
I think in this scenario I would only need 1 SQL Server Standard license?

Kevin
|||Ahh... that I’m afraid I cannot help you with much... instead I would suggest starting with the SQL Server 2005 Licensing: Frequently Asked Questions if you have not already found it.|||

If the ETL application is to be on the client then you will need to have a licensed SQL Server install there - although you need only install SSIS and tools, not the server itself.

A better - and more economical - scenario for you may be to have SSIS running on the SQL Server box. No additional license required. You can create a SQL Agent job to execute the package and invoke that job remotely from the client using T-SQL.

Either way, of course, you will have data moving over the network from client to server - and that may be a bottleneck for you.

Donald