btherl

In what way does it not work? Does it mangle the results or does it just not sort in the right order?

pg_insert()? I didn't know that existed Judging by the comment in the example in the php docs, it's injection safe. But the function is also labelled as experimental Anyway if it IS telling the truth and it is safe, then you definitely must NOT call pg_escape_string() yourself, as otherwise you'll get your strings escaped twice. That's a real hassle when that happens.

Columns get added all with one statement. For example: $sql = "INSERT INTO tab (col1, col2, col3) VALUES (E'" . pg_escape_string($col1_data) . "', E'" . pg_escape_string($col2_data) . "', E'" . pg_escape_string($col3_data) . "')"; If you need to add multiple rows, then you should use a loop for that. Just not for the columns (at least not normally)

You can use pg_escape_string on the date, then enclose it with single quotes. Something like this: $sql = "INSERT INTO tab (col1) VALUES (E'" . pg_escape_string($data) . "')"; The "E" says that there's an escaped string following. You can leave it out and it'll generally work, but newer versions of postgres will generate a warning. For data that should be a specific data type (such as an integer), you can filter the string so it only contains digits, for example.

No worries I guessed from how you worded the first post that you're new to php.

Ok there's a few problems there. The indentation at the start should be // Check if the form has been submitted. if (isset($_POST['submitted'])) { $errors = array(); // Initialize error array. // Check for a first name. if (empty($_POST['first_name'])) { $errors[] = 'You forgot to enter your first name.'; } else { $fn = trim($_POST['first_name']); } And notice that there's no closing "}" on that first "if" - so php will be expecting it to be closed further down. Second, there's a parse error: echo // Already registered. '<h1 id="mainhead">Error!</h1> <p class="error">This email address has already been registered.</p>; } // make sitename the current db $db_selected = mysql_select_db('sitename', $link); if (!$db_selected) { die ('Can\'t use sitename : ' . mysql_error()); } If you look at how phpfreaks highlights this, it looks odd. It's because the closing quote (the ' character) is missing. Try: echo // Already registered. '<h1 id="mainhead">Error!</h1> <p class="error">This email address has already been registered.</p>'; } // make sitename the current db $db_selected = mysql_select_db('sitename', $link); if (!$db_selected) { die ('Can\'t use sitename : ' . mysql_error()); }

Did you try using both of those pieces of code together? Also can I suggest using indentation like this: if (foo) { something; if (bar) { somethingelse; } else { anotherthing; } } That makes it much easier to understand how the program works. It will help you find bugs faster, and also help us to understand your code so we can answer your question The basic rule is that whenever you start an "if" or "while" or "foreach" or anything which has a "{" following it, then you should start indenting. When you reach the "}" at the end, then you go back to the previous indentation level.

Your form input is called "q", so you should access that with either $_POST['q'] or $_REQUEST['q'] in the code.

You probably want "SELECT *" rather than "SELECT ageGroup" too.

If you open a pop-up window, you can handle things there, and then just close that window. Another option is to use ajax to handle everything for the secondary table. In both cases you can use javascript to update the master page if necessary.

The database will make one locker wait while the other proceeds. It's first come first served. This is true for write locks, but not necessarily for read locks, as multiple users can read data at the same time. You should probably do it like this 1. Lock the tables involved 2. Read the relevant data (check if anyone else is editing) 3. Mark yourself as the editor 4. Release the locks The reason for that approach is that if you read before locking, you may get two users reading at the same time, both thinking they can mark themselves as the editor. If you lock the tables first, then any other user will be locked out until after you have updated, and when they read they will find you are editing. Are you asking if you should put NOT NULL in your table definitions? I usually do, if a value should not be null. If a value should not be null and you set it to null, then that's an error and I want to be notified. But if a value is allowed to be null, then of course it should not be declared "not null" So it depends on the meaning of the value.

