hitman6003

MySQL Administrator http://dev.mysql.com/downloads/gui-tools/5.0.html

If your host has MySQL 4.1 (which is bad...active support for MySQL 4.1 ended a year and a half ago), then you probably also have php4, which I'm not sure how much support there is for mysqli in php4.

I can only assume that you mean a database abstraction layer, and not creating functions in core php.... Use Zend_Db as an example: http://framework.zend.com/manual/en/zend.db.html You can simply extend the classes and name them whatever you want: class retrib_query extends Zend_Db_Select { ... }

By extending Zend_Auth_Adapter to be customized you can then return back a Zend_Auth_Result object that has whatever username you want...get if from the database for instance. Then, when you call Zend_Auth::getIdentity(), it returns the valid username, not the incorrect one. By breaking the functionality of getIdentity() (by it not returning a valid identity), you make things much more complicated for yourself...and whatever unlucky sap has to fix/extend your stuff in the future.

And what you're doing is defeating the entire concept of abstraction...now where ever you manipulate that data you have to call Zend_Auth, Zend_Session, and whatever code you're using to gather data from the database. Why not write a simple Zend_Auth_Adapter that does it for you, once.

Sounds like an extension to Zend_Auth is in order.....

Maybe this will help? http://www.stroz.us/php/index.php?option=com_smf&Itemid=53&topic=94.0

I don't see anything wrong with your file write code. If you are using php5 you can use the file_put_contents command, which is somewhat easier to read (and only one line). function void_case_statement($search_for, $replace_term, $filename){ $search_for = "\"$search_for\""; $replace_term = "\"$replace_term\""; $old_size = filesize($filename); //read contents and add new text $file = file_get_contents($filename); // update the file $new_size = file_put_contents($filename, str_replace($search_for, $replace_term, $content)); if ($new_size) { echo "File successfuly modified!"; } echo "Old file size was: " . $old_size . ".\n" . "New size is " . $new_size . ".\n" . "Expected size is: " . (($old_size - strlen($search_for)) + strlen($replace_term)) . "."; }

my.(cnf|ini), depending on your operating system. Perhaps you should ask your DBA to set it up.

Again, just storing information in a database does not cause it (i.e. the database or the table) to consume RAM...the only time data is stored in RAM is when the column is indexed. Of special interest here is InnoDB's B-Tree indexes. The leaves for an InnoDB primary key index store the data itself, so long as it doesn't exceed the size of the leaf (which, if I recall correctly, is 16KB), and the field is not a, or variant of, TEXT or BLOB (might be others that I don't remember off-hand). Secondary indexes store pointers to the primary key, which in turn, follows the above behavior of storing the data in the leaf. MyISAM indexes, conversely, simply index the column and store a pointer to the data on disk. Agreed, wholeheartedly...databases are much more expensive that web servers...they require higher paid admins, better storage, more RAM/CPU...so fiscally speaking, it doesn't make sense to use them for something as mundane as image serving. However, it's not impossible, and in some cases, is needed (what the easiest way to securely store documents without having to encrypt each one individually? Dump them into an encrypted table).

makes no difference... function mysqli_conn() { $host = "localhost"; $user = "xxxxxx"; $pass = "xxxxxx"; $db = "dev"; return new mysqli($host, $user, $pass, $db); } function query($sql, $db_connection) { return $db_connection->query($sql); } $database = mysqli_conn(); $result = query("SELECT * FROM tablename", $database);

I'm not disagreeing that ZO is necessary (the server's got to know how to read the "guarded" code), but ZG isn't free like ZO is...to some people that's a big deal.

MySQL administrator will tell you the size of the index on the table if you want to be sure. Additionally, if you want to ensure the index is in memory, you can create a second key buffer and assign that table to it specifically. See here: http://dev.mysql.com/doc/refman/5.0/en/myisam-key-cache.html

I think you mean Zend Guard.

Assuming you are using Unix, change the sendmail_path or mail.force_extra_parameters variable(s) in php.ini to silently include a bcc

I don't have a windows machine to test it on, but you will probably have to escape the newline characters in the CSV that don't denote a new row of cells... "line 1", "data 1", "this is a \\ndescription\\non multiple lines" "line 2", .........

There are some example my.cnf files posted to the MySQL forge: http://forge.mysql.com/tools/tool.php?id=138 http://forge.mysql.com/tools/tool.php?id=137 The suggestion was made by Brian Moon here: http://brian.moonspot.net/2008/05/06/example-mycnf-files/ to post conf files for public consumtion.

Why do you set them back to the defaults first? As bluejay said, just issue the second update query and be done with it.

http://dev.mysql.com/doc/refman/5.0/en/server-options.html#option_mysqld_character-set-server

How big is your MyISAM buffer? Is it big enough to fix the fulltext index in memory? If not, consider creating a buffer specifically for that index (assuming that the table and search speed is that vital to operations). I think you have two options otherwise...use MySQL6's Falcon engine, which has a new (better!) fulltext index, or use an external fulltext index, such as Lucene or Sphinx. The limiting factor is probably MyISAM's fulltext index itself, since the table is fairly large and I can only assume that a large part of that data is in the description (which is indexed, thus creating very large indexes).

Header errors == http://www.phpfreaks.com/forums/index.php/topic,37442.0.html

http://www.php.net/image.setup

That only checks to see if it exists (or is boolean false if it's of that datatype). As stated by Stephen, it does not check to see if it is an array, or if it has any elements.

How would it use memory (I'm assuming you mean RAM)? Unless you are indexing a blob...which is pointless (and I'm not sure it's possible). They are going to use HDD space regardless of where they are stored. Again, how? It may increase the amount of time it takes the query results to move across the network from the DB server to the web server, but the query times would not be impacted. The exception to this may be if you issue a query with a WHERE clause on an unindexed field and MySQL has to do a full table scan, which would cause it to have to read all the data off the disk. The easier part is a matter of opinion...some people prefer to just backup the database and not have to worry about a huge file system. The headers part is true...when you have the image stored in the DB you have to have a seperate php script to query the database for the image data, then issue image headers and stream the data to the browser. That can be done regardless of where the image is stored. Where to store the images is a matter of opinion primarily. There have been many many arguments between people about which is better. I, personally, use the file system. Database's generally have expensive storage...where I work the Apache servers have 10k SATA drives, the DB servers have 15k SCSI drives...and depending on what else the database is doing, you may not want it to have to devote CPU cycles to querying and sending images...it's much more difficult (generally speaking) to add additional computing power to a DB (horizontal scaling is one of the few options), however it's very easy to stand-up a new Apache server to server static images.

Security wise, there is probably no harm done. However, it's generally considered bad practice to pollute the global name space (at least as much as you can consider it a name space in php...). Why not just return the mysqli object from your function? function mysqli_conn() { $host = "localhost"; $user = "xxxxxx"; $pass = "xxxxxx"; $db = "dev"; return new mysqli($host, $user, $pass, $db); } function query($sql, $db_connection) { return mysqli_query($sql, $db_connection); } $database = mysqli_conn(); $result = query("SELECT * FROM tablename", $database);