Diff between update & modify

hi can anyone explain me that what is the diff between update & modify.
whether i can modify the database table with modify statement .
if yes then how?

Hi,
MODIFY:
To insert lines into a database table regardless of whether there is already a line in the table with the same primary key, use the following:
MODIFY <target> <lines>.
If the database table contains no line with the same primary key as the line to be inserted, MODIFY works like INSERT, that is, the line is added.
If the database already contains a line with the same primary key as the line to be inserted, MODIFY works like UPDATE, that is, the line is changed.
For performance reasons, you should use MODIFY only if you cannot distinguish between these two options in your ABAP program.
UPDATE:
The Open SQL statement for changing data in a database table is:
UPDATE <target> <lines>.
It allows you to change one or more lines in the database table <target>. You can only change lines in an ABAP Dictionary view if it only contains fields from one table, and its maintenance status is defined as Read and change. You may specify the database table <target> either statically or dynamically.
Regards
Sudheer

Similar Messages

Diff between update queue and delta queue

hi all
can anyone tell me wats is the diff between update queue and delta queue? wats is delta queue and update queue?
wats are the possible system generated errors and custom generated errors?
Thanks,
Shreya

Hi Shreya,
Update queue(LBWQ) comes into the picture when you choose Queued Delta for the Datasource. the data first comes to the Update queue and than goes to the Delta queue, however if you have choosen Direct Delta than the posted record will directly go to the Delta queue(RSA7).
Here is the URLS for Roberto's weblog to understand the whole LO-Extraction process.
/people/sap.user72/blog/2004/12/23/logistic-cockpit-delta-mechanism--episode-two-v3-update-when-some-problems-can-occur
/people/sap.user72/blog/2005/01/19/logistic-cockpit-delta-mechanism--episode-three-the-new-update-methods
/people/sap.user72/blog/2005/02/14/logistic-cockpit--when-you-need-more--first-option-enhance-it
/people/sap.user72/blog/2005/04/19/logistic-cockpit-a-new-deal-overshadowed-by-the-old-fashioned-lis
Hope it helps you!!!!
Regards,
Amit
Pls do not forget to assign points, if helpful.

Diff between update modes

hi guru's
i have one doubt regarding lo extraction.
we have 3 types of update modes in lo extraction. those are
queued delta
direct delta
unserialized v3 update
when will u go for each delta mode
what are the advantages and disadvantages of each delta mode
plz reply me asap.
thank u
from
v.vijay

