requinix

You're too restrictive with the name. IMO allow pretty much everything and let your code find out if the name is correct or not.

If you like rolling your own SQL injection prevention and type conversions then sure. If you won't be executing one query repeatedly using different values, or don't care about inefficiency in doing so, then sure. If you don't care that the mysql extension is being deprecated then sure. If you don't want any of the advantages of prepared statements then sure.

Okay, well, the normal mod_rewrite stuff does that by default so... have you tried anything yet?

SELECT RIGHT(field, 4) FROM table WHERE field REGEXP "^[A-Z]{3}[0-9]{4}$" ORDER BY RIGHT(field, 4) DESC

Multiple simultaneous INSERT queries will be queued up, not executed in parallel. I believe all engines will write-lock tables during INSERTs, but won't necessarily read-lock. Thus if you run one INSERT with multiple values, all the values will be inserted in one (pseudo-)atomic operation. In other words a mysql_insert_id() - mysql_affected_rows() should be safe.

The first generators? Even though $xml->ROW is multiple elements, if you treat it like it was just one then SimpleXML will give you back only the first one. $xml->ROW->GENERATORS

Wrong. split() and explode() are similar but not compatible. Wrong. I'm even not sure what you're trying to say but it sounds wrong. And apparently you didn't notice that this thread is three years old. There isn't anything left to say beyond what's already been said so there really isn't any reason to bump it.

Don't use regular expressions when there are (much) better tools available. Like SimpleXML. $xml = new SimpleXMLElement('http://www.tva.gov/lakes/xml/OHH_F.xml', 0, true); foreach ($xml->ROW as $row) { printf("Release date: %s\n", $row->RELEASEDATE); printf("Time period: %s\n", $row->TIMEPERIOD); printf("Generators: %u\n", $row->GENERATORS); // or is this a bool? }

return only returns from the current function. It doesn't propagate up the call stack or something. With your checkInput() as it is now, the isValid* functions can return whatever they want and it won't do anything because checkInput() doesn't look at their return values. So make it look at their return values: if any of them return false then checkInput() should return false too.

This topic has been moved to mod_rewrite. http://www.phpfreaks.com/forums/index.php?topic=360875.0 What? I can't use the normal message sometimes? I have to change it? Come on, gimme a break.

You can QA on your end to make sure you got things right, but then you can QA with them to make sure everything is set up right on their end. Maybe there are account settings that need to change, or options to enable, or stuff like that. And yes, you may need to help them do it, but make sure that ultimately they are the ones agreeing to the terms and conditions and whatnot. Developer accounts tend to have different agreements than production accounts: you'd probably use the former while they'd use the latter. If they're not so familiar with this then you can hold their hand through it. Sit down with them as they sign up for the keys and explain to them the things that they might not understand. Once that's done you can use their keys to do the final testing, after which it should all be ready to go. (Or maybe this all happens earlier on and you use the keys when you're comfortable enough to switch from yours.)

And at the end of a function definition it goes back into the class definition. And like you said, Summarized the code is /* comment */ add_action(); class sports_category { function sports_category() { } function widget() { ?> html } ?> html function form() { } function update() { } ?> html } ?>

Not off the top of my head. Can you narrow it down to a specific problem? Also enable display_errors=on and set error_reporting=-1 and look for error messages.

You agree to it for your own keys, they agree to it for their own keys. The two sets are completely separate. Don't give them your keys, but if they chose to give you theirs then that's their choice.

Uh yes, it is less likely. After pulling a non-5 there is a 4/51 chance of getting one, but after pulling a 5 there is a 3/51 chance. No? 5, 5, 5, 5: 4/52 * 3/51 * 2/50 * 1/49 = 0.0000369% all unique: 4/52 * 4/51 * 4/50 * 4/49 = 0.00394% What you say is true only if you pull a card, put it back, shuffle, and pull again.

Like I said, timestamps have nothing to do with timezones. It's the same number everywhere. Like right now it's 1339523573 (give or take) regardless of where you are. That corresponds to 10:52am PDT and 1:52pm EDT. Let me be even more explicit: printf("Timezone: %s\n", date_default_timezone_get()); printf("Unix timestamp: %u\n", time()); printf("Time: %s\n", date("Y-m-d H:i:s")); printf("\n"); date_default_timezone_set("UTC"); printf("Timezone: %s\n", date_default_timezone_get()); printf("Unix timestamp: %u\n", time()); printf("Time: %s\n", date("Y-m-d H:i:s")); printf("\n"); date_default_timezone_set("Asia/Shanghai"); printf("Timezone: %s\n", date_default_timezone_get()); printf("Unix timestamp: %u\n", time()); printf("Time: %s\n", date("Y-m-d H:i:s")); Timezone: America/Los_Angeles Unix timestamp: 1339523573 Time: 2012-06-12 10:52:53 Timezone: UTC Unix timestamp: 1339523573 Time: 2012-06-12 17:52:53 Timezone: Asia/Shanghai Unix timestamp: 1339523573 Time: 2012-06-13 01:52:53 Your problem is you're using the wrong timezone for something. You should never adjust a time() value to use a different timezone: use date_default_timezone_set() to change the timezone then date() to get a date string. (Or the OOP equivalent.)

What you need to do is keep track of the deck. Protip: make your code model your... well, model. $cards = range(1, 52); shuffle($cards); $first_player = $house = array(); $first_player[] = array_shift($cards); $house[] = array_shift($cards); $first_player[] = array_shift($cards); $house[] = array_shift($cards); 1-13 is one suit, 14-26 is another (subtract 13), 27-39 is another (subtract 26), and 40-52 is the last (subtract 39).

No. And you shouldn't, because using quotes is what you should be doing. Array keys are integers or strings, and with $a[test] = 1; PHP tries to find a constant "test". Even if it existed that's not what you'd want it to use. Strings have quotes, so if you want a string then use quotes.

time() is the number of seconds since the beginning of 1970 local time. As such it is not affected by timezones. What is affected is what you get when you convert that number into a date string. Also, use date_default_timezone_get/set() if you go procedural. function getTimeByZone($zone){ $old = date_default_timezone_get(); date_default_timezone_set($zone); $time = date('r'); date_default_timezone_set($old); return $time; }

checkExistence() could be useful somewhere else, but as you said canView() makes calling it redundant.

Oops >_> Er, I mean, yeah. I said "like". As in "similar to but not exactly"

That's right. @doubledee: Any problems? kicken is totally correct with what he's been saying.

A regular (INNER) JOIN requires that both tables have matching values. An OUTER JOIN does not. SELECT... FROM... LEFT OUTER JOIN... LEFT OUTER JOIN... LEFT OUTER JOIN... WHERE... Note that the "OUTER" is optional as long as you use a LEFT or RIGHT.

You would do it like I showed in your other thread.

You do understand that for every worker you try to read a new line from the file? It's not that you're reading a file and then checking it for all the workers?