I think it's in the tables

teemplaya

New member
Local time
Yesterday, 22:02
Joined
Aug 6, 2004
Messages
7
i'm putting together a db to track users who are assigned admin rights and/or have 'non standard software' installed on their machines (and why). i am in the early stages and believe my issue is in the table structure/design.

my goal is to open 'frmpractice_add_new', enter info and click on appropriate check box (for this example let's use the admin_rights checkbox) launching 'frmaction_reason' to enter reason user is being assigned (or has) admin rights (ultimately, i'd like to do the same with the 'nssw' checkbox).

I currently receive an error msg after I enter reason and attempt to close 'frmaction_reason'. i've attached db for review.

i'd really appreciate some help.

thanks,
teemplaya
 

Attachments

yes, i'd like to track both why users have been granted admin rights AND/OR the non-standard software they have installed. i've recreated my tbls and their structure, am I on the right track? what i've decided to do is create one main form consisting of user info and 2 subforms one using tbladmin_rights as control source, the other using tblnon_standard_software as control source. i haven't designed form because i've run into issue creating tbl relationships. initially the id fields in both subtbls were auto number but relationships could not be created...i've since changed to text data types. what do you suggest? the relationship between staff and admin_rights is one to one, the relationship between staff and nss is one to many. each staff can be assigned ar once but can possibly (and morethan likely) have multiple installs of nss. can you provide insight? thanks.

i've zipped another copy of db.
 

Attachments

First, let me thank you for the help. It is somewhat challenging for me to come up with proper tbl structure and relationships. I've studied your example and of course you make it look so easy....I hope to get there one day. It was very helpful for what I'd like to accomplish.

I've found that:

The tblnss is similar to your venue and tblstaff is of course your customers.

One staff member can install more than 1 piece of software and 1 piece of software can be installed for many staff (similar to venues form in your db).

Hence, the creation of the tbldoi (similar in function to your bookings tbl). I don't think I'll need the serial number field however, because, 'staffA' can install 'softwareA' on 01.01.05 and 'softwareB' on 01.01.05 and 'softwareA' can be installed later that day for 'staffB'. Please correct me if my thought process is a little skewed. To tbldoi, I've added upi, nssid, and doi as PK's and enabled Cascade Delete so if staff is removed, their software related records will go with them. QUESTION: If software is deleted, will staff be removed from tbl?

That's all for now. Please respond with your thoughts at your earliest convenience. If you find that I'm headed in the right direction, I guess my next step would be to add some buttons to add new record, delete current record, save current record and any changes recently made to db, and of course a menu screen.

Thanks again and I've included the latest .mdb.

teemplaya

Oh, and one more thing the upi is a unique preexisting number like a social sec. that must be entered. Also, I noticed as I was about to zip db and attach that the relationship between tbldoi and tblnss was incorrect. Don't I want to say that staffA can install softwareA and softwareB on dateC? But now that I think about it can't softwareC be installed on datesE, F, and G?

You see, this is so confusing for me? Please straighten me out.
 

Attachments

Users who are viewing this thread

Back
Top Bottom