kicken

exec'ing a batch file like you are will not run the process in the background. PHP will wait for that program to finish executing before it continues with your script. As for ways around a time consuming process, there are various options, such as: 1) Store the info into the database, and then have a scheduled task periodically run a PHP script which checks the database 2) If you use exec, you need to use a program that will really let you run it in the background, such as hstart 3) Create some sort of batching system w/ ajax that will run the task in batchs and provide a status update to the user (they would still have to wait for it to finish though).

Your missing several ;'s

It's not documented because it's not something that changed. It's a matter of not setting up the configuration the same after the upgrade. The sample INI configurations for PHP have included E_NOTICE in the error reporting for quite some time.

You're missing the END for the case statement, as well as your comma between fields. UPDATE regusers_test AS rt INNER JOIN alt_toon_test AS att ON att.`toonname` = rt.`toonname` SET rt.`server` = CASE WHEN rt.`username`='$user' AND rt.`server`='$oserver' AND rt.`toonname`='$otoon' THEN '$server' ELSE rt.`server` END , att.`server` = CASE WHEN att.`username`='$user' AND att.`server`='$oserver' AND att.`toonname`='$otoon' THEN '$server' ELSE att.`server` END WHERE (rt.`username`='$user' AND rt.`server`='$oserver' AND rt.`toonname`='$otoon') OR (att.`username`='$user' AND att.`server`='$oserver' AND att.`toonname`='$otoon')

Mark the image to save the alpha channel details using imagesavealpha and set it to true. Then allocate your background color using imagecolorallocatealpha and set the alpha parameter to 127. Floodfill the image using imagefill with the background color, then you should get your transparent background.

$datadownboxValue = str_replace(array(' ', '-', '/'), '_', $datadownboxValue);

Changing the timezone is going to affect how strtotime interprets the string given to it. eg: date_default_timezone_set('America/Los_Angeles'); $time = strtotime('2013-7-1 5:00'); echo date('r', $time).PHP_EOL; //Mon, 01 Jul 2013 05:00:00 -0700 date_default_timezone_set('Europe/London'); echo date('r', $time).PHP_EOL; //Mon, 01 Jul 2013 13:00:00 +0100 $time = strtotime('2013-7-1 5:00'); date_default_timezone_set('Europe/London'); echo date('r', $time).PHP_EOL; //Mon, 01 Jul 2013 05:00:00 +0100 Notice how the second output shows the time actually being converted from America/Los_Angeles to the equivilent time in Europe/London. The third output however shows that now strtotime is treating the initial time string as if it is in the Europe/London timezone so the time stays the same when output. So given your code, the first row's time will be converted from whatever the server's default timezone is, into the Europe/London timezone. All subsequent rows however will be interpreted as if they originate in the Europe/London timezone so they will not be converted. If you want to set a timezone for your pages, it is something you should do near the beginning of the script as part of the initialization work (ie, same place you'd call session_start, connect to the DB, etc).

I'd probably classify both your _GET ban and trying to use a trusted input list as a bit on the overkill side. If things are coded properly, then extra GET or POST fields are not going to have any negative effect on your code, other than using a bit more memory (which your validations won't prevent anyway). A downside to such code also is that whenever you need to expand things you'll have to update the trusted fields list, or start allowing GET if you decide you need it. You're claim of not using GET variables at all also makes me think that you are probably using POST where you should be using GET. Things like search forms or listings should be using GET and not POST. Essentially any request that merely queries for data, but does not alter data, should be done using a GET request.

The sub query for dti2 does not take the MRN into account when locating it's data. You'll need to add that as a condition in the WHERE so that it correctly matches the same MRN numbers. (SELECT DATE_FORMAT(MIN(addobs.datetime), '%m/%d/%Y %H:%i:%s') FROM addobs WHERE addobs.mrn = patients.mrn AND addobs.datetime >= lastOkPar.lastDatetime AND addobs.par >= $par AND addobs.hidden != 'yes') as dti2

Connecting to the DB server takes a bit of time as there is a fair amount that happens there (create connection, do authentication, allocate resource, etc). Trying to do that several times within a script is just going to waste time and resources. Open the connection once, then do everything you need to do. If desired, you can delay the opening of the connection until you are sure you need it. That way you can do a number of validations and possibly reject bad calls w/o needlessly connecting to the database. Another way to reduce the overhead of connecting to the database may be to uses persistent connections. In this way you'd open the connection with a p: prefix, but not explicitly close it. PHP will maintain the connection and re-use it next time a script that needs it is run. How well this works will depend on how your PHP setup is configured. If your using an Apache module or FastCGI it should work OK, you'd have one connection per PHP process.

You could setup your PHP script to allow Cross-origin resource sharing, that would allow you to use AJAX to make request to the script in the background. Other than that, your stuck sending a request then redirecting back when it is complete. Or possibly iframes, depending on what you need.

SELECT HEX(field) FROM table That should show you a hex representation of the field, you could find out what the ? character is that way.

