[AccessD] VBA Unbound data entry / update form

jwcolby jwcolby at colbyconsulting.com
Tue Jun 10 13:57:01 CDT 2008


Drew, EXACTLY WHAT do you think happens with ADO unbound 
recordsets being updated back to the database in VB.Net?

There are NO LOCKS THERE, but they have developed some 
system to "handle the situation".  It is my understanding 
that updates are legal in disconnected ADO recordsets.  Ergo 
there is a solution.

In ACCESS there are very valid instances where a bound form 
causes problems BECAUSE OF JET and page locking.

YOU WILL GIVE UP and blather on about "stick with a bound form".

I have never asked you to participate in this thread.  If 
you don't want to think about the problem, blather somewhere 
else please.

I was about as civil as I could get in the previous round. 
You are the annoying one insisting that since YOU don't have 
an answer there is no answer.

PLEASE, just butt out!

Thanks,

John W. Colby
www.ColbyConsulting.com


Drew Wutka wrote:
> Sigh....
> 
> JWC, please just stop.  This is getting annoying.  I've posted over and
> over that you have a gross conceptual error when it comes to unbound
> forms.  An unbound form is NOT meant to replace a bound form.  It is
> meant to do it's own job.  If you want an application, where multiple
> users are changing the same field over and over, stick to a bound form.
> If you want an application where the forms are tied to straight forward
> table structures, and any fancy structure quirks can be handled by a
> query, again, stick with a bound form.  If you want a form that has all
> of the bells and whistles of a bound form, STICK WITH A BOUND FORM!
> 
> Unbound is the way to go when you build complex structures that aren't
> as easy to represent with just a query.  Unbound forms are meant for
> systems where you NEVER have 2 people editing the same field (because
> the structure is designed to have 'multiple' entries put in multiple
> records, not the same field).
> 
> I just posted an example of an unbound form.  It was meant for a single
> user, but the core could be used in a multi-user environment without a
> hassle.  One user 'moving' inventory wouldn't interfere with another,
> because the transactions are new records.  Changes in a site name (which
> you wouldn't have User A 'deciding' to change the same site name that
> User B wants to change) are irrelevant because of that.
> 
> You started this latest bound/unbound debate about a limitation with
> memo fields and bound forms. I CLEARLY explained HOW to fix your problem
> in an unbound method.  You whined about having to stick with a faulty
> table structure.  Fine, stick with the faulty table structure, and quick
> trying to egg on developers who took one look at the process you are
> trying to fix and said 'well here's your problem'.  It's beneath you.
> (or should be)
> 
> Drew
> 
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
> Sent: Tuesday, June 10, 2008 12:37 PM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] VBA Unbound data entry / update form
> 
>  > I suspect that the unbounders on this list have all been converted
> and are therefore silent.  :)
> 
> ROTFLMAO.  I kind of doubt it.
> 
> I suspect there are several classes of unbounders hiding out there,
> those that...
> 
> 1) Don't handle it and don't want to admit it.
> 2) Handle it but the code was reaaaaaaaaallllllly messy and don't want
> to admit it.
> 3) Use "first wins" strategy and don't want to admit it.
> 4) Spent so much time and effort doing it correctly that they don't
> really want to give their work away.
> 
> I come to this conclusion because if they handled it correctly, and the
> code was neat and tidy, then they would be popping up all over like
> proud papas to show us their beautiful baby.
> 
> John W. Colby
> www.ColbyConsulting.com
> 
> 
> The information contained in this transmission is intended only for the person or entity to which it is addressed and may contain II-VI Proprietary and/or II-VI Business Sensitive material. If you are not the intended recipient, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. You are notified that any review, retransmission, copying, disclosure, dissemination, or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited.
> 
> 



More information about the AccessD mailing list