[AccessD] VBA Unbound data entry / update form

Edward S Zuris edzedz at comcast.net
Tue May 27 22:45:00 CDT 2008


 I love the LOL stuff.  But is someone will pay you to
 do something and it isn't breaking the law and get you
 thrown in jail - Hey why not.

 May of us did the non-bounded way especially if we
 transferred from VB3 to MsAccess.

 Hell, pay me an pittance and I'll rewrite whatever.


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of Drew Wutka
Sent: Tuesday, May 27, 2008 7:21 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] VBA Unbound data entry / update form


LOL.  Well, that is one of the points that we discussed in those
debates.  It all depends on what kind of systems you build, as to what
tools are more often used.  Allowing users to modify, or delete data is
a rarity in most of the systems I build.

Well, not in the way I think you are referring to. I will have a system
where I allow a user to change data, but the data change isn't going to
run into an 'overlap' issue.  For example, the product database behind
our companies website is maintained by our drafting department.  There
is not going to be a case where one person would change a product one
way, and another, another way. Just not how the system is put in place.


But if you think about it, in many cases, concern about data change
overlap should really be concern over the design of the database.  Why
would you EVER have two people making changes to the same field in the
same record at remotely close times?

Data in a record represents something real, in a manner of speaking.
There should only be one right value.  Yes, a value may change, but
change twice within moments?  I'd say 99% of the time, it's going to be
bad design that's the real issue.

Take the helpdesk system I built years ago.  The initial system that was
in place had a 'comment' field that tracked what the IT personnel did to
a request.  So you could have multiple techs trying to write to the same
field.  BAD DESIGN.  The system I built, has interim reports (reports of
work done in progress) and final reports (reports of completed work).
These are records put in their own tables.  So you could have a dozen
techs entering reports on the same ticket, and NO information is
changed, instead, a record is added for each change made, and thus
tracking in a much clearer fashion what was done.

Drew

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of jwcolby
Sent: Tuesday, May 27, 2008 8:29 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] VBA Unbound data entry / update form

 > However, where JWC is hitting a wall, is that he is 
trying to mimic the exact functionality of a bound form with 
unbound methods

Well... there is far too much "exact functionality" to even 
attempt to mimic, though the major parts would be nice.

 >though I know why he is, he is trying to disconnect it to 
try and remove a clog in the system

Uhhhh yep.  Under certain conditions Jet and the MDB BE 
cause issues.  I am trying to code a solution around those 
issues, not for use in every form, but I still need add / 
edit / delete functionality without data corruption.

 >The problem is that if you want all the features of a 
bound system, it's FAR easier to just use a bound system. 
Unbound forms are good for lightweight processes.

Which is precisely why I use bound forms 99% of the time. 
Why reinvent a rather complex, well designed wheel.  Said 
wheel works quite well BTW with a SQL Server data store, it 
is SPECIFIC issues with the MDB data store that appear to be 
the problem.

John W. Colby
www.ColbyConsulting.com


Drew Wutka wrote:
> Sorry, just don't build Access front ends very often.  ASP/HTML has
far
> too many advantages.
> 
> However, where JWC is hitting a wall, is that he is trying to mimic
the
> exact functionality of a bound form with unbound methods....there's no
> real point to do that. (though I know why he is, he is trying to
> disconnect it to try and remove a clog in the system).  The problem is
> that if you want all the features of a bound system, it's FAR easier
to
> just use a bound system. Unbound forms are good for lightweight
> processes.
> 
> Look at it this way.  A bound form is essentially like giving someone
> direct access to a table, with some extra bells and whistles.  To
> restrict capabilities (like not allowing certain fields to be edited,
or
> only certain records, etc.) you have to add to a bound form to get
those
> capabilities.  With an unbound form, you are coming from the opposite
> direction.  The user only gets the capabilities you create for them.  
> 
> Drew
> 
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.


-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com


More information about the AccessD mailing list