Convert Match code to Search Help

[Former Member]

Hi Gurus,

Please Provide me solution for this.

We are working on an ECC6 Unicode system in which there are still some match codes which have become obsolete after version 4.0 due to this we are facing error in some programs. We need to convert MATCH CODES to SEARCH HELP. Do we need to convert it manually or is there any automatic procedure to do so? What are the steps to be followed to do the conversion manually?

Please provide me urgently.

Thanks & Regards,

Radha.

[Former Member]

Hi raadha,

There is no such process to convert them. i think so there you dont need any conversion. pls chk once. even though i am providing some info.. just go thru with them

Matchcode Customizing

When a transparent matchcode ID is activated, the system checks if an

appropriate index exists for the ID. Normally, such an index is necessary to

support the matchcode query. If such an index does not exist, there can be

major performance problems during matchcode selection. The system assumes

that the first field in the matchcode definition (for client-dependent match

codes the first field after the client field) is the relevant search field,

i.e., that the user will narrow down the search by entering a selection

criterion in this field.

An index is considered appropriate for the matchcode if it contains this

relevant matchcode field (or the client field followed by this field).

If no such index exists, a warning is given during the activation of the

matchcode ID. At this point, there are two possible courses of action:

1) If the matchcode view in the database covers less than 1,000 data

records, it is not necessary to create an index.

2) If the matchcode view will search more than 1,000 records, you should

create an index.

The first fields of an index to support matchcode selection should be

those that will be searched with equality (client, language or general

fields for which the get/set indicator has been set, i.e., the flag GP is

set for the field in the screen Update Matchcode ID Fields).

The index should have the following structure:

Client field - Fields for which the Get Parameter flag is set

Search fields - This index structure does not guarantee that the index will

be used by the underlying database system. Which index is used depends on

the database system's optimizer. You must verify that the index you have

created actually is used by the database.

Use the following method to determine whether the proper index is being used

to support the matchcode query:

Open a second session and choose System / Utilities / SQL Trace.

Select Trace on.

In your first session, do a search on your matchcode ID.

In your second session, choose Trace off and then List trace.

Search in your list for the first statement in which the matchcode view

occurs. Use the function Explain SQL to obtain information about how the

optimizer services the query. In particular, you can see which index is used.

Surplus matchcodes:

Before Release 3.0, surplus matchcode IDs should be deleted.

As of Release 3.0, surplus matchcodes IDs should be deactivated.

Deleting matchcode IDs (before Release 3.0)

Before you can delete a matchcode ID, you must check if it is a "system

matchcode." You can tell this by looking at the field System matchcode on

the screen Update Matchcode ID (Attributes). If this field is set, SAP uses

this matchcode ID. You should never delete a system matchcode ID!

Unfortunately, the dictionary transactions will allow you to delete system

matchcodes, so you should be extremely careful to check this flag and don't

delete a matchcode ID for which the flag is set.

If the flag System matchcode is not set, you must check which programs

use the matchcode. Use the general table display function (se16) and enter

the matchcode object and matchcode ID as the table name.

Deactivating matchcode IDs (as of Release 3.0)

The function Deactivate in the menu MC-Id of the screen Update Matchcode ID

(Attributes) allows you to reduce the load of unnecessary matchcode IDs.

Rather than deleting the ID, the dictionary definition remains available in

the ABAP/4 dictionary. If at some point the ID is needed again, it can

simply be reactivated.

The function Deactivate can only be used for active matchcode IDs. Before a

matchcode ID can be deactivated, the corresponding objects in the database

must be deleted (e.g., the view and possibly the index for IDs of update

type I).

Note that when you deactivate a matchcode ID of update type S, the matchcode

records will no longer be updated to keep up with application data. If you

reactivate a matchcode ID, you must re-create the matchcode records with the

matchcode utilities.

Note also that the deactivated matchcode IDs will not appear in F4 help.

Warning: Deactivation is a pure customizing function, i.e., not a

transportable characteristic.

If a deactivated matchcode ID is delivered again by SAP, it will be active

