Change from Crystal Reports to SQL Server 2005 Reporting Services?

Hi all,
We have a web application that generates statistical reports in PDF format
based on customer data and we're thinking of migrating to SQL Server 2005
Reporting Services but I'd like to know if what we are doing is possible.
Basically, the customer logs onto the system via a regular browser, this
creates a folder on the backend based on their session info. Then they
select a couple of different reports, enter the required parameters and hit
print. The web app runs a VB program that loads the RPT file, modifies the
connections so it's getting the data from the correct customer database,
then exports the report as a PDF into the previously created folder. The
user is then redirected to that file so they can download it.
Whether the report is shown in a browser window or not is all dependent on
the customers settings for PDF documents. We don't need interactive
web-based reports, we don't need to drill-down, we don't need OLAP. It's a
simple "I want a report", "Here it is" scenario, but there is the definate
potential of having several hundred customers all requesting reports at the
same time, which is something our current solution can't handle.
Comments and suggestions are welcome.2005 has the ability to change the datasource at runtime. You do not need to
do any of this creating a folder in the background etc. Everything that you
want is really very simple.When your web app renders it can request it as
PDF. Also, you can send the report a parameter and based on that parameter
pick the appropriate database.
Implementing your security is the biggest issue (and what comes up the most
with an internet application). You will need to do forms based
authentication (which I have not done and do not know much about).
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Andrew Hayes" <AndrewHayes@.discussions.microsoft.com> wrote in message
news:OOzh8DapGHA.4408@.TK2MSFTNGP04.phx.gbl...
> Hi all,
> We have a web application that generates statistical reports in PDF format
> based on customer data and we're thinking of migrating to SQL Server 2005
> Reporting Services but I'd like to know if what we are doing is possible.
> Basically, the customer logs onto the system via a regular browser, this
> creates a folder on the backend based on their session info. Then they
> select a couple of different reports, enter the required parameters and
> hit print. The web app runs a VB program that loads the RPT file, modifies
> the connections so it's getting the data from the correct customer
> database, then exports the report as a PDF into the previously created
> folder. The user is then redirected to that file so they can download it.
> Whether the report is shown in a browser window or not is all dependent on
> the customers settings for PDF documents. We don't need interactive
> web-based reports, we don't need to drill-down, we don't need OLAP. It's a
> simple "I want a report", "Here it is" scenario, but there is the definate
> potential of having several hundred customers all requesting reports at
> the same time, which is something our current solution can't handle.
> Comments and suggestions are welcome.
>|||Thanks for the reply Bruce. Application security is already handled.
Maybe you can guide me through my understanding of how SSRS would handle
this?
a) User opens web-page.
b) User selects report from drop-down list, and the postback shows the
correct parameter options.
c) User enters the parameter values he needs.
d) User clicks on print.
e) Pop-up appears asking the user to wait while their report is prepared.
f) A few minutes later, the pop-up disappears to be replaced by the usual
File Download dialog.
g) User clicks Save and the PDF is saved to their PC.
We can do this in Crystal Reports without any fuss, but when more than 30
users are performing the same actions at the same time, the queue of report
requests ends up being pretty large as it takes quite some time to produce
each report. We're hoping that SSRS will let us "farm" out the report
generation to multiple servers.
"Bruce L-C [MVP]" <bruce_lcNOSPAM@.hotmail.com> wrote in message
news:OJlmwOcpGHA.3324@.TK2MSFTNGP05.phx.gbl...
> 2005 has the ability to change the datasource at runtime. You do not need
> to do any of this creating a folder in the background etc. Everything that
> you want is really very simple.When your web app renders it can request it
> as PDF. Also, you can send the report a parameter and based on that
> parameter pick the appropriate database.
> Implementing your security is the biggest issue (and what comes up the
> most with an internet application). You will need to do forms based
> authentication (which I have not done and do not know much about).
>
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
> "Andrew Hayes" <AndrewHayes@.discussions.microsoft.com> wrote in message
> news:OOzh8DapGHA.4408@.TK2MSFTNGP04.phx.gbl...
>> Hi all,
>> We have a web application that generates statistical reports in PDF
>> format based on customer data and we're thinking of migrating to SQL
>> Server 2005 Reporting Services but I'd like to know if what we are doing
>> is possible.
>> Basically, the customer logs onto the system via a regular browser, this
>> creates a folder on the backend based on their session info. Then they
>> select a couple of different reports, enter the required parameters and
>> hit print. The web app runs a VB program that loads the RPT file,
>> modifies the connections so it's getting the data from the correct
>> customer database, then exports the report as a PDF into the previously
>> created folder. The user is then redirected to that file so they can
>> download it.
>> Whether the report is shown in a browser window or not is all dependent
>> on the customers settings for PDF documents. We don't need interactive
>> web-based reports, we don't need to drill-down, we don't need OLAP. It's
>> a simple "I want a report", "Here it is" scenario, but there is the
>> definate potential of having several hundred customers all requesting
>> reports at the same time, which is something our current solution can't
>> handle.
>> Comments and suggestions are welcome.
>>
>|||Although implemented in a different way, the scenario described below is no
problem. RS has support for web farms. The Reporting Services app (which is
a 2.0 dotnet application) can run on a web farm. They all use the same
backend database for object/metadata caching. You do have to purchase a SQL
Server 2005 server license for each box running
PDF processing is more resource intensive than html or csv but RS 2005 has
improved this over RS 2000.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Andrew Hayes" <AndrewHayes@.discussions.microsoft.com> wrote in message
news:eqzqBohpGHA.1548@.TK2MSFTNGP04.phx.gbl...
> Thanks for the reply Bruce. Application security is already handled.
> Maybe you can guide me through my understanding of how SSRS would handle
> this?
> a) User opens web-page.
> b) User selects report from drop-down list, and the postback shows the
> correct parameter options.
> c) User enters the parameter values he needs.
> d) User clicks on print.
> e) Pop-up appears asking the user to wait while their report is prepared.
> f) A few minutes later, the pop-up disappears to be replaced by the usual
> File Download dialog.
> g) User clicks Save and the PDF is saved to their PC.
> We can do this in Crystal Reports without any fuss, but when more than 30
> users are performing the same actions at the same time, the queue of
> report requests ends up being pretty large as it takes quite some time to
> produce each report. We're hoping that SSRS will let us "farm" out the
> report generation to multiple servers.
> "Bruce L-C [MVP]" <bruce_lcNOSPAM@.hotmail.com> wrote in message
> news:OJlmwOcpGHA.3324@.TK2MSFTNGP05.phx.gbl...
>> 2005 has the ability to change the datasource at runtime. You do not need
>> to do any of this creating a folder in the background etc. Everything
>> that you want is really very simple.When your web app renders it can
>> request it as PDF. Also, you can send the report a parameter and based on
>> that parameter pick the appropriate database.
>> Implementing your security is the biggest issue (and what comes up the
>> most with an internet application). You will need to do forms based
>> authentication (which I have not done and do not know much about).
>>
>> --
>> Bruce Loehle-Conger
>> MVP SQL Server Reporting Services
>> "Andrew Hayes" <AndrewHayes@.discussions.microsoft.com> wrote in message
>> news:OOzh8DapGHA.4408@.TK2MSFTNGP04.phx.gbl...
>> Hi all,
>> We have a web application that generates statistical reports in PDF
>> format based on customer data and we're thinking of migrating to SQL
>> Server 2005 Reporting Services but I'd like to know if what we are doing
>> is possible.
>> Basically, the customer logs onto the system via a regular browser, this
>> creates a folder on the backend based on their session info. Then they
>> select a couple of different reports, enter the required parameters and
>> hit print. The web app runs a VB program that loads the RPT file,
>> modifies the connections so it's getting the data from the correct
>> customer database, then exports the report as a PDF into the previously
>> created folder. The user is then redirected to that file so they can
>> download it.
>> Whether the report is shown in a browser window or not is all dependent
>> on the customers settings for PDF documents. We don't need interactive
>> web-based reports, we don't need to drill-down, we don't need OLAP. It's
>> a simple "I want a report", "Here it is" scenario, but there is the
>> definate potential of having several hundred customers all requesting
>> reports at the same time, which is something our current solution can't
>> handle.
>> Comments and suggestions are welcome.
>>
>>
>

