Backend for Forms

[DDBeards]

My department uses 5 Db's each with many forms, subforms, and reports in
each. Many of the tables are used in all the systems via links. What I
would like to do is to create a backend file for forms and reports just like
I use for the data and call them into the front end when needed and delete
them when done. Can this be done and does anyone have sample code. Thanks
in advance

DDbeards

 

[Jack Leach]

I'm not sure this is a good idea... why not just keep distributing various
frontends with the required objects, or a single version which has all
objects, but with some security to let certain users see certain ones?

Import and deleting objects from a front end is generally avoided for
bloating reasons. In fact, many opt not even to use temp tables in their
frontends because of this... I can only see huge problems with rapidly
growing frontends doing this, as well as a good medium for corruption.

True, you could compact/repair to downsize the FE after you're done with
these "temp" objects, but even C/R on a FE is considered a waste... you
instead just get a new copy from the server.

I really don't think Access is set up to handle something like this. It may
be possible, but I doubt it would be a good thing to do.

hth

--
Jack Leach
www.tristatemachine.com

"I haven''t failed, I''ve found ten thousand ways that don''t work."
-Thomas Edison (1847-1931)

 

[DDBeards]

Thank you, this is what I thought so let me ask the second question. Can I
have FE that functions like a main menu that calls various frontends when
requested. I guess it would be a FE for multiple FE's?

DDBeards

 

[Jeff Boyce]

I'm open to new ideas ... but this seems unnecessarily complex.

Why not roll them all into a single FE, then use a menu (or menu plus login
IDs) to fire up only that portion that is appropriate?

Regards

Jeff Boyce
Microsoft Access MVP

--
Disclaimer: This author may have received products and services mentioned
in this post. Mention and/or description of a product or service herein
does not constitute endorsement thereof.

Any code or pseudocode included in this post is offered "as is", with no
guarantee as to suitability.

You can thank the FTC of the USA for making this disclaimer
possible/necessary.

 

[Jack Leach]

This may be a lot more reasonable. I've never done anything of the sort, but
I know you can Shell a file (your other FE), and I know you can close your
current (switchboard) FE (Application.Quit).

But you would need to keep local copies of each FE on the user's computer...
you certainly can't run from a network (hello corruption), and even if you
did each user would need their own anyway, otherwise (hello serious
corruption).

Anyway, assuming all the FEs are located in the same path as your
switchboard FE, something maybe as simple as a combo box and an Open button:

Private Sub btnOpenFE_Click()
If Not Isnull(Me.cboFEList) Then
Shell CurrentProject.Path & "\" & Me.cboFEList
DoEvents
Application.Quit
End If
End Sub


Again, this is not an area of expertise for me, but I think you might need
to be careful running more than one db at the same time, depending on your
coding standards (CurrentDb vs. DBEngine(0).(0) for example). That is, if you
should decide not to close the switchboard FE. Also, I'm not sure if there's
anything to watch out for in opening one DB and closing another right behind
it. I would be wary of the open/close procedures tripping over each other.

All in all, personally I would feel a lot better just using one large FE
that contains all the objects, or a seperate FE for each user with only those
objects required for that user.

The max filesize is 2gb, and I've never had an FE come anywhere even
remotely close to this. Depending on your form loading and binding
practices, a db of 500mb with tons of objects should be as quick to run as a
40mb db with not nearly so many objects.

Food for thought...




--
Jack Leach
www.tristatemachine.com

"I haven''t failed, I''ve found ten thousand ways that don''t work."
-Thomas Edison (1847-1931)