gizmola

Great. There are numerous ways to calculate the age. If you want to simplify your query a bit you can use this as well: SELECT *, FLOOR(DATEDIFF(CURRENT_DATE, STR_TO_DATE(CONCAT(year, '-', month, '-', day), '%Y-%c-%e'))/365.25) as age FROM member

My god man, OPTIMIZATION!!!! If he can't shave .0000 off that .0000 I don't know if the interweb will survive.

Did you read the blog article?

I meant to say: STR_TO_DATE()

Yes, you can manufacture a mysql date using TO_DATE()

Why would you use 3 seperate columns when you can use a single DATE column? Furthermore, if you do use a date column you can utilize built-in mysql functions to calculate age. See http://www.gizmola.com/blog/archives/107-Calculate-a-persons-age-in-a-MySQL-query.html

What rows would match WHERE cat_position > ($edit_cat_position) AND cat_position (some number > 0) AND also have a cat_position I think what you're trying to do here is very conrfusing, and will be prone to bounds issues, as you aren't checking for values less than 1. Inevitably you're going to shuffle all the values down to negatives, or if that is not possible with an unsigned column, then everything shuffling to 0. I think you'd be better off with an ordering routine that takes the result set of categories and numbers them rather than trying to produce a set of if-then-else conditions and queriies. In other words, unless you can produce something that is idempotent, you are guaranteed to have issues with the way you are approaching this.

The way your function works, your input array needs to be adjusted to this: $data = array('id'=>'nav', 'menu' => array ('menu1' =>'home', 'menu2' =>'create_post', 'menu3' =>'contact', 'menu4' =>'about'), );

Let's look at the 2nd query in your first condition: $update_query2 = "Update category set cat_position=cat_position-1 where cat_position > {$edit_cat_position} AND cat_position If you only get into this when $cat_position == 0, then that statement is never going to update any rows, is it?

You could write a function to do this. The basics would be: - BEGIN TRANSACTION -SELECT FOR UPDATE ... criteria ... ORDER BY sort_column -Have intialize counter variable to 1 -Foreach through result set. -- Compare counter variable to sort_column and if != update sort_column of row Only caveat is that you need a database engine that support transactions. Assuming mysql, this means your table needs to be innodb. If you omit the select for update, you could still write the function, but you could encounter a concurrency issue if 2 people were adding rows at roughly the same moment.

I think it's fairly obvious that if the result set is empty, trying to move the result set pointer, is not something you should attempt.

I'm not sure what you are asking here. mysql_num_rows returns the number of rows in a result set.

Avoiding session fixation is handled by this: session.use_cookies = 1 session.use_only_cookies = 1 You have a mispelling in your post, but I don't know if that is just a typo. Check it to be sure. As for session hijacking... well if you are not securing your connection then the data being transmitted is sniffable, and the session can be hijacked. Regenerating a session id by itself does nothing. Instead, the philosophy behind session regeneration is that, anytime you are going to allow someone to escalate their level of privilege, you are going to prompt them for authentication again. You then regenerate the session id, which in essence should orphan the session hijacker back at the old, unescalated level, until they once again hijack your session!

Xyph: When I wrote that I had a feeling you'd call me on it. However in practice people typically don't use isset() in that way, although I agree with your point, that PHP null can cause a lot of confusion, and should be avoided.

Haha, well not what I was talking about, but sure, that oddball setting still wouldn't allow for what he was orginally concerned with -- having 2 different multirow inserts running near simultaneously, resulting in the interleaving of key values. One would complete and get its range, and the other would get the next range. Still, we count on you to come up with this mysql minutiae fenway. Don't ever change man!

One of the big benefits of a class is that the class can contain variables as well as methods. In terms of evolution, OOP is a relative addon to procedural programming in a lot of cases -- c and c++ being one example. Originally procedural/function based languages had the ability to make structs or records. What turned them into objects was the addition of methods, so usually people who come to oop from that direction are already comfortable with the idea of storing a bunch of related data in a variable. PHP arrays are a good starting point. It seems the main thing you really want to remind yourself, is that class variables are there for you to stitch together your methods. Starting with setters/getters is a typical approach. It seems you were already pondering this question when you started: "I want a getNumrow() method. How do I implement that?" I just filled in an approach that works in this scenario. Since the value of num_rows is intrinsically tied to a SELECT query, it makes sense for that variable to be set at the time you execute a query. Since it's an internal detail, there is no real value to making the variable itself public. You need a variable to store the result of the mysql_num_rows() call, so you need a class variable. Hopefully this approach will help you solve similar problems as you expand the database class.

