UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
 
   Reply to this topicStart new topic
> What Are The Steps For Refactoring Dummy's VBA?, Access 2016    
 
   
Jaiket
post Dec 21 2017, 04:05 AM
Post#1



Posts: 125
Joined: 3-May 17
From: France


I have a database for handling gigs (music/stage-work, Access 2007). It attempts to handle everything from the song-list to the hotel access codes to the yearly analyses on each musicians pay. I built as I learned, but it hit the wall when I wanted to move from Estimates(Quotes) to a real-live Bill.

I have done a good deal of research and practise for a couple of years on concept, design, normalisation, naming convention, data dictionary, error-handling, relational flow, code encapsulation, - mostly on paper. My practise ground for real VBA was:
Building a form to automate table creation which forces best practises, a naming convention and blocking out bad Access settings like SubDatasheet[Auto].
Building a second form to automate writing VBA which forces best practises, a naming convention and automates repetitive VBA coding (declarations and Error handling). I have read that code that writes code is not a good thing, but I am stubborn and need to hit another wall before I stop doing that.
Both these things actually seem to work for my purposes.

I haven't yet looked at auditing, and I gave up on ERD, but I feel I will soon be ready to dig out my database and try again.

Assuming I don't just start again, how would I approach refactoring code written by someone who had no idea what he was doing (me)? I am now on Access 2016.

--------------------
UA = Unsurpassable Assistance. Couldn't do it without you.
Go to the top of the page
 
DanielPineault
post Dec 21 2017, 05:56 AM
Post#2


UtterAccess VIP
Posts: 5,861
Joined: 30-June 11



Often, you just start over.

Regarding Code that writes code, it is one thing to create some development tools to help you during development, which is fine, it is another to create such tools for production, in which case it is very ill-advised. I would also highly recommend you look into Mz-Tools for error handling, searching, and so much more. It is the go-to add-in for most serious VBA developers.

--------------------
Daniel Pineault (2010-2017 Microsoft MVP)
Professional Help: http://www.cardaconsultants.com
Free MS Access Code, Tips, Tricks and Samples: http://www.devhut.net

* Design should never say "Look at me". It should always say "Look at this". -- David Craib
* A user interface is like a joke, if you have to explain it, it's not that good! -- Martin LeBlanc


All code samples, demonstration databases, links,... are provided 'AS IS' and are to be used at your own risk! Take the necessary steps to check, validate ...(you are responsible for your choices and actions)
Go to the top of the page
 
jleach
post Dec 21 2017, 06:13 AM
Post#3


UtterAccess Editor
Posts: 9,893
Joined: 7-December 09
From: Staten Island, NY, USA


I'd say you're better off just learning and utilizing the best practices, without writing a tool to do it for you. For one, writing those kinds of tools are hard, and for two, you'll force yourself to adopt best practices if you do it manually.

With that said, there's stuff floating around out there (like Allen Browne's function to turn off SubDatasheets and set AllowZLS to False) that are quite handy, but in terms of naming conventions and such: tooling doesn't seem to help much with that.

--------------------
Go to the top of the page
 
GroverParkGeorge
post Dec 21 2017, 06:43 AM
Post#4


UA Admin
Posts: 32,352
Joined: 20-June 02
From: Newcastle, WA


I absolutely agree with Daniel and Jack here.

The analogy I like best is to compare Access to a canoe.

If you travel upriver, against the current, you have to paddle hard to make progress.

If you travel downriver, with the current, you let the current do the work and use the paddle to guide your progress.

Writing a form to generate code seems like a lot of extra paddle-work to me.

Go get MZ-Tools, or one of the other add-ins that provide a lot of assistance to guide your progress.

Of course, you might end up importing and tweaking existing code--we all do that to a larger or smaller extent. I have a library accde for exactly that purpose. It contains some basic, reusable Functions that I would otherwise have to import into every new accdb and keep updated. Instead, I set a library reference to it and call the relevant functions as I need them--and don't if I don't need them in any particular database.

Of course, like everything else to do with Access, your experience is going to be different and call for different strategies from time to time. If it were all the same for everyone, there'd be one master template somewhere that we'd all use for everything.

--------------------
Go to the top of the page
 
Jaiket
post Dec 21 2017, 07:35 AM
Post#5



Posts: 125
Joined: 3-May 17
From: France


Mz-tools apparently used to be free. I can see why the guy moved up a notch. I never thought to get the trial version so I can decide.. will do.

I did find it useful building these things because it forced me to concentrate on only tables and their inherent problems/best practises, then on only VBA statements and their particularities, not as a chapter in a 1000-page book, but in an actual application.

Thanks for those posts, guys, there were quite a few points which have become clearer, especially the context of code that writes code.
I seem to be at the stage of finally realising exactly which context is relevant to all this theory I've swallowed.
This post has been edited by Jaiket: Dec 21 2017, 07:39 AM

--------------------
UA = Unsurpassable Assistance. Couldn't do it without you.
Go to the top of the page
 
DanielPineault
post Dec 21 2017, 09:12 AM
Post#6


UtterAccess VIP
Posts: 5,861
Joined: 30-June 11



If you can still find the old free version of Mz-Tools, IMHO, it is the best!

--------------------
Daniel Pineault (2010-2017 Microsoft MVP)
Professional Help: http://www.cardaconsultants.com
Free MS Access Code, Tips, Tricks and Samples: http://www.devhut.net

* Design should never say "Look at me". It should always say "Look at this". -- David Craib
* A user interface is like a joke, if you have to explain it, it's not that good! -- Martin LeBlanc


All code samples, demonstration databases, links,... are provided 'AS IS' and are to be used at your own risk! Take the necessary steps to check, validate ...(you are responsible for your choices and actions)
Go to the top of the page
 


Custom Search
RSSSearch   Top   Lo-Fi    19th April 2018 - 06:16 AM