Drew Wutka
DWUTKA at Marlow.com
Tue May 27 21:21:03 CDT 2008
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.