FOR fuction causing comatibilaty issues looking for alternate of FOR fuction

224 views Asked by At

I am using DQM package in Cognos 11 report Studio. I have two queries which are joined to make a third query. In third query I am using filter condition as

[Cardex].[Transaction Date] = maximum( [Cardex].[Transaction Date] for [Cardex].[Lot/Serial Number])

If I disable this filter, my report runs and diplay data. But if I make it required which is our requirement, Report throws errors as

XQE-GEN-0018 Query Service internal error has occurred, please see the log for details.

Is there any alterway way of defining this filter condition?

[Cardex].[Transaction Date] = maximum( [Cardex].[Transaction Date] for [Cardex].[Lot/Serial Number])

where I should use FOR function and use any other compatible fuction

    Failure XQE-GEN-0018 Query Service internal error has occurred, please see the log for details. 
    10.100.190.127:9300 20948   2019-12-07 11:48:24.520 -5                  
    Default Executor-thread-3209    caf 2047    1   Audit.dispatcher.caf Request    Failure     SecureErrorId: 2019-12-07-11:48:24.520-#251  
    Original Error: XQE-GEN-0018 Query Service internal error has occurred, please see the log for details. 
    RSV-SRV-0042 Trace back:  RSReportService.cpp(764): XQEException: CCL_CAUGHT: RSReportService::processImpl()  
    RSReportServiceMethod.cpp(254): XQEException: CCL_RETHROW: 
    RSReportServiceMethod::process(): asynchRunSpecification_Request  
    RSASyncExecutionThread.cpp(887): XQEException: RSASyncExecutionThread::checkException  
    RSASyncExecutionThread.cpp(331): XQEException: CCL_CAUGHT: 
    RSASyncExecutionThread::runImpl(): asynchRunSpecification_Request  
    RSASyncExecutionThread.cpp(932): XQEException: CCL_RETHROW: 
    RSASyncExecutionThread::processCommand(): asynchRunSpecification_Request  
    Execution/RSRenderExecution.cpp(582): XQEException: CCL_RETHROW: RSRenderExecution::execute 
    Assembly/RSDocAssemblyDispatch.cpp(339): XQEException: CCL_RETHROW: RSDocAssemblyDispatch::dispatchAssembly 
    Assembly/RSLayoutAssembly.cpp(79): XQEException: CCL_RETHROW: RSLayoutAssembly::assemble  
    Assembly/RSDocAssemblyDispatch.cpp(448): XQEException: CCL_RETHROW: RSDocAssemblyDispatch::dispatchChildrenAssemblyForward  
    Assembly/RSReportPagesAssembly.cpp(185): XQEException: CCL_RETHROW: RSReportPagesAssembly::assemble  
    Assembly/RSDocAssemblyDispatch.cpp(384): XQEException: CCL_RETHROW: RSDocAssemblyDispatch::dispatchAssembly  
    Assembly/RSPageAssembly.cpp(314): XQEException: CCL_RETHROW: RSPageAssembly::assemble  
    Assembly/RSDocAssemblyDispatch.cpp(384): XQEException: CCL_RETHROW: RSDocAssemblyDispatch::dispatchAssembly  
    Assembly/RSTableRowAssembly.cpp(177): XQEException: CCL_RETHROW: RSTableRowAssembly::assemble  
    Assembly/RSDocAssemblyDispatch.cpp(384): XQEException: CCL_RETHROW: RSDocAssemblyDispatch::dispatchAssembly  
    Assembly/RSTableCellAssembly.cpp(151): XQEException: CCL_RETHROW: RSTableCellAssembly::assemble  
    Assembly/RSDocAssemblyDispatch.cpp(448): XQEException:
1

There are 1 answers

0
VAI Jason On

If I disable this filter , my report runs and diplay data . But if I make it required which is our requirement , Report throws errors as XQE-GEN-0018 Query Service internal error has occurred, please see the log for details.

I am guessing with the limited information provided

The filter is likely causing a join to a part in the model that is not connected

Using Framework Manager, make sure the tables are connected and with the correct scope

It is likely that the level of information has a gap (see ragged or unbalanced) Which means without the filter, the screen shows the initial results (which might be okay)

From the reporting side, it sounds like adding a filter gets us to the data that is ragged and produces the error

Here is a link to help understand this https://www.ibm.com/support/knowledgecenter/SSEP7J_10.2.2/com.ibm.swg.ba.cognos.ug_cr_rptstd.10.2.2.doc/c_cr_rptstd_wrkdat_ragged_hierarchies.html

To troubleshoot, build a simple version of the model with a very small result set that you know is balanced and well defined Then try your report

If it doesn't produce the error - it's not the report, it's the model

Let me know, and we can take the next step