System error when choosing FreeHand SQL

Stefan Dicu shared this problem 1 year ago
Resolved

Hi ,

Yesterday we have increased the Java memory from 1GB to 10 GB and today, not sure if related, we are not able to use FreeHand SQL, we get "System error".

I am attaching one gif to see what i get with the mention that one data source is not available for myself whereas that is available for my manager but when selected produces more detailed error, i am attaching that also maybe you are able to figure what is wrong.


Below the log:

YF:2017-09-28 01:43:58: INFO (MIReportInitAction:execute) - MIReportInitAction entered

YF:2017-09-28 01:43:58: INFO (MIReportInitAction:execute) - MIReportInitAction exiting with action: MIReportSQL

YF:2017-09-28 01:43:59: INFO (MIPreReportSQLAction:execute) - MIPreReportSQLAction entered

YF:2017-09-28 01:43:59:ERROR (MIReportProcess:loadSourceParameterList) - Error: java.lang.NullPointerException

YF:2017-09-28 01:43:59:ERROR (MIReportProcess:buildCacheMapTablesAndViews) - Error: java.lang.NullPointerException

java.lang.NullPointerException

at com.hof.mi.process.MIReportProcess.buildCacheMapTablesAndViews(MIReportProcess.java:19488)

at com.hof.mi.web.action.MIPreReportSQLAction.execute(MIPreReportSQLAction.java:204)

at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:425)

at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:229)

at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1913)

at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:449)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:622)

at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)

at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)

at com.hof.servlet.BrowserHeaderFilter.doFilter(BrowserHeaderFilter.java:43)

at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)

at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)

at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:198)

at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:108)

at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:589)

at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140)

at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)

at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:620)

at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)

at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:349)

at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:784)

at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)

at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:802)

at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1410)

at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)

at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)

at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)

at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)

at java.lang.Thread.run(Thread.java:748)

Best Answer
photo

Hi Stefan,

as far as I'm aware, there was never a Freehand SQL issue for calculated fields. What you're experiencing could be due to security on the Yellowfin data source - if the data source is set as Private then any users not listed in the security list won't have Freehand SQL in their reports (including calculated fields):


/EAAAAASUVORK5CYIIA


So can you please check whether your data source(s) has been configured with the private security setting and if so, then check the list of users.


regards,

David

Comments (19)

photo
1

Hi Stefan,

this is actually a known bug and has already been raised as defect YFN-7452 and will be fixed soon.

In the meanwhile thankfully there is an easy workaround. If you create just one Freehand SQL View (using any source, doesn't have to be the one you want to report from) then after that all Freehand SQL Reports will work (for any source). This fix will last until Yellowfin is restarted, in which case you'll have to create one more Freehand SQL View to get all Freehand SQL Reports working again.


regards,

David

photo
1

Hi Dave,

Thanks for the quick reply. The workaround works.

Can you please let me know when the bug is fixed so i can apply the patch? Do you have such tagging?

photo
1

Hi Stefan,


Apologies for the delayed response.

Yes this ticket has been linked to an actual defect task in our system. Once the task is fixed, this ticket will change to 'Defect Fixed' and we will let you know how you can get the fix (essentially which build includes it).


Please let us know if there was anything you were after in the meantime.

Regards,

David

photo
photo
1

Hi Stefan,

no problems, we'll notify you when the bug is fixed. At the moment the notifications aren't automatic but at some point they will be.

regards,

David

photo
1

Dave, ive seen the same behavior on Reports too but this time its nastier as we have to apply the workaround every time you log into the system. So its pretty ugly as it needs to be applied by every individual and its working only one session. The view workaround lasts till the server is rebooted but the report one only till you log out. Do we have an estimated time to get a fix for this ?

photo
1

Hi Stefan,

At the moment it'd probably be the end of November, so what we're trying to do is to move this up higher in the developers' queue so that it gets fixed sooner. I'll contact you at the end of this week and let you know what we think the ETA of the fix will be.

regards,

David

photo
1

Hi, do we have any updates on this issue? Seems it gets very bad, like the option is not available at all to some users.

We are several admins (full rights) and some see this option other dont.

photo
1

And the initial workaround doesn't work also since there is no more option to create a freehand sql View.

photo
1

Hi Stefan,

this defect has definitely been fixed, so if you download and run the latest build of the 7.3 Upgrade Installer then you will find the issue has been resolved.

regards,

David

photo
1

Hi Dave,

We are on Build:20170928. Can you confirm that build 20171201 is fixing this issue? I think i was advised to update to September build as it was solved in that build:

7731 - Fixed a problem with creating reports using Freehand SQL.


I thought i will get informed once the defect is fixed.


System Information

Application Version:7.35

Build:20170928

Java Version:1.8.0_131

Operating System:Linux 3.10.0-514.6.1.el7.x86_64 (amd64)

photo
1

Hi Stefan,

I have tested Freehand SQL Reports on my Yellowfin installation (7.35 20171201) and can confirm that it is working fine. I made a short video of my test and have attached it here for you.

regards,

David

photo
1

Hi Dave, thanks for checking.

Can you also check if the same FreehandSql option is resolved in Calculated Field? Currently from 3 SysAdmins only 1 has access to this option in "Calculated Fields" while the rest we dont see this option. Not sure why...

photo
photo
1

Hi Stefan,

as far as I'm aware, there was never a Freehand SQL issue for calculated fields. What you're experiencing could be due to security on the Yellowfin data source - if the data source is set as Private then any users not listed in the security list won't have Freehand SQL in their reports (including calculated fields):


/EAAAAASUVORK5CYIIA


So can you please check whether your data source(s) has been configured with the private security setting and if so, then check the list of users.


regards,

David

photo
1

Hi Dave,

You are correct! That was indeed the issue. That you for your time !

photo
1

you're welcome!

photo
1

Hi Dave,

Sorry to open this again but i have one question which is really important as I am building the security and the auditors will go thru.

So, if we provided Update to a user on a Private data source, this will only give the user access to Freehand SQL option and nothing else extra,correct?

photo
1

Hi Stefan,

no, if a user is granted Update privilege to a Private data source then he can create both Freehand SQL and Drag and Drop reports.

In summary, if a user is given any of the 3 privileges (DELETE, UPDATE, READ) for a private data source then he will be able to create both Freehand SQL and Drag and Drop reports.

However, if a user is not listed at all in the security list for a private data source, then that user will not be allowed to create Freehand SQL reports for that data source.

The reasoning behind this is because with Freehand SQL a user can interrogate any part of the data source (as there is no Yellowfin View required for Freehand SQL data sources). Whereas Drag and Drop reports are not as dangerous because the user can only interrogate the tables that are available to him via the Yellowfin View that he has been given access to.


Hope that makes sense.

regards,

David

photo
1

Hi Dave, thanks. Its pretty clear but for us i believe its ok as we intend to give access to Freehand SQL to out Superusers. So for us, in theory, these guys already create drag and drop reports and we provide specific access to the datasource in order to get this option enabled.

So, to conclude, in our case, since the users which will get this privilege they will in fact get only Freehand SQL in addition as we already gave them the drag and drop option

photo
1

Hi Stefan,

yes I understand now, your wording is very precise and I can confirm it is correct.

regards,

David

photo