RE: setting controlsource for 1:many objects in n-tier design

Ramble away---I appreciated your viewpoints! In some of the ASP code (where

an update is required), I've seen code more/less like the following: UPDATE

MyTABLE Set MyField1=3DlcField1, MyField2=3DlcField2, <etc=2E> WHERE UID=3DlcUID=20=

=20=

so if only 1 field is really changed, the entire record contents get changed,

not just the changed field=2E They dynamically build the SQL statement composed

of all the fields, not just the updated one, stepping through the Fields

collection=2E Not very efficient IMO, but perhaps it's easier to code it that

way than to write all the conditional logic to build the UPDATE SQL for only

the field that has updated=2E I haven't personally coded anything web-related

yet (via ASP), so I can't speak from experience=2E I've got samples from folks

on the list but have had limited time to explore them in depth=2E "So much to

do; so little time in which to do it=2E"

>>> "ahilton@usexpr=2Ecom" 06/04/01 03:09PM >>>

The mountain is, indeed, there =2E=2E=2E but it only has to be climbed once=2E

You're talking n-tier here=2E=2E=2E ease has nothing to do with it=2E <g> Throw y=

our

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

disconnected cursor retrieving/updating/deleting tasks for you=2E Personally,

I choose "make it" but that's just the way I am=2E

Yes=2E You should manage the updates manually and you *should* have a UID

(Unique ID) for each record=2E This allows you to go straight to the record(s)

you need without having to depend on recno()=2E Depending on your data store,

you have options as to how you do the actual updating=2E I've seen developers

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

all_the_time=2E I usually just swear at that one=2E <g> Others never insert new

records if there's records marked for deletion =2E=2E=2E just reusing them if

available=2E Do it however you wish but you'll still have to manage the

updating/insertion of records yourself=2E

As for buffering, I usually use a technique I call "Optimistic Realism"=2E For

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

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

that store who/when/why the record/table was starting to be edited=2E This

allows some flexibility in managing "locks" on my data=2EOf 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=2E But I think that was more than

you wanted to know=2E Sorry=2E I ramble=2E

- AHilton

=20=

*****************************************************

Michael Babcock

KePRO, Inc

Tel: 717-564-8288

Fax: 717-564-4188

Internet Address: mbabcock@kepro=2Eorg

*****************************************************