Changing chart type at run-time

Hello,

I'm coding a web application using ASP.NET 2.0 and I'd like to show users some charts allowing them to chose the chart type at run-time.
I'm building a rdlc (local) report source at run-time starting from a template and working in memory.
Users can select wich rows and columns from a table to display in the chart. They can also chose che chart type (Bar, line, pie etc.)

Now the code works fine the first time it's run. Then the report viewer keeps showing the chart with the same chart type and columns data. Only rows change accordingly to the user selection.

I'm using the following code to initialize the reportviewer:

Dim str As System.IO.MemoryStream = New MemoryStream
rptDoc.Save(str) //->that's the xml doc being saved to a memory stream
str.Position = 0
repView.LocalReport.ReportPath = String.Empty 'Just in case...
repView.LocalReport.LoadReportDefinition(str)
repView.LocalReport.DataSources.Clear() 'Just in case again...
repView.LocalReport.DataSources.Add(New ReportDataSource("DataSet1_01E01000", dt2))
repView.LocalReport.Refresh()

Any suggestion?

Thank you all.Can you share with me how you change the Chart Type at Runtime? Thanks!|||

Sorry for the late reply, I haven't checked forums lately.

As I said I'm building the rdlc (local) report source file at run-time starting from some templates.

The rdlc files are nothing more that XML files and the chart type is defined inside a node. All I do is put the desired type in the right node.

You can also build a rdlc right from scratch and pass it to the ReportViewer component via its LoadReportDefinition method using the overloaded version that gets a IO.Stream as source.

Ask me if you need a sample.

Bye.

|||

You need to reset the report by doing a

ReportViewer1.Reset();//Then setting the datasource and all the properties.

|||

Hello Stojilcoviz,

Can you share with me the sample of your code which changes the chart types at run-time in the RDLC? Thanks.

change to not allow nulls

Is there a *simple* way to change a collumn from allowing null to not
null?

I just unchecked "allow nulls" in EM and the SQL it generates to do
this one thing is astonishing, create table, drop FKs, copy data, drop
table, rename new table, rebuild FKs...

I'm saving a lot of these changes to run on another database at a later
date but would rather not require a terrabyte device to store the
script :-)I recommend you use TSQL scripts to make structure changes. You'll have
much more control and visibility over what happens and you'll be able
to test your scripts out before you go live with the change.

You can change nullability with an ALTER TABLE... ALTER COLUMN
statement but if the column is part of an index or constraint then
you'll have to drop that before you can make the change. That means
you'll also have to drop foreign keys that reference the column. EM
tries to make this easier by generating the script for you, so you
could save that script and take it as a starting point.

Another option that may be worth trying:
1. create a new column, populate it from the previous nullable one and
make it non-nullable
2. add constraints and indexes
3. drop the old column
4. rename the column you added

Possibly this method may incur less impact and downtime but that would
depend quite a lot on how the column is used and on other factors too
such as the size of the data and whether an existing index on the
column is clustered. Test it out and see.

--
David Portas
SQL Server MVP
--|||David Portas wrote:
> I recommend you use TSQL scripts to make structure changes. You'll
have
> much more control and visibility over what happens and you'll be able
> to test your scripts out before you go live with the change.

I am doing, I use EM to generate the scripts for some things if there's
a shed load to do in a table or if I don't know how to do something
(such as change a null column to a not null :-)

> You can change nullability with an ALTER TABLE... ALTER COLUMN
> statement but if the column is part of an index or constraint then
> you'll have to drop that before you can make the change. That means
> you'll also have to drop foreign keys that reference the column. EM
> tries to make this easier by generating the script for you, so you
> could save that script and take it as a starting point.

Thanks, it's just a description column so alter table should do it.|||Trevor Best (googlegroups@.besty.org.uk) writes:
> Is there a *simple* way to change a collumn from allowing null to not
> null?
> I just unchecked "allow nulls" in EM and the SQL it generates to do
> this one thing is astonishing, create table, drop FKs, copy data, drop
> table, rename new table, rebuild FKs...
> I'm saving a lot of these changes to run on another database at a later
> date but would rather not require a terrabyte device to store the
> script :-)

That is not the main problem with the scripts generated by Enterprise
Manager. The main problem is that if something goes wrong in the
middle of those scripts, you may end of with halfly-modified database,
and you may lose foreign keys forever. This is because the scripts
has a poor transaction scope.

Overall, I strongly discourage using the table designer in Enterprise
Manager to change tables. You can take the script as a starting point,
but there is a lot of problems to sort out. Some standard remedies
to apply:

o Remove all BEGIN and COMMIT TRANSACTION but the first BEGIN and last
COMMIT.
o Put all statements in EXEC('...'). (Except for calls to stored
procedures.
o Remove all GO.
o On all re-addition of foreign keys, insert WITH CHECK before
CHECK. (Yes, WITH CHECK CHCEK.)

For this particular case, adding a new column and then dropping the
old one may be a good idea, as David suggested.

--
Erland Sommarskog, SQL Server MVP, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp