gizmola

Well it looks like you are misunderstanding how to use sessions. You should have your session_start() call at the top of every page. You can't read a previously set session variable without doing session_start() first.

In the section of code you provided, I would suggest that every place there was an addtype, change that to AddType. See if that helps any.

There's actually 3 params you need to look at: query_cache_type=1 Will turn on the query cache and cache select statements. This should be the default. query_cache_size = Bytes in multiples of 1024. 40k needed for query structures. Defaults to 0, which essentially disables cache. query_cache_limit= Bytes. This is the maximum result set size that will be cached.

Check your error log then. The only other thing I can think is that your array does not in fact have 200 elements.

You talk to mysql using client libraries. That goes for a server running php, or the mysql command line client, or an application which makes calls to the client library. The protocol sends queries and data, and gets data back. So think of it as a 2 way pipe: Client --> This pipe has an associated character set/collation. Utf8 is a unicode character set. The idea is that every character in every language can be represented in unicode. utf8 uses a variable number of bytes to store a character (anywhere from 1-4 bytes) that does a neat trick so that it is typically byte compatible with latin1, which is in heavy use throughout the english speaking world. It is generally considered these days, that if your application needs to be multi-lingual out of the box, utf8 is a good character set to use, although like anything, flexibility often requires additional overhead.

The set names modifies the client protocol explicitly. The last 2 options do this by default, although PHP may override the default, so it may be necessary regardless. You'd have to test to know for sure. The reason this is necessary, is so that mysql knows that the data it is receiving from the client should already be in utf8 format, and no transcoding will be necessary. Otherwise, if it things the data is using a different character set, it may try and modify it on the fly which often ends up being lossy/truncated. In my experience it's more of an issue getting the data back out again, as without that, PHP turns all the utf8 characters into '?'.

I agree that in many cases the mysql manual isn't easy to read, but there is also google on each of the terms. In broad strokes I already explained what they relate to, but the topic could and does make up a chapter in any decent mysql book. Do you understand: -A character set? -A collation? -The mysql client protocol? -what utf8 is? The "defaults" simply apply those settings as default, so if you omit them on table creation for example, they will be applied to your new table automatically.

BTW, about the only area you really need to consider options for in this case, is the collation. This thread on the mysql forums does a fantastic job explaining the nature of the utf8_general_ci collation vs. using an alternative unicode collation. http://forums.mysql.com/read.php?103,187048,188748#msg-188748

Why not reference the mysql manual? Each of those are setting things up with the mysql server so that it utilizes the utf8 character set, associated client connection parameters, and a collation (ie. sortation) that works well with utf8.

I don't see an issue with the code. I actually suspect that you might be running out of execution time. Furthermore, for a bulk query like this, it's a lot more efficient to build one giant insert rather than doing 200 queries. This is set in the php.ini via the max_execution_time = directive, and defaults to 30 seconds. You can try overridding the default with set_time_limit(120) ; at the top of your script, to see quickly if that fixes your issue.

No, because that is the domain of the web browser. Sessions have their own expiration mechanism, and while you can try and get in the middle of navigation using javascript, users really don't like it for good reason, and may avoid your site simply because you're interfering in things that aren't your business, as a website purveyor.

I guess that's true if I hadn't declared $bar at all. Still, I guess it comes down to performance if that's the case. Should I avoid "!= NULL" condition statements and stick with isset() for now on? Again, there are 2 different concepts: "isset" -> does this symbol exist in the PHP symbol table. "NULL" -> does a matching symbol exist, however there is no associated value.

Great -- please mark this as solved.

No, that is a standard design pattern, and works well in most databases. Oracle is somewhat unique in that it has the very helpful CONNECT BY syntax, but I'm going to assume here that your trees aren't going to typically be very long, so even if you have to issue multiple queries to go up the tree to the ultimate parent, it's not going to be much of a problem.

Sort of. You should not use a column in the user table, but rather a seperate table that links the user to the saved queries. This might look something like: user_saved_searches --------------------- user_id (primary key) saved_searches_id (primary key) created_on timestamp This way, when you find a match on the query, it's a simple 3 way join from saved_search to user_saved_searches to user, to get the list of people who need to be emailed. As for the rest of the pseudo-code, I can only again say, that any solution is going to be highly dependent on your application and the nature of the existing database and search. You could have a compressed format for the search that you store in a db, which will make an indexed search against that column very efficient for finding similar queries, however, if you have a ranged component, then this is no longer trivial. When I say range, what I mean is, if there is ranged pricing for example, where a person can say: Less than $10. Now an item comes in that is $5. This is going to match pricing criteria for a whole bunch of people potentially, so that is not a simple thing to determine. You may need to cast a larger net and then eliminate people with saved queries who fall outside the range(s).