Hi,
Update Methods > Direct Delta, Queued, Non-serialized V3 Update and Serialized V3 (obsolete)
Direct Delta
Queued Delta
Un-serialized V3 Update
Serialized V3 Update (obsolete)
Direct Delta (update mode A): With this update mode, the extraction data is transferred with each document posting directly into the BW delta queue. In doing so, each document posting with delta extraction is posted for exactly one LUW in the respective BW delta queues.
Each document posting is directly transferred into the BW delta queue
Each document posting with delta extraction leads to exactly one LUW in the respective BW delta queues
Transaction postings lead to:
1. Records in transaction tables and in update tables
2. A periodically scheduled job transfers these postings into the BW delta queue
3. This BW Delta queue is read when a delta load is executed.
Pros:
Extraction is independent of V2 update
Less monitoring overhead of update data or extraction queue
Cons:
Not suitable for environments with high number of document changes
Setup and delta initialization have to be executed successfully before document postings are resumed
V1 is more heavily burdened
With this update mode, extraction data is transferred directly to the BW delta queues every time a document is posted. In this way, each document posted with delta extraction is converted to exactly one LUW in the related BW delta queues. If you are using this method, there is no need to schedule a job at regular intervals to transfer the data to the BW delta queues. On the other hand, the number of LUWs per DataSource increases significantly in the BW delta queues because the deltas of many documents are not summarized into one LUW in the BW delta queues as was previously the case for the V3 update.
If you are using this update mode, note that you cannot post any documents during delta initialization in an application from the start of the recompilation run in the OLTP until all delta init requests have been successfully updated successfully in BW. Otherwise, data from documents posted in the meantime is irretrievably lost. The restrictions and problems described in relation to the "Serialized V3 update" do not apply to this update method.
This update method is recommended for the following general criteria:
a) A maximum of 10,000 document changes (creating, changing or deleting documents) are accrued between two delta extractions for the application in question. A (considerably) larger number of LUWs in the BW delta queue can result in terminations during extraction.
b) With a future delta initialization, you can ensure that no documents are posted from the start of the recompilation run in R/3 until all delta-init requests have been successfully posted. This applies particularly if, for example, you want to include more organizational units such as another plant or sales organization in the extraction. Stopping the posting of documents always applies to the entire client.
Queued Delta: With this update mode, the extraction data is collected for the affected application instead of being collected in an extraction queue, and can be transferred as usual with the V3 update by means of an updating collective run into the BW delta queue. In doing so, up to 10000 delta extractions of documents for an LUW are compressed for each DataSource into the BW delta queue, depending on the application.
Extraction data is collected for the affected application in an extraction queue
Collective run as usual for transferring data into the BW delta queue
Transaction postings lead to:
1. Records in transaction tables and in extraction queue
2. A periodically scheduled job transfers these postings into the BW delta queue
3. This BW Delta queue is read when a delta load is executed.
Pros:
Extraction is independent of V2 update
Suitable for environments with high number of document changes
Writing to extraction queue is within V1-update: this ensures correct serialization
Downtime is reduced to running the setup
Cons:
V1 is more heavily burdened compared to V3
Administrative overhead of extraction queue
With this update mode, the extraction data for the affected application is compiled in an extraction queue (instead of in the update data) and can be transferred to the BW delta queues by an update collective run, as previously executed during the V3 update.
Up to 10,000 delta extractions of documents to an LUW in the BW delta queues are cumulated in this way per DataSource, depending on the application.
If you use this method, it is also necessary to schedule a job to regularly transfer the data to the BW delta queues ("update collective run"). However, you should note that reports delivered using the logistics extract structures Customizing cockpit are used during this scheduling. This scheduling is carried out with the same report which is used when you use the V3 updating (RMBWV311, RMBWV312 or RMBWV313).There is no point in scheduling with the RSM13005 report for this update method since this report only processes V3 update entries. The simplest way to perform scheduling is via the "Job control" function in the logistics extract structures Customizing Cockpit. We recommend that you schedule the job hourly during normal operation - that is, after successful delta initialization.
In the case of a delta initialization, the document postings of the affected application can be included again after successful execution of the recompilation run in the OLTP (e.g OLI7BW, OLI8BW or OLI9BW), provided that you make sure that the update collective run is not started before all delta Init requests have been successfully updated in the BW.
In the posting-free phase during the recompilation run in OLTP, you should execute the update collective run once (as before) to make sure that there are no old delta extraction data remaining in the extraction queues when you resume posting of documents.
Using transaction SMQ1 and the queue names MCEX11, MCEX12 or MCEX13 you can get an overview of the data in the extraction queues.
If you want to use the functions of the logistics extract structures Customizing cockpit to make changes to the extract structures of an application (for which you selected this update method), you should make absolutely sure that there is no data in the extraction queue before executing these changes in the affected systems. This applies in particular to the transfer of changes to a production system. You can perform a check when the V3 update is already in use in the respective target system using the RMCSBWCC check report.
In the following cases, the extraction queues should never contain any data:
- Importing an R/3 Support Package
- Performing an R/3 upgrade
For an overview of the data of all extraction queues of the logistics extract structures Customizing Cockpit, use transaction LBWQ. You may also obtain this overview via the "Log queue overview" function in the logistics extract structures Customizing cockpit. Only the extraction queues that currently contain extraction data are displayed in this case.
The restrictions and problems described in relation to the "Serialized V3 update" do not apply to this update method.
This update method is recommended for the following general criteria:
a) More than 10,000 document changes (creating, changing or deleting a document) are performed each day for the application in question.
b) In future delta initializations, you must reduce the posting-free phase to executing the recompilation run in R/3. The document postings should be included again when the delta Init requests are posted in BW. Of course, the conditions described above for the update collective run must be taken into account.
Un-serialized V3 Update: With this update mode, the extraction data for the application considered is written as before into the update tables with the help of a V3 update module. They are kept there as long as the data is selected through an updating collective run and are processed. However, in contrast to the current default settings (serialized V3 update), the data in the updating collective run are thereby read without regard to sequence from the update tables and are transferred to the BW delta queue.
Extraction data for written as before into the update tables with a V3 update module
V3 collective run transfers the data to BW Delta queue
In contrast to serialized V3, the data in the updating collective run is without regard to sequence from the update tables
Transaction postings lead to:
1. Records in transaction tables and in update tables
2. A periodically scheduled job transfers these postings into the BW delta queue
3. This BW Delta queue is read when a delta load is executed.
Issues:
Only suitable for data target design for which correct sequence of changes is not important e.g. Material Movements
V2 update has to be successful
Note: Before PI Release 2002.1 the only update method available was V3 Update. As of PI 2002.1 three new update methods are available because the V3 update could lead to inconsistencies under certain circumstances. As of PI 2003.1 the old V3 update will not be supported anymore.
With this update mode, the extraction data of the application in question continues to be written to the update tables using a V3 update module and is retained there until the data is read and processed by a collective update run.
However, unlike the current default values (serialized V3 update); the data is read in the update collective run (without taking the sequence from the update tables into account) and then transferred to the BW delta queues.
The restrictions and problems described in relation to the "Serialized V3 update" do not apply to this update method since serialized data transfer is never the aim of this update method. However, you should note the following limitation of this update method:
The extraction data of a document posting, where update terminations occurred in the V2 update, can only be processed by the V3 update when the V2 update has been successfully posted.
This update method is recommended for the following general criteria:
a) Due to the design of the data targets in BW and for the particular application in question, it is irrelevant whether or not the extraction data is transferred to BW in exactly the same sequence in which the data was generated in R/3.
Serialized V3 (obsolete)
Transaction data is collected in the R/3 update tables
Data in the update tables is transferred through a periodic update process to BW Delta queue
Delta loads from BW retrieve the data from this BW Delta queue
Transaction postings lead to:
1. Records in transaction tables and in update tables
2. A periodically scheduled job transfers these postings into the BW delta queue
3. This BW Delta queue is read when a delta load is executed.
Issues:
Even though it says serialized, correct sequence of extraction data cannot be guaranteed
V2 Update errors can lead to V3 updates never to be processed
Thanks,
JituK

