Jump to content

Recommended Posts

Is this the right code to count the number of members and display them?

 

	<table style="width: 100%" cellspacing="0" cellpadding="0">
<tr><td class="proinfo_h">Amount of members</td></tr>
<tr><td class="proinfo">
<?php

include("config_recipes.php");

// Retrieve data from database 
$sql="SELECT * count(User_id) as usercount FROM User_infoT";
$result=mysql_query($sql);
?>	
<? echo ['usercount']; ?>
</td></tr>
<tr><td class="proinfo_h">Amount of complaints</td></tr>
<tr><td class="proinfo">1234</td></tr>
<tr><td class="proinfo_h">Amount In my Inbox</td></tr>
<tr><td class="proinfo">1234</td></tr>
</table>
<br />

 

Cheers in advance

Link to comment
https://forums.phpfreaks.com/topic/146147-mysql-counting-the-number-of-members/
Share on other sites

<?php

   include("config_recipes.php");
                  
   // Retrieve data from database 
   $sql = "SELECT count(User_id) as usercount FROM User_infoT";
   $result = mysql_query($sql);

   $row = mysql_fetch_assoc($result);

   echo $row['usercount'];
?>

mysql_fetch_array returns two sets of arrays. A numerical array, eg $row[0], $row[1] etc and an associative array eg $row['field1'], $row['field2'] etc.

 

mysql_fetch_assoc just returns an associative array

 

Very interesting, thanks for the explanation.

 

So I suppose if most of the time I am calling my fields like so:

 

$row['name']

 

It would make sense and probably even from a resource standpoint(although would I really notice) to use:

 

mysql_fetch_assoc

 

If I never use $row[0], then I should probably never use the mysql_fetch_array function....

(assuming that $row[0] is $row['name'])

 

time to revise all my code!!!

 

 

You can limit the mysql_fetch_array to only return the assoc if you prefer.

 

array mysql_fetch_array  ( resource $result  [, int $result_type= MYSQL_BOTH  ] )

 

The 2nd parameter is type (which to return). MYSQL_NUM will return an indexed array only, MYSQL_ASSOC will return an associative array.

 

As for me, I tend to stick with just using the mysql_fetch_assoc as it saves less time typing. Just thought you might want to know that.

 

As for me, I tend to stick with just using the assoc as it saves less time typing. Just thought you might want to know that.

 

Agreed. Why go out of your way to add extra parameters when assoc will just do the job.

 

Glad I found this board because eventhough it's not PHP related, I still learned something for MYSQL.

 

I've also ALWAYS been using "@" to suppress any possible warnings with all my mysql syntax and as I found out,

the "@" makes the code very slow....so now I am in the process of removing the suppressions...

 

I thought it was GOOD coding practice to do that...oh well....

 

Agreed. Why go out of your way to add extra parameters when assoc will just do the job.

 

It does have it's uses. Let's say you want to create a mysql class where you want to use 1 function to fetch a query but have 2 functions that access that to say row or assoc (essentially this is most likely what mysql_fetch_assoc and mysql_fetch_row do). You could have each function call this 1 common function (without repetitious code) and that can use those to determine what to pull. IE:

 

<?php
function commonFetch($result, $type=MYSQL_ASSOC) {
     return mysql_fetch_array($result, $type);
}

function fetchAssoc($result) {
    return commonFetch($result);
}

function fetchRow($result) {
    return commonFetch($result, MYSQL_NUM);
}

function fetchBoth($result) {
    return commonFetch($result, MYSQL_BOTH);
}
?>

 

Something like that (it is a real basic example, but you get the point).

 

As far as @ definitely is not good practice. Remove any and all, it is better to just set display_errors to 0 on production servers, on development servers you want to see you errors so you can fix them. Doing the display_errors method, you can easily turn off or on the errors vs having to remove all the @'s to see your errors.

Agreed. Why go out of your way to add extra parameters when assoc will just do the job.

 

It does have it's uses. Let's say you want to create a mysql class where you want to use 1 function to fetch a query but have 2 functions that access that to say row or assoc (essentially this is most likely what mysql_fetch_assoc and mysql_fetch_row do). You could have each function call this 1 common function (without repetitious code) and that can use those to determine what to pull. IE:

 

<?php
function commonFetch($result, $type=MYSQL_ASSOC) {
     return mysql_fetch_array($result, $type);
}

function fetchAssoc($result) {
    return commonFetch($result);
}

function fetchRow($result) {
    return commonFetch($result, MYSQL_NUM);
}

function fetchBoth($result) {
    return commonFetch($result, MYSQL_BOTH);
}
?>

 

Something like that (it is a real basic example, but you get the point).

 

As far as @ definitely is not good practice. Remove any and all, it is better to just set display_errors to 0 on production servers, on development servers you want to see you errors so you can fix them. Doing the display_errors method, you can easily turn off or on the errors vs having to remove all the @'s to see your errors.

 

Thanks dude! Much appreciated. I am going to save your example for future use.....

 

Didn't know about "display_errors" either so I will have to look at that. Sounds perfect since I am taking out the "@" so I definitley don't want any warnings to show up...

 

 

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.