mryno

I feel pretty good about that solution printf. Nicely done. I thought you weren't understanding the problem, but that seems to be a pretty good solution. I will definitely give it a whirl and see how it goes. Thanks again!

Actually I think that would work. Is that the kind of solution you were looking at printf? For some reason I had it in my head that I had to foreach through the db results because a client could have: www.mysite.com/test1/test2/index.php - triggering two IDs and giving me issues, but that will be a problem no matter which direction I am checking from. Let's see what printf has to say though... The short answer, yeah that will work. I am going to have to find another method for checking against two identifiers in the URL since that could hypothetically, but not practically, happen.

Cool. Really I just need the something and test1. I don't need the URL or file name. Don't get me wrong. I totally appreciate your help. I just wanted to make sure you understood the problem. Thanks again!

The id's are coming from a DB query. The URL is where the HTTP request is coming from. The problem is that the URL could be anything and the identifier could be anywhere in the URL, so I can't search the same place in the URL every time because one company may do it differently from another. I need to search every element of the URL. Basically, I HAVE to use my array of id's and with each one look for a match in the URL. There are reasons. I promise. But I would like to have it so I don't foreach through all of them. If I call 'break' does that exit the foreach? That may be all I need. In plain English here is the problem: In this requesting URL there is an ID. Here are all the possible active IDs from the database. Go through the IDs looking for a match against the URL until you find a match. When you find a match, don't finish looking through the other IDs. That match is the company making the request. I kinda want to do a foreach/while combination.... While I haven't found a match, keep foreach'ing. When a match is found finish.

I'm with these guys. Store the user in the session when you run the log in script. Then there is only one query and it is always available in $_SESSION for other pages. I usually store other info in the session as well like the unique key of the user and whatever other details you may need to identify him in queries down the road. Like The Little Guy said, if he is an admin, throw that in, too. $_SESSION['USER']['is_admin'] = true $_SESSION['USER']['user_id'] = '1234' $_SESSION['USER']['user_first'] = 'John' $_SESSION['USER']['user_nick'] = 'John123' That kind of stuff is always useful. You may want to break it up like I did with all your USER info in one container and so on... If it is just a simple thing that only deals with users, you don't have to.

I also retract my props. Only the ones dealing with the IN() though. The other ones are still yours...for now.

The company names/ids are in a DB. I queried them out though. After querying for the IDs, I then search the URL to see which company ID is in the URL. I then use the rest of the record to identify everything about the company....

Props are definitely in order. I think I just wasn't on the same page when you mentioned it. Nailed it!

in_array is actually the opposite of what I want to do. Sorry if my explanation wasn't very good. I want to while/foreach through an array of strings and see which array item matches part of the URL. My array contains the search terms and I am searching the URL to see which of those array items it contains...if that makes sense.

Consider my world rocked! Very simple and elegant. That would have taken me forever. Great code Rhodesa.

I have an array of possible terms that could be in a URL: $results[0][id] = 'test1' $results[1][id] = 'test2' $results[2][id] = 'test3' Referring URL: www.mysite.com/something/test1/index.php I am looking for an alternative to foreach'ing through them and doing some kind of while so that I don't have to go through the entire array which could be quite long especially if the first term is a match...don't want to go through all the rest if I don't have to. **More Than You May Want To Know** I am basically checking the URL for known identifiers that I have stored in the DB that will identify a URL as belonging to a certain client. Given the project, this is just the way we have set up to serve multiple clients based on this specific project. There are other factors that have made it so that the URL identifies the client, but we won't go into that.

I edited my previous post, but I didn't make it in time: The issue with doing it your way corbin is simply that who's to say that a client's url to this isn't going to be: www.clientsite.com/something/test1/test2/index.php or that one of their directory names contains the term I am searching...just too many uncontrollables, but I do agree with you in general that MySQL should be used rather than using PHP to go through records. There is always a way with MySQL! Some of the data I have had to deal with IS hierarchical data, which doesn't help my lack of skills... In my experience with large-scale (100's of millions) record sets, it is beyond a doubt faster to use MySQL. It probably doesn't matter (isn't noticeably faster to the end user) as much with smaller sets (100's to 1000's) of data. MySQL is still faster in the smaller sets, but what is a tenth of a second?

That would seem like it would kill the DB if you had a lot to loop through. I mean, I've had my share of hammering mysql so of course you can get away with small tables and putting queries in a loop. But it would seem to make more logical sense to get all the info out first, put it in an array, and loop through the data with PHP... Absolutely true. I am not even to beta yet, so it just has to work with a very small load now for demos, but I am optimizing what I can so when there is a load I don't have to worry about hitting the DB so often. Most of that is my lack of MySQL skills on those 4th and 5th joins.... The issue with not doing it your way corbin is simply that who's to say that a client's url to this isn't going to be: www.clientsite.com/something/test1/test2/index.php or that one of their directory names contains the term I am searching...just too many uncontrollables on my part, but I do agree with you in general that MySQL should be used rather than using PHP to go through records. There is always a way with MySQL! Some of the data I have had to deal with IS hierarchical data, which doesn't help my lack of skills...

That is my thought also. I try to keep the workload on PHP. A query within a foreach just seems unnatural to me. I have used it once or twice, but there are definitely TODO comments right next to them. Good point corbin. If I could use the LIKE or something like that, it would be worth looking into. I think in this specific case since there are a bunch of unknowns and I won't have a lot of control over what people put in their URLs, I better put the query in the hands of the known variables. I agree though. Usually probably better and faster to let MySQL handle it if you can get it into a query. Thanks for the help!

You would parse the URL? The only problem is I would have to foreach and then query right? // parse URL to get the subdirectories and put them in the array $url pieces foreach $urlpieces { // Query each piece to see if it matches any SiteIDs in the DB } OR // Run query to get all SiteIDs as $results (1 fast query) foreach $results { // Match against the URL as a string using strpos or something similar } Is it faster to query multiple times (probably a maximum of 5) or is it faster to query once (getting possibly 100s of records) and have PHP go through them?