Hi Walter,

some minor stuff like SendUpDates and AllowUpdate, -Insert, -Delete. (If you miss)

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)

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.

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

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



Agnes
>Hi Agnes,
>
>Thanks for your reply
>
>>I use CA's for all data access and it works pretty well. One has to come around of some problems (for example return value of tableupdate) but I like the flexibility compared with views, mostly the independence from the database container. It's a native place for all datahandling. We use it it with our metadata for a long time now.
>
>What is up with the return value of Tableupdate() I've read upon some problem with the initial release in VFP8 that had to do with update conflicts, but I did assume that one was resolved in SP1. no ?
>
>What other pitfalls do I need to watch out for?