Monday, September 6, 2010

writing jobs


Also writing ad-hoc jobs to correct data or straighten faulty situations? These one-time jobs that will be used for weeks, months or even years? Put a stop to these jobs: refuse to write them!
Instead make decent and expandable user-proof solutions based on runBaseBatch for example. Put a little dialog on, make it configurable, useable by non-technical-skilled users, ....

Why going to all that trouble? We all know it is not just a one-time job ... it will start a life after you created it. Give  your coding an honourable life, even the lousy jobs!

If you do stick to writing a job, at least make it a respectable one:
- don't put hardcoded variables in there, use a dialog (which is as simple as in the code example below),
- add an info to inform what's been done (how many records, how much time, ...)
- use try-catch when appropriate
- give your variables meaningfull names,
- some comment never hurts,
- ...

static void LAX_Job_Dialog(Args _args)
    Dialog          dialog;
    DialogField     dlgCustName;
    CustName        custName;
    CustTable       custTable;
    Counter         cnt;
    dialog = new Dialog('find customer named ...');
    dlgCustName = dialog.addField(typeId(CustName));

    if (
        custName = dlgCustName.value();
        if (custName)
            // search for any customer with the entered value in the name
            custName = '*' + custName + '*';
            while select accountNum, Name
                from custTable
                where custTable.Name like custName
                info(strFmt('%1 - %2', custTable.AccountNum, custTable.Name));
        info(strFmt('%1 customers found', cnt));

P.S. Jobs are executed on the client-side. Drag your job into a menu-item, set the 'runon' property to 'server' and its speed will most likely boost. Especially jobs with while select loops in them.

No comments:

Post a Comment