[AccessD] Unbound Form Check For Changes

I am not working in Access much any more.  However if there is interest I will create a thread for a 
discussion about building a framework for implementing unbound forms using classes.  This will be 
YOUR discussion though, i.e. it will be a group effort, with group ideas on what has to be done. I 
will guide the class / framework side.

Let me know.

John W. Colby

Reality is what refuses to go away
when you do not believe in it

On 3/23/2014 10:50 PM, Bill Benson wrote:
> BTW As a diatribe against unbound controls, I like it. I just wish I could
> get away with all my laziassness using bound controls, but they never work
> for me because I never seem to know how to create an updateable recordset
> the way I do things. Like have large flat-ish tables wherein I need to
> create group by queries to present simplified information for them to
> cherry-edit values on unbound forms, then push the changes back to the main
> tables.
>
> No doubts about it John, you are the professional's professional. I am just
> a hack. Not proud of it, and maybe someday someone will pay me to learn
> better techniques. If they don't I will just do what I have time to do.
>
> BB
>
> -----Original Message-----
> From: accessd-bounces at databaseadvisors.com
> [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Jim Lawrence
> Sent: Sunday, March 23, 2014 10:35 PM
> To: Access Developers discussion and problem solving
> Subject: Re: [AccessD] Unbound Form Check For Changes
>
> Hi John:
>
> I see no flaw in your argument other than, if you don't already have classes
> built and tested, it can be a bit of over-complexing a rather simple
> requirement. For larger projects, a healthy code library, at your disposal,
> is of course now a requirement.
>
> Jim
>
> ----- Original Message -----
> From: "John W Colby" <jwcolby at gmail.com>
> To: "Access Developers discussion and problem solving"
> <accessd at databaseadvisors.com>
> Sent: Sunday, 23 March, 2014 6:54:51 PM
> Subject: Re: [AccessD] Unbound Form Check For Changes
>
> LOL, but you have already made clear that you see no benefit to classes in
> general.
>
> Classes allow us to use Object Oriented programming techniques. The
> programming language /
> environment is irrelevant, that is their purpose.
>
> OO is about storing the code and data for a given object in a single
> location, wrapping behaviors
> and data together.  If you are not using classes than you have scattered
> code to hell and back to
> handle the objects.  The events fire for a text box.  Where is the code to
> handle that?  In the
> form's class?  But the form's class is supposed to be modeling the FORM'S
> properties and events.
> Now it is handling every event for not only itself, but for every control
> that it contains.  And
> anything else you want to stuff there!!!
>
> If you design a table, do you place all the information about the client and
> their cars and their
> invoices and their orders all in the client table?  Obviously not, you
> create a table for each
> item.  You are MODELING objects, with each object having its own table.  In
> programming, I
> (personally) model each object.  OO teaches me that is the "best practices"
> way of doing
> programming. Each function is supposed to do one thing.  Each class is
> supposed to model one
> object.  The form's module is a CLASS!!!  It is supposed to model a specific
> form, NOT a bajillion
> other things as well.
>
> Microsoft, knowing full well that the average user will have no programming
> experience, ALLOWS you
> to put code and variables for the whole damned world into the form's class,
> but that does not make
> it the right thing to do.  As we "average users" become practiced
> professionals, we need to learn
> how to do things better.  If you never even consider using a class to
> encapsulate the behaviors of a
> text box, then you are just blindly using 1992 methods of Access
> programming.
>
> It feels that you never even consider whether a class would help to organize
> and encapsulate the
> behaviors you are trying to implement.
>
> An unbound form is a decidedly complex system.  To just blindly stuff crap
> into the form's module
> for this form, GUARANTEES that you will be doing the same thing into the
> next form.
>
> An unbound form needs to:
> 0) Connect to a data source.
> 1) Load a record from some data source (SQL Server?)
> 2) Disconnect from the data source.
> 3) Distribute that data out into controls - text boxes, combo boxes, radio
> buttons.
> 4) Watch those controls to discover whether changes are made.
> 5) connect to a data source.
> 6) Write the changes back out to SQL Server.
> 7) HANDLE edit collisions.
> 8) Disconnect from the data source.
>
> The connection to the server can be unavailable when you try to read it.
> The record being edited can be deleted.  What do you do then?
> The record you are editing can be edited by another user since you read it.
> How do you discover
> that?  How do you handle that?
> The record you are editing can be locked when you try and write it back.
> The connection to the server can be unavailable when you try to write it
> back.
>
> The unholy unbounders make light of bound forms but Access handles ALL OF
> THIS STUFF for you when
> you use bound forms.  If you are going to do unbound, YOU have to handle all
> this (and more).
>
> I did a 1 year contract at IBM.  They were using unbound forms and not
> handling ANY of this.  And
> the users are SWEARING (in general, but specifically) that they are making
> changes which just
> "disappear".  Well no shit Sherlock!  I can't imagine where the changes
> went!!!!
>
> So when a user says "I want to build an unbound form to edit data", I
> (personally) am VERY uneasy
> throwing out a trivial solution.  There IS NO TRIVIAL SOLUTION.  And none of
> the solutions I have
> seen proposed have even discussed ANY of the issues I have mentioned.
>
> Back to IBM... the previous programmer wrote the same code, over and over
> and over and over and over
> and over and over and over and over and over and over and over and over and
> over and
>
> in each and every form to read the data, distribute the code to the
> controls, watch the controls for
> changes, and write the data back out, all without ANY THOUGHT to edit
> collisions.  EVERY FORM had
> MILES of code in it.  Print that puppy out and EVERY FORM had a yard of
> paper.  Can you say "CRAP
> PROGRAMMING"???  Well, not exactly crap programming, more like novice
> programming.
>
> So now, are you going to encapsulate all of the REQUIRED programming (To do
> this correctly) in each
> and every form of YOUR solution?
>
> I am not.
>
> John W. Colby
>
> Reality is what refuses to go away
> when you do not believe in it
>
> On 3/23/2014 9:06 PM, Bill Benson wrote:
>> So what would the class be, of type Control? And.... why? The method I
> gave
>> returns that ANY change occurred, and it is simple.
>
> ---
> This email is free from viruses and malware because avast! Antivirus
> protection is active.
> http://www.avast.com
>


---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com