DB Management, Switchboard

[mjdemaris]

I have a couple of questions to post here. I am working on a sizable project and would like to be able to switch between Dev mode and Prod mode easily. I am considering creating a table with version numbers and using a module descriptor such as 'INV' for the main Inventory objects. Then, I think I could build a form that would allow me to select/enter which module of the app I want to test in Dev/Prod mode - which would then enable or disable certain code so I can open forms without going through user login/validation, etc.

Then I remembered seeing posts on Switchboards. I just used the wizard to create a Switchboard form, but there is nothing on it. It's continuous form, no code... I've never used a Switchboard and don't really know what it's supposed to do.

On an old thread, Gemma states he uses the 2003 Switchboard, even in later versions.

So, what are your thoughts on creating something to switch between Dev/Prod mode easily?

And, does someone have an example Switchboard or management system they use whilst building and testing?

Thanks,
Mike

 

[theDBguy]

Hi Mike. I am not sure you're really looking for a switchboard (unless that term applies to more than one application).

The built-in switchboard is merely a menuing system to quickly allow the user to go through the different parts of the database.

I am thinking what you need is more like a form or code to quickly switch the data connection between dev and prod BE. I have seen several demoes for that.

However, if you're trying to test new functionalities of your FE, I would think it is better to simply have two separate copies of your files. One for dev and another for testing. You could put them in separate folders. You could then put a copy of the test or prod BE into those folders.

So, when you need to add new features, you open the dev FE. When you want to test it, you create a copy and put it in the test folder and run it from there. When you're happy with it, you can deploy it to prod environment.

Just my 2 cents...

 

[jdraw]

I suggest you keep Dev and Prod separate. If the only thing saving a terrible/accidental change is you at the keyboard, then keep them separate. Don't put you PROD CODE AT RISK. You could have a third area Test/Maintenance, and move/import materials from either DEV or PROD for "testing" as needed. Ensure you have a good procedure(s) for starting test; importing objects; review/document tests; replace PROD modules/objects carefully. Also, make it simple to BACKUP materials being tested.
There's nothing worse than the "ooops did that just update prod" feeling!!!!

 

[mjdemaris]

Yeah, I get that!

However, I am not currently running a production version yet. Have not even split it yet. I suppose I should preface this with 'I basically go with the rapid design/development (prototyping?) idea.' Meaning - I design, build and test all at the same time, basically.

And I must admit I do not have this:

good procedure(s) for starting test; importing objects; review/document tests; replace PROD modules/objects carefully

Honestly, I am not sure how to develop such procedures. I usually find something to add/missing/errors, etc and fix it.

So going back and forth between Dev/Prod, at this point, means I want to open some forms without a block of code running that would normally run in my envisioned production. One issue with having two separate files whilst I am still building is that I would need to comment/uncomment code in several forms before testing.

For instance, my user name is set to provide special access, but if I want to test with someone else's, then I need to comment out a few lines in the forms I want to test.

Thinking this over, I could use some good tips on creating such procedures and on how to build a library of modules that I could easily import and black box test, so to speak. I noticed a while back someone shared a pic of a million folders with various utilities, made me jealous, lol.

 

[Gasman]

You could just set a global variable or tempvar to show what mode you are running?

 

[jdraw]

I agree with Gasman --use some Tempvars (or some very simple set up) so you can differentiate GenUser from AdminUser.
I would not be naming anything PROD based on your description of what you are doing. You may have DEV and ACCeptable. But you need some parameters for your own good. My guess is you are working in trial and error mode.

You may get some ideas from my Stump The Model. I recommend a high level model to ensure scope is correct; then more detailed model(s) as specific areas/info evolve.
Do you have a naming convention (alphas, no spaces in object names)?
Do you describe fields along with meaningful names?
Do you have test data (good and bad)? You need it to successfully validate things
Do you have some sort of business rules?
Do you have documentation/reference material on Who does what, when, how much, how often...?
You should determine and document what makes "something Acceptable"/quality assured.
Do you have any separate/objective testers/accepters?

There are lots of articles/tutorials in the Database Planning and Design link in my signature.

You may find this thread helpful.

 

[mjdemaris]