Diff between Update options

Hi,
Anyone explain me the what is the exact difference between the update options
like
PSA and then data targets(package by package)
Only PSA and update psa subsequently in data targets
and what is advantages and disadvantages of both and why SAP has given those two options when both functionality remain almost the same and when do we use those options meaning under which scenarios we go for it.
Thank you....

Hi Sridevi,
1. PSA and Data Targets/InfoObjects in Parallel (By Package)
A process is started to write the data from this data packet into the PSA for each data package. If the data is successfully updated in the PSA, a second parallel process is started. In this process, the transfer rules are used for the package data records, data is adopted by the communication structure, and it is finally written to the data targets. Posting of the data occurs in parallel by packet.
This method is used to update data into the PSA and the data targets with a high level of performance.
The BW system receives the data from the source system, writes it to the PSA, and starts the update immediately and in parallel into the corresponding data target.
2. PSA and Then into Data Target/InfoObject (by Package)
A process that writes the package to the PSA table is started for each data package. When the data has been successfully updated to the PSA, the same process then writes the data to the data targets. Posting of the data occurs in serial by packet.
Compared with the first processing option, you have better control over the whole data flow with a serial update of data in packages, because the BW system carries it out using only one process for each data package.
Only a certain number of processes are necessary for each data request in the BW system. This number is defined in the settings made in the maintenance of the control parameters in customizing for extractors.
3. Only PSA
Using this method, data is written to the PSA and is not updated any further.
You have the advantage of having data stored safely in BW and having the PSA, which is ideal as a persistent incoming data store for mass data as well.
The setting for the maximum number of processes in the source system can also have a positive impact on the number of processes in BW.
To further update the data automatically in the corresponding data target, wait until all the data packages have arrived and have been successfully updated in the PSA, and select Update Subsequently in Data Targets from the Processing tab page when you schedule the InfoPackage in the Scheduler.
A process that writes the package to the PSA table is started for each data package. If you then trigger further processing and the data is updated to the data targets, a process is started for the request that writes the data packages to the data targets one after the other. Posting of the data occurs in serial by request.
4. Only Data Target/InfoObject
We only recommend this method when loading from flat files or from data sources that are always available.
This is because the data is not always saved persistently into an incoming data store. This saves hard disk space, although it leads to a loss of the following: data security, an option to rebuild processes, and simulation options.
Sarhan.

