after a change in the sql, such as changing the name of a column or parameter, what am I supposed to do ? Should I remove the data block and add it again ? In some cases, reviewing the same block worked fine, but sometimes it doesnt change anything ...
Thanks :)

Comments

metzlerd’s picture

metzlerd CreditAttribution: metzlerd commented

You can remove the data block and add it again. That might be particularly necessary if you are adding parameters, but this is not often required.

Changing or adding columns to the SQL can be done by simply altering the report layout to add columns. You won't always want to display all the columns that are selected by a block, so just go in and change the name of the field in the report, (e.g. {oldcolumnname} to {newcolumnname}. That changes which column is displayed. Do understand though that in the layout tab, or in the frx file, you may change the Labels at the top of the columns without worrying about changing the column name in the data. Does that make sense? You can always experiment by editing the sample reports that are delivered. They are reset to defaults anytime you press save on setting the report repository location.

Note that on the parameters screen, you can change the label that a user sees for a parameter without changing the parameter name in the data bock. It's true that it won't "add new parameters" or change the names automatically, but you could get that to happen by using the technique of removing and readding the same datablock. I'm going to need to add some functionality in the parameters screen to improve that behavior in the future.

Doe this answer your question?

mojzis’s picture

mojzis CreditAttribution: mojzis commented

thanks, so to sum it up :
the query defines :

  1. column names
  2. security
  3. parameter names

while the first 2 are refreshed automatically, upon first use after the change in the sql file (right ? how about caching ?), a change in the third means to remove and add again the data block, to be able to see a difference in the params screen

metzlerd’s picture

metzlerd CreditAttribution: metzlerd commented

Close, but not quite.

Security is defined in the sql file and refreshed automatically.

The report contains a list of "possible parameters" and "possible" columns, but you can actually remove the parameters and or columns so that users are not prompted for them and they only come via the url (usally via links from other reports).

If you were to change the name of the column in a report. The report would not change automatically. But you could change it manually by correcting the {token} in the report.

metzlerd’s picture

metzlerd CreditAttribution: metzlerd commented
Status: Active » Closed (fixed)

A while with no activity, so calling this one resolved.

Pierre.Vriens’s picture

Pierre.Vriens CreditAttribution: Pierre.Vriens commented
Issue summary: View changes

Adapting title to make this issue fit for inclusion in the (new) Forena HowTos.

Pierre.Vriens’s picture

Pierre.Vriens CreditAttribution: Pierre.Vriens commented
Title: report refresh after sql change » How to retrofit SQL changes in existing reports?
metzlerd’s picture

metzlerd CreditAttribution: metzlerd commented

FYI: This one is old, and isn't really accurate anymore. There are different ways to deal with this in Forena 7.x-4.x I'd be really careful about including 6.x issue referenes in 7.x issue documentation.

Pierre.Vriens’s picture

Pierre.Vriens CreditAttribution: Pierre.Vriens commented

OK David, I was actually wondering such question myself. Thanks for correcting me, I now slightly corrected that HowTo page, indicating that this issue only applies to D6.

PS: Unless I hear different, I'll assume it's OK to add the comments to such "old" issues as I did in #5, together with a (minor) correction of the title to make it fit better.