unable to find DCR

Hi,

Can anyone tell me from where the list of all DCR's be populated when we click on File > New Form Entry, that is on 'Select a Form' page (you can find it in screenshot attached).

The list of DCR's I could see now contains DCR's which are not there in template data. So, when I am selecting that DCR, getting the below exception:

Unable to find
//sfa21751www004.managed.cln/default/main/www.appliedmaterials.com/common/WORKAREA/development/templatedata/Products/Product
Generic Page/datacapture.cfg. Please contact your system administrator.

Clicking on the Show Details button displays this message:
Root cause:
Couldn't get a DCT file at
//sfa21751www004.managed.cln/default/main/www.appliedmaterials.com/common/WORKAREA/development/templatedata/Products/Product
Generic Page/datacapture.cfg [datacapture.unable_to_find_dct.error.msg ]

Details...
com.interwoven.ui.formspub.datacapture.DCRPredicate$ReadDCTException:
Couldn't get a DCT file at
//sfa21751www004.managed.cln/default/main/www.appliedmaterials.com/common/WORKAREA/development/templatedata/Products/Product
Generic Page/datacapture.cfg [datacapture.unable_to_find_dct.error.msg ]
at
com.interwoven.ui.formspub.datacapture.DCRPredicate.findDCTFromTemplateType(DCRPredicate.java:110)
at
com.interwoven.ui.formspub.datacapture.NewDCRPredicate.execute(NewDCRPredicate.java:57)
at
com.interwoven.ui.formspub.datacapture.NewDCRCommand.execute(NewDCRCommand.java:325)
at
com.interwoven.ui.base.impl.command.CommandHandler.doExecuteCommand(CommandHandler.java:915)
at
com.interwoven.ui.base.impl.command.CommandHandler.tryRunCommandDescriptor(CommandHandler.java:752)
at
com.interwoven.ui.base.impl.command.CommandHandler.tryRunCommandID(CommandHandler.java:629)
at
com.interwoven.ui.base.impl.command.CommandHandler.runCommand(CommandHandler.java:419)
at
com.interwoven.ui.base.impl.command.CommandCallbackContextImpl.callback(CommandCallbackContextImpl.java:45)
at
com.interwoven.ui.base.wizard.WizardCommand.execute(WizardCommand.java:115)
at
com.interwoven.ui.base.impl.command.CommandHandler.doExecuteCommand(CommandHandler.java:915)
at
com.interwoven.ui.base.impl.command.CommandHandler.tryRunCommandDescriptor(CommandHandler.java:752)
at
com.interwoven.ui.base.impl.command.CommandHandler.tryRunCommandID(CommandHandler.java:629)
at
com.interwoven.ui.base.impl.command.CommandHandler.runCommandLoop(CommandHandler.java:234)
at
com.interwoven.ui.base.impl.command.CommandServlet.doGet(CommandServlet.java:163)
at
com.interwoven.ui.base.impl.command.CommandServlet.doPost(CommandServlet.java:263)
at
javax.servlet.http.HttpServlet.service(HttpServlet.java:709)
at
javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
com.interwoven.ui.base.impl.auth.AuthenticationFilter.doFilter(AuthenticationFilter.java:204)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
com.interwoven.ui.base.util.SetRequestEncodingFilter.doFilter(SetRequestEncodingFilter.java:105)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at
org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at
org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at
org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at
org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:595)

So, I want to know form where this list of all DCR's be populated.
Please provide me solution as soon as possible.

Thanks,
Pradeep Velpula.

Find more posts tagged with

Comments

Phanie

Hi Pradeep, you should be looking in templating.cfg and search for the category name where all these datatypes are. Once you find them you can delete all the datatypes which are not being used now.

--
Phanie

nipper

New form looks at the templating.cfg and the directory structure (if you have templating.cfg set to prune unavailable forms). It does not look for the DCT.

Adam Stoller

New form looks at the templating.cfg and the directory structure (if you have templating.cfg set to prune unavailable forms). It does not look for the DCT.

To be a bit more accurate here - as of TS 6.5 (I believe) the processing of templating.cfg was changed so that - by default - it will use the regex's specified within the templating.cfg file to determine, based on your current branch vpath, what DCT types (not DCRs as mentioned in the original post) are theoretically available.

For backwards compatibility (and because a bunch of us complained about the above change) - an attribute was added to the templating.cfg file: prune-missing-files="true". If you use that (read the documentation for information about where it goes) - then the vpaths are still potentially used - but the system will actually verify that all potentially available DCTs actually exist within the current area vpath before providing them as options to the user.

Interwoven claimed that that the newer mechanism of just using regex's is significantly better performance-wise - but thus far I've yet to see an environment in which the supposed performance degradation with prune-missing-files is noticeable - and I tend to make sure its set in all my implementations.

pradeep_velpula

Thanks alot for each one of you.
It's working great.

Regards,
Pradeep Velpula.