I have a general question:
If I create an order via "createOrder: (data, actions)" and do not approve this "order". How long is OrderID valid?
Thanks in advance!
Benjamin
You can count on it being valid for 3 hours
(though the actual time before it expires can be as long as 72 hours)
If it isn't used soon after creation, you should simply generate a new OrderID whenever one is needed.
Related
basically i have the same problem with this and use this solution too https://community.tableau.com/s/question/0D54T00000C6aS6/datediff-in-lod
so i want to count time diff between transaction for each transaction and for each users, basically my problem is just like this
same with that, ON interaction id = user id in my real data, so i want to know time different between date transaction for each users.
based on that, i made this on calculation DATEDIFF('day',LOOKUP(MIN([Created At]),-1), MIN([Created At]))
and here's the results
what makes me confuse is, why the first transaction of users always have time difference, instead it must be nothing because there's no time difference if you do first transaction, so how to make it not appear?
Create a table calc field for First
FIRST()=0
Edit the table calc so it resets ever new user id.
Now filter for False. You can remove it from Rows, I just kept it there for demo. Your calculation will still work.
I am currently trying to create a rota within filemaker 16 and I can't figure out how to create records that share a date.
I want to be able to have people assigned to jobs and jobs assigned to dates but currently when I create jobs with the same date it creates a new record instead of assigning it to the one already existing.
I have 3 tables currently jobs, date and people. I have a 4th layout with a portal where I wanted to view records related to jobs that are set for a certain day.
Any help would be much appreciated.
Many thanks.
I am not 100% convinced you need a Dates table. Do you have anything specific to record about a date, other than its existence?
However, you certainly need a join table of Assignments, with fields for:
PersonID
JobID
Date
(this is assuming your rota is daily, otherwise you will need to indicate the shift or hours too).
I think your structure should change on this.
So instead have:
Parent:
ProjectId
Date
PersonId
JobId
Date
Then make the project Id your 'Primary Key' so your parent record.
Then you are just assigning the person, job & date as the child.
That way you can always add to the previous record without relying on date field.
You could then filter via dates etc.
I want to know if there is a plugin or somehow to notify via email to moodle users if they have not connected since xxxx date to complete a course.
Is there a way to make this automatically via cron or so?
Thanks.
You're question is a 2 in 1. You're asking how to identify users who haven't signed on in a while, and how to email them. I'm going to answer in parts accordingly. All of this can be accomplished via cron, but I don't use Moodle so I don't know what plugins are available to you.
He's an example of a query that would identify users who haven't logged on in 180 days (but it will ignore those who have never logged in).
SELECT * FROM mdl_user
WHERE lastlogin < UNIX_TIMESTAMP(DATE_SUB(NOW(), INTERVAL 180 DAY))
AND lastlogin != 0
AND lastaccess < UNIX_TIMESTAMP(DATE_SUB(NOW(), INTERVAL 180 DAY))
AND deleted = 0
Now for the email bit. Per Google, Moodle uses the PHPMailer for it's email_to_user() function. An example of using this in PHP:
email_to_user($toUser, $fromUser, $subject, $messageText, $messageHtml, '', '', true);
$toUser and $fromUser should be Moodle user objects, not email addresses. Traversing your query results to build these objects would be all that's left to do.
Last tip: To get a user object based on each result of your query, you can use the get_record function like so:
$userObj = get_record("user", "id", $userID);
Wondering the best SQL to handle below situation: Client only wants to see invoices that have been declined. I started with only show me when STATUS_ID = 2, but then realized that it was paid as it was resubmitted and accepted so that didn't work. What is the best way to handle 2 records like below where I don't want the SQL to return any records if manifest + order code have a 1. Would you do a Min on Status ID or something of that nature?
VENDOR NAME manifest ORDER_CODE STATUS_ID
VENDOR 12345 BHGSDKJF1234 RU07 2 (invoice decline)
VENDOR 12345 BHGSDKJF1234 RU07 1 (paid)
This trick can be work for you in this case, but it's not solve the general case (what happens if the STATUS_ID for paid is 3, and all possible values are 0-5?)
you can use in general SWICH-CASE clause, that gives you some 1 (true) if the client has STATUS_ID = 1, and 0 otherwise. Then, pick the MAX() for each invoice.
You can also consider another design that might work for you:
Add time\time-stamp column (Maybe, for your purpose, you can use SYSDATE time for insertion time of the record to db).
After you have a time column, you probably can choose the columns with the last time STATUS_ID for each invoice (get the STATUS_ID in the row with the max time).
I'm creating an virtual stamp card program for the iphone and have run into an issue with implementing my database. The program essentially has a main points system that can be utitlized through all merchants (sort've like air miles), but i also want to keep track of how many times you've been to EACH merchant
So far, i have created 3 main tables for users, merchants, and transactions.
1) Users table contains basic info like user_id and total points collected.
2) Merchants table contains info like merchant_id, location, total points given.
3) Transactions table simply creates a new row for every time someone checks into each merchant, and records date-stamp, user name, merchant name, and points awarded.
So the most basic way to deal with finding out how many times you've been to each merchant is to query the entire transaction table for both user and merchant, and this will give me a transaction history of how many times you've been to that specific merchant(which is perfect), but in the long run, i feel this will be horrible for performance.
The other straightforward, yet "dumb" method for implementing this, would be to create a column in the users table for EACH merchant, and keep the running totals there. This seems inappropriate, as I will be adding new merchants on a regular basis, and there would need to be new columns added to every user for every time this happens.
I've looked into one-to-many and many-to-many relationships for mySQL databases, but can't seem to come up with something very concrete, as i'm extremely new to web/PHP/mySQL development but i'm guessing this is what i'm looking for...
I've also thought of creating a special transaction table for each user, which will have a column for merchant and another for the # of times visited. Again, not sure if this is the most efficient implementation.
Can someone point me in the right direction?
You're doing the right thing in the sense of thinking up the different options, and weighing up the good and bad for each.
Personally, I'd go with a MerchantCounter table which joins on your Merchant table by id_merchant (for example) and which you keep up-to-date explicitly.
Over time it does not get slower (unlike an activity-search), and does not take up lots of space.
Edit: based on your comment, Janan, no I would use a single MerchantCounter table. So you've got your Merchant table:
id_merchant nm_merchant
12 Jim
15 Tom
17 Wilbur
You would add a single additional table, MerchantCounter (edited to show how to tally totals for individual users):
id_merchant id_user num_visits
12 101 3
12 102 8
15 101 6007
17 102 88
17 104 19
17 105 1
You can see how id_merchant links the table to the Merchant table, and id_user links to a further User table.