Posts by smantscheff

The query is running on the server and not consuming bandwidth. Bandwidth is consumed by the query results, if they are transmitted as a whole.

This is correct, but for debugging purposes you should replace your error messages by something meaningful, viz. mysql_error()

$link = mysql_connect($DBSERVER, $DBUSER, $DBPASS) or die(mysql_error());
mysql_select_db($DB, $link) or die (mysql_error());

Study the CREATE TABLE syntax here: http://dev.mysql.com/doc/refman/5.1/en/create-table.html
Which fields do you want your table to have?

I don't know about the load distribution and the lack of it, but have a look at the slow query log of mysql to see if you can optimize applications on that level. Also check if all indexes are intact.

Your CREATE TABLE syntax is wrong. The table definition is missing.

I'm not arguing against referential constraints - your absolutely right in advocating them, and each novice should learn how to use them. I'm arguing against ON UPDATE/DELETE clauses because they will make happen things automagically which you better keep in mind and view when developing an application.

I strongly object to mschroeder's view about ON DELETE/UPDATE clauses and using mysql workbench.
For professionals this might be the way to go. But I assume most forum participants as non- or parttime professionals who will do data editing with tools like navicat, heidi, command line mysql and the like, and not with systems which completely map business rules to database procedures. And on this level you will find it quite helpful if MySQL tells you that you cannot delete a record because of foreign key constraints. Then you see that your thoughts and logic have been misguided.
As for the GUI database design, I strongly recommend the command line over any GUI. Command line DDL and DML in the form of scripts is repeatable, updateable and - once you have mastered it - fast to code, much faster than pointing and clicking on GUI elements. And you have a much clearer impression of what you are doing.

You have to separate statements by a semicolon.
Please show the file which does not upload.

Show your update query.

Use the mysql UPDATE statement.

They did it with some javascript functionality which you can find here: http://www.paid-surveys-at-home.com/maxheight.js

Assuming you are using mysql you can limit the result with a LIMIT clause in your select statement.

Do you mean that you want to show the image in your form?

You are confusing a lot of terms.
You don't insert data into a form, you set instead the values of some form input elements.
Your "original" is not a form element, but a hyperlink. What do you want to change it to?
Do you want a change in the "original" without reloading it? Then you'd have to use JavaScript.

Yes, that's the way to do it.
You could enhance the statement with ON UPDATE and ON DELETE clauses, but with your standard plain vanilla version you are on the safe side so that you cannot delete entries from the lookup tables which are still in use.

When you upload something through PHP, then on the server the upload is done by the process which is running the webserver. This process usually is associated with a user called www or apache or www-data etc. This user has to have write permissions to the directories involved, otherwise your upload will fail.
So you can either assign the upload directories to this user and make them user-writeable (755), or you can assign them to the same group as the one who created the site and make them group-writeable (775), or you make them world-writeable (777).
To set permissions you have (in linux) to log in as root to your server and use the chmod command.

You can have it also the easy way and code the values into you HTML. Then you can store them without any conversion:

<select name="chr_pet">
<option value="10">Pig</option>
<option value="20">Dragon</option>
<option value="30">Cow</option>
<option value="40">Horse</option>
<option value="50">Bear</option>
</select>

You do not "insert" a value into a form. A form is an HTML structure which is delivered to the browser. You build it using HTML and PHP. You use PHP for setting the dynamic parts of the form, in this case the "value" attribute.
Like in <form action="POST"><input type='text' name='ZipCat' value='<?php echo $_GET['ZipCat'];?>'/></form>

Do you mean: how can you attribute values to form elements before the form is delivered to the user?
Basically, your hyperlink should contain the ZipCat element as a get parameter to the php script which contains the form. Example:
Change echo "<td>" . $row['ZipCat'] . "</td>"; to echo "<td><a href='myscript.php?Zipcat=" . $row['ZipCat'] . "'>" . $row['ZipCat'] . "</td>"; and in myscript.php use the value of $_GET to fill a form field: echo "<input type='text' name='ZipCat' value='" . $_GET['ZipCat'] . "'/>";

