&NUM1 = Mod(&c,1000);
If IsInt(&Num1)=TrueCommitWork();elseEnd-if;place ur loops and other logic/syntax appropriately, but basically using Mod and INt every 1000 records, the program will issue a commit.

Its always good to differ :), however in this case a dynamic and varying counter level of commit is required. Complex programs where one has to vary the count dynamically and change counter would behave in a static sense.

There is no adverse affect of using the Commit Work function to direct that. If there are cases of the CommitWork having side effects, I would surely like to know.

Current case I think phani has asked for 1000 rows but my suggestion was purely based out if the count needs to be varied. Ideally a program with 10,000 rows to be updated/inserted. Shouldn't have a performance issue and 1000 counter seems to small for 10 commits to be issued.

Enabled only when a step contains one of the following actions: Do While, Do Select, or Do Until. Enter the numeric frequency with which Application Engine should commit. If non-zero, Application Engine commits every N iterations, and then again after the last iteration.

So if you have a step with one of the above "Do" Actions followed by PeopleCode or SQL action updating the database, it will commit based on the value you provide for frequency.

Now I am curious. If you are using FL and AE . You might be using delivered peoplecode to import data in a temp table . In this case , step commit frequency would not be helpful for you . Process is completely controlled by people code action .

In case you want to do some validation in data, then I think step commit frequency property will work for you .

If you just want to use commit for row data, I would advise to use explicit commit ( as discussed by gururaj ) otherwise for latter case , please use step commit frequency .