Diff between the Start routine and Update rules?

Hi Gurus
Diff between the Start routine and Update rules?
Thanks in advance
Raj

Hi,
Routines are like conditions or business rules that could be applied to filter the data while entering the BW system or could be used to apply certain conditions on the info objects itself.Update rule level you manipulate your data and write your start routine.
There are 4 types of routines
1. Start routine- Could be used at two levels (transfer rule level and the Update rule level)
This Start routine written at the transfer rule level helps filter the necessary data coming from the source system.
For Example: If you decide to extract data that contain only quantity greater than 500 , then you could specify the Start rouitne to achieve this.
The Start routine at the Update rule level provides similar functionality but at this point it helps direct specific data to
different data targets. For Example: If there 3 data targets being fed from the Infosource, you may want to apply some condition to each data target, like send year 2000 data ti Data target1, 2001 to data target 2 and so on. This can be achieved by using Start routine at the Update rule level
2. Transfer Routine: This feature is available at the transfer rule levels
While performing the transfer rules operation, there are 4 features available to the developers to create business rules on top pf the Infoobjects.
1. You could do a one to one mappping of the Infoobject
2. Provide a constant value
3. Include a formula
4. Write an ABAP routine.
These 4 options refers to the transfer routine
3. Update Routine:
The limitations of just having 4 options in the transfer routine is overcome at the update rule level. There are various other
sophisticated features avaialable apart from the 4 options mentioned above. These business rules could be specified pertaining to each data target.
4. Conversion Routine: It provides functionality to do Currency and unit conversion.
Regards.

What is the diff between additive,update ,delete,reverse images

what is the diff between additive,update ,delete,reverse images with an examples.

Hi,
You can read about it here:
http://help.sap.com/saphelp_nw04/helpdata/en/84/81eb588fc211d4b2c90050da4c74dc/content.htm
Hope this helps...

Diff Between USEREXITS and CUSTOMER EXITS?

Hi all,
What is the Diff Between USEREXITS and CUSTOMER EXITS.REgards,
Kishore.

Hi,
A point in an SAP program where a customer's own program can be called.
In contrast to customer exits, user exits allow developers to access and modify program components and data objects in the standard SAP System. On upgrade, each user exit must be checked to ensure that it conforms to the standard system.
There are the following types of user exit:
User exits that use INCLUDEs -
These are customer enhancements that are called directly in the program.
User exits that use tables -
These are used and managed using Customizing.
Customer Exit
SAP creates customer exits for specific programs, screens, and menus within standard applications. These exits do not contain any functionality. Instead, the customer exits act as hooks. You can hang your own add-on functionality onto these hooks.
If you want to enhance the functionality of your SAP System, you should take advantage of the exits available in standard applications. There are two main reasons why you should use exits rather than modifying SAP software yourself. Add-ons attached to exits have the advantage that:
· They do not affect standard SAP source code
When you add new functionality to your SAP System using SAPs exits, you do not alter the source code of standard SAP programs in any way. The code and screens you create are encapsulated as separate objects. These customer objects are linked to standard applications, but exist separately from SAPs standard software package.
· They do not affect software updates
When you add new functionality to your SAP System using SAPs exits, your objects (called customer objects) must adhere to strict naming conventions. When it comes time to upgrade a to a new software release, customer objects names ensure that they will not be affected by any changes or new additions to the standard software package.
Customer exits are not available for all programs and screens found in the SAP System. You can only use customer exits if they already exist in the SAP System. You find find more information about locating applications with pre-defined exits in Locating Applications that have Exits
User Exits:
User exits allow you to add additional functions to the SAP standard.
Programs with user exits contain subroutine calls at certain points in their syntax that are identified by the prefix USEREXIT. The actual user exits are located in an include that has been assigned to a module pool. This is where customers can include any changes (enhancements) that they want to make to the system. These includes are always processed during program flow.
Advantage: In principle, customers can modify anything they want that is found in the include (tables, structures, and so forth).
Disadvantage: SAP cannot check the individual enhancements themselves which often leads to errors in the enhancement process.
Thanks and Regards,
Bharat Kumar Reddy.V

