gizmola

MySQL doesn\'t support subqueries, except perhaps in the most recently released (beta?) version(s). Check your version to determine the status... I don\'t keep abreast of what\'s going on with MySQL development status well enough to give you the specifics.

Ok, you can then order by that column without applying any type of format. Formatting is converting the column to a string, and it\'s underlying format is an integer which will intrinsically sort as you would expect. If you want to format the columns for display, that is not a problem and can be done seperately from the order by, which is to say that you can have columns in your order by that are not in your select list. In your example, simply use a different alias for your formatted date, rather than re-aliasing the original column name and all should work as you want it to.

All I can suggest is that you look at re-installing mysql again. If the chown command didn\'t work then I would submit that you\'ve missed something, or misunderstood a direction. Some things to check out: Your my.cnf file. Take a look at this and verify that your directories are pointing to where they should be and that permissions are appropriate. For example, does your datadir directory have these permissions: drwxr-xr-x 20 mysql mysql 4096 Dec 30 02:58 mysql I suspect your initial issues with permissions may be the root of your series of problems.

All I can suggest is that you take a look at the error logs for mysql and try and determine why it crashed. Security is just a function of entries in a few mysql database tables. There\'s nothing I can think of that would explain what you are seeing.

Using the GRANT SQL statement you can create new users and GRANT them access to resources. Mysql has a data dictionary in the mysql database. The admin account can see this database but other users usually can\'t. There are a couple of tables that get updated when you use the GRANT command: user and db. Between these two tables mysql handles security.

Mysql has a data dictionary which is a database called mysql. If you can use that database, you can set permissions for individual users by using the grant statement (which also allows you to create users). I have a few examples in a mysql section of the tech page off my homepage. Link is in my sig. If you are in a hosted environment, chances are you have had a database user created for you, and will not have access to the mysql database.

What type is the column you are trying to order by?

If people are able to upload scripts to your webspace, then that\'s where your security problem lies. Using the raw functions will do nothing at all unless people know that you have certain include files that you use which provide a database connection.

Well the problem as I understand it is that your RewriteCond\'s are Ands. So i If 1st condition AND 2nd Condition And 3rd Condition. Hence when you have will not work, because while the http://domain.etc does match the first regex, it will not match the 2nd, and so it falls through. Anything to do with mod_rewrite is tricky, but I\'d question why you are trying to make two different rules when one can satisfy both conditions. On the other hand, simply adding the OR to your Flags might work. If you want to try my swag at having only one rule: RewriteEngine on RewriteCond %{HTTP_REFERER} !^$ RewriteCond %{HTTP_REFERER} !^http://(.*.|)domain.(.*)/.*$ [NC] RewriteRule (.*.(gif|jpg|avi|mpg|mp3|wmv|wma|rm)$) http://domain.com/hotlinking.php [R,NC] For your existing rule, it\'s certainly worth trying this first however: RewriteEngine on RewriteCond %{HTTP_REFERER} !^$ RewriteCond %{HTTP_REFERER} !^http://domain.(.*)/.*$ [NC,OR] RewriteCond %{HTTP_REFERER} !^http://(.*).domain.(.*)/.*$ [NC] RewriteRule (.*.(gif|jpg|avi|mpg|mp3|wmv|wma|rm)$) http://domain.com/hotlinking.php [R,NC]

Are you using the same user that phpnuke is configured with?

I did understand you, and I believe I addressed your question. There is no magic bullet that I know of with pure mysql SQL for this. If there is a way, it would have to involve some sort of computational column, but I doubt there\'s anything that will get around the group by issue. So you\'re really down to deciding whether one query with the group by works best, or seperate queries for each group does. *If* there was some sort of magic way to handle this, it would have to involve a computational trick involving a mysql function, but I couldn\'t thing of any that even warranted an experiment. Typically this would be handled easily (using a cursor) if Mysql offered stored procedures, but it does not. As to which of your two choices makes sense, as you stated, if you can limit the single result set down to a manageable number of rows my gut instinct is that will be faster than doing a whole series of seperate queries. If I come up with any brainstorms I\'ll let you know (digs for old copy of SQL for smartys)

With mysql updates are limited to a single row, or multiple columns if you specify a WHERE clause that includes a constant. Typically the way to do what you\'re trying to do would be something involving a subquery. I know that mysql is somewhat in the process of adding subqueries but I\'m not 100% current with version 4.x stuff now. The query would be structured like this (if subqueries were working): UPDATE staffemails SET is_registered = \'0\' (quotes not needed if is_registered is a numeric column type) WHERE staff_id = (select staff_id from staff where username=\'$user\') Alas they are not available to the best of my knowledge. I do question your premise though. You state that this query gives you your \"row\". It seems that all you are trying to do is shortcut your need to determine the user\'s staff_id. Simply select that first as I did in my subquery and do your simple update with the right staff_id in hand. It does take 2 queries, but they are short and should operate very quickly, especially if you are using the mysql_pconnect. Even if you aren\'t mysql\'s connections are lightweight and pretty efficient.

