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.
Related
I've built an MMORPG that uses a MySQL database to store player related data when the user logs off.
We built in a auto save timer so that all the data of every logged in user is saved to the database every 3 hours.
In doing so we noticed a fatal flaw....
Due to the fact that all our database transactions are sent to a single DB Thread the thread can become backlogged with requests. This produces a login/saving issue. When this happens players unable to login as the login process requires the use of the DB Thread to confirm login credentials. Similarly all save requests are queued to the back of the DB thread schedule. This produces a backlog of requests...
The only solution that I can think of for this is to introduce multiple threads and have 3-4 threads interacting with the database.
However, this opens up a new issue. Since multiple threads are sent DB requests this means that one thread can receive a save request from a player while another DB thread receives a save request from the same player.
For example....
PlayerA Logs In to the game
3 Hours pass & the auto save happens, playerA's data will now be saved.
PlayerA kills a monster and gains experience.
PlayerA logs off, which adds a save request to a DB thread.
Now we have two different save requests queue'd in the database. Assuming they are both assigned to two different DB threads, this could cause the users data to be saved in the wrong order... For example maybe the the thread handling PlayerA's log out save runs first and then the auto save for PlayerA runs after that on a separate thread.... This would cause loss of data (in this case experience).
How do other MMORPG's handle something like this?
You need a database connection pool if you're not using one already and make sure you're not locking more data than you need. If you are saving how much gold a player has, you don't need to lock the table holding the credentials.
Keeping the order of events in a multi-threaded scenario is not a trivial problem, I suggest using a message queue, a single producer per player and a single consumer per player. This link shows 2 strategies to keep the order.
A queue is actually important for other reasons. If a save request fails, it would remain in the queue to retry later. When dealing with players money and items, you probably want this.
Your autosave is deterministic, meaning that you know exactly when the last one occured and when the next one would occur. I would use that somehow, along with the previously suggested idea to add a timestamp. Actually, it might be better to make the updates represent only the increments/decrements along with a user timestamp and calculate the experience upon request ( maybe cache it then)
To avoid this problem in all cases you must not allow users to continue doing stuff before their last database transaction has been successfully committed. Of course that means that the DB has to be very fast -- if it can't keep the request queue below a couple of seconds worth of transactions at most, you simply have to make it faster. More RAM cache, SSDs, the usual MySQL optimization dance. Adding extra logic in the form of triggers etc. isn't going to help in the long run, especially because they can become really complicated in the case of inventories and the like.
If on average the system is fast enough but struggling in peaks like when everybody logs in during lunch break, adding something like Redis as a fast cache might help. You'd load the data into Redis when a user logs on (or when they first need a certain piece of data) , remove it when they log off or when it expires, and write changes back to the relational DB as fast as it can keep up.
I have a problem related to automatic task scheduling.
Currently i am able to find out when my customer has last credited his account, how am i able to find out whether he will pay anything in the next 3 days?
So if no payment has been made in the next three days for any customer, to automatically alert me preferably by a notification directly to my ipad.
I dont want myself to open the app for checks to be done only when i log in, because then if i jump on my application 6 days later, i could have had a customer that hasnt paid in 6 days when the app should have alerted me on the 3rd day so i could ring my customer up to deal with the matter.
I need to work in this matter due to the structure of my application and business.
I am able to monitor everything else but need some insight on how I can go about doing this. the current notification system inside the phone only fires based on time, and I cannot do interval checks where maybe i could run a background task, if that would work then i would have done it like that but thats not the case.
Pavan
If I understand your question correctly, you should compute the interval of the event that you want and post a wake-up timer that is that period of time from "now." If you need it through the notification center, then just handle it silently and clear it from the notifications.
Based on the discussion below:
You will need a little bit of server work. APNS looks complicated, but it really has very few moving parts -- especially if it is a private App. What system component is keeping an eye on Amazon? Do you have an App or web server? For example, if I were to poke a record into your system (purchased services) what workflow is triggered to notify Accounting to process an invoice and collections at a later date? Am I making any sense of your system architecture?
Perfect - you are done. You have all the system components you need and the rest is coding. The server app processes the accounts DB and finds new entries. If found, it publishes a record ID to the APNS server (Apple owns this server). You write code to register to receive the push-notification (subscriber). When you get a push, that will wake up your registered app with the record ID (and some other subscription stuff for bookkeeping -- but you are the only subscriber and only subscribing to one DB table -- so you can largely ignore. Now turn around and query based on that record. Done!
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
I need major help!!! I am designing a game that will be at a tradeshow which means lots of people walking by. The problem it seems is that once kinect sees you "New user" even if you are just strolling by it seems to kill or mess up the ONISkeletonEvent.USER_TRACKING data when that user is "LOST".
Please if you have any ideas I need them fast! This thing needs to ship end of week. I thought I could handle this by assigning an activeUserID and filtering based on that but it just doesn't care. When it "LOST USER" it is game over even if that was just someone watching and then moving away.
PLEASE HELP!!!
OpenNI identifies each user with a unique ID. Each event message comes with a user id which connects the message to a particular user.
Once a user has its skeleton calibrated, you can skip further calibrations for other users, thus limiting the skeleton tracking to the first user who completed the skeleton calibration procedure.
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.