btherl

Try smarty's "foreach" instead of section. That will loop only over keys which exist in the array.

The simple way is using implode: $final = implode("", $img_arr); The first argument is what to put between each array item, which is nothing, aka "" As for why it doesn't work inside the other script, I would need to see how you combined the scripts.

Depending on which linux distribution you are using, you can probably install a package that will do this. On my system there is a php package, a postgresql package, AND another package which makes postgresql available from php. That last package will install itself into the apache php.ini if apache is installed. If it doesn't, Maq's instructions ought to fix it. Which distribution are you using?

I believe php 5.3.0 and greater can do this. Otherwise you'll have to kludge it somehow, perhaps with a lookup table mapping names to class instances. http://www.php.net/manual/en/language.oop5.paamayim-nekudotayim.php

Hmm, try this. Unfortunately i don't have mysql to test with so I can't test myself. $query = "SELECT User, COUNT(Game) AS Game FROM Xbox360 GROUP BY User ORDER BY COUNT(Game) DESC, User"; That's a vanilla group by that ought to work.. if it gives an error, try "ORDER BY Game" instead of "ORDER BY COUNT(Game)"

If count(Game) is the value you want to find the top 5 of, you can do: $query = "SELECT *, COUNT(Game) AS Game FROM Xbox360 GROUP BY User ORDER BY COUNT(Game) DESC, User"; The ", User" means sort by user after sorting by count(Game). That acts as a tie breaker in case people have the same count. The value resulting from that query will be called "Game", ie: echo $row['User'].": ".$row['Game'] ; The reason for the is you said "count(Game) AS Game". The "as" gives a name to the count value.

I'm not sure what you're asking here. Do you want to reduce the width of the table so it matches the width of the data in the table?

What does "if ('submit')" supposed to do? It probably should be something like "if ($_REQUEST['submit'])". Or nothing at all. Those validation checks will match empty strings. Also there is no need to have that second check, the "$validchars = ..." one. You can do that much more simply with an eregi, as you do at the top of the script. For security from sql injection, escaping the data using the appropriate database function is good enough. In your case, as you have restricted the character set allowed in the variables used in the sql, I think you are fine.. So the only problem I can see is that you have too much validation

It's probably a character set issue. You can find exactly which part causes the problem by starting with submitting an all-english form, then progressively add greek to various parts until you find which causes problems. If it's just the email body, you can attach any kind of data using MIME.

Where is the code to execute the update query with pg_query()? When you execute it, do you use a different variable name instead of $result?

Where did you get this sample code from?

That means a request is being made to your site from a php script. It's not a browser (unless it's a php proxy server). I'd have to see the traffic to say any more, but I'm guessing it's most likely an automated program.

