I'm creating a database that registers working hours.
People can introduce start working day, when and how long they take lunch break, and the end of the working day.
All works well, and I've created some tables that proplery catch the time.
BUT my manager wants to prevent that people can change their working hours the next day (unless of course the field is empty because the user forgot). The user should only change his working hours when the admin (manager) gives access via a password.
Note that I've created a separate database for each user (which is automatically created when the user registers) due to the need for password protection.
How would I handle this best? I don't know if locking records would work (?).
Locking controls doesn't have a purpose, because the user obviously has manual access to his own personalized password protected database.
I could provide code, but the code I would provide would be useless to this specific problem...
(I've got a hundreds of lines by now, all not really anything to do with this specific problem).
Thanks for your suggestions
Related
I don't know if my idea is possible to solve with MS Access. The requirement:
I have one centralized DATA-database and several Client-Databases. It will be used to maintain a rescue team in our company. Each one has to press a button in his client and in the reception client is visible who is available in case of an emergency.
It even shows who is in which corner of the building the rescue person is.
Now, it's in human nature that in evening People forget to logout. Plan is to define a usual end of work time. The reception client verifies every 5 Minute if someone reaches his end of work time and can set him as out of office.
Problem is, perhaps Mr. X works today not until 17h as usuall - today he is available until 20h.
So, a message should Pop up 15 Min before his end-of work and ask him if he goes by time or not. If he answers to work longer, a flag should remove him from this function today.
Solution is almost 70% developped. Problem is now the little point, how to pop-up the message to the right user. One Idea is to check a message table if there is a message for him.
But, i don't like to make to much LAN traffic... if each client ask every 5 minutes the DATA DB if there is a message for him.
Has some one an idea?
Best regards
Roland
Polling a single table every 5 minutes should generate virtually no load. I've used a similar solution that polls every minute without any trouble on a networked database with ~20 users.
You can, of course, pull in these messages once, since they will fire at a set time, and then just raise them at that time.
You can just have a hidden form that's bound to a specific table, uses a filter on the username, and requery every x seconds, tests if there's a message ready, and then displays it.
Alternatively, you can pull in messages once, and have a hidden form that checks on timer if it's time to raise that message.
So this morning I was looking at our company's database users and it was a great mess, with some big potential insecurities. Since most colleagues where around I decided to gather them around and decide which users to delete.
Now I forgot one colleague uses powerbi and he wasn't around (a lot of different dashboards) and it will take some time for him te replace all the data sources with a new user. So I was wondering if there is anyway I can find the users I deleted so I can see which one was used by him since you cant see which credentials he was using in powerbi.
If the general query log was enabled on your server, then you have a log of each query and the user that executed it.
Alternatively, enable the error log and set log-warnings to 1 or higher and then ask the user to try to refresh the dashboard. The access denied event will be logged into the error log.
So I'm looking for some clearance, or advice as it were. I've set up my login system to save information about a user every time they sign in. I.e. IP Address, the ID of the user they've signed into, the timestamp, etc.
Now, my question is...is this wise? The reason I've done it is for future reference, if I ever needed to look into someone's account. This way I'll be able to see and pull back the information regarding every single time their user account has been accessed. It will allow me to see if someone has been accessing their account who shouldn't have been etc.
However, as the population of the database grows the table of all logins is going to become massive because a row is inserted every single time someone successfully signs into an account.
So, will this have any affect on my database further down the line, or is what I've done here perfectly fine?
Thank you for any advice you can give.
Unfortunately the answer is "it depends". The factors affecting the decision include but aren't limited to your server hardware and number of active users.
In general I don't see a problem with saving this login data to a database table. If you don't need historical data for logins after a certain amount of time you can delete old login data to manage the table size.
I would try it and monitor the table size and system performance over time. If it grows too fast then reevaluate its importance versus strategies to optimize it and keep the functionality. It all depends on your specific situation.
I wouldn't skip capturing data I think is important because it might cause problems. I would test and evaluate it over time, then use real metrics to guide my decision.
I am working on a project, which will be used by around 500 employees in my organization. Currently, it's still in development phase, and very few people(around 10) are using it. I'm using MySQL. I just want to know, what happens if many users are doing front end edits and then save, at the same point of time? Some SELECT queries that I've written do take as long as 6 seconds to execute. As only one query can be executed at any point of time, if already a query is in progress, and another hits the database, will it create problem? If this is a common situation in large scale projects, please let me know how can I handle this. I'm not sure, if I've made myself clear :). Any advice or links will be very helpful.
From technical aspect, no - nothing bad will happen, the database won't go ballistics and die on you, they're made for purposes like concurrent access.
From logical point of view - something bad will happen. If two people edit the same thing at the same time and then post it at the same time - it gets saved to hard drive one after another. The last one to save is the one whose updates will be on the HDD, effectively causing the first person to lose their changes.
You can approach this problem from several angles. Some projects introduce the concept of locking (not table locking but in-app locking). It revolves around marking a record as locked using a boolean column and if anyone tries to access that record for updating, the software says that someone else is editing it. It's something really difficult to implement and for the most time it doesn't work as expected (I think I vaguely remember Joomla! using something like that, it was one of the most annoying features ever).
The other option you have is to save each update as a revision. That way you can keep track on who updated what and when and you never lose any records in case of would-get overwritten. I believe that SO and Wikipedia use that approach and it works really great because you can inspect what two or more people have done and merge their contributions.
Optimistic Concurrency Control
http://en.wikipedia.org/wiki/Optimistic_concurrency_control
Make sure that each record contains date metadata on last changed/modified time, and load that as part of your data object. Then when attempting to commit the row to database, check the last_modified time in the table to ensure that it is the SAME as the one stored in memory for your object. If it matches, commit it, else throw exception.
In my MS Access application I have several forms that are very data intensive (several subforms based on even more tables). My users are complaining that when opening the data across the network the load times are unbearably long.
I have do have a slit front end / back end setup using the excellent autofe application.
One solution I have come up with to the problem is instead of docmd.close when the user clicks the "Save & Close" button I me.visible = false. The user then has the long wait time the first time after the application is loaded but for later loads performance is improved by a noticeable amount.
So far this has been working fairly well. I am just concerned that there may be some hidden gotchas hidden in this strategy that I haven't encountered yet.
My users aren't overly intelligent and I don't use the application myself so I can't expect to get meaningful feedback if something is behaving erratically.
Anyone else employed this strategy successfully or know of a good reason not to do it?
Anyone else employed this strategy successfully or know of a good reason not to do it?
Yes, that strategy is similar to recipe #8.1 Accelerate the Load Time of Forms from the second edition of the Access Cookbook. However that recipe pre-loads a set of forms, with WindowMode:=acHidden, at database startup. So the tradeoff is that database startup takes longer, but subsequent form opens (for the pre-loaded forms) are comparatively fast.
The discussion for that recipe didn't mention any drawbacks for that technique. In limited use, I haven't discovered any. And since it seems to improve your users' experience, I would continue to use it.
Beyond that, I would take a hard look at the amount of data your forms pull from the back-end database. Limit the number of rows retrieved as the Record Sources for the main and subforms. Give the user a method to select a different record or small set of records. Also make sure you use indexing to support Record Source WHERE and ORDER BY clauses. Avoid WHERE conditions that use functions which will force a full table scan to figure out which rows to exclude from the Record Source. Similar considerations apply to combo and list boxes which use saved queries or SELECT statements as their Record Sources; if you can't limit the rows, at least make sure to optimize data retrieval.
At first, just hiding the form is not too bad, I think.
I would dig a bit more on WHY your load times are so long. You mentionned several subforms. Are they all displayed at the same time, or are they in the various pages of a Tab control ?
In the latter case, you could quite easily unbind the subforms that are not visible, and bind them on the PageClick event. That makes a big difference in performance.
EDIT:
Also, a bit out of scope for this question, but good for every performance issue:
-did you double check that the foreign keys in the related tables are properly indexed ?
-make sure the back-end is regularly compacted.
Are you making sure that the data gets refreshed in an appropriate timeframe?
Yes, I've doen the same thing myself in very complex forms which had about 10 or 15 tabs each with a subform. Worked for at least ten years. You had to watch for varous form level values or unbound controls which you assume start as null or zero. But once it's running smoothly it should run just fine. We had to this back in Access 97 days because Access would crash with out of memory errors after the users had opened and closed varous forms thousands of times per day.