again after the upgrade.

Conversion to transparent matchcodes

Prerequisites for conversion

To convert a "physically stored" (pool) matchcode ID to transparent (view),

the following condition must be met:

All underlying tables of the ID must be transparent; no partial fields can

be used.

Note that when converting a program-controlled ID, you may need to adapt

the application programs.

Conversion procedure

To convert a physically stored matchcode ID (update type A, S or P) to

transparent (update type I), proceed as follows: Copy the ID you wish to

convert to the customer name range (IDs 0 to 9). Change the update type to

I and activate the ID.

If the original ID has the update type S, change the original to update type

A. This prevents unnecessary updates of the old ID. In Release 3.0, you

should simply deactivate the original ID.

Changes after the conversion

Searches are case sensitive

Queries on transparent matchcode IDs are case sensitive, i.e., when entering

a search argument in the text field, there is a distinction between upper

and lower case. The search string "hugo" would not match with the value

"Hugo" in the database. In some applications, there have been text fields

added to the original tables in which information is held redundantly in

upper case. If you use these fields in the matchcode ID, you can avoid this

problem of case sensitivity.

Sort order in output changes

For releases 2.1G to 2.1J, the output list is sorted by the index that the

optimizer chose for accessing the ID. As of 2.2E, the sort order depends on

the field order in the ID, i.e., the sort order will correspond to that of

the physical matchcode IDs. Transparent IDs that were not delivered with

2.2E must be activated again to have this new sort order.

Result set of a query can be smaller

The result set of a query on a transparent ID can be a real subset of the

results of an equivalent query on a physical matchcode ID. This is because

of the fact that transparent IDs are implemented with an inner join, whereas

the physical matchcodes are realized with an implicit outer join.

When searching with a transparent ID, records of a primary table that have

no corresponding entries in the foreign key fields of a secondary table will

not be found.

Example: An ID provides the search for an employee's personnel number using

name and department. The primary table contains the personnel number and

name. The secondary table contains departments and their employees.

Employees who have not been assigned to a department have no entry in the

secondary table. THose employees will not be found in a search with a

transparent matchcode with fields number, name and department. In a physical

matchcode ID with the same fields, those employees will be found.

Adapting partial fields

Partial fields in matchcodes are fields that you have defined so only a

portion of the original field is displayed and maintained in the matchcode.

You might want to show, for example, only the last six positions of SAP's

standard 16-character material number. If you defined partial fields for

the matchcode ID, their definitions must be removed to convert to a

transparent matchcode.

Further information

Issues especially for programmed matchcodes (update type P)

Programmed matchcodes are implemented physically, i.e., the matchcode data

is held redundantly in a separate table. The data is updated directly by

application programs, so that these application programs and other programs

always have access to the latest matchcode data. A function module is

generated during activation of the matchcode. The matchcode data is updated

when this function module is called. Conversion of programmed matchcodes to

transparent requires changes to the application programs that use the

function module. It is possible to just comment out the call to the function

module.

Adding tables to a matchcode object that contains a programmed matchcode ID

can lead to difficulties. Only one function module exists for all programmed

IDs in the object. This function module gets its information directly from

the matchcode object. For this reason, the function module interface should

be modified whenever the basis table of the object is changed, even if this

modification does not directly concern the programmed matchcode IDs.

Common problems with matchcode tables

Excessively large matchcode pool tables

At some point, it becomes difficult to manage large matchcode tables. There

are, for example, jobs that delete and re-create matchcodes; these run fine

if the master tables have only 50,000 records, but become quite cumbersome

if the master tables grow to have many millions of records. You may also see

a high number of extents on matchcode tables (i.e., table names beginning

with M_).

If you are having trouble managing pool matchcodes, you should seriously

consider converting to the new view matchcode technique.

thanks

sagar

reward me if usefulll

[Former Member]

Hi Sagar,

My Problem is,I have one Match code.

But in ECC6,I have Convert This Match Code To Search Help.

How I can do that.

Please Give Solution.

Thanks & Regards,

Radha,