Is indexing HD necessary?

I found this post about indexing a hard drive, http://discussions.apple.com/thread.jspa?messageID=692070. One of the replies said indexing was time consuming and unnecessary. They also mentioned they personally index only their documents folder, because that is the only folder they search.
I, on the other hand, need to search for files across my entire drive. But, everytime I try and do so my Finder freezes, and I end up having to do a hard restart.
If I index my entire drive will that help remedy my 'finder freezing' problem?
Thanks
933 MHZ Quicksilver Mac OS X (10.3.8)

any file you create should be placed in the Document folder
Thanks, but I must not be a normal user.
I find it easier, especially at work, to save files / folders of current projects on my desktop. Then, move them to another location for archiving purposes. So, I do need to index more than just my documents folder. Would indexing my entire drive help me search for files faster? Or, help alleviate my 'Finder Freezing' issue mentioned in my original post?
933 MHZ Quicksilver Mac OS X (10.4.2)

Similar Messages

FK's indexes : really necessary ?

Hi all,
I have a database with an index for each Foreign Key. This leads me to wonder whether theses indexes are really necessary ?
I read elsewhere that a query like this one would help me to see which indexes are really worth it (the bigger the ratio, the best the index) :
select distinct_keys/num_rows as ratio, distinct_keys, num_rows, index_name
from user_indexes
where num_rows != 0
order by ratio;Can anyone confirm this is a good clue, or give me some more advice
Thanks for your comments
Tittom
null

I found information on this topic here : %20and%20{key}]http://asktom.oracle.com/pls/ask/f?p=4950:8:71095::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:292016138754,{foreign}%20and%20{key}
It says that indexes on FK are necessary to prevent table-level locks.
Now my question is : what if statistics are not set for theses indexes ? Will Oracle ignore them and lock the tables ?
Thomas

Multi-column Index vs One index for each column

Hello everyone,
i have one table about 20 000 000 rows, some developers have to generate reports on it and i want to create indexes on this table.
The table has 34 columns, no primary key, no unique keys.
The "where..." clause of the reports usually use 8 columns but some reports uses 8 + some other columns.
can any one help me on what kind of indexes do i have to create?
1. one index for each column used in "where clause"
2. one index for 8 columns and some other indexes for other used columns
3. one index for all columns
or something else etc...
br flag

i have one table about 20 000 000 rows, some developers have to generate reports on it and i want to create indexes on this table.
The table has 34 columns, no primary key, no unique keys.
The "where..." clause of the reports usually use 8 columns but some reports uses 8 + some other columns.
can any one help me on what kind of indexes do i have to create?
1. one index for each column used in "where clause"
2. one index for 8 columns and some other indexes for other used columns
3. one index for all columns
or something else etc...What's the version of your data base? what kind of database you have, DWH or OTLP? The answer might depend on the type of database as far as bitmap indexes might suit or might not depending if you are runing DWH or OLTP kind of database
Let me suppose that you are runing OLTP database and you have a where clause with 8 columns.
1) are all those where clause equalities (where col1 = and col2 =) or there are inequalities?
2) could you evaluate the most repetitive columns?
3) could you know the column that could have the best clustering factor (the column which most follow a certain order in the table)
Based on that I would suggest to create one b-tree index having 8 columns (even though that it seems for me to high) this index should follow the following points:
1) put the most repetitive column at the leading edge (and compress the index if necessary)
2) put the columns that are used in equalitity predicate first
3) put the column having the best clustering factor first
The most precise index you have the best access you could gain.
Of course that you have to know that an index access is not always good and a FULL table scan is not always bad.
Best regards
Mohamed Houri
www.hourim.wordpress.com

Effect of Cube Compression on BIA index's

What effect does cube compression have on a BIA index?
Also does SAP recommend rebuilding indexes on some periodic basis and also can we automate index deletes and rebuild processes for a specific cube using the standard process chain variants or programs?
Thank you

Compression: DB statistics and DB indexes for the InfoCubes are less relevant once you use the BI Accelerator.
In the standard case, you could even completely forgo these processes. But please note the following aspects:
Compression is still necessary for inventory InfoCubes, for InfoCubes with a significant number of cancellation requests (i.e. high compression rate), and for InfoCubes with a high number of partitions in the F-table. Note that compression requires DB statistics and DB indexes (P-index).
DB statistics and DB indexes are not used for reporting on BIA-enabled InfoCubes. However for roll-up and change run, we recommend the P-index (package) on the F-fact table.
Furthermore: up-to-date DB statistics and (some) DB indexes are necessary in the following cases:
a)data mart (for mass data extraction, BIA is not used)
b)real-time InfoProvider (with most-recent queries)
Note also that you need compressed and indexed InfoCubes with up-to-date statistics whenever you switch off the BI accelerator index.
Hope it Helps
Chetan
@CP..

INDEX CREATION

Hi There
I have the following query to be optimized:
 select avbeln aauart avkorg avtweg a~spart
 aangdt abnddt aguebg agueen a~vkgrp
 avkbur agsber akunnr aerdat a~erzet
 awaerk avbtyp aautlf avsbed a~kvgr1
 akvgr2 akvgr3 akvgr4 akvgr5 a~abrvw
 a~abdis
 into table t_vbak
 from vbak as a inner join vbuk as b on bvbeln = avbeln
 where
 ( ( a~erdat > pre_dat ) and
 ( a~erdat <= w_date ) ) and
 a~vbtyp in s_doccat and
 a~vbeln in s_ordno and
 a~vkorg in s_vkorg and
 a~vtweg in s_vtweg and
 a~spart in s_spart and
 ( ( a~lifsk in s_lifsk ) or
 ( a~lifsk = ' ' ) ) and
 b~abstk ne 'C'.
 select w~mandt
 wvbeln wposnr wmeins wmatnr wwerks wnetwr
 wkwmeng wvrkme wmatwa wcharg w~pstyv
 wposar wprodh wgrkor wantlf wkztlf wlprio
 wvstel wroute wumvkz wumvkn wabgru wuntto
 wawahr werdat werzet wfixmg wprctr wvpmat
 wvpwrk wmvgr1 wmvgr2 wmvgr3 wmvgr4 wmvgr5
 wbedae wcuobj w~mtvfp
 xetenr xwmeng xbmeng xettyp xwepos xabart
 x~edatu
 xtddat xmbdat xlddat xwadat xabruf xetart
 x~ezeit
 into table t_vbap
 from vbap as w
 inner join vbep as x on xvbeln = wvbeln and
 xposnr = wposnr and
 xmandt = wmandt
BEGIN OF Change for EUCHG352069
 for all entries in t_vbak
End of changes for EUCHG352069
 where
