Big picture question about Reporting Services

I am an beginner who has completed one report under RS. I'm wondering if my
memory is playing tricks on me. This report has been rather easy to do.
I've hardly had to look at the documentation. (I should point out that I'm
temporarily using the SQL Express version because Someone misplaced the disks
for the full version.)
My question is this: I was under the impression that Reporting Services
involved actual Dot Net programming. At least that was the impression I got
from the early demos I saw, but it has been a while. Is there more to RS
than just dragging fields on a designer?On May 15, 8:51 am, B. Chernick <BChern...@.discussions.microsoft.com>
wrote:
> I am an beginner who has completed one report under RS. I'm wondering if my
> memory is playing tricks on me. This report has been rather easy to do.
> I've hardly had to look at the documentation. (I should point out that I'm
> temporarily using the SQL Express version because Someone misplaced the disks
> for the full version.)
> My question is this: I was under the impression that Reporting Services
> involved actual Dot Net programming. At least that was the impression I got
> from the early demos I saw, but it has been a while. Is there more to RS
> than just dragging fields on a designer?
There does not have to be any actual programming, even though you are
in Visual Studio. Demos or classes may have examples where you could
code an assembly and then call it from the report.|||You can write expressions in reporting services using visual basic.
No .net programming is required to create reports.
However, because the report definiton files (RDL) are basically xml files
then the system is wide open for customisation.
For example, I have a SQL stored procedure that generates hundreds of
reports automatically for me.
Now that is real power.sql

Big Picture Advice please to a SQL 2000 intermediate/beginner user

I am migrating a Mid-Frame DB to SQL Server 2000 PC.
I will call oldDB, OldTables the ones that belong to the Mid-Frame.
I will call newDB, newTables the ones that belong to the PC.
The oldDB has many versions and I have retrieved the oldTables to CSV
Files and then I use DTS to make a oldTables as tempTables in SQL 2000
PC.
I need to transform data and process the columns in tempTables to
create the NewTables (ie Final Tables).
I have used SQL scripts with UDFs to accomplish one run for one
version of OldDB to newDB.
The question is : Should I use ADO.NET or embedded SQL to process the
TemPTables
And CSV Files or Should stick with SQL SELECT, INSERT, UPDATE scripts
to do this ?
I have used SQL scripts with a dozen UDFs, is it time to start using
other tools /objects like SPs ?
GigaThanksInAdvanceGiga,
IMHO, if it works for you the way you're doing it, then I reckon stick with
it until you're comfortable moving to other features of SQL like stored
procs.
ADO.NET or SQL to me makes no diff if the end result is the same. You might
find things process quicker with native SQL commands. And there's not much
difference between scripts which run your UDFs or SPs to run them. Scripts
you run in QA will give you more of a visual on what's going on.
cheers
Danny
<placidite1@.yahoo.com> wrote in message
news:1179264486.895840.101790@.n59g2000hsh.googlegroups.com...
>I am migrating a Mid-Frame DB to SQL Server 2000 PC.
> I will call oldDB, OldTables the ones that belong to the Mid-Frame.
> I will call newDB, newTables the ones that belong to the PC.
> The oldDB has many versions and I have retrieved the oldTables to CSV
> Files and then I use DTS to make a oldTables as tempTables in SQL 2000
> PC.
> I need to transform data and process the columns in tempTables to
> create the NewTables (ie Final Tables).
> I have used SQL scripts with UDFs to accomplish one run for one
> version of OldDB to newDB.
> The question is : Should I use ADO.NET or embedded SQL to process the
> TemPTables
> And CSV Files or Should stick with SQL SELECT, INSERT, UPDATE scripts
> to do this ?
> I have used SQL scripts with a dozen UDFs, is it time to start using
> other tools /objects like SPs ?
>
> GigaThanksInAdvance
>

Big Picture Advice please to a SQL 2000 intermediate/beginner user

I am migrating a Mid-Frame DB to SQL Server 2000 PC.
I will call oldDB, OldTables the ones that belong to the Mid-Frame.
I will call newDB, newTables the ones that belong to the PC.
The oldDB has many versions and I have retrieved the oldTables to CSV
Files and then I use DTS to make a oldTables as tempTables in SQL 2000
PC.
I need to transform data and process the columns in tempTables to
create the NewTables (ie Final Tables).
I have used SQL scripts with UDFs to accomplish one run for one
version of OldDB to newDB.
The question is : Should I use ADO.NET or embedded SQL to process the
TemPTables
And CSV Files or Should stick with SQL SELECT, INSERT, UPDATE scripts
to do this ?
I have used SQL scripts with a dozen UDFs, is it time to start using
other tools /objects like SPs ?
GigaThanksInAdvanceGiga,
IMHO, if it works for you the way you're doing it, then I reckon stick with
it until you're comfortable moving to other features of SQL like stored
procs.
ADO.NET or SQL to me makes no diff if the end result is the same. You might
find things process quicker with native SQL commands. And there's not much
difference between scripts which run your UDFs or SPs to run them. Scripts
you run in QA will give you more of a visual on what's going on.
cheers
Danny
<placidite1@.yahoo.com> wrote in message
news:1179264486.895840.101790@.n59g2000hsh.googlegroups.com...
>I am migrating a Mid-Frame DB to SQL Server 2000 PC.
> I will call oldDB, OldTables the ones that belong to the Mid-Frame.
> I will call newDB, newTables the ones that belong to the PC.
> The oldDB has many versions and I have retrieved the oldTables to CSV
> Files and then I use DTS to make a oldTables as tempTables in SQL 2000
> PC.
> I need to transform data and process the columns in tempTables to
> create the NewTables (ie Final Tables).
> I have used SQL scripts with UDFs to accomplish one run for one
> version of OldDB to newDB.
> The question is : Should I use ADO.NET or embedded SQL to process the
> TemPTables
> And CSV Files or Should stick with SQL SELECT, INSERT, UPDATE scripts
> to do this ?
> I have used SQL scripts with a dozen UDFs, is it time to start using
> other tools /objects like SPs ?
>
> GigaThanksInAdvance
>

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 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 th
e
"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 versio
n
> 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.