nimeshrmr's approach sounds good to me. That's the basic method used in collaborative code repositories, though resolving conflicts can get messy. Another approach which may work (it depends on the situation) is to record the time and identity of the person wanting to edit, and give them a fixed amount of time to do the editing. Make sure the client software warns them if their time is running out. This can be simpler to implement as there's no need to resolve conflicts when two people make changes to the same record.

Change this line mysql_query($query); to mysql_query($query) or die("Error in $query: " . mysql_last_error()); It will tell you if there's a problem with the query. I think nafetski has picked up the issue already though.

So you want 3 data items: 1. The most recent user's name 2. The sum of the prayers column for all users 3. The sum of the prayed column for all users Is that right? I'm a bit confused as to whether you want the sum or the count. In any case, you should do it with two queries. SELECT user_name FROM users ORDER BY id DESC LIMIT 1 SELECT SUM(prayed) as sum_prayed, SUM(prayers) as sum_prayers FROM users I don't see any benefit to using one query only in this situation. Mysql can probably do the first query quickly using an index. If you find you have a performance problem with scanning the whole users table to find these counts, you can store the sums in a seperate table and update them every time prayers or prayed is updated for a user.

If you want to remove the proxy from the text file, the simplest is probably to read in the entire file, filtering for that proxy server as you go, then writing the entire file again. Or you can filter while writing instead of while reading.

Since you set the proxy type to HTTP, I would assume it will use an HTTP proxy. There is documentation for curl_setopt here. For your second question, that sounds awkward. What problem are you trying to solve by using that text file?

