Hi David,

By the way I contacted one of the authors and he already changed the version check, but still amry was not even roughly tested on vfp9.

 IF m.lcVersion < 'Visual FoxPro 06.'
   lcVfpExe = 'VFP.EXE'
 ELSE
   lcVfpExe = 'VFP' + LTRIM(STR(VAL(SUBSTR( m.lcVersion, ;
     LEN( 'Visual FoxPro ' ) + 1 )))) + '.EXE'
 ENDIF

He also gave me a fix of a bug that sometimes happens during cascading updates. But updating PKs and doing cascading updates of FKs is nonsense, so that bug doesn't bother me. If you're interested:

_RI_Update() in StdCode.prg must be changed:

* old
..
SET ORDER TO (m.tcKeyName)
SEEK m.tuKeyValue
SCAN NOOPTIMIZE REST WHILE ;
EVALUATE(KEY()) == m.tuKeyValue AND NOT m.llError
...
ENDSCAN
..

* new
..
SET ORDER TO (m.tcKeyName)
DO WHILE SEEK(m.tuKeyValue) AND NOT m.llError
...
ENDDO
..

But I wonder if that works, because SEEK() always finds the first record matching the seeked expression... I'd let that untouched!

_handleri seems to be a system variable amri defines and needs, which is not defined in your case. Maybe the structure of builder.dbf has changed? I rememeber _handleri from the install method of the setup form in conjunction with builder.dbf.

Amri works just fine with vfp7 and vfp8. Just wait a little, then it will be perfectly stable running on vfp9.

Have a nice weekend!

Bye, Olaf.