Again, the child record is updated if it's record pointer is moved or TABLEUPDATE issued on it. So unless I'm missing something, then you are doing it correctly.
>And if Row IS used for all related tables, and the parent record is saved via TABLEUPDATE() or the pointer in the parent table is moved - is the child records saved? I now execute a TABLEUPDATE() on each table - parent and all child.

I wouldn't use the "parent-child" terminology for the situation you describe of a one-to-one relationship. Personally, I would *probably* use row buffering. I understand (I think) Jim Booth's objections to it, but I am unconvinced of the drastic nature of it. I suppose that is simply one of the points to evaluated when choosing row vs. table buffering--what's the effect of pointer changing in row buffering on the system/user? So, you might prefer to use table buffering...Especially since there doesn't seem to be any performance penalty to be paid.

Another twist: Again, I should never say "never" but if a table has more than 255 fields, does the data design in fact really need to be rethought? Are you sure there isn't a parent concept in there with related information? For example, you might have a staff table, a certification table, a cross ref of which staff has which certification, a table of skills, a cross-reference table of who has what skills. You can even do this for addresses, phone numbers, preferences. That would be a normalized design and while it might seem like overkill now, it will save you headaches in the long run.

I don't mean to presume, if I'm telling you stuff you already know! :)


>Hello Nancy,
>
>Thanks for expanding on your response. Actually my application is not that complex. I'm working on several apps: an insurance verification which has a parent record(the insured business) and children(various policies - fire, theft, flood, etc.) and a History table. Typical - Row buffering for the parent, Table buffering for the child table/s.
>
>But the app that dosen't seem to be addressed in my research is a simple tracking/scheduling app for home health care workers. There are parent/child records because there is just too much data to for one table: name/address/etc. in the parent and skills(RN, LPN, HHA), dates for CPR, Physical etc. in a child, area, location, preferences (pets/smoking, etc.) in another child record. A ONE TO ONE - NOT ONE TO MANY. Hence maybe Row buffering for all related tables is more appropriate?
>
>And if Row IS used for all related tables, and the parent record is saved via TABLEUPDATE() or the pointer in the parent table is moved - is the child records saved? I now execute a TABLEUPDATE() on each table - parent and all child.