On Server1, i want to schedule a job (JobTest). I want to schedule this once another job(JobLive) is completed.
Job Live is on Another server (Server2)
How this could be done.
Please respond with your valuable information.
Jobs can only be scheduled to run based on a given time of day. They cannot be scheduled to run based on the completion of another job or any other type of condition.
One way to get what you seem to want to is to have the first job add a record to a table that the second job will have access to, and put a step in the second job to check the table, and if the record is not there in the table, don't do anything. Then you would need to schedule the second job to run throughout a range of time, so that it keeps trying until the record is there in the table. Then when the second job completes, it deletes the record from the table, so that it won't run again until the first job runs again.
Related
We have created CRON jobs in MySQL where some run daily and some run monthly.
We can see the list of events(jobs) using the following command -
show events from database_name
To identify the execution of an event, logs table was created, and a record was inserted in the logs table whenever an event was executed.
Even though the event is shown as "enabled", the corn job is not getting executed at the set intervals.
Is there a way to identify if the CRON job is properly configured?
Note: We are using MySQL Workbench.
If yes, please share the details.
Thanks in advance!
I would like to be able to have a MySQL record automatically deleted after 60 minutes if one of its columns hasn't been updated to a certain value within that period. I can set up cron jobs in my hosting, but I'd prefer to have more granular or exact (time-specific) control over the timing. I can't think of what would constitute the trigger (other than a cron job). Is it actually possible?
You could design your application/cron-job to schedule deletion of rows when they become close to expiry, so that they delete at that specific time. You would need to double check the row is still eligible for deletion at that time just before deleting it, in case it has been updated since.
I have Mysql database where tasks are inserted. Sometimes they are inserted by 1 or 2 per time, but sometimes they are inserted by 1000 or even more per time. I have workers on multiple servers which are ruled by listeners on these servers. One server = one listener. Listener selects tasks, that are not done yet and that are not in processing right now. It selects an ID of the task and status. If status is empty, then the task is new and we need to proceed id. Then we update the status with an id of server listener (unique) and that means that this server wants to get this task. Then we select tasks using this unique id of the listener and see if there was an attempt of the another listener to do the same at this time. We can see it if the status contains another id. If it is so, we skip the task and continue but if an id is ours we update the status to the processing state indicating our id only if the id in status is ours. After this step we can process the task.
The question is why could happen the situation when some servers process the same tasks? And how to avoid this?
In sql server job have two steps and two schedules with different time and date. Now i want to setup one step to one schedule and another step to another schedule.
Please let me know the process of setup.
Thanks.
Someone correct me if I'm wrong, but I don't believe there is any way to schedule a step. The schedule applies to the job... In other words, you need to break your job with two steps into two jobs with one step each in order to schedule them for different times.
Part 1 is #Clay's response
If you still need a cheat code then
Schedule the job for a certain time and in your steps check for the server time and then decide if you want to execute the step or not for e.g. a stored proc could be a good place to check.
I have a problem which I cannot seem to be able to resolve: I'm creating a login process for an application; anytime a user attempts to login and fails, an attempt record is inserted/updated up to 5 attempts. After the 5th attempt, the account is locked.
I have 2 tables for that process, the 'user' table where the user information is kept, and the 'attempts' table.
First, I don't want to use a session or cookie variable for the counting of attempts (cookies can be deleted, and session variables can become too much, since it's a high traffic site); I plan to use an update statement to increase the number by 1.
Here's where the confusion starts:
First, I'm not sure if I should update the row in the attempt table, or just insert a new row for every attempt (my preference is to insert on the first attempt, and to update the row on the remaining 4 attempts).
Second, I need a way to indicate that the attempt being made today is completely different from the one yesterday. For example, if a user attempted to log in yesterday, and succeeded after the third attempt, and then today, he attempted to login again, I don't want the attempt to increment yesterday's attempt. So, in a way, after every successful login, I need a way to ensure that any attempt after a successful login starts a new login process by itself.
I'm not sure if my question is clear. Please, ask for more clarification if needed.
I've racked my brain for 2 days without a solution to this process.
Thanks
P.S: I'm using stored procedure for most of the processing to eliminate the traveling back and forth for the processing.
Rather than have a separate table for login attempts, simply add a counter as a new integer column on the user table. Each time a failed attempt is made, increment that column for that record. Each time a successful login is made, reset that column to 0 for that record.
If you need to keep a running audit of all attempts, that's a separate concern. Auditing isn't part of the login process. For that concern you'd write failed attempts to some kind of audit log. This log can be a table in the database, but shouldn't be linked to the transactional tables in any way. And it can be a general logging system for all kind of application events, not just for failed logins. (Again, another concern entirely.)