Diff between programme BBP_GET_STATUS_2 & CLEAN_REQREQ_UP in SRM7.0

Hi Experts ,
We have ECC6.04 with SRM 7.0 with Classic Scenarion
I am confused over exactly what BBP_GET_STATUS_2 do in SRM ?
I believe CLEAN_REQREQ_UP update the SC with follow on document i..e Classic PO....
and BBP_GET_STATUS_2 update the entries in BBP_DOCUMENT_TAB..but not getting exactly what is does..since if we change qty in Classic Po ..it automatically updates automatically in SC follow on document...if we Craete GR in ECC it updates automatically in SC follow on document...
Can anyone please suggest me exactly what BBP_GET_STATUS_2 do in SRM ( what is exact diff between both )?
Thanks
NAP

Hello,
Report : BBP_GET_STATUS_2
Function : This reports updates the requirement coverage requests (Shopping carts) to ensure that information on the status of backedn purchase requisitions, purchase orders, and reservations is up-to-date.
You should schedule this report to run daily in the SRM server system.
Report : CLEAN_REQREQ_UP
Function : Interval for update check.
Updating of documents (purchase requisitions, purchase orders, reservations) is executed asynchronously in the backend system. You can only process the requirement coverage request in the SRM server system further after the update has been carried out. At the interval defined by you in Customizing, the system checks whether the documents have been updated and thus if you can further process the requirement coverage request.You should schedule this report periodically.
Hope this helps.
Best Regards,
Rahul

Diff between Purchase quotation (From Draft n direct document add)

hi.
i need a small information.
Normally We an add purchase quotation...Directly..
but in my case
I implement approval Procedures at purchase quotation..
So, If any body Add it first it is going to Draft mode..
We can add purchase quotation 2 ways.
form draft to purchase quotation
direct purchase quotation.
my question is in data base is there any field
document coming from draft or direct..
plz inform me if u have any information....

hi.
Taruna Talwar
Thanks for your reply..
Still my requirement is open..
Imagine..
i have added two documents at purchase quotation.. ok.
One is from approval i have added one is from direct from the purchase quotation screen ok
now tell me..
what is the diff between these two documents,
how can u say document1 is comming from approval other one is from directly posting..
i mean in opqt is there any field like draft or direct like this
any info plz update me...

What is the diff between general gl a/c, control a/c, reconciliation a/c,

Dear All
what is the diff between general gl a/c, control a/c, reconciliation a/c & offsetting a/c.

Hi,
Normal GL Account is the account where the accounting entries are posted. GL Accounts will be broadly of two categories like Balance Sheet Accounts (Assets & Liabilities) and Profit & Loss Accounts (Income and Expenses).
Reconciliation Accounts are used where a subsidiary ledger is maintained. For example for Customers and Vendors details are maintained in separate ledgers but the control totals are posted in the Reconciliation Account which is part of GL Accounts. Similarly reconciliation accounts are maintained for Assets and Materials also. Further, in case of Customer and Vendor accounts the number of line items will be very high, hence only the totals are updated in GL and line items will be individual ledgers. Basically reconciliation account and control account are similar.
Offsetting Account: In Financial Accounting for every debit there should be a corresponding credit. So when ever any entry posted it will normally hit two GL Accounts. When we look at one line item, we will be interested where the other side of the entry is posted. This entry is the offsetting entry.
If you find this usel, please assign points.
Thanks
Murali.

Diff between sap query and abap query

diff between sap query and abap query

