I'm making a database up Microsoft Access to help simplify my job, but I'm relatively inexperienced with it, so I need some help. I'm running Access 2016.
I have a database set up for when students enter the IT Office seeking help, which essentially just records when they enter and what they're here for. So I've put a form on, which lets you enter your information, like your student number, what your problem is, and what your laptop number is. The date and time of your entry are automatically generated by the system clock. The student then presses "Check In", which creates a record based on the information they've just entered to keep track of problems. So here's my question, how would I conveniently give them an option to check back out? I need some way to update the record they've just made, without giving them access to all of the other transactions. I managed to make a list box which makes a list of all the student numbers of people who've entered today, but I'm unsure how to set the check out time of the student when they leave.
Hopefully I've explained that well enough. If you need me to clarify, please pop in a comment.
Thanks everyone.
For users to re-find their record, and not be able to look thru other records - you essentially just need an ID field that they type in; and use that as the query basis for the look up. Possibly the name they entered could be used if you aren't passing out trouble ticket IDs.
The check out info really doesn't have to be a separate table. It can all be part of the same record as the original check in. You can have a separate check out time stamp field that gets populated by a check out button.
The check in and check out may look like separate sides to user - with separate forms that is fine - but behind the scenes I see no reason to have separate tables. keep it simple.
www.CahabaData.com
Related
[Note: There is a Teacher Object with the fields such as Teacher Name, DateofJoining, and also a formula field called Experience]
My Task was to create a Public Group consisting of another user
and this user should only see teachers who have experience greater than 2 years
But when i create a sharing rule based on criteria the field name called Experience doesn't show up as it is a formula field.
So i got an idea of creating a new field(maybe a text or number data type) which would have the value of Experience in it. (But i have no idea on how to implement this)
Is there a way to implement this?
Any other solution is also well appreciated!
Hard to say.
Normal trick would be to create a helper field (text, number, whatever) and have piece of functionality that populates it. An "early flow" or "before insert, before update" trigger ideally. Worst case a normal flow, process builder or "after insert, after update" trigger. Something like "if Experience__c != 'your formula here' then Experience__c = 'your formula here'". Consult normal SF help and trailhead if you never used early flows
You'd make an one-off data fix to populate existing records and job done, normal field should be selectable as sharing rule criteria.
=====
But I smell trouble with your formula. What exactly you have there, something like Experience__c = (TODAY() - DateofJoining__c) / 365? That's bit evil. Formulas with TODAY(), NOW() or anything with $ (roughly speaking who's looking at the data, user's name, profile role... not what's actually on the record itself) are "nondeterministic". Unpredictable.
A "today()" changes just like that, without updating the record. Sure, when you watch the record a fresh value will be calculated but other than that LastModifiedDate doesn't change, there's no magical trigger running at midnight that rechecks sharing. (especially that there's no single midnight, you could have users in multiple timezones). SF just doesn't allow nondeterministic fields in many places, see https://salesforce.stackexchange.com/q/32122/799
So if you do rely on TODAY() in your formula you might have to make a "scheduled flow" or read about schedulable, batchable apex. Create nightly job that would run and recalculate your helper field with right experience. You'd probably even need both solutions, a "before save" flow for new data created today and nightly job to advance the clock on existing old data...
I have a question regarding database/system design. We have a table user with user_id and a table school with school_id. We want to implement a feature so that users can add schools to their "favorites list". I already created a third table that contains the relationship between user_id and school_id. Now I have the two following questions:
When a user removes a school from "my favorites" list, should I delete it or keep it in the database but mark it as "deleted"? I want to keep it but it might leave tons of junk data in the table over time.
The front-end design looks similar to like/dislike button on twitter. User can favorite/unfavorite a school with one click. Is there any good way to prevent a bot from constantly hitting the the database by clicking the button?
Thanks in advance!
The answer depends on your application's logic. Both suggestions are ok.
If you need this data sometime in the future or if you are saving history of user actions then you can mark it as "deleted", else you can delete it immediately.
(another approach is mark it as deleted temporarily, and have a periodic job that cleans the table)
I don't have enough experience with this kind of threat, but a simple solution would be is to limit API calls per second per user
My requirement is I need to be able to track time for each sales person on activities. Also a report that administrators can run to see the amount of time each user spent working on calls/sales/opportunities etc.
What should I use to track how long is user using particular activities?
I think I can do it using auditing.
Do you have any better ideas?
User Auditing isnt going to be much help here, for starters it only reports every couple of hours and secondly you cant write report against for the audit table.
I would suggest adding a duration field to entities you want to track time against - activities already have a field for this. Then users just have to manually populate this.
Or if you want to automate you could use form JavaScript, for example:
New Field: Number, Duration
On Form Load: Capture a start time
On Form Save: Capture an end time
On Form Save: Work out the difference between the two, then add to the duration field
You would have to do this for every entity you want to track though. Its also not guaranteed to be accurate, for example if a user opens a couple of records at once, or goes to lunch, or just doesnt save the record immediately a much longer Duration could be recorded than actually occurred.
We have a customer that insists on putting contact details, at this time first and last names, into a single field. Take, for example, Mr. Bob Smith and Mrs. Jane Smith. Mr. Bob and Mrs. Jane would be entered into the first name field and Smith would be entered into the last name. It gets messier if the contacts have different last names or if there is a hyphenated name. The customer only wants one contact record so they came up with this system and implemented it on their own.
Our system is designed around contacts and each individual person is intended to be an individual contact, even married. Due to some of the attributes we must assign to people and notes we need to keep, a contact-centric approach is best. The above issue occurs in about 1/3 of the cases we handle.
Internally, my team has discussed how to sell the customer on using the database the way it was designed. We listed form letters and contact lists as being the main reasons for keeping the data clean and in the fields we designed. For example, using our recommendation, the customer will have much more granular control over form letter creation and sorting of data.
Any suggestions for how we sell this to the customer?
Tell them what they can get out of your system is only as good as what gets put in. If they want to enter inconsistent data, the cost they'll pay down the line is the inability to generate letters or mailing lists in the future.
They may need to learn this lesson the hard way for themselves. I see more problems with switching the names, for example, entering Smith as the first name and Bob as the last.
Also, can you make both fields required?
It sounds like what they want to enter is similar to AddressLine1, AddressLine2. It's just a poor design, I thought you had 2 name fields but they would only enter data in one of them (the first name).
All you can do it try to help them when they ask for it. They'll get the system they deserve.
Just show your customer the normal forms for database design:
> http://www.phlonx.com/resources/nf3/
Tell him that these normal forms are designed to make the database more manageable over time and make it more flexible.
Can't you just create a view that holds First and Last name together? For some servers you can also create editable views... So your customer will be happy and data will be stored normalized.
I'd try to put it in terms of money and time. You're going to spend more time trying to keep duplicates out of a db with their design, more time building relevant reports or queries (constantly having to parse a block name field... do they want address all in one too?!?), more money to scrub the data (either themselves or someone else) if they ever want to send the data to a third party for analysis and metrics.
It sounds like they don't want to let go of their design, maybe partly because they understand it. You may want to try and meet them halfway somehow at first, and involve them in the process of making incremental improvements to the design. That way they can see and understand the benefits that right now may just be over their head, pushing them out of their comfort zone. They have to trust you with their baby :)
The best argument is that you won't be responsible for the behavior of the database unless they put things where they belong.
If they want to make a single mailing to each "household", then I'm sure your app can do that. (Probably already does.) Y'all just have to come to terms on what "household" means. Since there may be rented rooms or long-term guests, it doesn't always mean "only one mailing piece per address".
FWIW, I've been doing this stuff for decades, and I still find doctors and attorneys (and their staffs) the hardest people to deal with. One time, I walked out of a meeting (and, of course, lost the chance to bid on the contract) when a doctor's IT guy stood up, pounded his fist on the table, and screamed at me over and over, "Doctors are not people! Doctors are not people!".
I am writing an application where I have some publicly available information in a database which I want the users to be able to edit. The information is not textual like a wiki but is similar in concept because the edits bring the public information increasingly closer to the truth. The changes will affect multiple tables and the update needs to be automatically checked before affecting the public tables.
I'm working on the design and I'm wondering if there are any best practices that might help with some particular issues.
I want to provide undo capability.
I want to show the user the combined result of all their changes.
When the user says they're done, I need to check the underlying public data to make sure it hasn't been changed by somebody else.
My current plan is to have the user work in a set of tables setup to be a private working area. Once they're ready they can kick off a process to check everything and update the public tables. Undo can be recorded using Command pattern saving to a table.
Are there any techniques I might have missed or useful papers or patterns?
Thanks in advance!
I would do it like this:
Use insert only databases, you never update data only add new rows
Each row has a valid from date, a valid to date and who made the change
Read the data through a query where the valid to date = null, and the row is approved, this gives the most recent row
When a user adds data, he can see his changes by selecting the last row that he added
When the user is happy with the changes he has made he can mark them as approved
When they are approved they can be seen by other users
Undo is not a problem since you have all the previous versions, you can mark a row as no longer being approved and revert to a previous version.