Hijack!!!Please start a new thread for your issue and don't hijack any threads
created long before for a completely different issue.

You can get out of range errors on %LOOKUP if startindex < 1, startindex >
%ELEM, numelems < 0, or startindex and numelems together would search past the
end of the array.

It's subtle, but yes, this is OK.

Reference for %SUBARR clearly states that number of elements must be >= 1 (and
<= end of array after applying start index).

For your %LOOKUP, you're telling it to search an array of zero elements (an
empty set), which will always return 0 for not found.

I have tested %LOOKUP and sorta.

%LOOKUP(fiel:arry:1:wlen)
SORTA %SUBARR(arry:1:wLen)

when 'wlen = 0',%LOOKUP returns 0;but sorta report error message like 'An 
array index is out of range'.

does it right?

"(the one retrieved with the Chain is not updated)"

Not sure if I understand your meaning in the above statement correctly, but 
the record you just chained is always the one that is updated - otherwise you 
get an attempt to update without prior read or chain.  Once a record has been 
read you may change any field value in the record, including key fields in the 
access path used or key fields in other access paths.  When you issue the 
update operation that is the record placed back in the file from exactly the 
same place you got it from.  Thus:

You Chain/Read a file for Key = 100, relative record of 1257.
You change Key to be 142.
You Update the record, the record replaced is relative record 1257, the access 
path will be modified removing the old Key/RRN and inserting the new Key/RRN 
combination.

Now in the above example, if the access path is unique and Key value 142 
already exists, then the update operation will fail and relative record 1257 
will remain with prior to Chain/Read values.

Maybe I'm late to the party but chances are that the Update and not the Write is
the one that is causing de duplicate key condition.
If Var1, Var3 or Var5 happen to be keys (one or more of them) and they are
changed, a new key entry is created (the one retrieved with the Chain is not
updated), and if the new key already exists in the tree and Unique had been
specified for the file, then the update fails.

That record format vs file name thing on opcodes always pissed me off.
I'm glad that we now have the ability to completely ignore the record format
name except on LIKEREC (which sucks!).

Also when using qualified i/o bifs like %found(armast), care is required when
copy/pasting code then changing record format and file names, get 'em all.

One more caution (mentioned in passing by Ringer, way below): CHAIN isn't the
only thing that sets %FOUND. %FOUND without a parameter could refer to CHAIN,
DELETE, SETGT, SETLL, CHECK, CHECKR, SCAN, or %LOOKUP. Note that half of these
are not file operations. So, for example, if you had:

Chain key table;
x = %LOOKUP(a:b);
If %FOUND;
  // do something
EndIf;

That something will be conditioned on the lookup, not the chain.

tnx man

%found() refers to the last operation that triggers found (in your case Chain 
c).
%found(myfile) always refers to the last operation that triggers found on 
myfile only.  Also any programmer coming behind you knows implicitely what 
found you're looking for, and they're not going to break anything by placing 
code that triggers an alternate %found between your chain and your %found.

%found referring to records in C.

In line with this. If you chain 3 files.

chain a
chain b
chain c

if %found()

Is %found referring to records in C?

thanks

If you set var1,3,5 are fields in file then you gets duplicate records error
because you:
1) Chain key table // no found for example
2) Change record var1,3,5
3) write ---> error this record already exists!!!.

%status may or may not be set unless the (e) operation extender is being used.

> Here I am getting duplicate record error...

Let's be sure. What is that value of %status? 01021 = duplicate key.

Chris

how is it possible neilrh?

Well if Var1, Var3 or Var5 happen to be Key or used as a Key, it's entirely 
possible to break a unique condition.

If you are getting a duplicate record something has to have a UNIQUE key.
Otherwise the system won't care. Do a DSPDBR on the PF, make sure you check the
PF and ALL LF to make sure.

Funny thing is that table&its indexes have no UNIQUE constraints :)

Definitely include the file name in the %Found(Table) 
Also the duplicate key may not be on the file you are chaining to. It will be on
either the PF or a LF whichever one that has a UNIQUE. 

My code was actually

Chain key table;
var1 = var2;
var3 = var4;
var5 = var6;
If %Found();
 Update Rec;
Else:
 Write Rec
EndIf;

Here I am getting duplicate record error :)...no idea how this could happen, so
i suspected my code. 

Sometimes i JUST don't have the patience to find things out.I have read in some
posts the newer kids want everything laid in front of them, I am one of them.

"Chain key table;
var1 = var2;
var3 = var4;
var5 = var6;
If %Found(TABLE);
          ^^^^^
 No issues;
EndIf;"

Fixed.  Less issues if you qualify the %found.

I do this in many places when validating against multiple files:

chain (product) prodMast;
chain (product) prodSupp;
chain (product) prodBuyr;

if not %found(prodMast);
  //  user entered crap
elseif not %found(prodSupp);
  //  there's a problem
elseif prodSupp.Field = some_excluded_value;
  //  can't do that with this product
elseif not %found(prodBuyr);
  //  user not authorised to that product
else;
  //  we're all good here
endif;


In fact I think that's my #2 rule after Bob's main rule...
1) Qualify your field types.
2) Qualify your I/O built in functions.

No but the *next* programmer could mess it up by inserting a CHAIN/Lookup/etc in
there. Do this to future proof it.

If %Found(table);

depends is var2, var4 and var6 coming from the table you are chaining to? if so
then var2, var4, var6 will contain the values from the last successful chain. 
IMO that's a sucky way to do it, check %FOUND directly *after* the
chain...always but then again that's JMO

A program 

Chain key table;
var1 = var2;
var3 = var4;
var5 = var6;
If %Found();
 No issues;
EndIf;

Any issues with this code since I am not checking for %Found immediately after
Chain?