@Pat Hartman It sounds like you have a form open (like a menu/switchboard) while you are developing; and when it closes, your code backs up your files. I could probably find a way to do that as long as I don't hit the 'Close all'.

I would like to know how you export your objects to text, and how would you recover using it?

For security, and thinking along the lines of @Gasman, I do have user tables in place for permissions, though the group thing is a bit of a headache around here. There are some things that only a manager should do, but if he takes time off, he then asks one of his team members to do it, who would normally have lower permissions. Anyway, getting to Gasman's point, I was thinking of using a table to store a value that would indicate if I'm running forms in dev mode for me, or wanting to test other user's permissions, then assign that to a temp variable so each form could check that value and run the corresponding code.

I might be overthinking this a bit, now that I reread it and your guys' replies. idk.

@jdraw I do have naming conventions, and some sort of business rules. As far as who does what, etc. most of that is in my head. And as I mentioned above, some of it changes if people are on vacation, and those other people wouldn't normally perform those actions/duties.

As far as what makes it acceptable...not real sure. Since I am one of the main end users, I do have an idea of what should be there and what kinds of things I don't want users to enter in, though I am still working on validation as there are some exceptions to the rule.

And as far as testers, not really. Just me. I do ask for feedback and ideas, though. Almost everyone else just wants something that works, and if it don't, well I hear about it!

I will have a look at those links as well, jdraw.

 

[jdraw]

Here's a write-up on Business rules to help with the kind of things involved. There are some helpful and humorous short videos on Business Analysis by BA_Experts. I really recommend that you build a model and vet/exercise it with sample data and sample scenarios. It's difficult to underestimate the "tweaks" you will discover in the process AND it is much easier to make changes at the logical model level than in a physical database. This is more a journey than an event, but it is a learning experience. The vetted model becomes a blueprint for your database.

...though the group thing is a bit of a headache around here..

Using the group approach and assigning userIds to Groups may resolve that headache. It can be a flexible approach to simplify changes and additions.

 

[mjdemaris]

Current Login setup:
1. open app
2. Autoexec checks for me
3. If normal users, open Welcome form.
a. check version info, update if necessary
b. initialize temp vars
c. get user name, id, dept
d. hide nav pane, ribbon
e. open Logout timer form, which stays open
f. if the login is a generic maintenance, open another form to allow them to select
their name. close this form
g. open the Menu form, which allows users to do various things, depending on their duties
h. close welcome form
i. Logout timer form checks for a boolean value if i need to close the app for an update.
4. If I open the app, Logout check form opens if I need to force logout and shutdown, then the timer form,
then a login form opens that allows me to 'login' as another user.
a. check version info
b. initialize temp vars
c. get user info
d. open Menu form

So the Logout Timer form is the one that stays open fulltime. (I don't remember who I got this setup from,
I should have entered it in a module header somewhere when I first used it. (Scott, Allan, Pierce...)

The main reason I hardcoded my user info into the forms was so that I wouldn't have to go through several forms each time I
wanted to make design changes and test how it works.

Being a girl and one to leave the oil changes to the garage, I had no idea that the dipstick told you how much you needed to ADD

One of the first things I teach them when they want to drive, check the fluids and other basic driver maintenance. (They don't usually stick to it tho, lol.)

50 years is a long time to be doing this...my hat's off to you, Pat!

Jdraw: Going through the business rule/data modeling stuff...my head spins. I've done reading before on this topic and have tried to formulate some of it, and even attempting to create some graphic models. But man! I tend to get turned around and lost real quick. Then I tend to jump in and build, then I forget about the design docs, lol.

 

[jdraw]

...Then I tend to jump in and build, then I forget about the design docs, lol....

We've all been there. It's very satisfying to write some code and run a test and confirm that it "works as planned". If, as Pat has mentioned, you have 50 years experience and intimate knowledge of the business, and explicit requirements, and independent reviewers to vet interim results..... then by all means jump right into coding. But without those things better to work on incremental pieces in a prototyping way to ensure and confirm the purpose, design and operation of the piece meets the requirements. With experience you'll find that happy middle ground that works for you. Just remember there's nothing worse than a misunderstanding of basic requirements that results in a system that doesn't do what was expected.

Totally agree --50 years is a long time to be doing this.

 

[digitioo]

Good information you solve my problem. Thank you!