Delete group (Banded Report Writer)
At 02 JAN 2012 03:06:03PM Jim Vaughan wrote:
Create a report and save to a group.
Delete report.
How do I then delete the group?
At 02 JAN 2012 04:45PM Richard Bright wrote:
Jim,
My observation is that BRW groups are saved in SYSREPOSREPORTS as AppID*OIBRW*GroupName, so you could delete the group using SYSREPOS tools. Otherwise within the BRW, with a report selected and Reports tab you could use the X button to "delete the selected report".
At 02 JAN 2012 05:07PM Jim Vaughan wrote:
Yes I had already tried that, deleting the record from SYSREPOSREPORTS does not remove the group from the BRW.
It's also not really a solution even if it works, my users are going to need to delete these from within the BRW.
Jim R Vaughan
At 02 JAN 2012 05:28PM bshumsky wrote:
Yes I had already tried that, deleting the record from SYSREPOSREPORTS does not remove the group from the BRW.
It's also not really a solution even if it works, my users are going to need to delete these from within the BRW.
Jim R Vaughan
Hi, Jim. When you say this doesn't delete the group from the BRW, you mean it's not deleted from the MRU (Most Recently Used) list? Or when you go to open a new report group, you still see that group in the list?
Did you delete the _entity_ (using the application manager, for example), or just delete the record from the SYSREPOSREPORTS? The key piece of information that may be missing here (and in your other question on how to copy reports) is that the BRW reports are "repository based" now, just like stored procedures. And just like deleting or copying stored procedures, you now actually delete or copy the repository entities of the BRW.
While I can see that maybe we should add an option to delete a report group in the BRW, I thought that using the RDK deployment tools for copying reports would be sufficient. How do you have your users copy things between different OI's now?
- Bryan Shumsky
At 02 JAN 2012 06:01PM Jim Vaughan wrote:
I deleted the record using the system editor ++.
It remains in the MRU, which I guess is OK but a tad messy.
However it also remains in the list of report groups that can be opened and saved to, that's wrong. Would using a REPOSITORY("DESTROY",REPORT_NAME), correct this?
I understand that they are repository based. However I need to allow a user to backup / copy their reports, I don't want to have to do it for them.
Our users are not going to be using RDK deploy to transfer between machines. RDK deploy would make sense if I wanted to make money off consulting. However we sell a software package, I don't want to sell consulting time, I want to spend my time selling and writing great software. We are a software company not a consulting company.
For other reports etc I have written my own code to allow the user export them to disk and also allow them to be re-imported.
Jim R Vaughan
At 02 JAN 2012 08:04PM bshumsky wrote:
I deleted the record using the system editor ++.
It remains in the MRU, which I guess is OK but a tad messy.
However it also remains in the list of report groups that can be opened and saved to, that's wrong. Would using a REPOSITORY("DESTROY",REPORT_NAME), correct this?
I understand that they are repository based. However I need to allow a user to backup / copy their reports, I don't want to have to do it for them.
Our users are not going to be using RDK deploy to transfer between machines. RDK deploy would make sense if I wanted to make money off consulting. However we sell a software package, I don't want to sell consulting time, I want to spend my time selling and writing great software. We are a software company not a consulting company.
For other reports etc I have written my own code to allow the user export them to disk and also allow them to be re-imported.
Jim R Vaughan
Yes, Repository("destroy") is the correct way to clean it up entirely, or (if you've got the Application Manager interface open, you can open up the entities list for OpenInsight/Reports/OpenInsight Reports/OpenInsight .NET BRW Reports, select the entity (report group) to delete, and then use Entity/Delete from the menu.
I don't know _how_ your users move data between machines; if it's via a process you've written for them, and you want them to move BRW reports between systems, then that's something you'd add to that process for them, right? If for example they wrote a report using the Report Builder, how would they move _that_ between different systems?
- Bryan Shumsky
At 03 JAN 2012 10:23AM Jim Vaughan wrote:
"Yes, Repository("destroy") is the correct way to clean it up entirely" How our my users meant to do this? They are not familiar with or even able to access this functionality. I would add a menu option to the BRW to do this but I don't believe I have the capability to do so.
In my application written in OI I can add whatever functionality is required but the BRW is a separate application that I don't think I can modify therefor it must contain all the functionality that a users needs. Deleting a group is I would have thought a fairly basic required function. Otherwise a complete re-install would be required to remove old groups.
Equally to have to add option to my application to export and import reports, although not hard seems messy and not very logical. It's not how I would expect my application to work. Having said that, that is what I will do.
I am still experiencing the BRW staying in memory on XP and also the lack of data in any report under Windows 7. I have not tested the lack of data under any other O/S, but I have tested it on two different installs on 2 different machines both running Windows 7. Any progress on these two items?
Jim R Vaughan
At 03 JAN 2012 01:39PM Jim Vaughan wrote:
I am adding code to export and import these reports.
Export is done.
Import is almost there, one question.
When importing a report builder report using
Repository("WRITE",ReportName,"",1,1,"","","","","",RecId,Record)
ReportName is equal to APP_NAME*OIREPORT*RBLAYOUT*:REC_ID
What is the equivalent statement for the new BRW? I think all i need is the Type Id and Class
Class I think is OIBRW, what is the Type Id.
Jim R Vaughan
At 03 JAN 2012 02:28PM bshumsky wrote:
I am adding code to export and import these reports.
Export is done.
Import is almost there, one question.
When importing a report builder report using
Repository("WRITE",ReportName,"",1,1,"","","","","",RecId,Record)
ReportName is equal to APP_NAME*OIREPORT*RBLAYOUT*:REC_ID
What is the equivalent statement for the new BRW? I think all i need is the Type Id and Class
Class I think is OIBRW, what is the Type Id.
Jim R Vaughan
Hi, Jim. Actually, you can make your life a little easier if you call the RTI_BRWSUPPORT routine - it can both read the report for you, and write a report for you.
REPORTDEF = RTI_BRWSUPPORT("READ", REPORTGROUPNAME, LOCKFLAG)
where REPORTGROUPNAME is the name of the report group to read, and LOCKFLAG is "1" if you want to lock the record when you read it (or "0" otherwise).
Similarly,
CALL RTI_BRWSUPPORT("WRITE", REPORTGROUPNAME, REPORTDEF, DEFAULTREPORT)
will write the report for you. REPORTGROUPNAME is the name of the report group, REPORTDEF is the report group definition itself (as returned by the READ, for example), and DEFAULTREPORT (if desired) is the name of the report inside the group that's the "default" report to run.
If you wish to code this yourself instead, here's a snippet of what's done in the "WRITE" call:
doWrite:
* param1: report group name
* param2: report definition
* param3: default report to run
entid = @appid<1>:"*OIREPORT*OIBRW*":param1
SWAP \0D0A\ WITH @FM In PARAM2
Call Set_Status(0)
Call Repository("NEW", entid, "", 1, 1, "", "", "", "", "", "BRW Report", '')
CALL SET_STATUS(0)
Call Repository("WRITE", entid, "", 1, 1, "", "", "", "", "", "BRW Report", param2)
If Get_Status(errcode) Then
rslt = errcodeparam1 = errcodeend
CALL SET_STATUS(0)
If param3 <> "" Then
Call Repository("SETSUBKEY", entid, subkey)Call Set_Status(0)End
Return
Hope that helps,
- Bryan Shumsky
At 03 JAN 2012 02:37PM Jim Vaughan wrote:
That definitely helps. Let me give this a try and get back to you.
Jim R Vaughan
At 03 JAN 2012 02:42PM Jim Vaughan wrote:
OK, that helped; I have it working.
Jim R Vaughan