Hi Walter

>Hi Agness,
>
>>some minor stuff like SendUpDates and AllowUpdate, -Insert, -Delete. (If you miss)
>
>??? What is up with these properties ???

Nothing important. Just don't miss one. It's always a lot of fun to see AllowUpdate set end SendUpdates not.

>
>>What I found tricky to is that a DE will open the adapters in the order of there ZORDER. This is very intuitive and easy to change. (I've skiped it and use a classfactory to add the CA's on runtime. I don't use SCX, so I can not drag - drop anyway)
>>The common problems of views on creating new records on the view like receiving the PK, problems with AutoInc remain.
>>It is tricky to write multiple tables. (Ok write is no problem but the errorhandling)
>
>We are not using the DE, so that should not be a problem for us. We are using a function to get a newkey for the keys in the cursorschema (just like we did with SQL views). BTW, I think there is an article from Calvin Hsia somewhere that describes how to get the key from the backend when its generated by the database itself.

If you found the link ... I found CAs without a DE hard to handle, since they can only be contained in a DE?

>
>>I do not use triggers, so I have no idea how this will work.
>
>>I found it uneasy to fill the properties directly, its very hard to follow. I have a method where I fill all the props via string operation. The logic is inherited from Mark McCaslands CursorAdapter VCX Builder Download#17264. I found this tool very usefull and have altered it so that it creates the DE, CA's and my factory entries from the cursors of an open datasession. This was very helpfull converting my view based apps to CA based.
>
>I See.
>
>>Update
>>
>>the tableupdate problem
>>tableupdate() returns .T. if the cursor itself is updated. This does not mean it is written to the source. You would need something like
>>

>>llx1 = TABLEUPDATE()
>>llx2 = _TALLY#0
>>

>
>I thought this only was a problem in VFP8 and resolved in VFP8SP1. No?
>
>In VFP9SP1 Tableupdate returns .F. when I try to tableupdate a change while the change was rejected by the backend.

Hm, I need to check. The code is there since VFP 8 and I never have altered it (Never touch ...)

>>As far as I see my code INSERT via TABLEUPDATE will made it even more tricky.
>
>???

There is some code here that will do special coding if the record is inserted in the CA. There must be a sense in it. Maybe VFP 8.0 as well.

>
>All in all... Are you satisfied with CA's? Are you using it in a mission critial application. Any other real life issues with it?

I'm satisfied. It is a good inheritable wrapper for data access. Most data access is with CA, this excludes runtime database generation and manipulation. Some imports run without it, but they where not viewbased as well (and they are exclusive for the database). So I do not touch without need.
What I like the most compared to views is that I can alter it without touching the database container. Much easier to maintain.

What means mission critical? My earning depends on it, is this enough?

I have never seen a problem that will not happen with views or simple SELECT SQL as well.

Agnes