Muddy_Funster

Well, I have got round the first part of the problem by using a cursor and two memory tables, which needless to say takes some time to run through. Would still like to know if there is some better way of doing this.

That looks too much like JS for me.

SELECT s.* , COUNT(h.status) FROM staff AS s LEFT JOIN hours AS h ON ( h.username=s.username AND (h.status="sick" OR h.status = "Late") ) WHERE s.username="jbloggs" GROUP BY h.status Should work....I think

yeah, gonna need the code - and the exact values that are contained within $variable, $start_record and $number_of_records The exact error message wouldn't go a miss either.

You could set a $_SESSION['cache_post'] variable using a hidden field in your "post comment" form, hold that through to the end of sign up/in and then call it with an if exists contitional at the point of final log in. I'm curious though, how does your system differentiate between a looged out member and a new user?

you are wrapping integer values within quotes, thus making them strings. This will not please your database if the fields are set to int, take the quotes out. Also, your actual error is coming from the fact that you have names a column in your table as "from". This is a reserved word. you will either have to rename the column (Recomended) or put backticks arround the colum title to tell your database not to process this as it normaly would. Final result using backticks should be: INSERT INTO hub_change (pilotID, `from`, to, reason, expDate) VALUES ($pilotid, '$oldHub', '$newHub', '$reason', '$expDate' I have only removed the single quotes from $pilotid as I expect that the others are possible varchar/text/date fields that you are entering numerical values into as test data, if they are not then you will need to remove the quotes from thise values aswell.

no, I said "are not used yet, so obviously can't be complete". I was trying to figure out something along the lines of SELECT master.id FROM recieved, master LEFT JOIN batch ON master.id = batch.batch_id WHERE id IS NOT BETWEEN (recieved.MAX(id) AND batch_id + (Count(batch_id)-1 Group BY batch_id) FOR EACH Batch AND WHERE id IS IN master AND IS NOT IN recieved It's clearly not code, or even psudo(it's all on my office comp, so I can get what even tomorrow) but it sould help explain how I was thinking about making it work. For some reason I just can't get my head around NOT BETWEEN part.

would be a question for the javascript section - not for hijacking an already solved thread in PHP

Let's do this your way Shock horror is that the best argument that you can give is simply making my point. The only reason to use * is to be lazy with your coding. It's not the fault of optimisers, it's primarily the fault of those who are new to SQL, learn using * from the beggining and then cause problems because there is no controlable ferrerence to the existing fields in the table that they are using for the query. So when that code then get's passed onto someone else to "make it better" there is no reffernce point to work with. It's grossly harder to manage code that uses a * than the explicit field names. It's the same problem with the single letter aliasing of table names - it starts off simple, grows, then someone else gets landed with it and has to keep scrolling back up to see what bloody table "d" was. I was reffering to the performance degridation of selecting fields that are not required, as well as the time and wasted while other developers work trying to exact the relevent code from a clearly non modular style. Generaly if a system is operating and then has to be modefied, it will be because there are additional functions being added, not because the ones that have been in use are being altered. Thus adding fields (even to 100 tables) is generaly to be expected as a process that will enable the construction of additioanl queries, not re-invent the ones that are still working. Universe? Seriously? I don't think we need quite so much drama thanks. Obviously no I have not come anywhere close to dealing with even a fraction of every possible permutation of "What could happen if". But the scenario was ludicrous in the effect that if it was an accurate representation of what was expected, it was clearly done wrong to start with. In which case a ground up review would be needed and the use of * would fall somewhere into meeninglessness (is that even a word?) in comparison to the rest of the work that would need to be done. Again, predominantly to be reffrenced by other, new queries. You'll find that happens quite a lot with me I had assumed that you were reffercing algebra for something more that "what goes is comes back out". My issue with the use of SELECT * isn't as eclectic as I have probably made it seem. It's more like how I veiw high grade explosives - should only be used by people who know exactly what they are doing with it. Too many people pick it up early and run with it forever more regardless of whether it is the right thing to do. I meen come on, how many times have we all seen SELECT * used in a user login script on this forum alone? Then how many times when people want to see a list from table1 that reffrences a join on table2, looking for a single pair of matched fields but wind up using select * to pull everything out of both? If someone is in the position where they know exactly what they are doing and how it is being done, then sure use SELECT * - otherwise you are probably doing it wrong.

so your practical benefit is...saving typing. shock horror. Efficiency is measured by more than how many words you need to change during design. And it's invalid to assume that by adding a field to a table you are going to want to refference that information in all pre existing code. As for having to update 100 tables at once...Really? You had to add 1 single field to 100 tables at the same time and then refference that field with every single pre existing query? dont make ludicrous scenarious just to keep from seeming quite such an opiniated fool. Likely you would update 100 tables and then waste your dear efficiency by using * to pull that field irrelivently into your pre existing queries that were never designed to refference them into variables anyway. It's not the fault of algebra: + performs an arithmetic action, * just cuts corners.

Really? well my question still stands - what practical benefit does it actualy give you over explicit field lists? Oh, and to liken it's use to the + operator is just stupid and petty - I have to assume you take offence at being grouped as lazy, but you really need a better argument than that.

add these two lines of code just before the if() print_r($checklist); exit(); and then tick all three checkboxes and post what you get back as the contents of $checklist

doesn't it work with UPDATE_DATE BETWEEN 2010-03-02 AND 2010-03-03

could try function getOverdueTime($sDate ) { $currentDate = time(); $sDate = strtotime(sDate ); $days = ($sDate - $currentDate) / 86400; $days = floor($days)+1; $days = format_date($days, 'd H:i') return $days.' day(s)'; }

is update_date your column name?

This sounds a lot like either an escaping issue, or a delimiter problem - what do you get if, you post sample data, as the contents of $birthday and $sqlcmd?

Ok, I have a sequence of ID's - for example sake say 100001 through 104320. These ID's are matched against a batch number taken from the first ID in that batch and attached to as many ID's as the user selects (supposed to be 20, but mistakes are made) so say 100001 - 100020 have batch number 100001, 100021 - 100040 have batch number 100021 etc. I bring up the user error because it meanse that I can't use an absolout value of 20 in any working. Now what happens is that each transaction is tied to an ID. once any ID from a batch is registered as complete the whole batch is then flaged as "In use". However through system problems and user issues not all transactions register as comlete, so some ID's go missing. This causes problems with billing and the such. To combat this there is a report that has been created to show all the ID's that have a batch flaged as "in use" and have not had a completed transaction. The problem that I am trying to resolve in the first instance is that if ID 100021 has had the most recent completed transaction, the report still shows 100022 through 200040 as being "problem" ID's. I was wondering if there was a way to check for "missing" transactions whilst ignoring what is efectivly pending ID's from the same batch. So if from batch 100001 - 100020 the following is true: 100001 - complete 100002 - complete 100003 - not complete 100004 - complete 100005 - complete 100006 -| ... | - not used yet so obviously not going to be complete 100020 -| I am looking for a way to identify that 100006 through 100020 are "pending" and not have them included in the report whilst still showing 100003 as being a potential loss of revinue. As it stands the vast majority of the results in the report are effectivly false, cloging up the true potential issues. That help at all?

... if ($_POST[spotlight]) { ... jumps out immediately try changing to if ($_POST['spotlight']) {

Hi all, I look after a database for a third party program. This program auto updates a sequence of job refference numbers as soon as a transaction is completed. These jobs are all processed in batches of 20, but the sequence numbering doesn't show that directly. The sequenced field (which I will call ID for arguments sake) is stored in different tables depending on it's status, as well as in a "master" table, so existing in 2 places at once as it is. The "master" table cross reffrences a batch table which alocates the ID to a Batch generated from the 1st ID in the batch and matched with a Number of ID's in Batch field (normaly 20, supposed to be always 20 but as it's user input can get quite interesting at times) I have no authority to manipulate the table structures or write any data to these tables, but I can create new ones if the need arrises. There is an ID list report within the 3rd party program is generated by listing all the ID's that have not been processed. However this then includes any Batches that have had the 1st of the 20 ID's processed but none of the other ones have been strated yet. I have been asked if there is any way I can check the sequencing of ID's within a Batch to establish if they are missing because of an error (which happens far too often - hence the problem), or if it is the end ID's in a batch that have yet to be processed. Then, if this can indeed be done Is it possable to make it clever enough to notice if the last ID in a batch is missing by error and not just because it has not been completed. Let me know what you think guys.

The SELECT * question is an ongoing debate where by some side with "If You want all the fields anyway it's fine" and other's (like myself) say "you should never use SELECT * for production applications. Having been in the situation on several occasions where pre existing table design has had to be altered to accomidate more/less fields I don't agree with SELECT * for anything other than a quick debuging session. That said, I REALLY hate it when people use INSERT INTO without explicitly naming every field being used. The only benifit you will ever get from using SELECT * is typing less. The better question is "Is there any reason to use SELECT * ?" The only real answer to that is "Because I'm lazy". The same answer that is valid for those people who need to ask themselves "Why did I alias all my table names to meeningless single letters?" In relation to your second question: Why do something twice if doing it once is enough?

do you happen to habe this code in a page that you call with include/require?

SELECT * FROM tblFormFields where (fld_Sex is NOT NULL) AND (fld_Month is NOT NULL) AND (fld_Day is NOT NULL) AND (fld_Year is NOT NULL) order by fld_Year desc should do it.

What's the error/issue - what's it not doing that you think it should? what's it doing that you think it shouldnt? When you echoed out the sting as WebStyles suggested what did you get? Did you echo out the $sql_insert variable? // THERE IS SOMETHING WRONG WITH THIS LINE I THINK IT IS LINE 118 NOTEPAD++ echo $sql_insert; exit(); could you post what you get when you echo that?

My feedback = Post in the right section of the forum!

Couldn't you just download the custom integration button code, stick that on your site and live with the redirect to paypal.com for payments? It's way, way easier than trying to get that bugger to do something custom yourself.