mikosiko

other option: WHERE DATE_FORMAT(events.bookingDate,'%Y') = DATE_FORMAT(curdate(),'%Y');

@tjburke79: HINT: explore the GROUP_CONCAT() function (be aware of the size limitations)

one way to solve it: use any of the functions weekday() or dayofweek() reading the description of your issue your select should be something like this: SELECT * FROM table WHERE date_field between (next_sunday - 30 days) and next_sunday ORDER BY date_field DESC LIMIT 30; obviously the challenge for you to work on (using one of the suggested functions) is to get the value of next_sunday and (next_sunday - 30)

@jacbey: error means that your query is failing, a good reason for that is the usage of a mysql reserved word read is one of them.... 2 options: a) change the name of the column (the best long term solution) or b) enclose it in backtics in this way `read`

yes. did you read the UPDATE manual pages? http://dev.mysql.com/doc/refman/5.0/en/update.html the last few paragraphs before the "Users Comments" show you how.... hint: JOIN

no... this is what you have (gif attached)... you will see that the relations are not correct based on your description. Edit: I saw that you added a store entity... good... now think about the item table.... should be the item name (apparently field `item`) be present in that table? [attachment deleted by admin]

I did notice also that in `item` the attribute `item_id` is duplicated, and probably `store` should be a FK to another entity (stores)

the answer depend on what each entity represent and how the relation among them is read (members is clear, item is suspicious, lists no clear) BTW.: The PK on `lists` is incorrect

if the file was encrypted with a key or passcode you need to have it to decrypt.

Yes, that is correct Yes, but that doesn't prevent to use them incorrectly.. that is were you are failing to understand the differences among them, and apply the right one (or combination of them) in your code what it is important for you is understand the differences/similitudes among mysql_fetch_array, mysql_fetch_assoc and mysql_fetch_row and to know exactly what each one is going to return, and how to use that result in the rest of your code... p.e: in your original code you have this lines (forget the errors in the first loop because you already fixed that using mysql_data_seek): while ($tableRow = mysql_fetch_array($results)) { echo "<tr>"; for($i=0; $i<count($tableRow); $i++) { and somebody else told you that you were using the count() incorrectly.... why? if you replaced mysql_fetch_array for mysql_fetch_assoc() in this part of the code it should gave a lot of errors... why? if you replace mysql_fetch_array for mysql_fetch_row now the code works... why? if instead of use count($tableRow) you use count(mysql_num_fields($results)) the code works no matter if you use mysql_fetch_array or mysql_fetch_row().... why? those are the basic questions that you must answer yourself (testing) to gain the understanding for future. hope this help

an alternative solution should be write to second loop in this way $nmr_fields = mysql_num_fields($results); while ($tableRow = mysql_fetch_row($results)) { echo "<tr>"; for($i=0; $i<$nmr_fields; $i++) { /// or use mysql_num_fields($results) directly here instead of $nmr_fields echo "<td>". $tableRow[$i] . "</td>"; } echo "</tr>\n"; }

have you tried GNUPG ? http://www.gnupg.org/

and are you sure that your university web server have MYSQL available for you and that you are allowed to create a DB on it?... you best bet is contact your university IT dept.

I will bet that you: a) replaced the mysql_fetch_array() for mysql_fetch_assoc() in your second while loop too.... or b) you still having mysql_fetch_array() in that loop but still using the counter incorrectly as somebody else told you some posts ago. easy solution.... read mysql_fetch_row() for the second loop

running late... but check your PM's

@mrt0030003: I didn't read all your code but my head is spinning already .. I see several loops on your code and UPDATE inside loops ... could you explain what exactly are you trying to accomplish ? ... is not more easy to put in an array (using checkboxes maybe) all the ID's that you want to update and execute ONLY ONE update like this (imploding the array obviously): or maybe I misread your objectives

nothing weird with that.... a good read on mysql_fetch_array() is in order.. pay special attention to the "DESCRIPTION:" same answer than before, but now pay attention to the paragraph "RETURN VALUES" finally based on some comments in your code, seems to me that you are tying to print the columns name in the table header row.. is that is case reading about mysql_fetch_fields() should help.

that is were things are a little more interesting and complicated... indexes are no "free".. correctly used could provide you the advantage of faster search, but slower write operations.. there are a lot of considerations that need to be done before decide to use indexes or not, like: table volume (#rows), index cardinality (how selective is an index), more used queries and the impact on performance on them with or without indexes, read vs write ratio, more used search criteria in the WHERE clause, etc... just to name a few. if you are working with small tables, start only with your primary key.. you can add more indexes later if necessary... I will not recommend to add indexes on names due to the probably high cardinality (lower the better). Profiling and EXPLAIN plans are tools that could help you to evaluate your queries and analyze indexes addition/removal

very simple real life explanation (non trying to insult your intelligence of course): think in a library with hundred of books... (your table... each book is a row) - In a library a book (and everything contained on it) is identified unequivocally by it ISBN number (Primary KEY... id in your example table) - Now... open the book... what do you see in the first couple pages?.... right!!... the Index pages... how do you use that Index pages?.... to locate in the faster way a chapter/topic/etc. .... (INDEX) (in a table could be composed by one field or multiples fields)... in your example, postcode is a candidate to be an INDEX. - In the book a Chapter# should be unique. A UNIQUE Index is just an specialized Index that allows you to define which field or combination of fields can not be duplicated in your table... p.e: if in your example table you add a column to identify unequivocally a user (SS #, Employee #, etc) that should be a UNIQUE INDEX. hope this simplistic explanation help

@imperium: even when I'm not sure which is the result that you are looking for, try this code (dirty..non tested on my side) it seems to answers this scenario: "Sum the posted amount of each pos with pos.currency = '£' that have invoiced jobs and have at least one record in the pourbaskets table with vat = 0" (not sure if that result is what you are after)... otherwise, clarify what do you want and post some table(s) data with the expected results ... sure somebody else will chime with the right solution.

@Muddy... is exactly what I thought will be your answer... unfortunately you are incorrect, the OP code is absolutely equivalent to the one that you are thinking, the only difference is that he is using IMPLICIT JOIN notation and you are using EXPLICIT JOIN notation.. The OP code is syntactically correct but functional incorrect, due probably to a wrong relation condition....just an small example: SELECT table_a.field1, table_a.field2, table_b.field1, table_b.field2 FROM table_a, table_b WHERE table_a.id = table_b.table_aid is 100% equivalent to SELECT table_a.field1, table_a.field2, table_b.field1, table_b.field2 FROM table_a JOIN table_b ON table_a.id = table_b.table_aid // and in this notation INNER is implicit too in the case of the posted OP code (IMPLICIT JOIN notation): it is equivalent to this (EXPLICIT JOIN notation) which one is better?... that is hard to tell/evaluate, but using EXPLICIT notation is mostly recommended because RDBMS's queries optimizer convert internally implicit notation to explicit notation, therefore is less job for the optimizer. but let focus in the real OP problem ok?

yes

take a look to the functions DATE_ADD() and DATE_SUB(), both could help you now and in the future http://dev.mysql.com/doc/refman/5.5/en/date-and-time-functions.html#function_date-sub

post your tables structure to offer better advise... small examples of your data and the expected results will help too

don't follow.... explain please what do you think is wrong with the OP code