The first thing you need to do is check return values for mysql_query(). And please remove all "@" signs from your code. At the debugging stage you want to know all of the errors. For example: function mysql_is_table($tbl) { $tables = array(); $q = mysql_query("SHOW TABLES") or die("SHOW TABLES failed: " . mysql_error()); while ($r = mysql_fetch_array($q)) { $tables[] = $r[0]; } # no @ - if there's an error here we want to know! mysql_free_result($q); # Again, we want to see the error if something is wrong. if (in_array($tbl, $tables)) { return TRUE; } else { return FALSE; } }

$conn = new CreateObject("ADODB.Connection"); // Microsoft Access connection string. $conn->Open("Provider=Microsoft.ACE.OLEDB.12.0; Remote Server=http:1.1.1.1:8080; Data Source=season.mdb;"); That should fix your parse error. Then you can see if the code actually works. There was a missing ";" symbol.

I like partial indexes .. very useful for some situations. I don't remember now what the actual situation was .. there may have been another solution like that one you suggested, but the problem of not being able to control the optimizer is still the same. We had similar issues recently where our nightly aggregation of clickstream data would occasionally take forever. It would have been great if we could have said "We want THIS query plan .. it may not always be optimal, but it will at least terminate within our lifetime". In this situation we were able to add extra indexes and now it runs fast enough regardless of which query plan it decides to use on any particular day.

If you've got complex queries and the postgres optimizer doesn't understand them, then you're pretty much on your own. We once struggled for months trying to work out why this was happening: create table tab ( a text, b text, c text, data text ); create index tab_ab_idx on tab (a, b); create index tab_abc_idx on tab (a, b, c); select * from tab where a = 'foo' and b = 'bar' and c = 'baz'; Now which is the correct index to do the lookup with? The index on ab or abc? Postgres invariably chose the ab index, because it thought that that would restrict the result down to one row. In reality columns a and b were highly correlated, so this index would produce many rows, and all the optimizer's calculations from that point on would be wrong. So the solution is simple right - make postgres use the abc index. But you can't! The only solution is to use "de facto hinting", such as rewriting the index such that the optimizer will use it, eg: create index tab_abc_idx_i_hate_postgres on tab (a || b || c); select * from tab where a || b || c = 'foobarbaz'; This is a hidden ugliness of the postgres approach. Apart from that though I love it I can put up with this annoyance for some of the other nice things postgres has.

"It has transactions uses MVCC to manage concurrency instead of locking" isn't really accurate or fair .. postgres does use locking, it just uses them better than the default mysql table type. And InnoDB uses MVCC. And from a DBA's point of view, one of the biggest weaknesses of postgresql currently - no query plan hinting. That's possibly the biggest way in which postgres wastes our time. Hopefully those new query monitoring tools promised in 8.4 will help

The easiest way to pick a random one is to generate a random number in php. You can find the highest code with "SELECT max(code) FROM item_codes", with the result being named "max". There's also a thread in the mysql subforum here about choosing random rows from mysql, but it's a little complex.

This command is done once only, to create a place to store data (called a "table"): $sql = "CREATE TABLE item_codes ( id serial, code text )"; $result = mysql_query($sql); if (!$result) die("Query $sql failed: " . mysql_error()); Then this query is done each time you want to fetch data from the table $sql = "SELECT * FROM item_code"; $result = mysql_query($result); f (!$result) die("Query $sql failed: " . mysql_error()); while($row = mysql_fetch_array($result)) { echo "ID :{$row['id']} <br>" . "CODE : {$row['code']} <br>"; } But first you will need to add some data, otherwise you'll get nothing from that SELECT query: $sql = "INSERT INTO item_code (code) values ('foo')"; $result = mysql_query($result); if (!$result) die("Query $sql failed: " . mysql_error()); Once those ones are working you can add some more data and start looking at the "WHERE" clause from SELECT.

I think you could implement it something like this: CREATE TABLE item_codes ( id serial, code text ); CREATE TABLE ip_item_codes ( item_id bigint, ip text, date_fetched datetime ); "id" is an integer uniquely identifying each item. ip_item_codes records which items have been given to which ip address, and at what time. This is assuming you use ip address to uniquely identify your users (which is fraught with problems). Each time you give out an item you can store a row in ip_item_codes. Then you can refuse to give more items if that ip has a row in that table with date_fetched less than 24 hours ago. This is not an ideal solution but it's a start. This also allows you to check that someone has been given an item code when they try to use the item, as you can check in the ip_item_codes table.

Infect, you'll need to get some experience with mysql first. Also your description is a bit too vague. Can you say what this is for? The best solution depends on the task.

Is your goal to understand the previous implementation or to implement it yourself?

The postgres serial data type is a bit of a hack, so it doesn't follow all the rules you might expect it to. It's basically a standard column with a default value of the next number in a sequence. Apart from that it acts exactly like a normal column. So you can set it directly and even update it to a new value. You can also set the "next in sequence" value if you want.

Is there a reason why you can't specify the column name? SQL is not supposed to be used the way you are trying to use it. If you really want it to work that way you can try creating the table with the score column first and the serial column second.

Yes they can. The command which alters records is "update". For example UPDATE foo SET name = 'btherl' WHERE userid = 10 That will change all rows in table foo which have column userid equal to 10, setting column name to 'btherl' in each one. If there is only one row with userid 10 then only 1 column will change. If there's 0 rows matching, 0 rows are changed and it isn't an error. If there's many rows, all are changed. PS: These are all generic SQL commands. If you find a MySQL tutorial, which is easier to find than a postgresql tutorial, you can learn SQL from there and then use most of it in Postgresql.