Arthur Fuller
fuller.artful at gmail.com
Wed Dec 14 11:10:59 CST 2011
Without pretending to expertise on this topic, although admitting some experience, I have found that the best way to handle this stuff is via Views. Which is also a statement of principle: never let Anyone but God touch the tables, me and in your case You assuming the God role, allow no mortal to ever touch the tables: that is Your province; they all go through sprocs or views; it happens that in an Access app, I prefer views, because they are much more flexible: simple, simple, simple: main form has one view, details form has another view, linked Master and subForm keys; drop-dead simple, and works like a charm. Maybe not scalable to hundreds of users, although I have made it work with 70+ users, and it was Fast. I have no complaints about that approach, although I am also looking at C# and LightSwitch alternatives, and attempting to re-write client apps on these new models. It's a learning experience. A. On Wed, Dec 14, 2011 at 7:05 AM, jwcolby <jwcolby at colbyconsulting.com>wrote: > I am moving to SQL Server and when a user tries to update data that has > changed a message is generated. The nice part is that Access places the > change in the paste buffer. > > How do I handle that at the form? Trap the error and requery the form > then the prompt the user to insert the paste buffer? > > I will be testing that stuff but have no experience here. > > -- > John W. Colby > Colby Consulting > > Reality is what refuses to go away > when you do not believe in it > > -- > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/**mailman/listinfo/accessd<http://databaseadvisors.com/mailman/listinfo/accessd> > Website: http://www.databaseadvisors.**com<http://www.databaseadvisors.com> > -- Cell: 647.710.1314 Thirty spokes converge on a hub but it's the emptiness that makes a wheel work -- from the Daodejing