Hi,
ABAP query is mostly used by functional consultants.
SAP Query :
Purpose
The SAP Query application is used to create lists not already contained in the SAP standard system. It has been designed for users with little or no knowledge of the SAP programming language ABAP. SAP Query offers users a broad range of ways to define reporting programs and create different types of reports such as basic lists, statistics, and ranked lists.
Features
SAP Query's range of functions corresponds to the classical reporting functions available in the system. Requirements in this area such as list, statistic, or ranked list creation can be met using queries.
All the data required by users for their lists can be selected from any SAP table created by the customer.
To define a report, you first have to enter individual texts, such as titles, and select the fields and options which determine the report layout. Then you can edit list display in WYSIWYG mode whenever you want using drag and drop and the other toolbox functions available.
ABAP Query,:
As far as I Believe, is the use of select statements in the ABAP Programming. This needs a knowledge of Open SQL commands like Select,UPdtae, Modify etc. This has to be done only by someone who has a little bit of ABAP experience.
To sum up, SAP queries are readymade programs given by SAP, which the user can use making slight modification like the slection texts, the tables from which the data is to be retrieved and the format in which the data is to be displayed.ABAP queries become imperative when there is no such SAP query existing and also when there is a lot of customizing involved to use a SAP Query directly
use either SQ02 ans SQ01
or SQVI tr code
for more information please go thru this url:
http://www.thespot4sap.com/Articles/SAP_ABAP_Queries_Create_The_Query.asp
http://goldenink.com/abap/sap_query.html
Please check this PDF document (starting page 352) perhaps it will help u.
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/BCSRVQUE/BCSRVQUE.pdf
check the below link will be helpful for u
Tutorial on SQVI
once you create query system generates a report starting with AQZZ/SAPQUERY/ABAGENCY2======= assing this report to tr code for the same
regards,
vasavi.
reward if it is helpful.

Main diff between call transaction and session method

hi frnds.
my friend went for an interview they asked her whts the diff between call tran adn session?
she told more thn one transaction we can call for an session she told itseems. but he told tht by cal tran also u cn call more thn one tran it seems... so please canu help me out regarding this question? how we hve to tell in interview?
in advance thanks....

Hi
Batch Input and CALL TRANSACTION are both data transfer methods. Batch Input usually are used to transfer large amount of data. For example you are implementing a new SAP project, and of course you will need some data transfer from legacy system to SAP system. If there is no standard batch input program, direct input program, you would need to write your own data transfer program and it is going to be batch input program. CALL TRANSACTION methods is real-time method, whenever you run the program CALL TRANSACTION can be triggered. CALL TRANSACTION is used especially for integration actions between two SAP systems or between different modules. Users sometimes wish to do something like that click a button or an item then SAP would inserts or changes data automatically. Here CALL TRANSACTION should be considered. You use CALL TRANSACTION and you do everything automatically, collect necessary data, call transaction and so do database update. If any error occurs, show the user them.
Batch Input
With the Batch Input method, an ABAP program reads the external data that is to be entered in the R/3 System and stores the data in a batch input session. The session records the actions that are required to transfer data into the system using normal SAP transactions.
When the program has generated the session, you can run the session to execute the SAP transactions in it. You can explicitly start and monitor a session with the batch input management function (by choosing System - Services - Batch Input), or have the session run in the background processing session.
It offers management of sessions, support for playing back and correcting sessions that contain errors, and detailed logging. Your program prepares the data and stores it in a batch input session. A session is a collection of transaction data for one or more transactions. Batch input sessions are maintained by the system in the batch input queue. You can process batch input sessions in the background processing system.
Your program must open a session in the queue before transferring data to it, and must close it again afterwards. All of these operations are performed by making function modules calls from the ABAP program.
The most important aspects of the session interface are:
Asynchronous processing
Transfer data for multiple transactions
Synchronous database update. During processing, no transaction is started until the previous transaction has been written to the database.
A batch input processing log is generated for each session
Sessions cannot be generated in parallel. The batch input program must not open a session until it has closed the preceding session.
CALL TRANSACTION
In the second method, your program uses the ABAP statement CALL TRANSACTION USING to run an SAP transaction. External data doesnt have to be deposited in a session for later processing. Instead, the entire batch input process takes place inline in your program. With CALL TRANSACTION USING, the system process the data more quickly than with batch input sessions. Unlike batch input sessions, CALL TRANSACTION USING does not automatically support interactive correction or logging functions.
Your program prepares the data and then calls the corresponding transaction that is then processed immediately.
The most important features of CALL TRANSACTION USING are:
Synchronous processing
Transfer of data from an individual transaction each time the statement CALL TRANSACTION USING is called
You can update the database both synchronously and asynchronously. The program specifies the update type.
Separate LUW (Logical Units of Work) for the transaction. The system executes a database commit immediately before and after the CALL TRANSACTION USING statement.
No batch input processing log

