In the championship’s rules there were 4 important restrictions that have been applied:

• The minimal volume of the transaction - 0.1 lot
• Step-interval of volume changing - 0.1 lot
  
• The maximal volume of the transaction - 5 lots
  
• The maximal total amount of the open and pending orders - 3
  

These restrictions are configured on the trading server settings on which the Championship will be held. The trading server will not pass these trading operations that would breach the above Championship restrictions. Thus, information of such violations will be stored in the server’s log-file. Expert advisors that breach the above mentioned restrictions on a regular basis can be disqualified and removed from participation in the Championship.

All these restrictions are related to the function OrderSend(). It is necessary to trace these restrictions and not to allow falsely call of this function. When the wrong value of volume is inputted (lots less than minimal value, or more than the maximal value, or an error of granulation) the function will return as an error. GetLastError() will return a code 131 (ERR_INVALID_TRADE_VOLUME).

In most cases, a certain function for order volume calculation is used, that based on money management strategy. Usually in calculations used, the following are considered: balance, equity, free margin, and leverage and risk percent. This function may look as follows:

//--- extern variables
extern double ExtMaximumRisk=0.05;             // 5% by default
 
//--- calculate current volume
double CalculateVolume()
  {
   double lot_min =MarketInfo(Symbol(),MODE_MINLOT);
   double lot_max =MarketInfo(Symbol(),MODE_MAXLOT);
   double lot_step=MarketInfo(Symbol(),MODE_LOTSTEP);
   double contract=MarketInfo(Symbol(),MODE_LOTSIZE);
   double vol;
//--- check data
   if(lot_min<0 || lot_max<=0.0 || lot_step<=0.0) 
     {
      Print("CalculateVolume: invalid MarketInfo() results [",lot_min,",",lot_max,",",lot_step,"]");
      return(0);
     }
   if(AccountLeverage()<=0)
     {
      Print("CalculateVolume: invalid AccountLeverage() [",AccountLeverage(),"]");
      return(0);
     }
//--- basic formula
   vol=NormalizeDouble(AccountFreeMargin()*ExtMaximumRisk*AccountLeverage()/contract,2);
//--- additional calculation
//   ...
//--- check min, max and step
   vol=NormalizeDouble(vol/lot_step,0)*lot_step;
   if(vol<lot_min) vol=lot_min;
   if(vol>lot_max) vol=lot_max;
//---
   return(vol);
  }

It is not recommended to store important market characteristics in the function init(), it is better to request market conditions in a place of use and it is obligatory to check them on empty/zero values. Otherwise, an attempt of starting a script on inactive accounts may result in receiving the wrong values. For example, in the function above it is possible to receive fatal "Zero divide" both at lot_step=0, and at AccountLeverage()=0.

Now we shall discuss the total of open and pending orders. This value is returned by function OrdersTotal(). In case of restriction error of total open and pending orders the function OrderSend() will end with error, and the value returned by function GetLastError() will be equal to 148 (ERR_TRADE_TOO_MANY_ORDERS). To avoid this error, it is enough to check the total active orders before any operation SendOrder():

//--- extern variables
int ExtMaxOrders=3;
 
  ...
//--- check before SendOrder
  if(OrdersTotal() >= ExtMaxOrders) return(...);
//--- send order 
  int ticket=OrderSend(...);
  ...

There are very serious dangers both to the trader and to the trading server by means of "scripts-killers" which without the realized control send set of trading transactions into the server. This often happens in the form of cyclic attempts to push the incorrect request into server over and over again. We shall examine some cases:

• Rough neglect of the control over errors with cycling
  

  For example, the trader is confident that there are no errors and writes such a source code. As well as considering the market environment updates, knowing that the market is changing, but forgets the weekends (there is no trade), market limits (stop levels) are dynamically vary (especially on news) and other reasons. As a result, such source code leads to the blocking of the account by the broker.

  while(OrderSend(...)<1) RefreshRates();

• Absence of the control for OrderSelect - asynchronous processes in operation
  

  Usually the trader perceives the program as one-valued and unique. But in reality within the trading account occurs a set of asynchronous changes directly during work of the expert. Orders are modified, added and deleted. If the trader does not control the result of each call of function OrderSelect(), during this time the expert will operate with incorrect (zero) data and will make an incorrect action.

• Omission of market environment updating via function RefreshRates()
  

  This error happens when a series of consecutive trading operations or reiteration of the transaction after the previous failure. The error is not understood, as the code sometimes works and sometimes not. Some examples:

  //--- close all positions
  for(int i=OrdersTotal()-1; i >= 0; i--)
    {
     if(OrderSelect(i,SELECT_BY_POS,MODE_TRADES)==false) break;
     switch(OrderType())
       {
        case OP_BUY:  OrderClose(...); break;
        case OP_SELL: OrderClose(...); break;
       }
    }
   
  if(SendOrder(...) < 1)
    {
     if(GetLastError()!=ERR_REQUOTE) return(false);
     //--- lets try again!
     if(SendOrder(...) < 1) return(false);
    }

• Griders: mass pending orders with mass cancellings
  

  Unfortunately, some traders are assured that there is not a problem. Hundreds and thousands of exposed, modified and then cancelled pending orders during a small time frame is a real problem, which frequently leads to the blocking of the account. Without dependence that in this occasion the trader thinks.
  
  

In the section of documentation "MQL4 Reference - Trading functions - Execution errors" the recommendations on trading errors processing are published.