The mountain is, indeed, there ... but it only has to be climbed once.

You're talking n-tier here... ease has nothing to do with it. <g> Throw your

boots away after the first climb and make or buy a class that handles these

disconnected cursor retrieving/updating/deleting tasks for you. Personally,

I choose "make it" but that's just the way I am.

Yes. You should manage the updates manually and you *should* have a UID

(Unique ID) for each record. This allows you to go straight to the record(s)

you need without having to depend on recno(). Depending on your data store,

you have options as to how you do the actual updating. I've seen developers

swear by just deleting the original record(s) and inserting new ones

all_the_time. I usually just swear at that one. <g> Others never insert new

records if there's records marked for deletion ... just reusing them if

available. Do it however you wish but you'll still have to manage the

updating/insertion of records yourself.

As for buffering, I usually use a technique I call "Optimistic Realism". For

the actual locks, I setup the data store as optimistic (physically locking

at the time of update/insertion = "Optimistic") but I use a class & fields

that store who/when/why the record/table was starting to be edited. This

allows some flexibility in managing "locks" on my data.Of course, it's not

used or even appropriate in all cases or even all apps of mine but it has

worked well for 1-tier, C/S, and n-tier work. But I think that was more than

you wanted to know. Sorry. I ramble.

- AHilton

>

> You would then have to code the updates manually, however, as

> they would be no

> physical tie to the real table (like in a view), right? You

> could still use

> the buffering I suppose with GETNEXTMODIFIED to determine what record to

> update, and then dynamically generate the UPDATE SQL assuming the

> record has a

> unique identifier for it. Seems like a lot of work, however. Perhaps I'm

> making a mountain out of a mole-hill?