What's the difference between masters, modified & original in iPhoto?

Could someone please explain the difference between masters, modified and originals in the iPhoto Library? I am trying to make a backup online and want to cut out unnecessary transfer of data.
I've recently installed an online backup service (with LiveDrive) and my MacBook Pro is slowly uploading over 50gb of data. This is frustratingly slow and I suspect unnecessary. I've instructed the program to not back up thumbnails and previews, but don't know whether to limit the backup to, say, masters. What are they?
I've read quite a number of discussions from which I've learnt a lot - for example that iPhoto library is where the files are kept containg the data for photos, and that iPhoto is an ap that draws on those files. I can guess the difference between files containing original data and those with modified. But what are masters? And could I safely restrict the backup to masters?
Please advise me!
John

Here's what I do:
My Library lives on my iMac. It’s Backed up to two external hard disks every day. These disks are permanently attached to the iMac. These back ups run automatically. One is done by Time Machine, one is a bootable back up done by SuperDuper
It’s also backed up to a portable hard disk when ever new photos are added. This hard disk lives in my car. For security, this disk is password protected.
I have a second off-site back up at a relative’s house across town. That’s updated every 3 or 4 months.
My Photos are backed up online. There are many options: Flickr, Picasa, SmugMug etc. However, check the terms of your account carefully. While most sites have free uploading, you will often find that these uploads are limited in terms of the file size or the bandwidth you can use per month. For access that allows you to upload full size pics with no restrictions you may need to pay. Only some will upload and store Raws etc.
The added advantage of using a site like SmugMug / Flickr is that the images are available to share and can be viewed from any computer. And for the ones you don't others to see, many of these sites also have password protection. It's for reasons like these I chose SmugMug, but YMMV
Every couple of months I test the back ups to make sure they are working correctly. It’s very easy to mis-configure a back up application, and the only way to protect against that is to do a trial restore.
So, if you look at my set up:
I have daily protection against the Mac going down, I have a recent version in my car, and a 3 month version across town. That's all protection of my entire library - imges, database and so on.
Then online, I have my photos, so that at least I have them if the Mac crashes, the house burns down, the car is stolen and my sister's house collapses...

Diff between issession and issystem

All,
Wanted to understand ..When we need to restart he DB servers in case if we change some parameters ...?
What is the diff between issession and issystem modifiable clauses ...?
Thanks

Got the answer

Diff between all views

hi all,
can any body tell me the diff between all views
projection view ,database view,maintance view,help view
plz tell me the difference with a example
hope for positive reponse

Maintenance views offer easy ways to maintain complex application objects.
Data distributed on several tables often forms a logical unit, for example an application object, for the user. You want to be able to display, modify and create the data of such an application object together. Normally the user is not interested in the technical implementation of the application object, that is in the distribution of the data on several tables.
A maintenance view permits you to maintain the data of an application object together. The data is automatically distributed in the underlying database tables. The maintenance status determines which accesses to the data of the underlying tables are possible with the maintenance view.
database view
Data about an application object is often distributed on several database tables. A database view provides an application-specific view on such distributed data.
Database views are defined in the ABAP Dictionary. A database view is automatically created in the underlying database when it is activated.
Application programs can access the data of a database view using the database interface. You can access the data in ABAP programs with both OPEN SQL and NATIVE SQL. However, the data is actually selected in the database. Since the join operation is executed in the database in this case, you can minimize the number of database accesses in this way. Database views implement an inner join
projection view
Projection views are used to hide fields of a table. This can minimize interfaces; for example when you access the database, you only read and write the field contents actually needed.
A projection view contains exactly one table. You cannot define selection conditions for projection views.
There is no corresponding object in the database for a projection view. The R/3 System maps the access to a projection view to the corresponding access to its base table. You can also access pooled tables and cluster tables with a projection view.
help views
Help views are used if a view with an outer join is needed as selection method in a search help.
You have to create a help view if a view with outer join is needed as selection method of a search help.
The selection method of a search help is either a table or a view. If you have to select data from several tables for the search help, you should generally use a database view as selection method. However, a database view always implements an inner join. If you need a view with outer join for the data selection, you have to use a help view as selection method.

Diff between update & modify

Similar Messages

Maybe you are looking for