CacheRDD

Yes. RDDADS, DBFCDX and CachéRDD all are tested to be working together. However, you must take care of RDD specific functions which may be callled at the execution of the application. For example, AdsGetServerDate() might be a candidate to guard it against which RDD is in operation at the time when this function is called.

Yes. You need to guard all your database updates like: CachéBeginTransaction() BEGIN SEQUENCE // Your database updation code // ... RECOVER // In the event of any error CachéRollBackTransaction() END SEQUENCE CachéEndTransaction() In the event of system failure, CachéRollBackTransaction() will ever be executed in case application does not reach to the line CachéEndTransaction().

Yes. But partially. Still it is not clear from the documentation in what circumstances it is supported and under what circumstances it is not. It will be reported on this web-site when it will be completely ready, but for the time being avoid using nested transaction control, though you are open to experiment.

1. Do not use UDF's. Only Clipper functions pertaining to index-expressions are supported. ...

2. Do not put two fields under one expression, i.e., Upper( L_Name + F_Name ) will fail and a r/t error will be raised. "Upper( L_Name, 20 ) + Upper( F_Name, 20 )" be used instead. ...

3. Index key length is NOT limited to any amount.

No. Not at this point of time. Only valid Clipper functions which are usable with indexes are supported. One more point to remember is all parameters associated with a function has to be passed, i.e., Substr( L_Name, 3 ) is not a valid expression, instead, Substr( L_Name,3,7 ) is valid. Though in the case of inadequete parameters indexes will still be created but do not expect their correct behavior.

Yes. And these are true server-side indexes. The following are the valid examples: L_Name + F_Name + Designation Code + Dtos( D_Birth ) + Upper( L_Name, 20 ) + Substr( Status, 2, 4 ) + Str( Salary, 10, 2 )

Yes. But only the FOR condition is supported. As CachéRDD supports only one order bag containing unlimited tags, WHILE condition is not supported at all which creates the temprary indexes which are erased when not needed. CachéRDD handles only persistant indexes. FOR condition has to confirm to index rules set for CachéRDD index expressions explained elsewhere. INDEX ON Name TAG 'Name' FOR LEFT( Name, 1 ) == 'A'

No. CachéRDD is designed to be co-existant with external non-RDD processes/applications which do not know anything about the deleted status of a record and how to maintain it. For that matter no RDBMS is designed like this. It was possible to simulate this feature but then you have been at loss not to mixup RDD application with many-many available tools to harness the power of ODBC, JDBC, .NET etc. Once a record is deleted is gone for ever. However, CacheRDD supports management of deleted records in some other way documented elsewhere on this portal.

Once RLock() is successful, no other process, be it RDD oriented or non-RDD oriented, can update thr RLock()d record. It behaves just like other xbase dialect offers. You can be sure that only the instance which has obtained record lock with RLock() can update that record.