Microsoft Access - back to the abc's -- storing useful code

Hello Eggheads:

Yeah, I know, it's been a while. Hope you're all well. 

So my question is very basic, very elementary.  It's been a long time since I've done this, so I wanted to get straight once and for all what the lowdown is on saving some VBA udf's for use in other Access db's. 

I'd done this with Excel 2003, and it was sort of arcane then; and I know it's even more bizarre under 2007 -- at least for Excel.  Not sure about Access. Anyway, I think that now, in the 21st century, I should probably evolve beyond copying and pasting code from old modules.  Would like to streamline that a bit not only cuz it looks cool and impresses the boss but also because -- if it doesn't require a white-paper to describe it -- it might actually make life a bit easier and would surely prevent the code from being exposed in a text editor like a petunia in the eye of a hurricane. 

Thanks in advance.

I would like to hear the same thing.  I've been capturing my bits of code in different named modules for years, in both Access and Excel.  It works, but I don't have a good naming convention for the modules, tending to group them by function (basChart, basUser, basSortFind, etc).  When I'm putting together forum answers, I'll create a separate spreadsheet (or database) with an appropriate function name, but again my convention is not solid.

If you look at Chip Pearson's web site, it appears he tends to do something similar, grouping by his code by topic:  http://www.cpearson.com/Excel/Topic.aspx

Since so much code references different functions, it would probably be good to have more of a database of code, with metadata for easy cross reference.  Of course, it also helps to have a platform and valid data to demonstrate the code in use.

Good question, does someone have a good standard to discuss?

FMS sells a pretty good product that works with VB as well as Access.
http://www.fmsinc.com/Products/sourcebook/index.html
It is $399 per seat which may seem a little pricey but if you think about how long it would take you to replicate it at your hourly rate, not to mention the code samples it comes with, it is not a bad deal.  In any event, it should give you some idea of how a code library is implemented.

wow. makes me feel like a professional, thinking about subbing stuff out like that.

What about .dll's and things, which I'm somewhat more familiar with (and they're lightning fast), having made them work in Excel 2003, w/Visual Studio?  [thinking out loud] I suppose I could just call the .dll's from Access VBA like I did from Excel...but then how would I do SQL within C++?[/thinking]

I have only glanced at the links provided, so I'm not sure if this approach is similar or not, but it seems to me that I read somewhere that you can reference an access file in Tools>References, thereby using it as a code library.  I believe the same is true of Excel.

Memory on this is a bit fuzzy, though, so if it needs correcting please, by all means, correct/elaborate.