Your ideal Developer's form (1 Viewer)

[zeroaccess]

What would it have on it? Talking about at the database control and development levels, not doing simple things like adding users or adjusting privileges. I'll start. It would be nice to have an Developer's form with controls to:

• Kick out all users within a specified time
• Set flag to lock the database for maintenance
• Enable/Disable shift bypass (with plenty of warnings in case you accidentally bump it)
• Load an alternate Login form that skips startup code (avoid hiding toolbars, etc) for development
• Create a new form with preset styles and properties
• Apply styles/properties to existing forms

What else would you have on your development form?

 

[arnelgp]

much better to have a Separate db (not form) with unrestricted access to msa objects.

 

[CJ_London]

agree with arnel in that separate db for developer functions, but currentdb for admin functions. Of your list, I would perhaps only consider the first 2 to be admin.

 

[HiTechCoach]

How I handle this

Developers and deployment tools are not the same as admin tools. Admin tools are deployed while the developer's tools are not.

I have tried both ways, but found Admin tools are best in a separate front end. (items 1 and 2)

I deploy all Front Ends as compile databases (mde/accde).


At startup, I check to see if the front end is compiled.

I use this as a flag to do things like if it is the developer user logging in and not compiled then "skipping startup code (avoid hiding toolbars, etc) for development "


After I compile a new front end, I open it and log in. Relink to the production back end. The startup code automatically checks for compiled and locks it down for deployment automatically. That is all I do to prep for deployment.


About these:

• Create a new form with preset styles and properties

I have a database of template forms and reports that I simply import as needed. This makes cleanup before deployment easier.

• Apply styles/properties to existing forms

I use "theme" code to automatically apply styles when forms load. I have adapted it to add the option for users to pick a light or dark mode color theme.

 

[zeroaccess]

Maybe I should have been more clear. I'm talking about a form with controls on it that can only be opened from the developer's .accdb file, that aids the developer in performing tasks quicker and easier.

We could certainly come up with an ideal admin console that exists in the deployed .accde, too - it's just not what I had in mind.

Agree that a kick out and lock needs to be in a separate db because you need tables closed.

 

[HiTechCoach]

Maybe I should have been more clear ...

When dealing with programmers/coders it is always best to be as specific as possible or you will probably not get the answer you are looking for.

When you a programmer/coder an open or ambiguous questions

Here is what they hear:

Select Answers FROM Knowledgebase WHERE Question like "How to *";

Like in the movie Phenomenon, where is what it is like to ask a programmer/coder a question:

 

[zeroaccess]

What would it have on it? Talking about at the database control and development levels, not doing simple things like adding users or adjusting privileges.

^ Well I thought my OP was pretty clear, but yeah.

Anyway I thought it would be cool to see others' ideas or things they already have in use.

 

[HiTechCoach]

^ Well I thought my OP was pretty clear, but yeah.

Anyway I thought it would be cool to see others' ideas or things they already have in use.

I agree it would be an interesting discussion.

I think part of the confusion is the forum used.

If this were posted in the forum Theory and practice of database design and you stated clearly on the first line that you were opening discussions about ideas for what other people used then you probably would have got a different response.

Not sure what you were after, I shared the key things I do to make it streamlined but they had really very little if anything to do with forms.

I find it best to do the admin function outside of the primary and most used front end by the users. For 20+ years I had a separate user/data entry/daily function front end and a separate "Application Manager" front end for adding users, maintaining lookup tables, configuration, etc.

I do this for several reasons. The main reason is that it keeps the primary/most used front end as small and "lightweight" as possible. It also makes testing easier with fewer objects.

I found from looking at the activity logs that the Application Manager can go months without every being access. It makes sense to me to move rarely used objects to a separate front end.

About:

• Kick out all users within a specified time

I have rarely had to do this. I do not want to add the overhead of a timer event to do something that I rarely would use. If I need to disconnect users, I use Windows' built-in tools. I do whatever I can to make it best for the users.

• Set flag to lock the database for maintenance

I keep it simple and use a text file for the flag.