[AccessD] One Note

For the past couple of years or so, I have been storing snippets of VBA
code as separate files in a subdir called VBA. But in the past couple of
months, I have switched to OneNote, and I am totally impressed with this
mechanism. I now have a NoteBook called VBA, and it contains several
sections, and I have copied and pasted all the former txt and bas files
into OneNote. This solution is WAY slicker than my old method.

We all have different methods. No slight upon anyone here intended; my
preference is to include all the required code, and only the required code,
in any deployed solution. I do not want to burden the client with an
"Everything Including the Kitchen Sink" solution; 70%+ of which will go
unused in any given situation.

Call me old-school: I can deal with that. I want all the required code and
only the required code to be deployed in any given deployment. This
practice dates to my years in lower-level languages. I admit that. But I
also resist the tendency to include "Everything including the Kitchen Sink"
approaches.

Today I finally got around to importing all the snippets, previously stored
as separate text files, into one single OneNote file. Actually, I have
several such files now. Of interest here might be the MS-SQL file as well,
which contains several dozen sprocs and views and so on. Another contains
Recipes, since I am a fanatical cook; this file has two sections, Slow
Cooking and otherwise.

The more I use OneNote, the more I'm loving it. It loads quickly and saves
automatically. Today's project was to import all my Access and SQL snippets
into a corresponding pair of OneNote files, and this solution is extremely
cool.

The next logical step is to share said files with the community. No doubt,
there will be some overlap, but assuming that I send you my OneNote VBA
file, you could open it and import everything of interest into your own
equivalent.

This approach strikes me as way more intelligent than than the old horse
"create a library and set a reference to it", for a couple of reasons: 1)
the larger the library, the longer it will take to load the module of
interest; 2) any code not part of the app of interest ought not to be there.

Admittedly this is a tad more work than the old approach, but I like lean
and mean versus the "junk in the trunk" approach. Call me an old-timer if
you wish.

-- 
Arthur
Cell: 647.710.1314

Prediction is difficult, especially of the future.
  -- Niels Bohr