D
David Portwood
I think it was one of Tom Wickerath's suggestions to separate Memo fields
from main tables because tables with Memo fields don't allow row level
locking. Instead, put the Memo field into a separate table linked 1:1 to the
main table. I do want row level locking for my multiuser app. How best to
implement this?
My first thought was to base my form on a query linking the main table and
the memo table. This way I get all fields on the form including the Memo
field. However, if the tables are linked 1:1, does this allow row level
locking? I would think that restrictions on either of the tables in a 1:1
relationship would affect the other table the same way. Or is this wrong?
Another possibility is to use an unbound field and in the AfterInsert method
of the main form open a recordset to update the Memo table. Actually, I
would keep the recordset open while the form was open. I would populate the
field in the Current method of the main form.
Which is the best way to go and why?
from main tables because tables with Memo fields don't allow row level
locking. Instead, put the Memo field into a separate table linked 1:1 to the
main table. I do want row level locking for my multiuser app. How best to
implement this?
My first thought was to base my form on a query linking the main table and
the memo table. This way I get all fields on the form including the Memo
field. However, if the tables are linked 1:1, does this allow row level
locking? I would think that restrictions on either of the tables in a 1:1
relationship would affect the other table the same way. Or is this wrong?
Another possibility is to use an unbound field and in the AfterInsert method
of the main form open a recordset to update the Memo table. Actually, I
would keep the recordset open while the form was open. I would populate the
field in the Current method of the main form.
Which is the best way to go and why?