You can do that with a union query (I'm ad-libbing table and field names here):

select state as location from states where state like "%AR%"
union
( 
  select concat(city,', ',state) as location 
  from cities join states 
  where cities.state_id=states.state_id and city like"%AR%" or state like "%AR%"
)

As for names, I wouldn't call a table tbl_... From the syntactical context it is quite clear where a table or view and where a column is being referred to. And a database is not only a means of storing data, but also a means of communication - between you and yourself in half a year when you have to modify your code.
Make sure that your cigar table has foreign keys into the lookup tables.
Add further LEFT JOINs to pritaeas' sample query to integrate the other cigar attributes into your query.

You have one form in your HTML and then some input elements outside of the form. They are never sent.
For me, the easiest way to transform POST data in a mail text is a post array walk:

foreach( $_POST as $key => $value ) 
  $message .= "$key: $value\n";
mail($to, $subject, $message );

text data type is for very long texts. MySQL doesn't allow for indexes of more than 1024 characters, so you couldn't index a full length text field, but you can index the whole of a varchar field.
URLs can be more than 1.000 chars long, though. So if you plan to store URLs that long, you cannot index them in full length. Then you will need a hash value field with the MD5 or a similar hash value which can be indexed, and you cannot have a unique index for URLs that long.
Therefore chose varchar if you can guarantee that your URLs will have less than 256 chars, and text otherwise.
Set up the database and all connections in UTF-8 and don't worry any more about escaping and encoding.
What for would you encrypt URLs?

Use the php mail() function.

How does the resulting HTML source code look?
Did you really use $targetpath as variable name, or shouldn't ir read $target_path ?

This looks like a good start.
Make a list of all business transactions and check if you can map them to your database structure in all details.
I do not understand the relation between orders, parts and products. What is a part? How does it relate to products? How many parts are there for one product?
The OrderDetails table lists OrderNo as a foreign key. This should probably read OrderID.
Where do you store the ordered items? In the order details table? Then you need a foreign key into products or parts.

Sou you want to match one, two or more keywords to various fields in the database.
I recommend a regular expression search over a concatenation of fields.
Example:

select * from table1 join table2 on table1.id=table2.id
where concat(table1.field1, ' ', table1.field2, ' ', table2.field1) rlike "(keyword1|keyword2)"

I want all the states to show up in the suggestions whether we have jobs in the state or not. Hopefully, that makes sense.

No it doesn't. Why would you show states for which you don't have jobs? To make the user believe that you have a large database?
To show states regardless of their presence in the job table you can combine state and town names in a union query in which you pull all towns with states from the job table and all states which are not linked to the job table from the states table.

Your code table seem to me like a unstructured mass of text strings with codes attached. Each of the lookup tables refers to only one field in one table and makes sure that only certain values may be entered. You could have a similar effect by enum fields which list all allowed content strings, but they are not so easy to maintain as lookup tables.

Session variables rely on cookies - on the session cookie, to be precies, which in standard PHP has the name PHPSESSID. Check the cookies in your browser to see if this cookie is set, and if it has a path other than '/'.

Please mark this thread as solved.

In the long run it pays to have your data as structured and un-redundant as possible. So I support pritaeas' advice to use lookup tables for coded values.
Regarding efficiency and performance, with properly set indexes you will not notice any difference if you use text strings or code numbers - at least not if your row count stays below a million or so. Therefore it might be easier to store each string explicitly, but with a foreign key reference pointing to a lookup table so that you cannot store 'uncontrolled' string values.

In standard configuration this error message is accompagnied by the file name and line number where the output started. Did you look there?

Thanks for the update. It's always good to know where doom looms.

Between 2000 and 2005 I ran a website with 15 mio. page impressions / month and a few thousand users with a few ten thousand of pictures in a MySQL 3.21 database. No performance problems and easy handling.
But if you go for flat files keep in mind that to many files in one directory can degrade the performance quite a bit. On other projects I limited the number of files to about 1.000 per directory. You could for example use the last three digits of a car number as the directory name.
For deleting I would either write a cronjob which loops through image directories and checks for each file if its parent record in the database has the "deleted" flag set (I hope that you do not physically delete old records). Or I would write a query which lists all deleted image names and paths and feed it to a delete script (as a cronjob, too).

Your HTML code is malformed, but I doubt that this is the cause of the unexpected behaviour.
If I understand the specs correctly, cookies are sent with the current document path as the cookie path. But all browsers which I have tested behave as expected on your code - the session cookie is set correctly and the session variables are available.
Did you try another browser?

Please mark the thread as solved.

Change if(preg_match("/^[ a-zA-Z]+/", $_POST['search']) to if(preg_match("/^[ a-zA-Z0-9]+/", $_POST['search'])

Your delete query is malformed and nonsense.

$sql = "DELETE FROM products WHERE id='$id_to_delete" or die(mysql_error());
$result = mysql_query ($sql);

should read

$sql = "DELETE FROM products WHERE id='$id_to_delete'";
$result = mysql_query ($sql) or die(mysql_error());

I believe you are barking up the wrong tree.
Storing image data in the database does not affect database performance. Database performance is mainly determined by table structure and indexes, not by the amount of data stored in the DB. If pictures have their own table and you use the implicit mysql query cache the performance loss is minimal.
Also your argument of website / HTML performance is not true. The performance is the same, regardless of the content of the IMG src attribute which would make the only difference in not pointing to a physical file but to PHP script which outputs the image data.
Bookkeeping, moving and deleting images with their rows would be much easier. You could not use batch conversion programs like convert, though, without first exporting images from the database.

The code is fine - at least it runs on my Apache installation, and the output is "1", as expected.

Please show the "CREATE TABLE Users" statement.
And for debugging change

$result = mysql_query($query);

to

$result = mysql_query($query) or die(mysql_error());

You cannot do that with MySQL without a sort order.
If you have a sort order, e.g. by a field named ID, you can check the limit entry like this:

select t1.id from mytable t1 where (select count(*) from mytable t2 where etype='p' and t2.id < t1.id) = 9;

And instead of a limit clause you use this value as your select condition:

select * from mytable t where t.id <= (select t1.id from mytable t1 where (select count(*) from mytable t2 where etype='p' and t2.id < t1.id) = 9);

You should set up the "date" column as a true date field, not as a character field. Then you could sort by this field.

Use a WHERE clause.

Look here: same problem, solution: mysql inline functions to order by.
http://www.daniweb.com/forums/thread345754.html

That's what a programming language is for: automating tasks.
Write a PHP script which sets up your input HTML page with all the controls you need. E.g. along the following lines:

$groups = mysql_query('SELECT * FROM groups');
while ($group = mysql_fetch_array( $groups )) {
  $groupId = $group['id'];
  for ($week = 1; $week <= 12; $week++) {
    echo "<input type=checkbox name='cb$week"  . "_$groupId'/>Group $groupId, week $week<br/>";
  }
}

These are four different queries. If you use prepared statements, each needs its own statement.

You are confusing file names and page titles.
The page title which a browser shows is stored in the html <title> element.
You can redirect file names in the apache webserver using the redirect module (ModRewrite). If the redirect engine is installed and active and redirection is allowed for your .htaccess file and directory, then you can use .htaccess to redefine file names. Example:

RewriteEngine On
RewriteRule test1 page.php?id=1
RewriteRule test2 page.php?id=2

or more generally RewriteRule test([0-9]+) page.php?id=$1

Try google. http://www.phpclasses.org/package/2874-PHP-Recognize-text-objects-in-graphical-images.html