'Batch Input' Versus 'Direct Run'
If you can wait, 'Direct Run' will usually be the best choice. This is not only because of the internal audit trail that Transact maintains of files that have been run, but, primarily, because it is so much easier to identify, separate, fix and re-run failed records with Transact than it is with Batch Input. In all cases, we would always recommend running at least a percentage of your transactions using 'Direct Run', so that you get an appreciation of the quality of your data before committing larger volumes to the batch input queue.
For larger volumes, batch input may be the best choice. The problem with using large volumes through Direct Run is that it runs on your PC and prevents you from using Transact for anything else whilst running the file. However, you could split your data into smaller, more practical, files that can be more comfortably put through a Direct Run.
Being precise about what constitutes a 'large volume' is difficult as the time taken to run an SAP transaction is highly dependent upon the number of screens in the transaction – this can have a greater impact than the number of records to be run to the overall run-time.
In general, we would recommend not using Direct Run for a single data file containing more than 2,000 to 3,000 records. This is not because it can’t handle more, but because it is usually more convenient to put larger runs on a batch input queue and let them run.
If you have 10,000 records, or so, we would recommend splitting this into 3 or 4 smaller file sizes and doing several direct runs. Alternatively, you could do a single batch input for the whole 10,000. The choice is yours, but keep in mind the advantages with using direct run - you should really only choose batch input if you are very confident that your data will run okay.
Even using batch input, for very large data volumes it is still more practical to split your files. Just from the perspective of managing problems and monitoring, we would recommend putting no more than 20,000 to 30,000 records through a single data file/batch input session. Additionally, for example, if you have 100,000 records to load, splitting into blocks of 20,000 also means that you can run 5 batch inputs in parallel – getting your data in faster.