DavidAM

You can use PHP to retrieve the data from the database and generate a page when requested by the user. There is no real reason to store the data on your server separately for PHP. For the automatic refresh you can use JavaScript (which is different from Java) and AJAX (Asynchronous Javascript And XML). Start by building the page to be viewed using PHP to generate the HTML sent to the browser. Once you have that working. It will be fairly easy to add the JavaScript (to the HTML) for the AJAX calls to get the updates (based on a timer).

You start with: 123 [test=abc]cba[/test] 321then you told it to replace [test=abc]cba[/test] with abc. that leaves 123 abc 321which, when printed to the browser will show as 123 abc 321 That is, the numbers (123 and 321) were not matched and therefore not affected by the preg_replace.

LI is a child of the UL, isn't it? Wouldn't it be: #product_tabs ul:last-child { Disclaimer: I'm not an expert at CSS, so I could be way off here.

ALT is used to display text INSTEAD of the image if the user has images turned off, or they are using a non-graphical browser. Some browsers display the ALT value in a "tooltip" just because they want to. However, you can use the TITLE attribute, which (I believe) most browsers will display as a "tooltip" on hover.

1) A single equals-sign is ASSIGNMENT, it takes two to COMPARE: 2) It looks like you spelled the GET variable wrong:

Please use CODE tags when posting code: That error would indicate that you have not selected a database. Back at the beginning of the code you have: //2. Open the database connection and use the winestore database mysql_select_db($dbname, $connection); add the or die(mysql_error()); to that statement to see why the database selection is failing. Either the database does not exist, or the user does not have access to it, or the variable is not defined, or something.

If a "difficult" user changes the ID that is being submitted, the worst thing that can happen is he gets no data back. If, on the other hand, he changes the FILENAME to /etc/passwd, he can learn a whole lot about your system users. Keep in mind: just because you use AJAX to get the file, and your Javascript processes the returned contents, does NOT mean that someone cannot get the contents of the file. If AJAX can request the file, I can request it directly in the browser, or with wget or curl or telnet. None of those is going to have your JS "protecting" the contents from prying eyes.

1) Define "not working" -- What exactly is it doing that it should not do, or what is it not doing that it should do? Have you printed (or echoed) the ultimate query statement before attempting to execute it, to see what it says and what might be wrong? 2) You did not show the code that is actually executing the query. Are you using mysql_query or are you using mysqli_query or are you using PDO, or something else? You cannot mix driver functions. 3) Escaping values is important for two reasons: 1) It prevents characters that are "special" to the database engine (such as a single-quote) from being interpreted as the special character, so it is treated as data; and 2) it prevents "special" characters from being injected into the query from user-supplied values - without the escaping, it is possible for a malicious user to manipulate the query. "I only need it for ...", yeah, I've thought that to, and then three weeks later tried to insert data in another field that was not escaped. The script crashed and I had to fix it. It WILL NOT HURT to use it on ALL STRING DATA, so there is NO REASON to NOT USE IT. 4) Well, actually this should be #1, but I'm too lazy to renumber. Turn on error reporting. The only reason mysql_real_escape_string() should fail when mysql_escape_string() works is that you don't have a mysql connection to the database (see #2). mysql_escape_string is deprecated and should not be used. 4a) When the query fails, you need to echo mysql_error() (or whatever the error message function is for whatever driver you are using). It will tell you what the database said is wrong. This is DIFFERENT and SEPARATE from PHP error reporting.

