Design change proposals for the End User Designer

Posted by: mschmitz on 21 August 2020, 1:57 am EST

    • Post Options:
    • Link

    Posted 21 August 2020, 1:57 am EST - Updated 30 September 2022, 6:29 am EST

    The textbox for entering a data set’s query has a max length character limit of 32767. I know the limit of a query in oracle can be well over 1mb. I did one test of 1.5mb, read about someone else who ran a 3mb query and another person who said they ran 20mb. Not sure what the limit is but we’re hitting issues where we need to refactor our queries because of this. I’m guessing that the textbox control used on that form has the limit and may need to be swapped with another control that doesn’t have that max length limit.

    (making this 3 posts due to sensitive spam detection here)

  • Posted 21 August 2020, 1:58 am EST - Updated 30 September 2022, 6:29 am EST

    It would be nice if there were a property setting on the report explorer control (kinda like ReportSettingsVisible or VisibileNodes) to either hide connection string tab when editing a dataset or prevent the editing of a dataset altogether.

    I’m using a slightly modified version of the designer where we pre-populate the datasource and credentials. The credentials populate when the page report is loaded and get removed when the page report is saved. The idea is to have the account credentials concealed from the user while also giving them the ability to create and run reports without needing an account of their own.

    In active reports 11, when using oracle client as the connection type the connection string used to be on a separate tab. Then I would have a timer running in the background always looking for when the “Report Data Source - General” window opened up and then disable that tab so people couldn’t switch to the connection string tab to see the password of the account that connected.

    But when upgrading to active reports 14 and having to use “Oracle Managed Data Access”, the only tab visible is the connection string where the user would ordinary see the password. The way I’m getting around that is still disabling the window but putting a bunch of semi-colons in the beginning of the connection string so that the credentials are outside of the viewing area.

  • Posted 21 August 2020, 1:58 am EST - Updated 30 September 2022, 6:29 am EST

    The other thing is it would be nice if the edit data set window were resizable and you could have the query text boxes resize when the screen is re-sized. Often times that window is too small and I’d need to paste the query in another editor in order to get a good look at it.

  • Posted 21 August 2020, 1:59 am EST - Updated 30 September 2022, 6:29 am EST

    I couldn’t do this in one post due to spam protection^

  • Posted 25 August 2020, 2:00 am EST

    Hello,

    Issue1:(Character Limit)

    I have forwarded the issue to the development team(AR-24991) and will inform you once I get any information from them.

    Issue2:(VisibleNode)

    You can hide the option as we discussed in the following case:

    https://www.grapecity.com/forums/ar-dev/prevent-access-to-oracle-d

    Also, you are able to hide the connection string by putting a bunch of semicolon. Request to please confirm if I am missing something.

    Issue3:(DataSet dialog Size)

    I have forwarded the issue to the development team(AR-24992) and will inform you once I get any information from them.

    Issue 4:(Regarding Spam)

    I am discussing with the concerned team and will inform you once I get any information from them.

    Thanks,

    Mohit

  • Posted 25 August 2020, 4:29 am EST

    Regarding issue 2, the workaround discussed in https://www.grapecity.com/forums/ar-dev/prevent-access-to-oracle-d did not pan out. I saw some side-effects from the design changes, though can’t remember what they are now. I’ve been searching my e-mails for what issues it caused. Back in February 2019 I reverted to another method where I have a timer that’s constantly checking if the edit data source window appears and then disables the controls that would let them see the connection string.

    But with either fix or hack used on this software, a design solution would be preferred. It does look more obvious that I’m trying to conceal the connection string now. That wouldn’t happen with a design solution.

  • Posted 25 August 2020, 11:20 pm EST

    Hello,

    Regarding the text limit, can you use names queries/procedures that are saved in the DB instead of saving large queries in the report’s body.

    Also, can you disable the default “DataSet” and “DataSource” dialog and create your own dialog to full your requirement:

    Sample Code:

    reeView node = reportExplorer.Controls[0].Controls[0] as TreeView;
    
    var tag = node.Nodes[0].Nodes[0].Tag;
    node.Nodes[0].Nodes[1].Remove();
    MenuItem menuItem1 = new MenuItem("Add");
    MenuItem menuItem2 = new MenuItem("Edit");
    ContextMenu cm = new ContextMenu();
    cm.MenuItems.Add(menuItem1);
    cm.MenuItems.Add(menuItem2);
    
    TreeNode treeNode = new TreeNode();
    treeNode.Text = "Data Sources";
    treeNode.ContextMenu = cm;
    treeNode.Tag = tag;
    
    node.Nodes[0].Nodes.Insert(1,treeNode);
    

    Thanks,

    Mohit

  • Posted 26 August 2020, 12:46 am EST - Updated 30 September 2022, 6:24 am EST

    Hello a procedure won’t work because oracle procedures can’t return sql query results like microsoft sql do. Measures like storing large portions of a report’s query inside a database view to shorten a query could work but then they would need the help of other departments to work around this length limitation. We’ve also explored other options like using the With statement to shorten code, remove comments, shorten alias names.

    We’ve had to do refactoring to get around this limitation. It is possible to do these things but then, besides having to deal with the inconvenience of having to do that, any time a user would need to edit the report they would have to go through a bureaucratic process to get database objects updated.

    I’ve tried to put your code sample in the project in various places but the menu items are not showing. Is there a place I should place it? If there was an alternative window that could be loaded then that window could have the textbox for the query without the 32767 limitation and then could probably enter the query into the dataset through code. Although then the user would be missing out all the other configurations that window provides.

    I’ve also thought about putting longer queries in the rdlx file itself except I think it would get clipped if anyone tried to modify the query from that current textbox length issue.

  • Posted 28 August 2020, 1:30 am EST

    Hello,

    I have escalated this to our development team and will inform you once I get any information from them.

    Thanks,

    Mohit

  • Posted 5 September 2020, 10:17 pm EST

    Hello,

    Could you please share the end user can create/edit/delete the DataSet in the report or not?

    Thanks,

    Mohit

  • Posted 10 September 2020, 11:08 am EST

    Yes the can do that

  • Posted 10 September 2020, 2:52 pm EST

    Hello,

    Thanks for the information. I have forwarded this to our development team.

    Thanks,

    Mohit

  • Posted 22 December 2020, 6:15 am EST

    Hello I was wondering if there was any traction on this (maybe some of these changes ended up in active reports 15?)

  • Posted 22 December 2020, 7:02 pm EST

    Hello,

    Currently, there is no additional feature as been added in the AR14 or AR15.

    Issue1:(Character Limit)

    You can implement your own query editor to avoid this issue

    Issue2:(VisibleNode)

    You can just encrypt the connection string in the report’s body and decrypt it in the custom data.

    Please refer to the attached modified sample to implement the same.

    Thanks,

    Mohit

    OracleEud2.zip

Need extra support?

Upgrade your support plan and get personal unlimited phone support with our customer engagement team

Learn More

Forum Channels