Sliders are clientside animals. Assuming the slider works fine with 5 images, it is reasonable to assume that the limitation is built into the slider itself. You'd need to look at the client slider code, which I assume is in javascript (although it could also be a flash movie for all we know). Most of these widgets these days are built on top of jquery. I'd suggest you look there first.

Fredundant: I would suggest you put your login check into a single function that you include and use in all your pages. This will eliminate the possibility that a variable typo or some other logic error causes a variation. It will also help you pinpoint what to look for and what not to look for, as PFMaBiSmAd suggested. Last but not least, it's part of the DRY philosophy that all good programmers try and follow.

That is exactly what php sessions already do.

Based on my understanding of your reply, if you are just trying to do a series of columns that go into a traditional user profile, then you are doing exactly what just about everyone else does, so I see no issue with that. Even though you could be a purist and get some flexibility out of the approach, it is absolutely more complicated, not to mention a lot tougher on the database to fully normalize out the profile attributes. I would typically allow those to be null just as you have, purely for pragmatic reasons.

Anything having to do with dates would be better if you were using a php date variable or datetime object. They provide functions that will let you take a "month/day" and turn those easily into regular dates or datetimes. Then you can do range calculations which work. You might also want to think about making the feature generic, and storing a table that schedules banners. An easy/flexible way to handle that would be: From, To, Banner Then you need only create a generic banner script that determines the current date, checks to see if that date falls between any of the date ranges in the table (as suggested by requinix) and displays the appropriate banner, or falls through to some other banner. The only thing you are left to have to decide upon is the storage format (flat file/database/nosql/hardcoded array). If you wanted to opt for the array then something like this would work well: // holiday banner schedule $holidaybanner = array(); $holidaybanner[] = array('name' => '4th of July', 'fromMonth' => 7, 'fromDay' => 2, 'toMonth' => 7, 'toDay' => 4, 'banner' => '/path/to/independence.png'); $holidaybanner[] = array('name' => 'Christmas', 'fromMonth' => 12, 'fromDay' => 23, 'toMonth' => 12, 'toDay' => 30, 'banner' => '/path/to/christmas.png'); Of course the problem with this is that certain holidays do not fall on the same dates, but you could engineer in some additional sophistication, and allow for actual date ranges for specific years. New years is kind of tricky as well, but that is the fun of programming.

There's a number of different ways to address your requirement. Here's one: class DB { private $_numrows = 0; // rest of your class omitted function select($table, $rows="*", $cond="") { $this->_numrows = 0; $query = "SELECT ".$rows." FROM ".$table." "; if ($cond != "") { $query .= "WHERE".$cond; } $result = mysql_query($query); if ($result) $this->_numrows = mysql_num_rows($result); return $result; } function num_rows() { return $this->_numrows; } }

Debbie, It's your choice as a designer whether or not you want to support null. As long as you understand the ramifications of that decision. I have some rules of thumb I go by, but it's good to keep in mind that the use of null can produce some odd behavior, and the guy who invented relational databases (Dr. Ted Codd) recommended that null not be used. Having read through this thread, I'm not sure I understand the use case enough to offer an opinion either way. If you're saying that you have a "question/answer" structure, and you're storing all the answers in one table, then that is not the proper structure anyways. What ends up being most important, in terms of null is how you will be querying, and if queries will include the column in question. If you ever need to have rows returned with NULL values in them, they will not be returned without doing an "IS NULL", so for that reason many people opt to have default values. Again it entirely depends on you and what you want to do, but I assure you there is no hard and fast rule to follow -- only someone's recommendation. In defense of Xyph, one irrefutable proof in the realm of database design, is that as databases get large, every byte counts, and the smaller tables == better performance and scalability. So watching bytes is a very good thing. Last but not least, the concept of null in php has nothing at all to do with database nulls. When you're dealing with strings, in php, a "null" string is the same thing as an empty string. As for netbeans debugger, the choice of the debugger to not show variables that are null might be a by-product of the debugging api itself, as well as the php garbage collector. PHP garbage collects any variables that it determines are no longer needed, so it's possible that they are simply doing what they have to do. This is the nature of php, where all debuggers are inherently required to make remote calls to the server process, and only have available to them what the api provides.

We would need to see your entire class. Do you have a class variable that stores the result? I can't help but point out that you're out of step with the current recommended approach, in building a db class on top of the mysql api, when there is mysqli or pdo available, which both support bind variables.

I'm a fan of themeforest as well.