NO!!!!! htmlspecialchars() is for escaping HTML (hence the name). --- mysql_real_escape_string() is for escaping data for mySql (look, there's the name again). @OP I don't see you using mysql_real_escape_string in that code at all. In order for it to work, you have to escape each individual variable, not the entire statement (a common noob mistake). It should look something like this: $q .= ",('" . mysql_real_escape_string($ass_orderID) . "','','" . mysql_real_escape_string($product->virtuemart_manufacturer_id) . "','','" . mysql_real_escape_string($product->virtuemart_product_id) . "','" . mysql_real_escape_string($product->product_name) . "','" . mysql_real_escape_string($product->product_price) . "','" . mysql_real_escape_string($product->dl_ebook_url) . "','" . gmdate("Y-m-d H:i:s") . "','0')"; Although, you don't need it (and should NOT use quotes) for numeric data.

You can make it an array: <INPUT type="checkbox" name="checked[]" ...>Then collect them when you get to the other page: $checkedList = implode(',', $_GET['checked']); $query = "SELECT * FROM list WHERE id IN ($checkedList)"; Of course, you should still validate to make sure the submitted data is valid and safe before sticking it in a query

The third parameter to substr is the LENGTH not the POSITION. You need to determine how many bytes you want.

You are using mysqli in your original code. You can NOT mix mysql calls with that. You must use mysqli_fetch_assoc(). If you are expecting and wanting only ONE row. You just need the $row = mysqli_fetch_assoc($query); without the WHILE () { and, of course, remove the closing brace afterwards. $query = $mysqli->query("SELECT * FROM insurance WHERE insuranceid = '1'"); $row = mysqli_fetch_assoc($query); #MAD# Added #MAD# while($row = mysqli_fetch_assoc($query)) # Removed #MAD# { # Removed echo "<tr>"; echo "<td> The price for insurance will be " . $row['insuranceprice'] . "</td>"; echo "</tr>"; #MAD# } # Removed echo "</table>";

When you come to the page by a redirect, $_POST will not exist. So this code will trigger a warning and then assign NULL to your $_SESSION variables. You need to test for $_POST. If the $_POST fields are not set, then keep the current session values. To make your form "sticky" you need to apply the $_SESSION values in the INPUT tags (looks like you have that). Of course, on the first time visit to a page, the $_SESSION values will not exist, and referencing them will trigger a warning. So we have to check for them as well. So, something like this: <?php session_start(); $_SESSION['clientname'] = (isset($_POST['name']) ? $_POST['name'] : (isset($_SESSION['clientname']) ? $_SESSION['clientname'] : '')); //name $_SESSION['clientcompany'] = (isset($_POST['company']) ? $_POST['company'] : (isset($_SESSION['clientcompany']) ? $_SESSION['clientcompany'] : '')); //company ?>which is functionally equivalent to: session_start(); if (isset($_POST['name'])) $_SESSION['clientname'] = $_POST['name']; elseif (! isset($_SESSION['clientname'])) $_SESSION['clientname'] = ''; if (isset($_POST['company'])) $_SESSION['clientcompany'] = $_POST['company']; elseif (! isset($_SESSION['clientcompany'])) $_SESSION['clientcompany'] = ''; # Now we can refer to $_SESSION without concern of how we got here. Of course, you still need to sanitize and escape the data when you use it.

You never retrieve the results of the query in any of the ELSEIF blocks. mysqli_query only executes the query, you need to use mysqli_fetch_assoc after that to get the data. And, by the way, if are only selecting one row and only processing one row, you do not need the while loop. You can just do the fetch.

Yea, I thought about that. It was the child records that caused me to ignore it and besides, he's setting the child's NUM to the parent's NUM + 1, and we really don't know what this value represents. We could replace the if {...} else {...} with that single-query logic (or similar), which might save a little time in the long run. In retrospect, if I really needed to do this, with an unknown number of levels, I would build a Stored Procedure to handle the looping update. Then it could be done with a single call to the database.

I'm not sure what it is called either, but it looks like the same code over and over and over ... First, use mysql_fetch_assoc instead of mysql_fetch_array(). Then I don't have to keep looking back at the query to see which column $row124[3] is referring to. Second, how about a recursive function? (man I love these things) // Recursive function returns when no rows are found for the Bin ID function updateBinID($psBinID) { $sql = "SELECT bin_id, left_id, left_num, right_id, right_num FROM binaries WHERE left_id = '$psBinID' OR right_id = '$psBinID'"; $res1 = mysql_query($sql); $num1 = mysql_num_rows($res1); if ($num1 > 0) { $row1 = mysql_fetch_assoc($res1); if ($row1['left_id'] == $bin_id) { // bin_id is left child of $row1[0] $sql = "UPDATE binaries SET left_num = {$row1['left_num']} + 1 WHERE bin_id = '{$row1['bin_id']}' LIMIT 1"; mysql_query($sql) or die(mysql_error()); } elseif ($row1['right_id'] == $bin_id) { // bin_id is right child of $row1[0] $sql = "UPDATE binaries SET right_num = {$row1['right_num']} + 1 WHERE bin_id = '{$row1[bin_id]}' LIMIT 1"; mysql_query($sql) or die(mysql_error()); } // Oops, almost forgot. Let's free the query resource so we don't overflow the stack mysql_free_result($res1); // level 2 updateBinID($row1['bin_id']); } } * Not tested As in your code, this only processes the FIRST row of the query. If there might be multiple rows, you need to inject a while loop inside the IF ($rows1) part. Also, there's no real reason now to keep the "1" on all the variable names, I just got lazy. Of course, since the mysql extension is deprecated, this should be converted to mysqli. And as long as you're doing that, we should use prepared statements for the SELECT and the UPDATE, that should speed it up a bit. My guess is that Barand will come along with a nice neat SQL-only solution that makes all of my hard work here mute. But hey, live and learn. (yes, that's a challenge).

It would have to be >= not >. The first character in a string is at position zero.

Hey, be nice to Jessica, she's my friend! It answers the question implied by the part of your statement that I highlighted there. INDEXES are the key to fast queries (and low CPU resource use). In a really big site, if the sheer number of users starts bogging down your indexes, you could create special cross-reference table(s) to speed up queries. But you don't do that until you have a solid database design and application design, and know what kind of problems you will run into. And you have to do a very good job of maintaining the references. It's probably easier and cheaper to just throw hardware -- disk space, memory, additional servers -- at the problem. As for Facebook, they use multiple database servers with replication. The other night, my daughter and I were sitting on the couch, side-by-side, using our separate notebooks, making changes to a family group. And while we could each see our OWN changes on the screen, neither of us could see the other's changes right away (measured in minutes). The replication was running kind of slow.

I can't really follow the code. But the id column should probably be auto_increment in the table so the system will automatically assign the next id value. Otherwise, you have to insert some value into this field.

Sorry, I gave an incomplete answer. shlumph is correct, depending on which way that asp statement is. If you are replacing CRLF with <BR> (for HTML display) it would be the first one. echo str_replace("\r\n", "<BR>", $property_description); Or you can look at the nl2br function, which doesn't actually replace them, it just inserts the HTML <BR> before the CRLF (which is fine for HTML). echo nl2br($property_description); What I was getting at with the define, was something like this define('vbCrlf', "\r\n"); echo str_replace(vbCrlf, '<BR>', $property_description);

vbCrlf is a Carriage-Return--Line-Feed pair. In PHP, it is "\r\n". Or you could add a define in the PHP code: define('vbCrlf', "\r\n"); Note: The double-quotes are required here because those escape sequences are not interpreted in single-quotes.

Disabled INPUT elements are NOT posted with the form. They are disabled. You can use READONLY to display an input that cannot be typed in, it WILL be posted with the form. That being said, it is VERY VERY easy for a user to change the value in ANY INPUT element -- even READONLY and HIDDEN and, yes, DISABLED -- before posting the form. If you have a value that needs to survive from one "page" to another with no chance of being modified by the user, you need to look into sessions

Because most of us are professionals who have been there and done that; and suffered the consequences of taking shortcuts. You are getting professional grade advice for FREE. You should at least be grateful that we are providing it. And because there is no one-word answer to the question -- there are too many unknowns when looking at a single line of code. The extract() function blindly creates variables in the current namespace. It will overwrite any variables that already exist with the same name as any selected column; it will fail or error in some way if the column name or alias does not constitute a valid variable name; if SELECT * is used, you get a bunch of variables that you might not need; if the table structure changes (and SELECT * is used), it could overwrite a variable that was used because it was not a column name when the code was written, causing the code to start failing without any changes to the code. Using SELECT * is generally not considered good practice because it wastes resources retrieving, returning and storing (in memory) data that is not going to be used; besides, looking at the code, you can't tell what values are coming back so you don't know what data you can access. If you must use extract you should use the third parameter to provide a prefix for the variable names so you know where they came from when reading the code and it will not overwrite existing variables that are not from the database (as long as you don't use the prefix on non-extracted variables). This still does not address the potential issue of invalid column/alias names. If this is not "real-world" programming, then what's the point. If it takes two nanoseconds longer to check for errors in a script that is not being used on a site that gets a million hits per second, what possible difference could it make. I have written thousands, probably millions of lines of code, no matter how sure I am that I will never modify "this" code in the future, I inevitably have to review it at some point in time. Shortcuts like this not only make the code harder to debug, but make it harder to see what the code is supposed to be doing. Even if I'm not debugging code, I often refer back to code to remember how I did something. The only real way to answer your question is to benchmark it. But, as I said, there are a large number of variables: what else is running on the server; what else is accessing the database; what are you doing with the data that is retrieved -- specifically, how is it being accessed; how much other memory is the script using for other variables; how many instances of this script are running concurrently; and on and on.

There is no way you can know that for a fact. The database server may crash, which will definitely produce an error. The database may get corrupted (or hacked) and that row may be lost, which will produce zero rows. The connection to the database server may get severed and you would get an error. You cannot assume that code is always going to work just because it should. If you write your code that way, you get absolutely no help when a problem occurs. You have to start rewriting code to get it to show you errors before you can even start trying to fix the problem. This sounds like a case of micro-optimization. The resources saved, if any, by combining those function calls is not worth the additional effort that will be required when you have to debug or modify it.

This is because you are only resizing the display of the image. You are still downloading the full 20 MB photo (or whatever size it is). If you create an actual thumbnail, it is a much smaller image file and downloads much faster.