Managing a lot of forms/queries efficiently.

[emihir0]

I have been working on an Access application that has around 70 forms and 40 queries.

What is the standard procedure to make your forms/queries manageable? What are the standard naming conventions?

Currently I use:

<Prefix (T for tables, Q for queries, F for forms and R for reports)>_<some specific name>_<Suffix (for forms specifically - SF - single form, DS - datasheet...)>



So for examples a F_Orders_S would be some single form view of the orders.

However, this is becoming a mess as the application expands.

One solution would be to split the front end into several smaller front ends, but that seems counterproductive as users would have to switch between them to do what they need to do.

[ranman256]

i dont see the need for the underscore, but if you already have 70 forms, then keep it.
fOrders, fReports, etc works.
Tho, why you need 70 forms is beyond me.

I maintain a table, tForms. It has a list of the forms for users to pick in a combo box. Then they click the open button
( docmd.openform cboForms )
This is on the main menu form, fMainMenu.

Your idea of smaller front ends may work for you too.

[emihir0]

Well there are about 18 "main" forms but all of them have several subforms most of the time. The most extreme case is 10 subforms or so. However, all of these subforms are still present next to their mainforms counterparts in navigation pane, making it chaotic (differentiating between "what is an important form and what is not" is sometimes a pain).

My idea would be to make some sort of tree-view where you can expand from the "main navigation" form all the way to the smallest subform.

Is something like this available/possible?

[Micron]

I'd say if you look around, you'd think there is no real standard naming convention, but there is more than one. For the most part I'm consistent with objects but I seem to alternate between a few VBA variable prefixes (sv or str, rst or rs for example). I think you got too detailed with the form names. I'll use frmOrders and if you asked me if it was a single form or data sheet, I'd say don't expect me to remember. It's no longer important once I made the decision and it's been working fine, and too many name characters makes for awkward coding. If frmOrders has a sub, it would be frmOrdersSub - no spaces (EVER) and no need for the underscore. As for subs, I thought the limit was 7? Maybe I'm thinking of 7 nested levels.

Which brings me to your quantity. 70 forms sounds like a huge amount of user capability in one db to me, or an awfull lot of one to many relationships. I can't imagine having ten recordsets (subs) related to the main form but not each other. Maybe that's not what you're saying. Or are there, for example, versions of the same form so that you could open one in edit, one in add and one in read mode? That would have been a mistake (sort of). If you are wondering whether or not a form in the nav pane is important or not, it sounds like the db has been around too long, had too many hands in it, and has become bloated with confusion. Maybe you will have to bite the bullet and split up the functionality if that's the cause. For one particular work group, I created 3 databases because there is no relationship between onsite contractor body counts, offsite parts repair contracting and permit creation even though it's the same people. This has kept everything purring along for years now, and major changes in one don't affect the others.

[emihir0]

Thanks for the reply.

What I meant by "10 subforms" is basically that a mainform can have a subform which has another subform/s in it. So it is not necessarily a A-B, A-C, A-D... relationship, it's more like A-B-C, A-D-E, A-F-G-H display (nested subforms showing related data).

The reason why I use underscores is because I do not want to use spaces, ever, and so this makes my naming somewhat clean.

My DB has about 40 tables in it and so each of them has usually 1 datasheet view subform which is used at the very low level and then some of them have single form view for higher level forms and then, finally, some main forms for overview with several of these datasheet view subforms or buttons for these single forms.

[Micron]

You are absolutely correct not to use spaces, but you still don't need the underscore if you subscribe to of of those methods I mentioned. I think it works this way: the object identifer is lower case, and each word or part that follows is written in proper case; e.g. frmSales, frmInvoice, rptSalesByRegion, ctlAreaDept and so on. Of course, there's nothing wrong with what you do, but I can type fairly quickly yet dislike having to shift+type for the underscore character. For anyone reading this thread, here is one source of suggesting for naming objects. http://access.mvps.org/access/general/gen0012.htm
I confess I don't follow it verbatim, as I use mdl for module, not bas. I suspect a lot of people have never heard of BASIC (not Visual Basic) from which it comes.

[CJ_London]

I use a naming convention which groups main forms and subforms together alphabetically. Having started with '97 the navigation window was much simpler then

so

frmOrders
frmOrdersSFCustomer
frmOrdersSFDetail

As with micron, I avoid underscores for the same reason

However I have similar style which effectively automates navigation

Ipt0Orders
Ipt1OrdersCustomer
Ipt1OrdersDetail
rpt0Orders
rpt1Customers

So my navigation form lists all forms start with lpt0 under the Input tab, and all forms starting with rpt0 under the report tab, etc, so the addition of a new form or report requires no change to the navigation form.

Both methods can have issues - quite often I have the same subform used in several forms, just perhaps need to reconfigure it from the main form on opening - so have to decide what to call it!

I'm really not interested in if the form is single, continuous or datasheet since (per the previous paragraph) I may change it on the fly.

[ItsMe]

I use something like
frmOrderNew
frmOrderNewSub
frmOrders

I try to think about what my objects will look like in alphabetical order and how I can keep the name as short as possible. I don't think adding whether a form is continuous single, etc. is important to p[lace in the name. I like the idea of distinguishing subforms. However, I will make a form object multipurpose if it is possible to do so.

I counted 44 form objects in one of my larger DB's. Not sure what that means, exactly. 70 forms sounds large. Like others, I try to make an application that does something specific. If there is a way to divide an application into two or more apps, I say do it.