aschk

thebadbad beat me to it.... dang!

Do you want to show us what it changed to, or would you like us to guess?

Although if you are reaching the size limit of 128MB i would consider asking yourself if what you're doing can't be facilitated better another way (database storage?).

I agree with "thebadbad". You appear to be creating 3 images in memory (the original, and 2 tmps). If you are deleting the original why don't you just alter that memory image directly and save it before remove the tmp. Also put it all into a function, something like: function createResizedJpeg($src, $dst, $toWidth, $toHeight){ static $srcFile; static $srcResource; static $srcWidth; static $srcHeight; // If we don't have a cached file source create a new one. if(is_null($srcFile) OR $src !== $srcFile){ $srcFile = $src; $srcResource = imagecreatefromjpeg($src); list($srcWidth,$srcHeight) = getimagesize($srcFile); } // Create tmp. $tmp = imagecreatetruecolor($toWidth, $toheight); // Resize imagecopyresized($tmp, $srcResource, 0, 0, 0, 0, $toWidth, $toheight, $srcWidth, $srcHeight); imagejpeg($tmp,$dst,100); imagedestroy($tmp); } I make no guarantees the above code will be any better but to make sure we're not recreating the src file resource it uses a simple caching technique. You may wish to put in additional checks to make sure the src image filename is actually a jpeg.

I've not heard of anything like this built into PHP natively. Can you give a reference for the source of your information?

Where are these "keywords" coming from exactly? It seems to me that the current product being viewed contains one of the keywords in question. i.e. product is "sony tv", and you've listed it with keywords "sony". If you do a keyword search for "sony" it's going to come back ;-) But i also suggest your schema is wrong if you're storing all the keywords in 1 field for each row, LIKE '%blah%' is highly inefficient. Also to answer your question regarding limiting the results that don't contain the productid. Try: id <> '$productid' Also, echo the sql statement (fully formed) to see what it's actually running, and is the productid an integer or a string?

In both instances (1) and (2) that you posted you require the user to log in ( via a web interface i'm guessing ). So where's the problem? Assuming you storing some information (dob, name?) on the user in your databases and the user is logged in (are you using sessions??) you don't need to store any cookies unless you need some information to persist on the client machine. I'll just re-state; you're making the user login regardless of their location so you don't need to facilitate any magical cookie movements. Ya dig? Perhaps if you explain better what it is these "cookies" are supposed to be doing then maybe we can shed some light on the real issue.

By "framework for mysql database" i'm assuming you mean a PHP class or script that abstracts the database. Why don't you just use PHP's native mysql_* functions? See: http://uk2.php.net/manual/en/ref.mysql.php

The queries don't seem like they're going to be similar in what they display. the first query looks at the boards, but the 2nd query is looking at topics... significantly different unless i'm mistaken. How about you give us a sample of what you suspect the query might look like, and also what you expect the output to look like.

I recommend you post some code with what you've got so far and what you require (example dataset).

p.s. make sure to add a WHERE clause because Corbin's SQL statement will update EVERY row in your table... WHOOPS!

And you're sure that your database tables are using UTF-8 and that the characters in question are valid in the utf-8 charset?

I think I might be misunderstanding here, (or perhaps you're not sure what cookies are for). But you want to store cookies in your database. Why? And which cookies? Cookies are to be used to store information on the client's machine, which can then be read by your PHP scripts when they access your site.

For those interested the link to the UPDATE syntax is here: http://dev.mysql.com/doc/refman/5.1/en/update.html

As a quicker pointer, you appear to want to be grouping by firstname, surname, so I suggest you alter your SQL statement to reflect that...

Indeed, as Mchl suggested, I suspect your syntax is wrong. i.e. UPDATE table1 (col1) VALUES(val1) is invalid. It should be UPDATE table1 SET col1 = val1 What you're doing is using the INSERT syntax for UPDATE, they're not the same

You need to load these tables up into another MySQL installation (by placing the files into the MySQL directory structure, google it). Then you can do a mysqldump from cmd line to get a SQL script to run with most other dbs

Do echo $sql, at the bottom of your script to see what the full SQL query is. Basically I expect it to be malformed. Post it here for us to see.

The one thing the diagram seems to be missing here is relationships, i.e. 1-> many, 1->1, many -> many. This isn't clear. I'm guessing that (for example) vid to video_by_category is a 1-> many (i.e. 1 video can be in more than 1 category). Alter your diagram to show these relationships.

Just changing the my.cnf file won't faciliate anything, you'll need to restart the service and verify that the my.cnf is being loaded on startup (should be by default from /etc/my.cnf).

I suspect that DB Visualiser won't show references because they're not enforced in MyISAM tables. Check the DB Visualiser DOCS...

Typo.... See "WHEN 7 THEN EFT('Archived',20)" Can you spot the error?

It's a self join, i.e. JOIN table1 ON table1. Given that you're identity is the "id" column you'll be joining on that. I'm assuming you know how to do a join so i'll leave you to figure out the exact SQL. However, I think what you're ideally looking for is a cross-tab. Needless to say, the self-join will suffice for now. p.s. the join is a LEFT JOIN

Yes, if you're not got any indexes defined...

Which of those statement's is causing the problem, and which field? Also when you do inserts specify the fields you're going to be inserting into (it makes it clearer). e.g. INSERT INTO table1(field1, field2) VALUES(value1, value2) This also avoids the issue where you have to supply '' for your primary key (which i'm surprised hasn't errored yet).