The important question to ask, is what function your \"5 favorite things\" list will have on the site. 1. Is it possible there will be more than 5 favorite things in a list? 2. Will you be searching for all users that share the same favorite thing? 3. Is there a lot of additional information related to a \"favorite thing\" like perhaps a long description of why it\'s their favorite, or a related image or url. If the answer to question 1, 2 or 3 is yes, then having a 2nd table is a good idea, since it will give you the flexibility and the functionality you need. One additional question you would need to add is whether or not you need to maintain ordering of the list for a person (#1 Favorite, #2 Favorite etc). I\'m going to assume that this is how your system will operate (although at the cost of added complexity in your code). Since favorites can\'t exist without the person for whom the favorite was created, the typical way to handle that is with a dependent relationship. How this is structured, is that you would have a concatenated primary key (that is it will have 2 columns). The first column will be the same name and type as the primary key for your user table. The second column will act both as a way of uniquely identifying a row (needed by the PK) from any other row, and will also maintain the order of the user\'s items. Here\'s how the tables would look: I would need to know more about what the are \"favorites\" of. If the favorites list is standardized and people are choosing from a global list of favorites, then the structure could be further broken out to be 3 tables, but that would depend on having answers to my previous questions.

your query syntax should be something like this: SELECT col1, col2 FROM tablename WHERE col2 LIKE \'%$searchphrase%\'

That sounds good. I don\'t think you want one with a NULL username.

Ack too much information... to many questions. Try breaking em down one at a time. You will probably have more luck.

If you were absolutely in love with the idea of reusing keys you could implement a custom reuse system. What this would involve is that you would need a seperate table in which you stored keys everytime you deleted an item (hence freeing it\'s ID number). When you needed to insert a new row you would: LOCK TABLE reuseidtable select id limit 0,1 If you get a row, you use would delete it from the reuseidtable, and unlock the table. Then when you went to do the insert into the table, you will specify this as the key value. The interesting thing about AUTO_INCREMENT to realize, is that it only kicks in if you do NOT specify a value for the column. You can override AUTO_INCREMENT by manually specifying a value if you choose. If you didn\'t get a key then you\'d do your typical insert without specifying a value for the PK column, and auto_increment will work as usual. This is a lot of complication in order to save what typically is not a particularly precious commodity. Simply specify a large number type for your key and you shouldn\'t have to worry about running out of numbers for the lifetime of your application.

Not really. You could use a group by group & item to get the sum(hits). This would give you everything you needed in one query, but you would still have to go through it and discard the items in each group which were not the top 3 in each group. This *might* be more efficient than what you are doing (a seperate query for each group) assuming you have a limited number of total items. The query would be something like: select a.group, a.item, sum(hitcount) as hitcount from item a, hits b where b.item = a.item group by a.group, a.item order by a.group, hitcount

All design decisions like this involve tradeoffs. BBS polls are very simple because they can ask only one question, and then have a fixed set of answers that are always an enumerated list. Since they wanted to KISS, they used a compressed non-database centric structure. If your application was focused on polls, then this might be a bad decision, but since polls are essentially fluff in the context of a forum, it really doesn\'t matter. In their case they opted for a structure that is storage friendly but computationally taxing. This however allows them to focus on the forum code and be database agnostic which was probably one of their design goals.

Mysql is a table locking database. Selects/inserts and updates all lock the table... so queuing is an intrinsic function of the database. Mysql uses priorities... the default is that writes are processed in the order received, and have a higher priority than reads. Nevertheless, Reads also lock the database from writes. By default LOCK TABLES will block/wait until it gets all the table locks you are asking for.

Well I\'m gonna eat my words on this one a bit... mysql kinda sucks in numeric presentation. Again if you really want to do this apparently you need to specify a width attribute for the column (in your case 2) with the zerofill attribute. When you do selects, the numbers will come out with leading zeros. Again, none of this necessary if you just use a Date, which gives you the great date formatting.

Not really... and it is the best way to handle your problem My only quibble is that you should use $_POST rather than the $HTTP_POST... Your code btw, is completely incorrect, because all you are checking is whether your query completed or not. It would almost certainly always be true (assuming you didn\'t have a syntax error in your statement).

Get into the database and use mysql; Select * from users; Look for a * in the user name column and remove that row in the table. After doing so you may have to flush priveleges;

The storage and presentation are two different things in sql. You can display a number any way you want using the format() function. I think that not using a date or datetime column is a very very bad idea... you say you want to, but not the reason why. Nevertheless if you feel you must fight against the features the database gives you, it sounds as if any mysql integer type will work fine for you. In this case the smallest one will work (two digit day/month/year) so a tinyint sounds right.