Barand

+--------------+ +-----------+ +----------------+ +-------------+ | contact_info | | register | | health_profile | | bloodgroup | +--------------+ +-----------+ +----------------+ +-------------+ | username |---+ | id (PK) | | id (PK) | | id (PK) | | phone | | | firstname | +-------| username | +-------| user_group | | address | | | lastname | | | blood_group |-------+-------| donor_group | | town | | | email | | | age | +-------------+ +--------------+ +----<| username |----+ | weight | | password | +----------------+ +-----------+ then SELECT user.firstname as user_firstname , user.lastname as user_lastname , bg.user_group , donor.firstname as donor_firstname , donor.lastname as donor_lastname , bg.donor_group , ci.phone , ci.address , ci.town FROM health_profile as hpu INNER JOIN register as user ON hpu.username = user.username INNER JOIN bloodgroup as bg ON hpu.blood_group = bg.user_group INNER JOIN health_profile as hpd ON bg.donor_group = hpd.blood_group INNER JOIN register as donor ON hpd.username = donor.username INNER JOIN contact_info as ci ON donor.username = ci.username WHERE hpu.username = '$patient' AND hpu.username <> hpd.username ORDER BY donor_group Job done

You need that to query for possible donors

Looks like you need another table to store bloodGroup | compatibleGroup -----------+---------------- O- | O- O+ | O+ O+ | O- A- | A- A- | O- A+ | A+ A+ | A- A+ | O+ A+ | O- etc

You can't just change the word SELECT to UPDATE and magically get a valid UPDATE statement. http://dev.mysql.com/doc/refman/5.6/en/update.html

Do not run queries in loops. Create a single query using a JOIN. SELECT p.nome , COUNT(c.produto) as contagem FROM produtos p LEFT JOIN carrinho c ON c.produto = p.nome GROUP BY nome ORDER BY contagem DESC Loop through the results echoing "nome" and "contagem"

Will that use the indexes?

Just my 0.02 worth, but if you store a date of 9999-12-31 instead of NULL in the end date of the current price then it makes joins easier when you want the price that was applicable at the time of the transaction EG SELECT .... FROM transaction INNER JOIN price ON transaction.date BETWEEN price.startdate AND price.enddate

Yes, GROUP_CONCAT is one way. The other way is the same as in your other thread for the emails.

That's the way joins work. They match data in one table with the corresponding data in the other, matching on the key values. If you have 1 record in tableA matching 3 records in tableB then you get 3 records output, each with the data from B and the matching data from A.

You may find it easier to concatenate the image names into a comma-separated string for each service $prep_stmt = " SELECT s.id , s.name , s.description , i.image , GROUP_CONCAT(i.image_path) as images FROM services s LEFT JOIN images i ON i.service_id = s.id GROUP BY s.id";

Not so long ago I spent hours answering these same questions for you in this topic http://forums.phpfreaks.com/topic/296918-automatic-php-email/ That topic shows you how to join to the renewal table. Now you want us go through it all again? Where were you during that marathon topic. If you cannot be bothered to learn you are wasting our time.

It should be the id of whichever user you want to link that particular visitor record. So, if that is what is in $_POST['userid'], then yes $userid= mysqli_real_escape_string($conn, $_POST['userid']);

The only value you ever store in $userid is an empty string

See what mysql_error() outputs when it fails

From the sample data I posted you can see that member id 1 is a member of two committees (Procurement and Paper Clips) so shouls have access to the links for those two committees. The query lists all committees and shows which ones member 1 can view (non null member id in results), so loop through results output committee name if (member_id is not null) output link to committee page endif endloop

You tell me, you're the one doing the testing

It was only to help with testing. If you have finished testing it can go.

Good luck with that, cyberRobot. He's been asked several times already

If you are setting this up as a cron job then you would be better logging the emails sent in a file rather than echoing messages to the screen. And no, do not set the test script up as cron job - it will screw up your notification dates. It was merely to test the queries, it's job is done now.

The test script current starts on the 2015-06-12 and queries the data for every day for the next 30 days to see which renewals would be notified by email. So it shows that on the 12th June, renewal 111 for 2015-06-26 was inside 14 days and a notification would be sent. on the 20th June, renewal 111 for 2015-06-26 was inside 7 days and a notification would be sent again on the 12th July, renewal 110 for 2015-07-26 was now inside 14 days and a notification would be sent.

Yes, a separate page. Though it is unlikely that 26 June will be re-sent as it already well inside the 7 day limit.

Perhaps if (time() >= strtotime($convoydate) )

That is precisely what that test script I sent you does.

Sorry, had to make a couple of other adjustments having combined the two queries into a UNION Try SELECT v.visitor_id , visitor_name , visitor_email , visitor_model , visitor_plate , item.description , renewal_id , DATE_FORMAT(renewal_date, '%e %M %Y') as datedue , renewal_date FROM visitor v INNER JOIN renewal USING (visitor_id) INNER JOIN item USING (item_id) WHERE renewal_date BETWEEN CURDATE() AND CURDATE()+INTERVAL 14 DAY AND IFNULL(date_notified, '1901-01-01') < CURDATE()-INTERVAL 14 DAY UNION SELECT v.visitor_id , visitor_name , visitor_email , visitor_model , visitor_plate , item.description , renewal_id , DATE_FORMAT(renewal_date, '%e %M %Y') as datedue , renewal_date FROM visitor v INNER JOIN renewal USING (visitor_id) INNER JOIN item USING (item_id) WHERE renewal_date BETWEEN CURDATE() AND CURDATE()+INTERVAL 7 DAY AND IFNULL(date_notified, '1901-01-01') < CURDATE()-INTERVAL 7 DAY ORDER BY visitor_id, renewal_date

Yes