No worries, I kinda realized that after writing the post. I agree it's silly to use it on most functions. A lot of code for no benefit. That's a good point. My workplace has never used automated documentation generation methods, so it's not something I'd considered. I also don't use an IDE Unless you consider vim with all the code writing add-ons an IDE. Do you mean you have to set default values in the called function for unused arguments? I'm not sure what you mean there. Here is how I see it, where named arguments mean less mess when calling with only some optional arguments set (though more code in the called function): function annoying($userid, $casefold = false, $include_admins = false, $start = 0, $limit = null, $generate_paging_data = false, $glob_globules = false) { # Here goes type checks, range checks, etc etc ... } annoying(123, null, null, null, null, null, true); # We only want to glob the globules. Defaults for other arguments. function nice($args) { $userid = $args['userid']; $limit = $args['limit']; # Allow null as default value ... $glob_globules = isset($args['casefold']) ? true : false; # Convert to boolean. Or we can type check our argument with is_bool() and take action if it isn't # Here goes any further range and type checks not done above. } nice(array( userid => 123, glob_globules => true, )); } Calling nice() looks better than calling annoying() to me, even with the funny looking array() syntax. On the last point, I agree the extra coding is annoying. You can't get around that in perl either, all you've got is slightly nicer calling syntax.

I was thinking more like this: CREATE TABLE photos (photoID VARCHAR(32) NOT NULL PRIMARY KEY, userID VARCHAR(32) NOT NULL, photo VARCHAR(20), photo_number TINYINT); This is not necessarily a better design, but it might be better. It helps if you want to renumber photos - you just need to update the photo_number column, instead of moving values around between photo_1, photo_2, and so on. It also helps if you want to search for all photos with a particular name, as you can search for the photo column only, instead of searching 5 columns. It also lets you change the allowed number of photos without adding columns. These days I don't worry about too many tables because I'm quite good at joining tables together. If you're not experienced with joins it can be quite tricky though. There's no technical issue with having 100 or 500 tables, just the issues that might arise when joining many together. It is often more efficient to include data in a table rather than have two tables and join them together.

So do I. As I mentioned earlier, I start with simple function arguments, and convert to named arguments as needed. What's the documentation issue? Both functions with and without named arguments require documentation. If you were relying on the argument list itself for documentation, then you've already got documentation issues! Now, on to those criticisms: Introduces a non-standard coding practise which will increase the learning curve associated with your code, as well as annoy a reasonably number of people. Yes, this a disadvantage Emulates something that has been excluded from PHP for a reason (it doesn't follow KISS). In the right situation, it does simplify things. The right situation is functions with large number of optional arguments, where the "simple" argument passing method becomes cumbersome Makes it more cumbersome to set default values for parameters. I believe it is simpler to set default values with named argument style in the right situation. Traditional argument passing can be problematic here, as all default values must be to the right of the last required value, giving an artificial constraint on argument ordering. Not to mention that the developer must handle dummy argument values, and the caller must pass the correct dummy value. Required parameters have to be enforced by the developer instead of by the Zend engine, which is just further overhead in terms of both performance and coding. Not an issue in the right situation. A function with many optional arguments will rarely have its performance dominated by argument parsing time. If it does, you can simply use traditional arguments and put up with the inconvenience. Unfortunately, PHP doesn't support a shorthand array syntax like ['value1', 'value2'], so having to use array() for every arguments decreases readability. Yes, this is a disadvantage. An unfortunate design decision for PHP, I would say Perl got this right. Doesn't allow for type-hinting of objects and arrays, instead, the developer is required to implement this. I'm not sure what you mean here My claim: Named arguments are superior to traditional argument passing for some functions, in particular those with more than one or two optional arguments.

There's a few things I would suggest 1. Use date data types whenever storing a date, so you can do comparisons in SQL easily. 2. Store multiple items like attributes and photos in a seperate tables. You can have a column to indicate whether it's #1 or #2 or #3. That allows you to easily change the number of items that can be stored, and also lets you more easily do operations that affect "all photos" or "all attributes". Eg, let's say you want everyone with attribute "strong". In your current design, you have to check three columns to see if any matches. 3. If there's any possibility of changing usernames in the future, you should identify users with user id (the PK of the user table) rather than user name.

Really? This is pretty standard in perl. Not just because it allows painless addition of new arguments, but because it allows painless passing of just a few from a large selection of possible arguments. DateTime for example. Can you imagine doing that with traditional PHP style arguments? As for the idea of designing the system in its totality before starting the coding, that's just not possible in the business I work. We build the application to spec and then our boss says "Why is it doing X? It should be doing Y instead". So we modify it. Then he says "It shouldn't be doing Y, it should be doing Z". It's a constant cycle of modification that continues until the end of the application's life. We can't blame our boss either, as a lot of these change requests come from customers wanting features Y and Z, not because he gave us the wrong spec.

As a possible caution, you'll need to make sure whoever is maintaining your code understands how it works, since it's not as standard in php as it is in perl.

Having used it for a few years now (that original post was from 2006), I think it's great The same idea is very popular in perl too, and perl's syntax is even nicer for it. Thanks for pointing out that other thread. What I do these days is I start functions with simple arguments, and then I switch them to named arguments as needed. Functions that benefit from named arguments typically aren't called in many places, so this works well. If there's a function that IS called from many other places, then I can always add a named argument wrapper for it rather than changing all the places where it's called from. I had to do that once only (and actually that was in Perl, but the same principle applies).

Ok, makes sense.. so then users can browser the database, following the links. Is the tokenizing necessary because you have data stored as strings, such as "Rewards"? If I was writing this I would store that data using the database structure itself. Eg, table Items and table Quests, each with a primary key, would be linked by table "QuestItemRewards", which would have one column for the Quest ID and another column for the Item ID. Presence of a Quest ID and Item ID pair in that table means that quest has that item as a reward. This allows for multiple items as a quest reward, as well as a single item being rewarded for multiple quests.

Ok, from what you've told me now you've got several kinds of objects. A quest, a monster, a skill, an item ... knowing that, having them all in one table is probably a bad idea So I would keep each category in its own table. I'm still too confused to give any useful advice though. I'm imagining you want something like a table listing items, and along with each item you have links to other database objects (like quests or monsters) which are related to that item. Is it something like that?