Yes, such a concept is known as Progressive Enhancement. Basically write the HTML in a way that works well without javascript, then use JS to modify it if necessary and add all the event handling. Eg, for tabs you'd maybe do something like: <ul class="tab_menu"> <li><a href="#tab1">Tab 1</a></li> <li><a href="#tab2">Tab 2</a></li> <li><a href="#tab2">Tab 3</a></li> </ul> <div id="tab1"> <noscript><h1>Tab 1</h1></noscript> Tab 1 content </div> <div id="tab2"> <noscript><h1>Tab 2</h1></noscript> Tab 2 content </div> <div id="tab3"> <noscript><h1>Tab 3</h1></noscript> Tab 3 content </div> Without JS the user would just see a list of links at the top, and clicking the link would take them to the appropriate content section. If JS is enabled then the HTML/CSS gets modified to create the tab layout and let the user switch content sections by clicking the tab link. Any well-written tab control script would allow for this type of setup. JqueryUI's and YUI's both work similarly to this. I'm not overly familiar with bootstrap but a quick glance at it's documentation seems to indicate it also follows a similar pattern as what I showed.

$sql = "{:retval=CALL SearchForXML6b(73543,892245,'YearPublished DESC, SortTitle ASC',1,20)}"; $stmt = $this->c->prepare($sql); $stmt->bindParam(':retval', $retval, PDO::PARAM_INT, 10); $stmt->execute(); You don't need the @vars, just pass the values. You also don't want PARAM_INPUT_OUTPUT, giving a length parameter is enough to get the value back as output. Are you using the PDO_SQLSRV driver? You should be if not.

Raspberry Pi will run normal linux setups so all you need to do is get a distro installed and configure apache/php/mysql in order to get it to parse pages. Determine which distro you want to use and hit tutorials or forums for that distro to get instructions on how exactly to setup that software. When that is done, you need to determine how exactly you want to use your raspi. Do you want to be able to carry it with out and just hook it up to any PC? Or do you want to leave it at home and just access it over the internet? The first option may be a bit difficult because each computer you use will likely have different configurations/restrictions on how you might connect up your raspi. You'd need to get it configured to handle a variety of possibilities such as having to be a dhcp client, dhcp server, static network config, etc. The latter option would be fairly simple, just set it up, plug it into your network somewhere and setup port forwards in your router if necessary. You may need to setup DynamicDNS in order to track the IP if you do not have a static IP assigned to you. This method wouldn't help you if you have no internet access, or for some reason your home connection goes out.

a is equal to the function itself, not it's return value. a(x) is equal to the return value of function(b) which is itself another function. var fn = a(x); That line locks b in as the current value of x, which is 2. So fn gets assigned the value function(c){ return y + 2 + c; } console.log(fn(unknown)); When fn is executed there, c comes from unknown and y takes the value of the global y definition, which at that moment is 3, so the equation would look like: 3 + 2 + c. So then it's just a matter of solving for c 10 = 3 + 2 + c; 10 = 5 + c; 10 - 5 = c; 5 = c;

Your EXPLAIN output seems to indicate that no indexes are being used. Is your ID column the PRIMARY KEY? Is it the only column in the primary key, or are there others?

You can just use copy if allow_fopen_wrappers is enable. Otherwise just make the request using cURL and save the results to a file using fopen

For such a simplistic query, the only things really that would improve it is would be 1) Ensure an index exists on the id column 2) If the table is massive, partitioning may help Add EXPLAIN to the font of the query and run it to verify that your index is being used.

WHERE DATE(timeColumn)=CURDATE() AND HOUR(timeColumn) = HOUR(NOW()) That compares the date portion of the timestamp column to the current date to limit the query to only rows for today, then the next bit compares the HOUR porition to the current hour, further limiting the result set to only the current hour's records.

No, errors such as that have always occured. Many places will merely disable their display by adjusting the error_reporting php.ini directive to exclude E_NOTICE level errors. Under such a configuration the error still happens (php reports throws it, runs error handlers, etc) but the default error handler doesn't output any messages about it. For your development work, you should leave your error_reporting set as high as possible (E_ALL for >=5.4, E_ALL&E_STRICT for <5.4) so that you can identify and properly handle such errors. Regarding request variables such as the above, one way to avoid having to constantly check isset() (which gets annoying with large forms) is to access the values via a function such as: function _GET($n, $d=null){ return isset($_GET[$n])?$_GET[$n]:$d; } Then the previous code could be written as: $id = _GET('id'); The second parameter is used to specify a default, for instance: $action = _GET('action', 'list'); if $_GET action was set you'd get that, if not you'd get 'list'.

When you build your SQL query you need to make sure you use the keyword NULL as the value for the column. ie: $val = !empty($val)?"'".mysql_real_escape_string($val)."'":'NULL'; $sql = 'INSERT INTO table (val) VALUES ('.$val.')'; That way if the value is blank, you end up with a query that looks like: INSERT INTO table (val) VALUES (NULL)

Any of your variables that come from the request ($_GET, $_POST, etc) you need to verify that they exist before trying to use them. Failing to do that will result in that Notice message. $id = isset($_GET['id'])?$_GET['id']:null; That uses the ternary operator to do a quick inline if/else statement. It checks if that get variable exists, and if so returns it's value. If it does not exist, it returns null.

Variables do not carry over from one request to another. The request in which you define $a, is not the same request in which you are attempting to echo it. During the request you try and echo $a, you never define it because isset($_POST['posted']) is false for that request. You need to embed $a into a hidden input in your forms in order to pass it along from request to request. When you need it again in the last request, pull it out $_POST array again.

As part of your function to add the new inputs, you need to initialize the datepicker on the new inputs. This bit of code you have: $(function() { $('input[name^="inv_date"]').each(function() { $(this).datepicker(); }); }); Will only initialize the inputs which exist at the time the page is loaded. Any elements added later are not affected.