Designing Reports for SQL Reporting Services 2000

My customer has SQL Reporting Services on a server with SQL 2000 Standard Edition. The customer wants to develop his own Reporting Services reports. We have been recommending Visual Basic.NET Standard 2003 for this purpose in that it costs less than $100 (usually). However, with the advent of Visual Studio 2005, the VB.NET 2003 is becoming difficult or impossible to obtain. One option is Visual C#.NET Standard 2003 - I assume it will work - does anyone know for sure?

More importantly, when Visual C#.NET 2003 becomes unvailable, what options are left for developing RS 2000 reports?

Thanks for any suggestions.

Mark

>More importantly, when Visual C#.NET 2003 becomes unvailable, what options are left for developing RS 2000 reports?

None from Microsoft. There are third-party solutions, e.g. Cizer.

|||

You could also write a small tool that performs a RDL structure "downgrade" conversion (see e.g. http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=988366&SiteID=1). However note that RS 2000 doesn't support a number of RS 2005 features (e.g. multi value parameters).

-- Robert

Design advice?

I have an construction estimation system, and I want to develop a project management system. I will be using the same database because there are shared tables. My question is this, critical data tables are considered tables with dollar values and these tables should not be shared across the whole company. I do however need information from these tables, such as product and quantity of the product for a given project. When an estimate becomes a project it is assigned a project number. At this point I thought of Copying the required data from the estimate side to the project side. This would result in duplicate data in a sence but the tables will be referenced from two standalone front end applications. Should I copy the data from one table to another, or create new "views" to the estimate tables for the project management portion.

What would be the best solution to this problem? I find in some circumstances, a new table is required because additional data will be saved on the "Project Management" side, but not in all cases.

Mike Bi'd make a new table and transfer contents of estimates table into it once the estimate matures into a project. at least one reason behind it: you can have multiple estimates and all but the final one will stay estimates. i'd also designate a grouping field to identify what estimates may relate to what project (i am talking about estimates that never became a project, but are related to the one that did)|||i'd also designate a grouping field to identify what estimates may relate to what project (i am talking about estimates that never became a project, but are related to the one that did)

I have already done that, it is a "Project Reference ID". Thanks for the input. It is pretty much already what I was thinking, but.....I am very under confident in my decisions (inexperience I guess).

Mike B