Multiple DB for System info.

[MadTom]

I have a Split DB used for Parts Inventory. I would like to share this with others and would like to keep track of Users and Ver # for the FE. I also have Queries and Forms that I use to setup tables to send to others, but I don't want to send this info. on the FE DB. My question is would I setup 2 DB's linked to FE and put all my Users info. and tools in the main DB and then send FE and BE to the user?
Would love to have your input.
Thanks
Mad-Tom

[ranman256]

Everyone should be on the same version.
you can lock the db so nobody can alter it.
Use their user ID to track who did what,when.

[MadTom]

Everyone should be on the same Ver., standalone FE only. The question is all the data, query and forms are on FE now, should I start another DB with Users info. and From tools on another DB that would not be sent to users?
Thanks!

[Micron]

Not sure what you're asking.
If you split the db then make the fe connect to the be, the connection information is part of the fe design (table connection strings). Everyone who gets a copy of the fe should then be connected to the same be automatically as long as they have the right network permissions. However, one thing you have to be concerned about is that if the connection path is based on a network drive letter (e.g. F:\) everyone must be be using that drive letter. If not, connect using a UNC path.

[MadTom]

OK, not a big problem. I have a split DB for stand alone PC, for Inventory. I have many tables and forms. Some of my forms are tools or Utilities I either downloaded or made to change table info., Like a form to purge table data for Parts or add Ver number or set security data. I may have a table with users with their info. I could make a copy of my FE and strip out the tables and forms they don't need after I setup the Parts table. I was looking at starting a 2nd DB linked to my FE with the files only I need and then make a copy of FE to send to others after setup has been complete. I could make a copy of FE and then have a form to strip all info. not needed and setup tables. (maybe the way to go?) 4,480K FE file.
Thanks!

[Minty]

That's not a big FE file.
I have quite a lot that are 70-80Mb where there are loads of forms/code and reports.

If you are on about removing unused tables that makes sense.

I sounds like you are maybe thinking of creating multiple front ends for different parts of the process, just don't!
It will become an absolute nightmare to maintain.
Simply restrict access and compartmentalise the various sections if that is a concern.

[MadTom]

This is my plan, I'm going to create a form the will setup my tables, delete unwanted objects and code, copy and rename my FE and BE to be shared. I can also keep track of all copies in my DB of who has what. Copy would be xxx Parts FE and xxx Parts data in a new split DB to share.

[Minty]

I'm still not clear about what xxx Parts and xxx Parts FE really represent.

I have VBA code set up to adjust various forms and objects to be visible and not open in a modal fashion in some larger databases, which when you are developing is a PITA, but I still only have the one FE for all users.
The automation can only be run in the immediate window of the editor and is only for my use as the developer.

MakeProd True

This simply automates a host of adjustments, re-hides various tables other things I don't want end users "Stumbling on" even the super admin end users who can access the navigation window.
I don't delete the code or any f the tables that drive certain development only features, there is no point. I'd end up maintaining two versions one for me one for the end user.

Beyond this all the different DB features are accessed only by those users that have sufficient privileges determined by their login.

[Gicu]

@MadTom - If your "tools and utilities" are only needed to perform very infrequent tasks on the data you could have a small separate db for admin tasks that you never share with users, or you could even store them in the back-end itself (you can add code in the forms to check who the user is and stop anybody else but you to open them). Or you can leave them in the front-end and restrict access to them based on a custom access level structure for your users. Please have a look at my free utility that you can implement to segregate access to various objects: http://forestbyte.com/ms-access-util...access-levels/

And you might also want to have a look at my free front-end updater or many others available on this forum:
http://forestbyte.com/ms-access-util...a-db-launcher/

Cheers,
Vlad