Yeah, i need the names of the columns, but you get the idea. If you don't specify the order and number of columns on the insert ie. INSERT INTO tbl (col1, col2, col3 ...) VALUES (1, 2, 3... ) etc. then the values must exactly match the structure of the table.

Just do a string comparison foreach($d as $f) { if ($f !== 'filename to hide') echo "$f"; }

The standard solution to this is to move load off the database and into an in-memory cache. The most frequently used cache is memcached. As to your current conundrum, as Mchl already indicated, you need to figure out what query(s) are bogging down, although this can sometimes be misleading when it is related to contention or locking. If you do find it's a basic query, then you will want to get very familiar with mysql's explain, as well as understanding how to optimize queries. The main thing you want is to make sure that you aren't doing table scans. Luckily there are a lot of good resources on the use of EXPLAIN and how to optimize mysql queries.

Please post a describe of the table Justin_Demographic

Yes, your dates are strings -- so they must be enclosed within quotes.

You still haven't indicated what your problem is. I'm going to throw out a few general comments. - You seem to have a routine where the goal is to write out an htaccess file at some point. That htaccess has a bunch of apache mod_mime addType statements. - addTypes are part of mod_mime, and simply associate a file extension with a Mime type and ideally apache handler. If you have "Mime type problems" then I would assume it is related to an understanding of apache's MOD_MIME module, the addType directive, MIME types in general, and/or some combination of these items. Please do some of your own research given the information I've given you. If you can't explain what your problem is we can't help. PLEASE NOTE: NO WE DON'T WANT TO SEE A BUNCH MORE OF CODE YOU HAVEN'T WRITTEN AND DON'T UNDERSTAND YOURSELF!!!! Please read the forum posting rules and TOS if you're unclear about how to approach things: http://www.phpfreaks.com/page/rules-and-terms-of-service

The answer is entirely dependent on your schema, but the first thing I'd point out is that the interface to search is completely different from the actual SQL required. What you should be saving is the state of the UI that then leads to the queries. If you've solved this elegantly, then there should be some normalization involved, and hopefully you will have a table or set of tables that can describe a saved query. For efficiency, when a user saves a query, the first thing that should happen is, your code should determine if this saved query already exists. If it doesn't then you: -Create a new saved query -Link the saved query to that particular user. IF however, the query is found: -Link the saved query to the user. Obviously this will save resources, as users who have the same criteria will share the saved search. I don't know what database you're using, but this is a good strategy if you're using mysql. - Have a replicated mysql server for running your saved queries off. You can use maatkit to control the amount of drift between your servers. Check it out. At batch time (stop the replication on the slave server) Run your saved queries process on the slave, and not the master. This will insure that master (your transaction database) isn't effected by the load of the batch process Have your batch process run through the saved queries, and mail results. Since you have a many to many relationship between users and saved queries, you'll save substantial overhead anytime users have saved the same query, which I would predict will happen quite frequently. One important thing to consider -- how long will stored queries persist? Make sure you have a timestamp on the relationship between the user and the query. You can then easily have a pruning script that runs, that clears out obsolete queries (maybe it's 90 or 180 days?) or whatever criteria. This also allows you to indicate if a user no longer wants to receive updates (otherwise you'll be violating canspam). Obviously there's no reason to run a query if there are no users interested in the results. Hope this helps you.

Wait, Geocities was still running? Truthfully, Geocities was horrible. Had they updated their tools they might still be around. Amazing to think that POS was once valued at 3 billion dollars.

It looks like this function is attempting to create an .htaccess format string. Why you are doing this, and to what end, we can only guess. We also have no idea what your problem is. You aren't going to get help without providing detailed information about what you are trying to do and SPECIFICALLY what errors or problems you are having.

You can't get dynamic behavior without javascript or some other clientside technology. The only other option is to require individual requests be sent each time one of the parent select boxes is chosen. That's certainly safe and old school, but in today's dynamic/ajax/web 2.0 world, it may be highly annoying to users who may abandon the form rather than complete it. It's really up to you and the client to decide what you want to invest. It's possible to sniff out the availability of javascript and not use it only if the user doesn't have it available, but then of course that makes the application a lot more complicated.