You are not logged in.
Pages: 1
Hi,
When I export a report of any kind (birt, jasper or dynamic list) and then import it again, I would expect it to overwrite the current version. But actually what it does is create a duplicate with the same name but with a different ID. It does not matter if I check 'Remove 'key' field in all imported reports if necessary:' or not. Is this a bug?
I am using 64 bit version of reportserverenterprise-3.0.2-3 from bitnami.
Kind regards,
Gerard
Offline
Hi Gerard,
this is not a bug. This is the expected behavior.
The option "remove key field in all imported reports if necessary" removes the key for the imported reports, since you cannot have two reports with the same key in reportserver.
Cheers,
Eduardo
Offline
Thanks Eduardo,
but how would you then deploy changes from a test environment to production? In the current situation it creates a duplicate report. I'd have to delete the old version but that will delete any references like in teamspaces, schedules and what about permissions? For a Birt or Jasper report the workaround would be to upload the new template file to the existing ID. But how about dynamic lists? I don't want an administrator to go into the coding and having to change the SQL etc.
Kind regards, Gerard
Offline
I also would be interested in knowing if there's any way to use the Import tool to overwrite or merge two objects.
Offline
Hi,
the underlying problem is conflict resolution between existing objects (EO) and objects that are to be inported (IO). Consider the following cases:
i) IO is new, that means no EO has a semantical relation to IO -> create new EO from IO
ii) IO has a semantical relation to EO:
a. IO leaves content of EO untouched but adds qualities to EO (for exapmle new attributes, new template), so to say existing variants in teamspaces keep there semantical meaning-> conflict could be resolved by overwriting
b. IO changes the content of EO, existing variants change their semantical meaning and might even be not executable any more -> conflict can not be resolved by overwriting
The problem here is to distinguish between ii) a. and ii) b.: Variants of whatever EO are complex objects and even though i might be able to kategorize a change by formal means, whether a change has consequences for the content of an EO (consider a report) or not is very difficult to decide. Plus the End User might simply not have noticed that the report he has been using ever since has change (even if for the better) and might put the blame of any of his misconceptions of this on you!
Therefore we decided not to overwrite existing object during import so far.
Here are two approaches to deal with the issue:
A1) Develop only new objects and put the effort on moving variants on to the (smart) users. "You want the new report ? Just get it via the Teamspace import funktionality! You need a variant here ? simply create it". You can support users them by dragging and droping exisitng varants to new Reports if compatible.
A2) Change existing Objects via export from production and import in test (with or without variants). Change them in test and reimport them into production (with or without variants in teamspaces) as new objects and remove the existing Report after confirmation of the users that it is no longer needed (might be quite a few). You can support users by dragging and droping exisiting variants to new Reports if compatible.
The strategy is to make changes known to users (for not beeing blamed for changes). Keep in mind that it is usally not known to administrators what users consider "important information". Also keep in mind that report objects sometimes have a lot of subscribers. I happily admit that it is defensive.
Hope that helps
jan
Offline
Pages: 1