CRS021 sorting order (X1,X2) used in Xtend M3

Hi,

If we do not have required Index available on M3 table, and create Sorting Order with "X" in CRS021, can we use them in Xtend M3 extensions?

I tried to use but at the statement i get an error after executing Xtend M3 API

DBAction query = database.table("OCUSMA").index("X4").selectAllFields().build()

Error :-

### EXCEPTION STACKTRACE ###
java.lang.ArrayIndexOutOfBoundsException: -1
at mvx.db.common.GenericDef.getNrOfFields(GenericDef.java:870)
at fnd.db.builder.impl.DBActionBuilderImpl.addAllFieldsToSelection(DBActionBuilderImpl.java:90)
at fnd.db.builder.impl.DBActionBuilderImpl.build(DBActionBuilderImpl.java:78)
at extensibility.api.exposed.provided.DatabaseAPI.lambda$build$5(DatabaseAPI.java:101)
at extensibility.api.ExtensibilityApiEnv$ExtensionRunnable.run(ExtensibilityApiEnv.java:27)
at extensibility.api.ExtensibilityApiEnv.execute(ExtensibilityApiEnv.java:43)
at extensibility.api.ExtensibilityApiEnv.execute(ExtensibilityApiEnv.java:54)
at extensibility.api.exposed.provided.DatabaseAPI.build(DatabaseAPI.java:97)
at extensibility.api.exposed.provided.DatabaseAPI$build$4.call(Unknown Source)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:115)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:119)
at LstOCUSMA.main(LstOCUSMA.xtendm3:27)
### END OF EXCEPTION STACKTRACE ###

Any idea os alternate solution on this in case of non exist Index?

Thanks in advance.

Find more posts tagged with

Accepted answers

All comments

Legacy Contributor

Hi Swati,

User defined indexes are not supported in XtendM3. You may use standard generic APIs e.g. MDBREADMI to retrieve data with those sorting order rather than using DatabaseAPI directly.

Thanks!

Legacy Contributor

Hi Swati,

Erfan already gave the answer, I would suggest the Expression factory in such a case to build a filter.

swatiy

Thank you very much Erfan for this reply

swatiy

Thanks Sudhakaran

Legacy Contributor

That's an alternative solution and it is OK on smaller datasets. If the table is large, using expressions on fields that are not part of the the index used for reading will result in performance issues.

It is also important to know the order of fields in the index.

For example, if you are using index 50 from OOHEAD, where the order is CONO, FACI, CUOR, CUNO and ORNO, and you use an expression to filter based on CONO and CUOR, then the index will not be efficient and performance will not be good, in that case you should be using index 30 instead where CONO and CUOR are the consecutive keys in the index.

So in summery, having columns used by expressions in index is important but not enough, the expression columns and the partial keys used have to be in an orderly fashion so that the index will be used efficiently.

Thanks!

Copyright © 2025 Infor. All rights reserved.