BEGIN OF Change for EUCHG352069
 w~vbeln in s_ordno and
 w~vbeln = t_vbak-vbeln and
 ( ( werdat > pre_dat ) and ( werdat <= w_date ) ) and
 ( ( ( erdat > pre_dat and erdat < p_syndt ) or
 ( erdat = p_syndt and erzet <= p_syntm ) ) ) and
End of changes for EUCHG352069
 w~matnr in s_matnr and
 w~pstyv in s_itmcat and
 w~lfrel in s_lfrel and
 w~abgru = ' ' and
 w~kwmeng > 0 and
 w~mtvfp in w_mtvfp and
 x~ettyp in w_ettyp and
 x~bdart in s_req_tp and
 x~plart in s_pln_tp and
 x~etart in s_etart and
 x~abart in s_abart and
 ( ( xlifsp in s_lifsp ) or ( xlifsp = ' ' ) ).
Is it advisable to create an INDEX for improving this query performance?
If yes, upon which field of which table, I can create an index?
Plz suggest!

Hi,
An index is a copy of a database table that is reduced to certain fields. This copy is always in sorted form. Sorting provides faster access to the data records of the table, for example, when using a binary search. A table has a primary index and a secondary index. The primary index consists of the key fields of the table and is automatically created in the database along with the table. Secondary Indexes are necessary if the table is frequently accessed in a way that does not take advantage of the primary index. Different indexes for the same table are distinguished from one another by a separate index name. The index name must be unique. Whether or not an index is used to access a particular table, is decided by the database system optimizer. This means that an index might improve performance only with certain database systems. You specify if the index should be used on certain database systems in the index definition. Indexes for a table are created when the table is created (provided that the table is not excluded for the database system in the index definition). If the index fields represent the primary keys of the table, that is, if they already uniquely identify each record of the table, the index is referred to as an unique index.
Procedure :
1. Choose the Indexes tab.
2. To create an index, choose New.
3. Enter a name for the index. Index names, like table names, also have a prefix, followed by an underscore.
If the name of an index was registered on the name server, it cannot be deleted.
4. To select table fields, choose New.
5. if the index is a unique index,
6. If the index is used for all databases, choose and whether it is to be created for all databases. Choose the appropriate checkboxes.
7. Choose File® Save All Metadata.
Primary index : Its the index which is automatically created for the PRIMARY KEY FIELD(S) of the table.
The primary index is always created automatically in the R/3 System. It consists of the primary key fields of the database table. This means that for each combination of fields in the index, there is a maximum of one line in the table. This kind of index is also known as UNIQUE.
Secondary index : Its created as and when required,
based upon other field(s) of the table,
on which search criteria is used in sqls.
Secondary indexes should contain columns that you use frequently in a selection, and that are as highly selective as possible. The fewer table entries that can be selected by a certain column, the higher that columns selectivity. Place the most selective fields at the beginning of the index. Your secondary index should be so selective that each index entry corresponds to at most five percent of the table entries. If this is not the case, it is not worth creating the index. You should also avoid creating indexes for fields that are not always filled, where their value is initial for most entries in the table.
Regards,
Shiva.

Do i need to drop index even when i drop data in data target

Hi ,
I am having a PC and i am dropping entire data in my data target. do i still need to add drop index to my process chain.
Can any one tell me what extactly happens if i drop data in a data targets and what happend if i drop the index? which tables it will be affecting.
Thanks,
Ram.

Since you are dropping the whole table then there is no need to keep the index, deleting indexes is necessary only if you are loading data to the cube which has already data so that performance of data load won't be affected. Every time when you have data and don't delete the index, each record need to align properly with the existing indexes which will slow down data load, but if you delete indexes then no time will be spent on aligning exact position of the data and recreating index at the end of the data load doesn't take much.
thanks.
Wond

Is it possible to created secondary indexes on ODS in Production

Hi,
Is it possible to created secondary indexes on ODS in Production System. I need to create secondary indexes on ODS but it is already in production. Hence Can I directly create secondary indexes without transportation from dev to production?