Cast - differences between SQL2000 and SQL2005

I came across a problem when migrating from SQL2000 to SQL2005.

Table1 - large table with multiple columns including columns (X21 varchar(50), Start datetime, Complete datetime)

View1 - Only returns integer values into the dwpId column

SELECT X21 AS dwpId, Start AS startDate, Complete AS endDate
FROM Table1
WHERE (X21 IS NOT NULL) AND (X21 LIKE '[0-9]%') AND
(ProjectID NOT LIKE '%_WI')

View2

SELECT cast(dwpId as int) as dwpId, startDate, endDate
FROM View1

In SQL2005, when selecting values from View2 an error is returned indicating that the statement failed when converting a varchar value to a data type int. In SQL2000, this same statement would return the appropriate rows from the view.

I dont think this is a problem with cast..

Problem is with your data, see the Select statement for Creation of view1,

If the data contains any non numerics also, It will select ex: '123A'

Modify your Select Query to fetch only Integers like this

SELECT X21 AS dwpId, Start AS startDate, Complete AS endDate
FROM Table1
WHERE (X21 IS NOT NULL) AND ISNUMERIC(X21)=1 AND
(ProjectID NOT LIKE '%_WI')

|||

IsNumeric does not guarantee that the data can be converted to an integer. IsNumeric simply gurantees that the value can be converted to 'some type' of numeric data type. There is a trick that you can use with IsNumeric to assure that you have an integer.

