corbin

Hrmmm... Why do you want to do this? Why not just use what ever language you're pulling the data into? If you're trying to select things between something, you can do WHERE x >= 5 AND x < 10 (not sure if MSSQL has BETWEEN or not).

Have you read: http://www.phpfreaks.com/forums/index.php/topic,95378.0.html ?

Yeah, true. I feel that people are a lot more picky about visual things though. Then again, don't have much client interaction experience, so I could just be assuming wrongly ;p.

$sql = "insert into User Table(first_name,last_name,user_name,password) values(\"$firstname\",\"$lastname\",\"$username\",password(\$password\") )"; Should be $sql = "insert into User Table(first_name,last_name,user_name,password) values(\"$firstname\",\"$lastname\",\"$username\",password(\"$password\") )"; And really, you could use single quotes so it looks cleaner: "INSERT INTO table VALUES ('{$val1}');"

Glad I don't design ;p.

Errr..... What are you trying to do? A WHERE clause in an INSERT statement makes no sense.

The first comment is hilarious. Oh, and the crashie stuff also is awesome.

What are you trying to do? That syntax is entirely wrong. ^ means starts with, and $ means ends with.

oci_num_rows "Note: This function does not return number of rows selected! For SELECT statements this function will return the number of rows, that were fetched to the buffer with oci_fetch*() functions. " No idea what function you do use to get the number of rows from a SELECT statement though.

You could just use str_replace. As a side note, you should do a while loop instead of a do while loop with database results unless you know for sure that there's a first result. (You would need to get rid of the $row_rs1 = mysql_fetch_assoc($rs1); before the loop.)

session_set_cookie_params You'll need to set the domain to kinggoddard.com or maybe ".kinggoddard.com"

Whenever I first saw this thread, I thought it was going to be supporting the idea of a conspiracy. I was like "Oh no...." Personally, I've seen no proof that it was or wasn't a conspiracy. But as far as the United States doing it? Why? Why would anyone have wanted to do that? Makes a lot more sense that terrorists would just hate the United States.

Wow.... Lamebook has now replaced FML in my mind.

Hrmmm, the only thing I can think of is that www.mysite.com will be remapped, but not mysite.com. In other words, subdomains and domains are separate. Aside from that, I doubt it's the problem, but you could try flushing your DNS cache. (Open command prompt and type in "ipconfig /flushdns".)

Yeah true.... He seems like the type that would purposely omit the first letter. What's the point in repetition anyway?

The first thing that I noticed was that it's missing the second T. How do you know it's the second and not the first one that's missing? Because I assume that he forgot to type the second one, not typed the first one, removed it and then typed the second (or typed the first and second then removed the first). Then again, perhaps I shouldn't count from the left.

The first thing that I noticed was that it's missing the second T.

"or should I first download the file to the vps server then send it to the user?" That would use double the bandwidth (for you, not for the user). There isn't technically a way to send someone somewhere without sending them there.

That could all be caused by the whole "shutting down abruptly f's stuff up" thing... Side note: While doing some googling, came across http://tag1consulting.com/MySQL_Engines_MyISAM_vs_InnoDB explains everything fairly well.

Is that really a word filter? Surely not.... KKK Edit: I had to know!

why is that? Is it because of all the sandwiches? That's what happens when I post on PHPFreaks first thing after waking up.

Your webhost disabled InnoDB? Lame. Perhaps the reason that I've never had many issues with MyISAM corruption is that I rarely ever use MyISAM unless I need fulltext indexes. As for the speed thing, I'm probably also thinking of old benchmarks. So in that case, ignore everything I said about MyISAM pretty much ;p. Hrmmm, The Little Guy, this is a random hunch, but try removing content IS NOT NULL and see if the speed gets any better. Edit: Nevermind. Based on some ghetto benchmarking, it's definitely the SQL_CALC... I thought maybe there wasn't an index on content that could be used to check null-ness and that causing it.

Yeah, I must agree with the replication point. I should have thought about that actually. Semi-side note: Does MyISAM have a binary log like InnoDB? Guessing no. You would have to use LIKE clauses that could not use indexes, which would cause entire table scans. Even worse, if the table were large, there would probably be a huge amount of disk I/O. Just of curiosity, why do you think InnoDB is faster? I've never heard of a query that properly uses indexes in both MyISAM and InnoDB being faster in InnoDB. Perhaps some memory settings would need to be tweaked. For example, MyISAM index searches are a lot faster if the entire index is in memory for the table. Or maybe InnoDB just handles some types of indexes better or something. As far as data loss, I think that problem is over exaggerated by most. Yeah, MyISAM is quite sensitive. If you shut MySQL down improperly, you're supposed to repair tables, backups are a bit more difficult, so on... But I still don't think that data loss because of MyISAM is that common. In my experience, MySQL is pretty good about doing the maintenance on MyISAM that people don't realize that they need to do. Note that I'm not saying that data loss isn't a lot more common, I just feel that "very prone" is a bit overstating it. Oh also with your InnoDB table, on MyISAM tables, locking can happen at all kinds of weird times (for example, a long select can actually hold up other selects if a write is pending in between the reads). So perhaps InnoDB is faster due to locking stuff.

Forget turkey. Deserts are where it's at on Thanksgiving.

It's not nearly that simple. I think you could learn more from google, but here's a short explanation of the pros and cons of the two most widely used MySQL engines, InnoDB and MyISAM. ----InnoDB--- --Pros-- -Row level locking (can have concurrent INSERTs/UPDATEs as long as it's not the same row) -Better data recoverability -Handles unexpected shutdowns better --Cons-- -Slower extraction -No fulltext indexes ---MyISAM--- --Pros-- -Faster data extraction -fulltext indexes --Cons-- -Table level locking (Reads can be done concurrently, but altercations are queued linearly) -Data is more prone to loss (although usually this is not a significant risk) Basically for data without a fulltext search need, if concurrency of insert/updates is needed, InnoDB is your best option. If there will be few writes and a lot of reads, MyISAM is your best bet. If fulltext searching is needed, MyISAM is your only option in MySQL (I hear that the Falcon engine in MySQL 6 handles fulltext well, but no idea how accurate that is or not).