Hi,
Secondary Indexes for DSO can be transported. For the transport the DSO objects needs to be transported (R3TR ODSO <technical name>.
Additionally, secondary Indexes are necessary quite often for DSO tables, which can be transported. In few cases you need indexes on other BW tables, but they cannot be transported. Never create additional Indexes on InfoCube tables (like E- and F-Fact tables and Dimension tables)
Thanks & B.R.
Vince

Does moving data require a re-index?

I have just moved 0.5TB of data off my C: drive and onto a new drive I have installed, for the sole purpose of managing/storing photos. The new drive is drive F:
Do I need to tell Bridge of this chage and do any form of re-indexing?
In addition, do I need to let Photoshop or Lightroom know too?
Thanks for your help.

Re-indexing is necessary if you want to use Find. Re-indexing is done when visiting the folder or you can re-index by doing a search from the top of your index tree with the box checked to look an non-iindexed folders also.
You may run into some permssion problems in trying to write metadata to an external drive.
Add Drive F to your favorites list for easy access.

Repair Critical System Index

First, The actual error code is below:
SQL> create table foo (data varchar2(100));
Table created.
SQL> drop table foo;
Table dropped.
SQL> purge recyclebin
2 ;
Recyclebin purged.
SQL>
SQL> create table foo(id number primary key);
create table foo(id number primary key)
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-08102: index key not found, obj# 49, file 1, block 57390 (2)
OK, now I will explain to the best of my ability, the situation:
This error message is associated with an error in the core database product. The problem is NOT in the Apex product itself. There is a damaged Oracle database dictionary, damaged file/ index. We need a fix to repair the specific System index that is damaged. The problem we are having is that the index is a critical index. When we attempt to rebuild the damaged index we are told the damaged index is necessary for a warm restart of the database. At this point we are stuck. If we cannot repair the specific System index we will have to wipe the system and reinstall Apex. If we do this we will have to rebuild all of our tables and more. This represents weeks of work or more. So we would like to have help repairing the specific damaged critical index as opposed to wiping everything.
Specifically, we cannot create tables that have a primary key (cannot create an index). When we attempt to create a table with a primary key the message above is the message we receive. We can create a table that does not have a primary key.
History: FYI
About six weeks ago we upgraded our Apex from version 3.1 to version 3.2. The first attempt failed the second attempt succeeded. In order to get the update to work we had to allocate more file space for the tables so there would be more storage space for the tables to utilize.
We are dead in the water until we resolve this issue. Please help.

Roark wrote:
Thanks for the prompt response.
I have been told by customer support that I cannot receive paid support for free versions of Oracle software even if I otherwise have a paid license and a service agreement. I am told the service agreement will only cover paid versions of Oracle products. So, as far as I can tell I have nowhere to turn for assistance accept the help forums. If anyone knows specifically whom I should contact please, I am all ears.
I am using Oracle Apex Version 3.2How about if you export all of the schemas that contain your work, and import that into another database?

Missing Instruments in Loops

I am using Soundtrack Pro in Final Cut Studio 2. The instruments are missing from my loops. It seems the other sound effects and music cues are present (although, I've never seen a list of what, precisely is supposed to be included -- anyone know?).
I have done a search of my hard drive. I've combed through the Apple Loops folder. I've searched for "piano" and "cello" -- I've done a search of .caf files (apple loops). I am pretty convinced the instruments aren't on my hard drive.
In a search of this forum, someone spoke of "indexing"; but first gave the advice to return to "setup". That is a little vague for me --(both "indexing" and "setup") -- can anyone give me some instruction on how to use "setup" to try to add the loop files that didn't seem to make it onto my harddrive, during installation of Studio 2? And then how do I "index", if necessary? Thanks much.

Afaik, there's no instruments coming with Soundtrack Pro, only SFXs and Music Beds. The instruments are coming from Garage Band and/or Logic. However, if you didn't uninstall Garage Band, you should have them on your hard drive. If you don't see any instruments in your STP search tab, it's probably because they're not indexed. To index them, go to the Search tab, in the lower-right and click on the Setup... button. A new window will open. Once there, click on the + button and navigate to that folder: Library/Audio/Apple Loops. Select the folder "Apple Loops for Garage Band". STP should then index that folder.

Azure Search Best Practice

I have a few questions regarding best practices for implementing Azure Search, I am working on loading Titles and Usernames into Azure Search with a unique ID as key, search would be on various matching words in Titles or Usernames:
- Is there a detailed article or whitepaper that discusses best practice?
- Should we always use filter instead of search to improve response time?
- I don't know how things work under the hood, is it possible to turn off certain features; for example, scoring profiles, to improve response time?
- Can i run a load test on GET queries? How many different GET queries? Does the same query get cached?
- I have setup an indexer with a AzureSQL data source with a data change policy against a DateModified column in the table. This indexer runs every 5 minutes. I'd imagine an index is necessary on this column in the SQL table? Also, when
the indexer runs, does it check all documents in the search index against the data source?
Thanks in advance,
Ken

We don't have an end-to-end whitepaper that covers all of this yet. Here are notes on your specific questions, feel free to add more questions as details come up:
Filter vs search: in general, more selective queries (where the combination of filter + search matches less documents of the overall index) will run faster since we need to score and sort less documents. Whether you choose filter vs search: if you want
an exact boolean predicate then use a filter; if you want soft search criteria (with linguistics and such applied to it) then use search.
Scoring profiles are off by default. They only kick in if you create a scoring profile in the index explicitly and either reference it in queries or mark it as default. With no scoring profiles present, scoring of documents is based on the properties of
the search text and document text.
Yes, you can do your perf testing using GET for search requests. While the same query doesn't get cached the underlying data ends up being warmer. A good pattern is to have a bunch of keywords and have your test create different searches with 2-3 words each
(or whatever is typical in your scenario) based on those keywords.
For the SQL table question, yes, it's better if you have an index in the column you use as high-watermark so SQL doesn't need to do a table scan each time the indexer runs. The larger the table the more important this is.
This posting is provided "AS IS" with no warranties, and confers no rights.

Data Selection at infopackage

Hi BI Experts,
I have created an ABAP routine for sales document type (0doc_type) on Data Selection Tab to restrict the volume of data extracting from transactional DSO to the cube and the infoobject is part of the selection table as well.
In order to speed up the data extraction process, I also added an index (0doc-type) on the DSO. But, when I analysed the code on ST05, the database optimizer did not use the index on its SQL statement. It used the different document types specified in the ABAP routine on WHERE condition but did the TABLE FULL ACCESS /BIC/AZO_SOP_100.
Do I need create index when defining selections at the infopackage? If so, why the database optimizer did not use it?
Could you help me on this matter please?
Thanks.

Hi,
if You use or have a full Table scann = read all the data in a table than an index makes obviously no sence.
This is what the database thinks. All Data = no Index access necessary.
You try to can overcome this if You do not need all columns and build an index on the columns You need.
Than, hopefully, you get a "full index scan".
Best
Martin

Form takes long time to Launch

The from "Find Invoice Distributions" under Payables Inquiry is taking inordinate amount of time in launching/getting back for Type = Expense and any specific GL Batch Name.
Does any know what could be causing this?
Thanks,

Thanks Murali.
One thing I have been able to find out so far is that the query behind the form (for a valid combination of values) is a monster. I am trying to get apps dba help to get the SQL Advice in order to tune the query, potentially adding indexes whereever necessary.
Thanks,

Restoring Your Entire System / Time Machine

Disclaimer: Apple does not necessarily endorse any suggestions, solutions, or third-party software products that may be mentioned in the topic below. Apple encourages you to first seek a solution at Apple Support. The following links are provided as is, with no guarantee of the effectiveness or reliability of the information. Apple does not guarantee that these links will be maintained or functional at any given time. Use the information below at your own discretion.
Q: Can I restore my Macs’ entire system, and how is Time Machine involved?
A: Yes, you have several options, each involving increasing degrees of severity. In all cases Mac OS 10.5 (Leopard) will be required as previous OS X versions do not work with Time Machine backups. Naturally, all of these methods will require a significant amount of time, so plan accordingly.
*Archive & Install*
An Archive and Install is the least invasive of the 3 methods. This approach results in a fresh copy of the Mac OS system software while at the same time preserving all current user accounts on your Mac. Additionally, this method will permit Time Machine to continue backing up to the same set of backups it did prior to the installation.
Procedure:
Verify that your Mac has uninterrupted AC power.
Turn “OFF” Time Machine in the Preferences.
Insert your original Mac OS 10.5 Leopard DVD and reboot while holding down the “C” key.
At the “Welcome” screen click “Continue”.
At “Select a Destination” choose your Macs’ hard disk.
Click “Options” in the lower left.
Choose “Archive and Install”.
Ensure that “Preserve Users and Network Settings” is checked.
Click “OK”.
Back at the “Select a Destination” screen click “Continue”.
At “Install Summary” click “Install”.
Once the installation is complete, use Software Update to bring your Mac up to date.
Next, Launch Disk Utility, select your Macs’ internal disk on the left, and click “Repair Disk Permissions”.
During this initial period, Spotlight is going to re-index your Mac’ hard disk. This can take up to several of hours depending upon the volume of data. Allow it to complete before resuming Time Machine backups. You can monitor its’ progress by clicking on the Spotlight icon in the menu bar.
During the installation a new folder was created at the root level of your hard disk labeled “Previous Systems”. These are all the system files that were just replaced with fresh copies. If you are comfortable, you can delete this folder right away. Otherwise, wait a week or so incase there is something you wish to retrieve, then delete it.
Finally, turn Time Machine back “ON” in the Preferences. Time Machine should continue to backup to the same set of backups that it did prior to the Archive & Install. However, due to the extensive changes to the systems’ directories, the first backup will require a lengthy session of “Preparing...” as Time Machine performs a “deep traversal”. Allow this to proceed uninterrupted. Naturally, this first backup may be a significant one, perhaps involving several GB of data, so attempting this wirelessly will require time and patience.
*”Restore System From Backup...”*
If however, your system has experienced a serious malfunction, or a Mac OS software update has produced undesirable behavior, you can perform a full system restore from your Time Machine backups. This will result in a system virtually identical to the OS environment that existed on the date of the backup you choose to restore from. All system software, applications, and user accounts will be replaced with copies as they existed when that backup took place. The advantage here is that, generally, no further installation of 3rd-party software is required and all of your personal & system settings a preserved. The disadvantage is that because you retain your personal settings and system files, you run the risk of reintroducing any problems you experienced with the previous installation, including issues that necessitated the full restore in the first place.
Naturally, the time and date you choose to restore from can make a significant difference in the state of your resulting OS environment. Choosing the most recent date from which to restore is most desirable. If, however, one or more Time Machine backups occurred after you began experiencing issues with your system, then going farther back in time to restore from will be more advantageous. Files created or modified after you began experiencing system issues may later be recovered via Time Machines’ “time travel” interface (“Browse other Time Machine disk...”).
Unfortunately, restoring your system by this means will result in Time Machine abandoning previous backup sets and beginning a new set. So verify ahead of time that you have enough space on your backup drive for another full backup. Alternatively, once the full restore is complete, you can delete the old backups to free space on the drive. Or you can begin backups on a different hard disk while retaining the older backups until you are satisfied that the current set have accumulated enough history.
Procedure:
Verify that your Mac has uninterrupted AC power.
For faster installation, Time Capsule/AirDisk users should connect their Macs directly to their Airport device via ethernet.
Insert your original Mac OS 10.5 Leopard DVD and reboot while holding down the “C” key.
At the “Welcome” screen go up to the “Utilities” menu and select “Restore System From Backup…”.
The “Restore Your System” window reminds you that this procedure will erase all data on your Macs internal hard disk. Click “Continue”.
At “Select a Backup Source” choose your Time Machine backup disk and click “Continue”. (If the backup disk you are restoring from is a network drive then click “Connect to Remote Disk”. Next, choose the disk image from which the restore will be drawn from and click “Continue”.)
At “Select a Backup” choose from which set of backups you would like to “Restore From” in the drop-down menu. (If your backup drive only has one set, this will be grayed out.)
Next, highlight the date and Mac OS X version from which you would like to restore.
Click “Continue”.
At “Select a Destination” choose your Macs’ internal hard disk. Give the installer time while it calculates the space required for the restore. When ready click “Restore”.
Confirm your desire to erase the drive by clicking “Continue”.
Obviously, this will take quite some time. But when the installer finally announces it has finish, click “Restart”.
After logging in, immediately go to System Preferences --> Time Machine, and turn “OFF” backups, even if a backup attempted has begun.
Next, Launch Disk Utility, select your Macs’ internal disk on the left, and click “Repair Disk Permissions”.
During this initial period, Spotlight is going to re-index your Mac’ hard disk. This can take up to several of hours depending upon the volume of data. Allow it to complete before resuming Time Machine backups. You can monitor its’ progress by clicking on the Spotlight icon in the menu bar.
Finally, turn Time Machine back “ON” in the Preferences. Time Machine should continue to backup to the same set of backups that it did prior to the restore. However, due to event logs being out of sync, the first backup will require a lengthy session of “Preparing...” as Time Machine performs a “deep traversal”. Allow this to proceed uninterrupted. Additionally, the subsequent backup may be quite substantial involving many GB of data, but don’t be alarmed.
Your system has now been restored to virtually the same state it was in on the date of the backup you chose. (See this article for a list of files that TM does not restore, http://shiftedbits.org/2007/10/31/time-machine-exclusions/)
*Erase, Install, & Migrate*
A final option, reserved for last resort, is to erase the hard disk, install a fresh copy of the Mac OS, and then use Migration Assistant during the installation to restore your user accounts. This is the Mac equivalent of ‘Slash and Burn’, and really should only be necessary if you require a completely fresh start.
Procedure:
Verify that your Mac has uninterrupted AC power.
For faster migration of user data, Time Capsule/AirDisk users should connect their Macs directly to their Airport device via ethernet.
Insert your original Mac OS 10.5 Leopard DVD and reboot while holding down the “C” key.
At the “Welcome” screen click “Continue”.
Click “Agree” to the user agreement.
Select you Macs internal hard disk and click “Options”.
Select “Erase and Install”.
Select “Mac OS Extended (Journaled)” for disk format. (Avoid selecting “Case-sensitive” unless you know what you are doing.)
Click “OK”.
Click “Continue”.
At “Install Summary” click “Customize” if you would like to eliminate certain Print Drivers, Fonts, or Language packages from being installed. Otherwise, click “Install”.
If you wish, you can click “Skip” when the DVD integrity check begins.
After the initial installation completes, your Mac will restart and you will see the video introduction.
At “Welcome” select your country and then preferred keyboard.
At “Do You Already Own a Mac?” you are asked “Would you like to transfer your information?”
+from another Mac+
+from another volume on this Mac+
+from a Time Machine backup+
+Do not transfer my information now+
Select “from a Time Machine backup” and click “Continue”.
At “Select a Backup Volume” choose your Time Machine backup disk and click “Continue”. (If you are attempting the migration wirelessly, then click “Join...” and select your network first.)
At “Transfer Your Information” check all the categories you wish to migrate over. If you wish your Mac to be in the same state as your last backup, then check everything. Give the installer time to calculate sizes.
Once that is complete, the “Transfer” button will become active and you can click it.
After the install, verify the registration information, click “Connect” and you are done.
After logging in, immediately go to System Preferences --> Time Machine, and turn “OFF” backups, even if a backup attempted has begun.
Next, Launch Disk Utility, select your Macs’ internal disk on the left, and click “Repair Disk Permissions”.
Interestingly, no Spotlight indexing appears necessary, so, once the permission repair is complete, turn Time Machine back “ON” in the Preferences. Time Machine should continue to backup to the same set of backups that it did prior to the restore. However, due to event logs being out of sync, the first backup will require a lengthy session of “Preparing...” as Time Machine performs a “deep traversal”. Allow this to proceed uninterrupted. Naturally, the first backup after a significant installation like this will be quite large so don’t be alarmed.
Do you want to provide feedback on this User Contributed Tip or contribute your own? If you have achieved Level 2 status, visit the User Tips Library Contributions forum for more information.

Beardpapa wrote:
-I popped in a laptop hd I had lying around while waiting for the RMA replacement on the dead one, and did a remote restore in Snow Leopard Dvd utility using my latest TM backup (used mount_afp afp://user:pw@host/ etc etc etc in terminal).
Did you do a full system restore, per #14 in Time Machine - Frequently Asked Questions (or use the link in *User Tips* at the top of this forum)?
If so, everything should have been restored, just like they say, unless things were excluded from Time Machine (there's some very bad advice about that on the internet).
All the things you describe are in +*<home folder>/Library/Preferences.+* If you used +Migration Assistant+ instead, you may have an extra user account, that has the restored preferences.
-I also looked over at the User Tips post by Glenn Carter on Restoring Your Entire System / Time Machine.
That applies to Leopard only.

Regarding matchcode

hi to all experts,
 my question is what are match code and matchcode id . what are the differences between search help and match codes.help me very urgent.

Hi
Match codes and search helps both are same which are used as a search tool for getting the fields values from a table
Here is complete Overview of Match code with each and everypoint covered
Match Code
Matchcodes are an SAP technique to help users find information, normally in
connection with the F4 key on an input field. Information from one or more
tables can be combined and queried on using various search criteria: for
example, all companies whose name starts with "LEVI" and whose location is
"San Francisco."
How are matchcodes implemented?
Traditionally, matchcodes were implemented as redundant collections of data
in pool tables, as illustrated in the following:
Company header table Company detail table Matchcode pool table
 (TAB1) (TAB2) (M_POOL)
The advantage of the old pool matchcodes was a quick and easy search, as
long as the significant fields were entered by the end user (in this case,
company name and location). The disadvantage was that for every change in
the master tables, the system had to make redundant updates in the matchcode
tables. In addition, it was impossible to search in a pool matchcode for any
but the significant fields, i.e., it would have been very CPU intensive to
search for all companies in San Francisco.
This limitation led to the creation of matchcodes (more precisely, in SAP
terms, "matchcode IDs") for every possible query you could expect from end
users (one with company name as the significant field, one with location,
yet another with customer number, and so on). Customers with a very high
number of debitors, for example, soon found that their pool matchcode tables
grew to unmanageable sizes.
As of release 2.1, it is now possible to define so-called transparent or
view matchcodes. Transparent matchcodes are implemented by defining a
database view for the information that should be queried. Database views are
not redundant containers of data, but are merely definitions of paths to
obtaining that data. In the example:
Company header table Company detail table Database view:
 (TAB1) (TAB2) (M_VIEW)
The advantage of this new technique is that it is no longer necessary to
maintain redundant matchcode data: a view takes only a small amount of
database dictionary space. Using this technique, the query is converted by
the database to a query against the original tables, so it becomes very
important that access be supported by the proper indexes.
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<Development Class [Save[Choose Sec. Tab. "presents candidate list
(&Tablename [Choose)... [Copy
[Fields
[Yes "Save before terminating Editing?
[Enter
(&Tablename [Choose Fields #Choosefields)..
[Save [Back [Activate
"Match Code Object is now created and activated.
Or simply follow this
SE11à Search Help àZmatchcode(Give ur name with starting Z) à F5(Create)
àShort Descriptionà Selection Method(Select your table or press F4 and select)
àDialog Type(Display Values Immediately,Dialog Depends on Set of Values, Dialog with restriction.)
*For present you can select Display Values Immediately*
Next goto Search Help Parameter declare your fields from table which already you had declared above. Then select both Import & Export Paramaters Give Lpos & Spos 1. Then check(Ctrl+F2) Then activate it.
Search Help
A search help is an object of the ABAP Dictionary with which input helps (F4 helps) can be defined.
There are the following types of search helps:
· Elementary search helps implement a search path for determining the possible entries.
· Collective search helps contain several elementary search helps. A collective search help therefore provides several alternative search paths for possible entries.
· Append search helps can be used to enhance collective search helps delivered by SAP with customer-specific search paths without requiring a modification.
The three components of the input help process described by a search help are the outer interface, the online behavior and the method of data collection.
The outer interface is defined by specifying the interface parameters They define the context information to be used in the input help process and the attributes to be sent to the screen by the input help.
The search help attachment defines the field contents for parametrizing an import parameter and the fields of the input template in which the contents of the export parameters should be returned.
The dialog behavior and data collection are defined differently for elementary search helps and collective search helps.
The behavior of a search help can be made more flexible than usual with search help exits
Elementary Search
An elementary search help is a search help that describes an input help process in which it is not possible to select one of a number of search paths.
The online behavior of an elementary search help is controlled by defining the dialog type and by specifying the fields to be displayed in the dialog box for restricting values or in the dialog box for displaying the hit list (including the order in these dialog boxes). These fields must be defined as parameters of the search help.
For data collection, a database table or a view is normally defined and the possible values are selected here. This table/view is called the selection method of the search help. If the selection method is a table, a text table can also be used for collecting data if one exists. In the selection, those fields of the selection method (and possibly of the text table) which have parameters with the same names in the search help are used.
If the standard options for describing the online behavior or data collection for the search help are not sufficient, you can define its behavior more flexibly by using a search help exit
Collective Search
A collective search help describes an input help process in which the user can choose one of several alternative search paths. Each alternative search path corresponds to an elementary search help i.e. a collective search help contains several elementary search helps.
Both elementary search helps and other collective search helps can be included in a collective search help. if a collective search help contains other collective search helps, they are resolved down to the level of the elementary search helps when the input help is called.
Like an elementary search help, a collective search help has an interface of import and export parametersThe data is exchanged between the screen template and the parameters of the elementary search helps contained in it using this interface. The parameters of the search helps included in a collective search help must be assigned to the parameters of the collective search help.
During the input help process, the collective search help only controls the user's selection of the required search path. The rest of the dialog and data collection is controlled by the selected elementary search help. If selection of the required elementary search help should be made flexible (e.g. with context-specific definition of the set of available search paths), the collective search help must be assigned a search help exit
Append Search
An append search help is used for modification-free enhancement of a collective search help (that is not the original in the current system) with further search help inclusions. This technique can be used for example in special developments and country versions, and by SAP partners and customers to add further search paths to a collective search help of the standard system.
An append search help has a fixed assignment to a collective search help (its appending object). This appending object is enhanced with the append search help.
The structure of an append search help corresponds to that of a collective search help, but the append search help takes on the parameters of its appending object so that it cannot be maintained separately any longer. Furthermore, an append search help cannot be assigned a search help exit.
An append search help is automatically included in its appending object. The parameters of the two search helps having the same name are assigned to each other.
Note: You can also hide modification-free search helps from a collective search help with an append search help. You have to insert the search help to be hidden in the append search help and then hide the inclusion there. The search path(s) defined by this search help are no longer offered in the appending search help. To cancel this, remove the hidden inclusion again from the append search help.
Note: Append search helps can also be used themselves to describe an input help. They are treated like collective search helps.
Note: If the parameters of the appending object change, this change is not automatically made in the append search help. Instead, you are informed that the parameters of the append search help should be adjusted. In this case you should check if you want to change the assignments between the parameters of the append search help and the search helps included in them.
Procedure: Proceed as follows to enhance a collective search help of the standard system with your own search paths:
1. For each search path, create an elementary search help in your namespace and activate these search helps.
2. In display mode, go to the maintenance screen for the collective search help and choose Goto -> Append search helps. Create the append search help in your namespace.
3. Include the elementary search help defined in the first step in the append search help. Maintain the parameter assignments between the parameters of the append search help and the parameters of the included search helps.
4. Activate the append search help. The append search help is automatically added to your appending object. The search paths inserted in the append search help are now available in the collective search help. They appear at the end of the list of available elementary search helps.
Search Help Exit
A search help exit is a function module for making the input help process described by the search help more flexible than possible with the standard version.
This function module must have the same interface as function module F4IF_SHLP_EXIT_EXAMPLE. The search help exit may also have further optional parameters (in particular any EXPORTING parameters).
A search help exit is called at certain timepoints in the input help process.
Note: The source text and long documentation of the above-specified function module (including the long documentation about the parameters) contain information about using search help exits.
Function modules are provided in the function library for operations that are frequently executed in search help exits. The names of these function modules begin with the prefix F4UT_. These function modules can either be used directly as search help exits or used within other search help exits. You can find precise instructions for use in the long documentation for the corresponding function module.
This module has been created as an example for the interface and design of Search help exits in Search help
All the interface parameters defined here are mandatory for a function module to be used as a search help exit, because the calling program does not know which parameters are actually used internally.
A search help exit is called repeatedly in connection with several
Events during the F4 process. The relevant step of the process is passed on in the CALLCONTROL step. If the module is intended to perform only a few modifications before the step, CALLCONTROL-STEP should remain unchanged.
However, if the step is performed completely by the module, the following step must be returned in CALLCONTROL-STEP.
For more detailed information please refer to the documentation describing the concept of the search help exit.
The module must react with an immediate EXIT to all steps that it does not know or does not want to handle.
During the input help process, a number of timepoints are defined that each define the beginning of an important operation of the input help process.
If the input help process is defined with a search help having a search help exit, this search help exit is called at each of these timepoints. If required, the search help exit can also influence the process and even determine that the process should be continued at a different timepoint.
The following timepoints are defined:
1. SELONE
Call before selecting an elementary search help. The possible elementary search helps are already in SHLP_TAB. This timepoint can be used in a search help exit of a collective search help to restrict the selection possibilities for the elementary search helps.
Entries that are deleted from SHLP_TAB in this step are not offered in the elementary search help selection. If there is only one entry remaining in SHLP_TAB, the dialog box for selecting elementary search helps is skipped. You may not change the next timepoint.
The timepoint is not accessed again if another elementary search help is to be selected during the dialog.
2. PRESEL1
After selecting an elementary search help. Table INTERFACE has not yet been copied to table SELOPT at this timepoint in the definition of the search help (type SHLP_DESCR_T). This means that you can still influence the attachment of the search help to the screen here. (Table INTERFACE contains the information about how the search help parameters are related to the screen fields).
3. PRESEL
Before sending the dialog box for restricting values. This timepoint is suitable for predefining the value restriction or for completely suppressing or copying the dialog.
4. SELECT
Before selecting the values. If you do not want the default selection, you should copy this timepoint with a search help exit. DISP should be set as the next timepoint.
5. DISP
Before displaying the hit list. This timepoint is suitable for restricting the values to be displayed, e.g. depending on authorizations.
6. RETURN (usually as return value for the next timepoint)
The RETURN timepoint should be returned as the next step if a single hit was selected in a search help exit.
It can make sense to change the F4 flow at this timepoint if control of the process sequence of the Transaction should depend on the selected value (typical example: setting SET/GET parameters). However, you should note that the process will then depend on whether a value was entered manually or with an input help.
7. RETTOP
You only go to this timepoint if the input help is controlled by a collective search help. It directly follows the timepoint RETURN. The search help exit of the collective search help, however, is called at timepoint RETTOP.
8. EXIT (only for return as next timepoint)
The EXIT timepoint should be returned as the next step if the user had the opportunity to terminate the dialog within the search help exit.
9. CREATE
The CREATE timepoint is only accessed if the user selects the function "Create new values". This function is only available if field CUSTTAB of the control string CALLCONTROL was given a value not equal to SPACE earlier on.
The name of the (customizing) table to be maintained is normally entered there. The next step returned after CREATE should be SELECT so that the newly entered value can be selected and then displayed.
10. APP1, APP2, APP3
If further pushbuttons are introduced in the hit list with function module F4UT_LIST_EXIT, these timepoints are introduced. They are accessed when the user presses the corresponding pushbutton.
Note: If the F4 help is controlled by a collective search help, the search help exit of the collective search help is called at timepoints SELONE and RETTOP. (RETTOP only if the user selects a value.) At all other timepoints the search help exit of the selected elementary search help is called.
If the F4 help is controlled by an elementary search help, timepoint RETTOP is not executed. The search help exit of the elementary search help is called at timepoint SELONE (at the moment). This search help exit should not do anything at this timepoint. Any preparatory work should be carried out at timepoint PRESEL1.
Standard Search Help Exit for Changing Hit List
Functionality of F4UT_LIST_EXIT
With this module you can create another pushbutton in the hit list of an input help in addition to the standard pushbuttons. You can freely define the functionality behind this pushbutton .
To use this option, you must describe the input help process with a search help. You must write a search help exit for this search help and call this module in the search help exit at timepoint 'DISP'. Define the attributes of the pushbutton with IMPORT parameters NAME, ICON_TEXT, QUICKINFO and TEXT (see also the long documentation for these parameters).
Then assign a function code to the pushbutton in IMPORT parameter FCODE. It must have one of the following values: APP1, APP2, or APP3.
If the user presses the pushbutton defined in this way, the search help exit is called again. The function code defined previously in FCODE is passed as the timepoint.
Example
You can find an example of using this function module in the search help exit SAPBC_GLOBAL_F4_SFLIGHT_DISEDI of search help SFLIGHT_WITH_DISPLAY_AND_EDIT.
Notes· You can create up to three additional pushbuttons with the three possible function codes in the hit list by calling this module repeatedly.
· When handling the additional functions, you can use function module F4UT_LIST_EXIT_GET_INFO to get information about the status of the hit list.
· If the IMPORT parameter is set to REMOVE, the pushbutton is removed from the hit list with the function code defined by FCODE. Parameters NAME, ICON_TEXT, QUICKINFO and TEXT are meaningless in this case.
· The other parameters of this module must be defined as the parameters of the search help exit having the same name.
Functionality of F4UT_LIST_EXIT_GET_INFO
With this module you can obtain information about the status of the hit list when handling a self-defined supplementary function (see function module F4UT_LIST_EXIT) within a search help exit.
EXPORT parameter LINE contains the number of the line of the hit list where the cursor was when the function was triggered. This value is 0 if the cursor was in the column title or in the area of the constant columns removed from the list at this time.
EXPORT parameter PARAMETER contains the name of the search help parameter where the cursor was positioned when the function was triggered. Normally this means that the cursor was positioned in the corresponding column of the hit list. If the contents of the parameter, however, were removed from the list as constant value, the cursor was positioned in the corresponding line over the hit list.
EXPORT parameter MARK_TAB is only filled if the input help was called with multiple choice. In this case this parameter contains the list of line numbers that were marked in the hit list when the function was triggered.
Notes
· This module only works at timepoints APP1, APP2, APP3.
· The TABLES and CHANGING parameters of this module must be parametrized with the parameters of the search help exit having the same name.
Search Help Inclusion
The search help inclusion is the mechanism with which the alternative search paths defining the behavior can be assigned to a collective search help
In a search help inclusion, any other search help can be assigned to the including collective search help. Normally the included search help will be an elementary search help In this case the search path implemented by this search help will become one of the alternative search paths of the including search help. If the included search help is also a collective search help itself, all the elementary search helps contained in this collective search help will become alternative search paths of the including collective search help. In such a multi-level inclusion, however, you must note the following special features
Passing on the context information and returning the selected attributes on the screen is described by the assignment made between the parameters of the including search help and the interface parameters of the included search help.
The search help inclusion is a part of the definition of the including search help. A search help can be included in any number of search helps.
Note: An append search help is automatically included in its appending object. You may not include an append search help in other collective search helps.
When you include a collective search help I in a collective search help S, you should note the following features:
· When you display the search paths available in S, all the search helps contained in S are resolved to the level of the elementary search helps.
· If an elementary search help is contained more than once in a collective search help, e.g. because it is contained in more than one of the included search helps, it is offered only once in the dialog box for selecting the search path ( shadowing mechanism).
· If I has a search help exit, it is not taken into consideration in an input help process defined by S.
· Context information is transported to the input help process and from field contents from the input help process with the assignment for the parameters of I and S made during the inclusion.
· If parameter PAR of I is not an IMPORT parameter or if it was not assigned to a parameter of S in the inclusion, any existing default value of PAR is passed to all IMPORT parameters of included search helps that are linked with PAR.
· I may not contain S (or be the same as S).
Shadowing mechanism
If a collective search help S contains two search helps I and J which in turn contain a fourth search help U, a shadowing mechanism takes effect. If U is contained in I or J, it is shadowed (depending on which inclusion in S comes last). If J = U, however, J must precede I as otherwise the inclusion of J in S would be meaningless.
Default Value
A default value of the right type can be assigned to a parameter of a search help. The parameter is assigned this default value in the following cases when the input help is called:
1. If the parameter is not an IMPORT parameter.
2. If nothing is assigned to the parameter in the search help attachment with which the search help is attached to the screen field.
3. If in the search help attachment a field was assigned to the parameter that does not exist on the screen or in the flow logic (module pool) in the input help process.
4. If a search help is included in a collective search help and the parameter is not linked with any parameter of this collective search help.
There are the following options for the default values:
a) Constants enclosed in apostrophes ('). The constant must be specified in internal representation for parameters whose data type has an editing mask (e.g. date and time). For example the date 01.03.1998 must be defined as '19980301'.
b) System fields. These are fields of the DDIC structure SYST where the prefix SY- can be used instead of the prefix SYST-.
c) The ID of a GET parameter.
Set/Get parameter ID
A field can be filled with proposed values from SAP memory using a parameter ID.
Example
A user only has authorization for company code 0001. This company code is stored in memory at the beginning of a transaction under the corresponding parameter ID. Fields that refer to the data element are automatically filled with the value 001 in all subsequent screen templates.
Dependencies
A field in the screen template is only filled automatically with the value stored under the parameter ID of the data element if this was explicitly permitted in the Screen Painter.
Position in the hit list of an elementary search help
Position of the parameterin the hit list.
If the parameter should not appear in the hit list, leave this field empty. No position number may occur more than once in this column, but gaps are allowed. They do not affect the design of the hit list.
Example: An elementary search help contains parameters PAR1, PAR2, PAR3 and PAR4. Field LPos is defined as follows:
Parameter LPos
PAR1 3
PAR2 0 or ' '
PAR3 1
PAR4 7
Parameters PAR3, PAR1 und PAR4 appear in this order in the hit list.
Note: In an elementary search help, at least one parameter should appear in the hit list. The only exception to this rule is the elementary search help, in which the display of the hit list is entirely copied from a search help exit
Text table
Table A is the text table of table B if the key of A comprises the key of B and an additional language key field (field with data type LANG). Table A can therefore contain explanatory text in several languages for each key entry of B.
To link the key entries with the text, text table A must be linked with table B using a foreign key. Key fields of a text table must be selected for the type of foreign key fields.
Only one text table can be created for a table. When it is activated, the system checks whether another table already has a text foreign key for the specified table.
If a text table exists, it is used at different places in the system to show the text for the key entries in the logon language of the user automatically.
If for example table B is the check table of a field, the existing key entries of table B are displayed as possible input values when F4 is pressed. The explanatory text is also shown in the logon language of the user for each key value.
Selection method of an elementary search help
The possible entries for a field displayed in the hit list are determined at runtime by selection from the database. The selection method describes the database object from which the data is read. A database table or view can be defined as selection method.
To use a field of the selection method in the input help (as field in the dialog box for restricting values, as column in the hit list or as value returned to the screen), a parameter with the same name must be inserted in the search help.
Process On Value request
PROCESS ON VALUE-REQUEST.
Event in user-programmed help that occurs when the user presses F4 with the cursor positioned on a screen field. The modules specified in the subsequent FIELD statements are called instead of the SAP help system.
Example
FIELD XY MODULE XYZ
Module XYZ determines the value of field XY and places it in the input field on the screen.
VALUES
Definition of the valid input values:
FIELD field_name VALUES (list of values)
The list of values can define single values and/or intervals for input values that are allowed or not allowed. The values must be enclosed in apostrophes and separated with a comma.
('value') valid single value
(NOT 'value') invalid single value
(BETWEEN 'value' AND 'value') valid values in the interval
(NOT BETWEEN 'value' AND 'value') invalid values in the interval
SELECT
SQL interface
SELECT * FROM table name
 WHERE table-keyfield = inputfield
 and ....
 INTO fieldname
 WHENEVER NOT FOUND (or FOUND)
 SEND ERRORMESSAGE (or WARNING)
 messagenumber
 WITH fieldname ...
You do not have to specify a message number and var. texts (WITH). If there is an error (FOUND or NOT FOUND), a standard message is output.
If the INTO ... statement is not defined, the table entry is not read in.
Check table
Table whose key fields are used to check the foreign key fields (see Foreign Keys). Only entries that are contained in the key fields of the check table can be contained in the foreign key fields.
The check table is used to check whether the input values are valid and for the input help (F4 help).
Foreign key
A foreign key creates a link between two tables T1 and T2. Every primary key field from T1 (check table) is assigned a field from table T2 (foreign key field). The fields from T2 assigned to primary key fields are marked as foreign key fields.
The most important function of the foreign key is the support of data integrity. The foreign key fields can only accept values which appear in the primary key of the check table. During input the values of the foreign key fields can thus be checked against the entries of the assigned key fields of the check table.
Foreign keys are also the foundation for defining lock objects, maintenance views and help views. These objects contain fields from several tables. All the tables used in such an object must be linked with foreign keys.
Dialog type
The dialog type defines the dialog steps executed for an input help.
There are the following dialog types:
· Immediate value display: The hit list is displayed immediately after the input help has been called. This option is advisable if the hit list usually contains only a few entries.
· Dialog with value restriction: The dialog box for restricting values is displayed immediately. Select this option if the list of possible entries is normally very large. Restricting the set of data to be processed increases the clarity of the hit list and reduces the system load during value selection.
· Dialog depends on value set: If the hit list contains less than 100 entries, it is displayed immediately. If the hit list contains more than 100 entries, the dialog box for restricting values is displayed.
Search Help Parameter
A search help parameter is a field for controlling the behavior of a search help.
There are the following roles for search help parameters, where a parameter can have more than one role:
1.
Import parameters: These are parameters with which context information can be copied to the input help process from the input template or from the module pool of the processed screen.
2. Export parameters: These are parameters with which values can be returned to the input template from the input help process.
3. Internal parameters: These are parameters used for the input help process. Further data can be applied in the input help process using parameters that appear in the dialog box for restricting values or that have a default value. Furthermore, all the fields displayed in the hit list are internal parameters of the search help.
Import and export parameters of the search help are also called their interface parameters.
The corresponding assignment of the search help attachment or search help inclusion control the field contents with which an import parameter is parametrized and the fields of the input template in which the contents of the export parameters should be returned. However, you should note that the values are not returned beyond the limits of a subscreen or a line of a step loop or table control
The fields of the selection method are assigned to the parameters of an elementary search help by equality of name. The non-key fields of a text table may also be specified.
Types must be defined for the parameters of a search help. The parameters of elementasry search helps normally take on the attributes of the fields of the selection method having the same name. The types are defined by assigning a data element to the parameter. This field or data element also defines the behavior of the parameter at the interface for parameters that also appear in one of the dialog boxes of the input help process.
Default Value
A default value of the right type can be assigned to a parameter of a search help. The parameter is assigned this default value in the following cases when the input help is called:
1. If the parameter is not an IMPORT parameter.
2. If nothing is assigned to the parameter in the search help attachment with which the search help is attached to the screen field.
3. If in the search help attachment a field was assigned to the parameter that does not exist on the screen or in the flow logic (module pool) in the input help process.
4. If a search help is included in a collective search help and the parameter is not linked with any parameter of this collective search help.
There are the following options for the default values:
a) Constants enclosed in apostrophes ('). The constant must be specified in internal representation for parameters whose data type has an editing mask (e.g. date and time). For example the date 01.03.1998 must be defined as '19980301'.
b) System fields. These are fields of the DDIC structure SYST where the prefix SY- can be used instead of the prefix SYST-.
c) The ID of a GET parameter.
Search Help Attachments
A search help attachment is an assignment of a search help to a table, structure or data element, causing the corresponding search help to be automatically used to describe the input help process at this field when an ABAP Dictionary field is used in a screen.
You can attach a search help as follows:
1. Attach a search help to a structure or table field: The attached search help is available for all screen fields that refer to the table or structure field. There must be an assignment between the interface parameters of the search help and the fields of the table or structure for this type of attachment. In the input help process, this assignment results in a value transport between the corresponding fields (if they are known at least to the module pool of the screen) and the search help parameters. As for the foreign key definition, you can assign nothing, a constant or any other field (which is then sought in the module pool) to indivdiual search help parameters.
2. Attach a search help to a table: The assigned search help is available for all screen fields for which the table is a check table There must also be an assignment between the search help parameters and the key fields of the table for this type of assignment.
3. Attach a search help to a data element: The attached search help is available for all screen fields that refer to the data element. If the search help is attached to a data element, an export parameter of the search help must be assigned to the data element. If the user chooses a row of the hit list in the input help, the contents of this parameter are returned in the corresponding screen field. More than one value is not returned when a search help is attached to a data element.
The described attachments only take effect if the field was not yet assigned an input help in the screen definition. Such an assignment can be made with the mechanism PROCESS ON VALUE-REQUEST in the flow logic or by attaching a search help to the screen field in the attribute maintenance screen. A F4 help can also be assigned to the field in the flow logic by using VALUES or SELECT In the latter case, the input help here behaves as if the table specified under SELECT were assigned to the field as check table.
If more than one of the described mechanisms compete in defining the input help method of a screen field, the first one named will take effect. If none of the described mechanisms is available, the domain fixed values of the field will be used for the input help if necessary. If the domain of the field has no fixed values but has data type DATS or TIMS, the input helps that are assigned to these types are used for the input help. Otherwise there will be no input help available for the field.
A search help attachment always belongs to the definition of the object to which the attachment is made (structure, table or data element). It is also maintained in the maintenance transaction for this object and transported with this object.
See the links:
http://help.sap.com/saphelp_nw04/helpdata/en/cf/21ee38446011d189700000e8322d00/content.htm
http://help.sap.com/saphelp_nw04/helpdata/en/cf/21ee45446011d189700000e8322d00/content.htm
https://forums.sdn.sap.com/click.jspa?searchID=3173469&messageID=2176485
https://forums.sdn.sap.com/click.jspa?searchID=3173469&messageID=3601619
pls go through this for search help creation
http://help.sap.com/saphelp_nw2004s/helpdata/en/41/f6b237fec48c67e10000009b38f8cf/content.htm
Search Help Exits:
++

Is indexing HD necessary?

Similar Messages

Maybe you are looking for