The following can be copy/pasted to a query analyzer window and run so that you can see the difference.

Declare @.Temp Table(Data VarChar(20))

Insert Into @.Temp Values('1')

Insert Into @.Temp Values('1.3')

Insert Into @.Temp Values('1e4')

Insert Into @.Temp Values('2d3')

Insert Into @.Temp Values('$43.3')

Insert Into @.Temp Values('abc')

Select Data, IsNumeric(Data), IsNumeric(Data + '.0e0')

From @.Temp

Only the first value is an actual integer. By adding .0e0 to the string before checking for IsNumeric, you are guaranteed to have a valid integer.

I recommend changing your query. .. And IsNumeric(X21 + '.0e0') = 1 and ...

|||

Good Suggestion, IsNumeric returns 1, If the data contains valid integer, floating point number, money or decimal type

Change the Query ,according to the mastros suggestion

|||

The problem is that SQL Server 2005 is more aggressive in terms of evaluating expressions in your query and moving them to different stages of the query plan. This might result in conversion error like in your case if the CAST gets computed before the WHERE clause checks. So there is no guarantee that the expressions in the WHERE clause will be computed first. This was true even in SQL Server 2000 except that you probably never hit it for your schema/data set. You can get the same error there also if the query plan changes.

To resolve the problem, you need to either correct your data model to represent the values correctly. Use float if your data is float - don't mix values from different domains. Or you will have to use CASE in the SELECT list to avoid the conversion problem. Note that using CASE expression is the only way to control order of execution of various expressions. See link below for more details (search for unsafe expressions):

http://msdn2.microsoft.com/en-us/library/ms143359.aspx

To summarize you have two solutions:

1. Fix your data model / schema so you represent the values in their proper domain (not float values in varchar and mixing various values in string)

2. Or modify your SELECT in the 2nd view to:

SELECT cast(CASE WHEN dwpId LIKE '[0-9]%' THEN dwpId END as int) as dwpId, startDate, endDate

FROM View1

Note that even above check is not entirely correct because not all values that have just numeric digits can be successfully converted to int. You might get overflow errors for example. You could use ISNUMERIC but that checks for integer, numeric, and money conversions so it will let more data through. So it is best you correct your schema to avoid all these issues.